i already had trace turned on. i was just too dumb to look at the traces.
it turns out that in Scenario 3 when using:
@PersistenceUnit(unitName="SVG_drawings")
private static EntityManagerFactory emf;
then, both 'appclient only' and appclient/JWS spew out the same error:
NoClassDefFound: org/osgi/framework/BundleActivator
but, the trace has a whole lot more good things to say before spewing the
error. appclient/JWS is trying real hard to do the right thing - it gets up
a PUD, it has a hold of persistence.xml, its doin' real good, then suddenly
com.sun.enterprise.appclient.MainWithModuleSupport <init> croaks on an
error.
by the way, Scenario 3 uses EJBClassLoader, while Scenario 2 uses
sun.misc.Launcher$AppClassLoader
-----Original Message-----
From: Timothy.Quinn_at_Sun.COM [mailto:Timothy.Quinn_at_Sun.COM]
Sent: Friday, September 08, 2006 5:47 PM
To: users_at_glassfish.dev.java.net
Subject: Re: AppClient/JWS/Derby/Security problems
Hi, again, Ray.
One quick note, with perhaps more thoughts to follow later...
You can have Java Web Start capture the console window output in a trace
file as well so you can review what happened at a "more leisurely" pace.
Please see this post; the section near the end of the entry gives the
details for turning on tracing:
http://blogs.sun.com/quinn/entry/launch_that_app_client
<
http://blogs.sun.com/quinn/entry/launch_that_app_client>
- Tim
Martin, Ray wrote:
Excellent post, Sir,
I have read it twice and i am gonna read it again more slowly - there is a
lot of info for me to digest and i want to make sure that i understand.
Also, i will be reading the 'signing link' that you provided.
Scenario 1
From my first read, i believe some of my tests are inappropriate. For
example, after creating a jar file from a project, i did not deploy that jar
file to Glassfish. Instead i did the following at the command line:
/usr/local/glassfish/glassfish/bin/appclient -client
/usr/local/provision/DrawingAddon/dist/DrawingAddon.jar
Can you confirm that this is an inappropriate test (even if the test does
not need all the good features of Glassfish like signing and stuff)?
Scenario 2
Project is KART. KART.jar is created and deployed to Glassfish as an
Appclient with JWS enabled. And - DrawingAddon is deployed to Glassfish as
a web application. There is a web page with a link for starting KART, but i
stopped using that link until i get the correct combination and syntax for
the URL. i type the URL into the browser as follows:
http://gateway:8080/KART?prop=DBHome=/usr/local/dbHome
<
http://gateway:8080/KART?prop=DBHome=/usr/local/dbHome>
The error is: javax.persistence.PersistenceException: No Persistence
provider for EntityManager named SVG_drawings
and the stack trace points to my application code, the following line:
private static EntityManagerFactory emf =
Persistence.createEntityManagerFactory("SVG_drawings");
As pointed out earlier in this thread, the following annotation can only be
used in the main class, so i am using the above line.
When running 'appclient only' in this scenario as follows:
/usr/local/glassfish/glassfish/bin/appclient -client
/usr/local/glassfish/glassfish/domains/domain1/generated/xml/j2ee-modules/KA
RT/KARTClient.jar
the error is:
at
oracle.toplink.essentials.exceptions.ValidationException.currentLoaderNotVal
id(ValidationException.java:1865)
followed by a stack trace
Scenario 3
This scenario is a new one - from the things that i have learned from the
experts thus far.
In KART's main class, i add the following:
@PersistenceUnit(unitName="SVG_drawings")
private static EntityEntityManagerFactory emf;
Note: i am not yet using emf in any way - just getting it created.
i build the project and deploy the resulting jar file to Glassfish. i put
the same URL as scenario 2 into the browser - looks as follows:
http://gateway:8080/KART?prop=DBHome=/usr/local/dbHome
<
http://gateway:8080/KART?prop=DBHome=/usr/local/dbHome> - the Java
console pops up after JWS has done its thing - and then - KA_WHAM - the
console falls flat on its face before i can get to see the error report.
This is the first that this has happened - oh boy...
While KART has been deployed to Glassfish in this manner, i give 'appclient
only' a try as follows:
/usr/local/glassfish/glassfish/bin/appclient -client
/usr/local/glassfish/glassfish/domains/domain1/generated/xml/j2ee-modules/KA
RT/KARTClient.jar
This kicks a brand new error:
Warning: ACC03: Application threw an exception.
java.lang.NoClassDefFound: org/osgi/framework/BundleActivator
followed by a huge stack trace (sorry - its on another network)
i never heard of that BundleActivator guy before...
-----Original Message-----
From: Timothy.Quinn_at_Sun.COM <mailto:Timothy.Quinn_at_Sun.COM> [
mailto:Timothy.Quinn_at_Sun.COM <mailto:Timothy.Quinn_at_Sun.COM> ]
Sent: Friday, September 08, 2006 4:00 PM
To: users_at_glassfish.dev.java.net <mailto:users_at_glassfish.dev.java.net>
Subject: Re: AppClient/JWS/Derby/Security problems
Martin, Ray wrote:
In 'appclient only' and appclient/JWS, i am running into errors before
getting to appreciate whether or not DBHome has been effective.
If one should not pass parameters to let appclient/JWS know where the user
policy is located, what is the appropriate mechanism to set security
parameters? Where is the policy that appclient/JWS is using? is it
available to me, an end-user, so that i can define application security
parameters?
A bit of background, for those on the mailing list who might be new to app
clients on GlassFish... When you deploy an app client JAR or an EAR that
contains at least one app client, GlassFish creates a generated app client
JAR. This file contains contents of the developer's app client plus possibly
some additional files. This is the JAR file that the deploy --retrieve
option and the separate get-client-stubs asadmin commands download.
For Java Web Start launches of an app client, GlassFish automatically signs
the generated app client JAR if the administrator has not signed it manually
after GlassFish has generated it. (See
http://blogs.sun.com/quinn/entry/signing_the_glassfish_java_web
<
http://blogs.sun.com/quinn/entry/signing_the_glassfish_java_web> for some
more about this.) Either way, the downloaded app client JAR is signed. The
JNLP that GlassFish generates requests that the app client code be granted
full permissions. The Java Web Start code on the client system detects
this, makes sure the JAR has been signed, and then displays information
about the cert that was used to sign the JAR and asks the user whether he or
she wants to trust that code. Assuming the user agrees, the download
proceeds and Java Web Start grants full permissions to that code. We
adopted this approach so that users can make the conscious choice about
whether to trust downloaded code or not. The level of granularity with
which permissions are granted is a characteristic of Java Web Start.
GlassFish just uses that mechanism.
The end result is that the client code should have all permissions...if the
user has agreed to trust the code.
I know you've described in this thread several issues you've encountered in
a variety of experiments. Can you reiterate which error you are
encountering now? Is it still the null emf?
- Tim
-----Original Message-----
From: Timothy.Quinn_at_Sun.COM <mailto:Timothy.Quinn_at_Sun.COM> [
mailto:Timothy.Quinn_at_Sun.COM <mailto:Timothy.Quinn_at_Sun.COM> ]
Sent: Friday, September 08, 2006 2:47 PM
To: users_at_glassfish.dev.java.net <mailto:users_at_glassfish.dev.java.net>
Subject: Re: AppClient/JWS/Derby/Security problems
Hi, again, Ray.
Note that the Java Web Start-launched app client container no longer
honors the policy setting option you have been specifying on the URL.
This was determined to be a security risk because code from an arbitrary
source could try to grant itself elevated permissions this way.
As for setting DBHome... You should be able to add to the query string
in the URL something like this
prop=DBHome=correctValue
separated using an ampersand ('&') from any other argument or property
settings in the query string. This blog entry
http://blogs.sun.com/quinn/entry/command_line_arguments_and_properties
<
http://blogs.sun.com/quinn/entry/command_line_arguments_and_properties>
has more details.
Could you try that and see if it gets you farther?
- Tim
Martin, Ray wrote:
Because i am not able to get appclient/JWS to 'play nice' with my security
policy, i commented out code that causes a SecurityManager to be required.
i took out all the getClassLoader calls - they were just for learning
experience. i commented out all setProperty methods - now i cannot set
DBHome - not a good thing.
So, now i am back to seeing how well appclient/JWS will run my
application.
It keeps coughing up the error, javax.persistence.PersistenceException: No
Persistence provider for EntityManager named SVG_drawings. This raises
the
question of why appclient/JWS cannot see META-INF/persistence.xml in my
application jar file - while on the other hand, 'appclient only' fails on
the same line (the creation of EntityManagerFactory), but the error report
is totally different - 'appclient only' kicks out the
currentLoaderNotValid
error.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe_at_glassfish.dev.java.net
<mailto:users-unsubscribe_at_glassfish.dev.java.net>
For additional commands, e-mail: users-help_at_glassfish.dev.java.net
<mailto:users-help_at_glassfish.dev.java.net>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe_at_glassfish.dev.java.net
<mailto:users-unsubscribe_at_glassfish.dev.java.net>
For additional commands, e-mail: users-help_at_glassfish.dev.java.net
<mailto:users-help_at_glassfish.dev.java.net>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe_at_glassfish.dev.java.net
<mailto:users-unsubscribe_at_glassfish.dev.java.net>
For additional commands, e-mail: users-help_at_glassfish.dev.java.net
<mailto:users-help_at_glassfish.dev.java.net>