users@glassfish.java.net

RE: AppClient/JWS/Derby/Security problems

From: Martin, Ray <armart3_at_tycho.ncsc.mil>
Date: Mon, 25 Sep 2006 18:13:19 -0400

Hello Mr Quinn,
 
I am reading your comments and trying to figure out how to accomplish the
creation of the proper EAR file.
 
But, a quick question first. I was under the impression that any J2SE
application could be deployed to Glassfish as an "App Client Modules". So,
I created a J2SE app and deployed to Glassfish knowing that my app did not
use many of the services that are most likely available to "App Client
Modules", but eventually I wish to gear up to the point of using the
security features and possibly some session bean features.
 
My J2SE app requires third party jar files such as pastry.jar for
communication. I set the ant script to include pastry.jar for the app. The
app is deployed to Glassfish. The app runs and communications occur -
pastry.jar is functioning
 
I go back to the drawing board for a bit and add persistence to the J2SE
app. This time I set the ant script to also include derby.jar. The app is
deployed to Glassfish. The app runs, communications still occurs, but
persistence fails.
 
My 'quick question' is - what is the difference between pastry.jar and
derby.jar in this situation?
 
To follow your comments below, I assume that when an EAR file is created, it
is then deployed to Glassfish as an "Enterprise Applications". Is that
correct?
 
I have not yet figured out to do step 1 and 2 - for example, I didn't get
Netbeans to consistently provide a lib directory in my enterprise app.
 
I have lots of jar files in my J2SE app (KART), but when I add KART to the
J2EE app in Netbeans, clean and build - I am getting all kinds of strange
results when deploying to Glassfish. In addition, I have no idea what to
set the URL of the browser to get JWS to load KART from the deployed
"Enterprise Applications". I am doing searches for how these types of
things are to be accomplished - ain't havin' a whole lotta luck...

-----Original Message-----
From: Timothy.Quinn_at_Sun.COM [mailto:Timothy.Quinn_at_Sun.COM]
Sent: Sunday, September 24, 2006 9:43 AM
To: users_at_glassfish.dev.java.net
Subject: Re: AppClient/JWS/Derby/Security problems


Hi, again, Ray.

I was reading back through this thread, and I have an idea about what's
causing the problem.

I noticed in one of your posts that you said you are packaging your client
as a stand-alone client, and this may be the key. As an experiment, can you
please try creating an EAR that contains your app client as a submodule and
the derby.jar as a library JAR? You can add JARs as libraries to EARs in
GlassFish in several ways.

1. Place the JAR into the EAR's lib/ directory.
2. Place the JAR into some other directory within the EAR and set the
deployment descriptor's library-directory element to that directory.
3. Place the JAR at the top-level of the EAR.

Technique 3 works only for GlassFish and is there for backward compatibility
with past releases of Sun's app server product. I would suggest that you
use 1 or 2 instead because the Java EE 5 spec prescribes them so they will
be portable.

There is no similar mechanism for bundling library JARs into stand-alone app
clients. The spec does not require any and GlassFish does not provide any.


Bundling the app client into an EAR, deploying the EAR, and running the
generated app client JAR works for situations like this because the spec
requires that JARs bundled as libraries in the EAR be made available to all
submodules, including app clients, in the same EAR. To provide for this,
GlassFish bundles the library JAR into the generated app client JAR that it
creates during deployment. So when you download the generated app client
JAR for a client inside an EAR - either using the asadmin deploy ...
--retrieve <local-path> option, the asadmin get-client-stubs command, or the
Java Web Start feature - GlassFish also includes any library JARs packaged
with the EAR.

I hope this makes sense and lets you get past the current roadblock.

- Tim

Martin, Ray wrote:

Sir,

no particular reason for using EmbeddedDriver. did some searches to find the

best way to go - couldn't find anything useful - tossed a coin - ended up

with EmbeddedDriver.



i don't mind the requirement to place derby.jar into JRE's lib/ext

directory. you pointed out that ClientDriver can be used without the

requirement to put derby.jar into the JRE directory - i haven't tried that

yet. thanx for all the good advice. i really appreciate it.



somewhere (i am looking back thru this thread) it was stated that there is

another way, aside from using persistence.xml. can anyone point me to some

reading on the subject? i want my substrate to handle the database

connection, then each dynamic addon provides the data access layer (Entities

and methods of communicating to those Entities) that it requires - this does

not play well with peristence.xml.



any thoughts on how to get my app running in appclient/JWS? EntityManager is

still misbehaving.







-----Original Message-----

From: Sanjeeb.Sahoo_at_Sun.COM <mailto:Sanjeeb.Sahoo_at_Sun.COM> [
mailto:Sanjeeb.Sahoo_at_Sun.COM <mailto:Sanjeeb.Sahoo_at_Sun.COM> ]

Sent: Monday, September 18, 2006 11:49 PM

To: users_at_glassfish.dev.java.net <mailto:users_at_glassfish.dev.java.net>

Subject: Re: AppClient/JWS/Derby/Security problems





Any particular reason for using org.apache.derby.jdbc.EmbeddedDriver as

opposed to org.apache.derby.jdbc.ClientDriver? There will probably be a

difference in performance, but is that the reason? If you use

ClientDriver, then you don't have to place derby.jar in jre/lib/ext as

that driver(derbyclient.jar) is in set in CLASSPATH (see

$GF_HOME/bin/appclient script).



Thanks,

Sahoo



Martin, Ray wrote:

  

i am duly embarrassed



org.apache.derby.jdbc.EmbeddedDriver is in derby.jar



i am using persistence.xml, which has url/usr/pwd



i place derby.jar into JRE's lib/ext (as i was originally told to do) and

appclient works GREAT - no error.



i was definitely in the Twilight Zone - sorry.



-----Original Message-----

From: Marina.Vatkina_at_Sun.COM <mailto:Marina.Vatkina_at_Sun.COM> [
mailto:Marina.Vatkina_at_Sun.COM <mailto:Marina.Vatkina_at_Sun.COM> ]

Sent: Monday, September 18, 2006 3:16 PM

To: users_at_glassfish.dev.java.net <mailto:users_at_glassfish.dev.java.net>

Subject: Re: AppClient/JWS/Derby/Security problems





Ray,



Can you send us a stack trace (with all nested parts available in the

    

log)?

  

But this statement surprises me: "driver is in toplink-essentials.jar" -

there is no database driver in that jar.



Also, do you look up a database by jndi name, or provide url/usr/pwd as

toplink... properties?



thanks,

-marina



Martin, Ray wrote On 09/18/06 11:28,:

  

    

i tried - it didn't like me - SOS (that last word would be stuff - yea,

that's it - Same Old Stuff)



the driver is in toplink-essentials.jar - which i copied into JRE's

    

      

lib/ext

  

    

like you said.



running appclient with my app (KART) results in the "No suitable driver"

error.





i then tested KART outside of appclient - it too failed with "No suitable

driver".



i removed toplink-essentials.jar from JRE's lib/ext and KART would run

    

      

stand

  

    

alone (but still would not run using appclient). i have never

      

experienced

  

anything like this one. by taking toplink-essentials.jar out of JRE's

lib/ext, my app would run, but putting toplink-essentials into JRE's

    

      

lib/ext

  

    

causes the app to fail with "No suitable driver". ooohhhh boy.



so, i tried a second app (DrawingAddon) just to make sure i was not in

      

the

  

Twilight Zone. same thing - the app fails with toplink-essentials.jar

placed into JRE's lib/ext directory and runs ggggreat when JRE's lib/ext

does not contain toplink-essentials.jar. okay - this is starting to make

    

      

me

  

    

feel like a crazy person - what in the world am i doing wrong?







-----Original Message-----

From: Sanjeeb.Sahoo_at_Sun.COM <mailto:Sanjeeb.Sahoo_at_Sun.COM> [
mailto:Sanjeeb.Sahoo_at_Sun.COM <mailto:Sanjeeb.Sahoo_at_Sun.COM> ]

Sent: Monday, September 18, 2006 1:44 PM

To: users_at_glassfish.dev.java.net <mailto:users_at_glassfish.dev.java.net>

Subject: Re: AppClient/JWS/Derby/Security problems





Put the JDBC drivers in $JAVA_HOME/jre/lib/ext and try.



Thanks,

Sahoo

Martin, Ray wrote:



    

      

here is a snippet of Main.java



        ...

        public class Main {

33 //_at_PersistenceUnit(unitName="SVG_drawings");

34 private static EntityManagerFactory emf;



            private EntityManager em;



            pubic Main() {

                ...



48 emf =

Persistence.createEntityManagerFactory("SVG_drawings");

49 em = emf.createEntityManager();



                ...

        }



1) if i use line 33 and remove line 48 - i get the error:

org/osgi/framework/BundleActivator



2) use line 48 and 49 - i get the error: "No suitable driver"



3) use line 48 and remove 49 - JWS occurs and the app stands up (but, of

course, not useful because there is no EntityManager



How can i get past #2 above?

i know you said "...the driver is not in the classpath..." - what am i

supposed to do about that?



How does appclient 'see' Persistence?



i include derby.jar, pastry.jar, xmlpull_1_1_3_4a.jar, and

xpp3-1.1.3.4d_b2.jar in my application jar, which is KART.jar. KART.jar

      

        

is



    

      

deployed to Glassfish as an AppClient Module.



i know that these jars can be 'seen' because PASTRY runs, therefore, the

pastry.jar is visible.



i have not included javaee.jar - so, i do not understand how Persistence

      

        

is



    

      

'seen'.



just one more little bit of help, please.







-----Original Message-----

From: Martin, Ray [ mailto:armart3_at_tycho.ncsc.mil
<mailto:armart3_at_tycho.ncsc.mil> ]

Sent: Wednesday, September 13, 2006 6:17 PM

To: ' users_at_glassfish.dev.java.net <mailto:users_at_glassfish.dev.java.net> '

Subject: RE: AppClient/JWS/Derby/Security problems





i put derby.jar into KART.jar. derby.jar is not included in any addon

      

        

jar.



    

      

is including derby.jar into the KART.jar a bad thing? this runs nicely

outside of appclient.



-----Original Message-----

From: Marina.Vatkina_at_Sun.COM <mailto:Marina.Vatkina_at_Sun.COM> [
mailto:Marina.Vatkina_at_Sun.COM <mailto:Marina.Vatkina_at_Sun.COM> ]

Sent: Wednesday, September 13, 2006 6:16 PM

To: users_at_glassfish.dev.java.net <mailto:users_at_glassfish.dev.java.net>

Subject: Re: AppClient/JWS/Derby/Security problems





You can have EMF anywhere in the code where you can do a lookup

if you want to use a container-managed EMF. Now, if you use app-

managed EMF, you can create it by yourself via

Persistence.createEntityManagerFactory("...") as you would

do in a Java SE environment.



If you would like to use injection to create it, the rules

of the main class apply.



The "No suitable" error means that the driver is not in the

classpath. Tim, how this can be checked?



thanks,

-marina



Martin, Ray wrote On 09/13/06 14:55,:

 



      

        

KART.jar is deployed to Glassfish as an AppClient Module. There is no

enterprise archive file relative to KART. When an AppClient Module is

deployed, there are two pages in the Web Admin Console. The first page

has a check box for Java Web Start enabled. I check that box.

Thereafter, the following URL in Firefox causes KART to stand up:

http//:gateway:8080/KART?prop=DBHome=/usr/local/dbHome



I also have a JSP available from an enterprise app deployed to

Glassfish. But, this is probably a 'don't care' relative to our

discussion - just wanted to make sure.



So what is the next step? Should I send something? test something?

your wish is my command...



I reviewed the stack trace below before hitting the send button and I

thought of something else that may be relevant.



There is a web app, Addons.war, that is deployed to Glassfish. In that

war file are simply three jar files - ChatAddon2.jar, DrawingAddon.jar,

and SecurityAuditor.jar



After JWS has launched KART, the substrate, a GUI is available - the

user can select a button, "VisitAddon Store". This button points to

          

the

  

URL of Addons.war in Glassfish. The resulting HTTP response is parsed

and the three jar files are shown in a Swing Listbox. The user can

select an addon one at a time.



If I select ChatAddon2 from several different computers (each from a

KART launched via JWS) then the chat GUI stands up and a chat session

can occur between the collaboration nodes of the structured overlay

network. This is working.



If I select the addon, SecurityAuditor, the GUI stands up - but, this

addon is immature and does not do much just yet (but, eventually, it

will need data persistence). This addon is working to its current

          

level

  

and does not crash.



If I select the addon, DrawingAddon, then the bold lines below occur -

and crash.



What is happening is that when the user selects an addon from the list,

KART asks that addon if it has a DataAccess layer. Both ChatEditor2

          

and

  

SecurityAuditor respond with a null signifying that they do not have a

DataAccess layer. DrawingAddon responds with the name of the class

          

that

  

is its DataAccess layer. KART then uses its AddonClassLoader to

retrieve the DataAccess class, in this case, DataAccessImpl, from

DrawingAddon.jar not from KART.jar. After DataAccessImpl has been

instantiated, KART passes emf (EntityManagerFactory). In the method

that DataAccessImpl receives emf, it then has the line: em =

emf.createEntityManager();



We discussed that EntityManagerFactory needed to be in the main class

          

of

  

KART. But, we did not discuss that EntityManager needed to be in the

main class of KART. But, I will go ahead and test passing

          

EntityManager

  

        

          

>from KART to the DataAccessImpl - just as easy to do - just did not

      

        

happen to do it that way.



Before sending the email, I moved: em = emf.createEntityManager(); -

          

the

  

main class of KART and re-tested. The error moved for both 'appclient

only' and appclient/JWS as can be seen in the attached traces.







I would like to have EntityManager and EntityManagerFactory in my

addon.DataAccessImpl class and not in kart.Main class. Also, I would

like to utilize persistence.xml from the addon jar not the KART jar.

PLEASE.



   -----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:* Wednesday, September 13, 2006 4:19 PM

   * To:* <To:*> users_at_glassfish.dev.java.net
<mailto:users_at_glassfish.dev.java.net>

   *Subject:* Re: AppClient/JWS/Derby/Security problems



   Hi, again, Ray.



   In the stack trace related to the permission problem launching via

   Java Web Start (in Thread-25 as excerpted below) I suspect the error

   occurs because, although the TopLink code itself has been granted

   elevated permissions and would be allowed to read the property, the

   SecurityManager will not permit it to do so unless all intervening

   methods in the call stack also have that permission. I suspect that

   the kart... classes are not being granted permissions (bolded in the

   stack trace).





   With that in mind - and if you have already described this earlier

   in the mail thread I apologize for asking again - can I ask how,

   physically, are the kart.* classes made available to the client?

   Are they packaged in the app client itself, or in a JAR within the

   containing EAR? The Java Web Start-aware app client container (ACC)

   should be making sure, within the Java Web Start security model,

   that adequate permissions are granted to the code downloaded in the

   app client JAR. If this is not happening then we need to find out

   

        

          

why.

 



      

        

   - Tim





   Exception in thread "Thread-25"

          

java.lang.ExceptionInInitializerError

  

       at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native

   Method)

       at



   

        

          

sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAcces

  

  

    

sorImpl.java:39)

 



      

        

       at



   

        

          

sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstruc

  

  

    

torAccessorImpl.java:27)

 



      

        

       at

        

          

java.lang.reflect.Constructor.newInstance(Constructor.java:494)



    

      

       at java.lang.Class.newInstance0(Class.java:350)

       at java.lang.Class.newInstance(Class.java:303)

   * at kart.Model.setDataAccessLayer(Model.java:326)

       at



   

        

          

kart.addon.loader.AddonClassLoader.loadAddon(AddonClassLoader.java:223)

 



      

        

       at



   

        

          

kart.addon.loader.AddonClassLoader.beginLoad(AddonClassLoader.java:264)

 



      

        

       at

   kart.addon.loader.AddonClassLoader.start(AddonClassLoader.java:256)

       at kart.Model.execAddon(Model.java:230)

       at kart.KARTgui$11$1.run(KARTgui.java:592)*

       at java.lang.Thread.run(Thread.java:595)

   Caused by: java.security.AccessControlException: access denied

   (java.util.PropertyPermission toplink.validation-only read)

       at



   

        

          

java.security.AccessControlContext.checkPermission(AccessControlContext.java

  

  

    

:264)

 



      

        

       at



   

        

          

java.security.AccessController.checkPermission(AccessController.java:427)

  

 



      

        

       at

   java.lang.SecurityManager.checkPermission(SecurityManager.java:532)

       at



   

        

          

java.lang.SecurityManager.checkPropertyAccess(SecurityManager.java:1285)

 



      

        

       at java.lang.System.getProperty(System.java:627)

       at



   

        

          

oracle.toplink.essentials.ejb.cmp3.EntityManagerFactoryProvider.getConfigPro

  

  

    

pertyAsStringLogDebug(EntityManagerFactoryProvider.java:295)

 



      

        

       at



   

        

          

oracle.toplink.essentials.internal.ejb.cmp3.EntityManagerSetupImpl.isValidat

  

  

    

ionOnly(EntityManagerSetupImpl.java:567)

 



      

        

       at



   

        

          

oracle.toplink.essentials.internal.ejb.cmp3.EntityManagerSetupImpl.shouldGet

  

  

    

SessionOnCreateFactory(EntityManagerSetupImpl.java:577)

 



      

        

       at



   

        

          

oracle.toplink.essentials.ejb.cmp3.EntityManagerFactoryProvider.createEntity

  

  

    

ManagerFactory(EntityManagerFactoryProvider.java:130)

 



      

        

       at



   

        

          

javax.persistence.Persistence.createEntityManagerFactory(Persistence.java:83

  

  

    

)

 



      

        

       at



   

        

          

javax.persistence.Persistence.createEntityManagerFactory(Persistence.java:60

  

  

    

)

 



      

        

       at

   draw.resources.dal.DataAccessImpl.<clinit>(DataAccessImpl.java:62)

       ... 13 more







          

------------------------------------------------------------------------

  

---------------------------------------------------------------------

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>



---------------------------------------------------------------------

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>



    

      

---------------------------------------------------------------------

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>



---------------------------------------------------------------------

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>