Hi, Ray.
Martin, Ray wrote:
> 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
Just so I'm very clear on what you mean -- You constructed an app client
jar and deployed it?
I just reran my very simple test in which I bundled a JAR into an app
client JAR, and the client cannot find the contents of the JAR. In
contrast, when I bundle the app client into an EAR and bundle the extra
JAR into the EAR, the client can correctly access the extra JAR's contents.
I do not know why your client is able to access pastry.jar in your
example unless it is available in some other way. One way to do this is
to define the APPCPATH environment variable before using the appclient
script to launch the client. (There is no equivalent for Java Web Start
launches, basically because Java Web Start's philosophy is to make no
assumptions about the environment on the client system to which the app
is downloaded.)
> 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?
I'm afraid I can't tell from here.
>
> 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?
Yes, that's right.
>
> 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...
Can you explain what you mean by "strange results?" Errors in server.log?
When you bundle JARs into an EAR like that, the app client container
adds those JARs to the class path automatically. You don't need to do
anything with the browser other than use the normal URL to launch the
client. (To find out what URL to use to launch a client using Java Web
Start - whether it is a stand-alone app client or part of an EAR - is to
look in the server.log file just after you deploy the app. You will
find a log message reporting the "context-root" to use. See this blog
entry <
http://blogs.sun.com/quinn/entry/launch_that_app_client> - search
for the heading *What's the URL for launching an app client? - * for
more information.)
- Tim
>
> -----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]
>> Sent: Monday, September 18, 2006 11:49 PM
>> To: 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]
>>> Sent: Monday, September 18, 2006 3:16 PM
>>> To: 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]
>>>> Sent: Monday, September 18, 2006 1:44 PM
>>>> To: 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]
>>>>> Sent: Wednesday, September 13, 2006 6:17 PM
>>>>> To: '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]
>>>>> Sent: Wednesday, September 13, 2006 6:16 PM
>>>>> To: 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]
>>>>>> *Sent:* Wednesday, September 13, 2006 4:19 PM
>>>>>> *To:* 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
>>>>>> For additional commands, e-mail: users-help_at_glassfish.dev.java.net
>>>>>>
>>>>>>
>>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: users-unsubscribe_at_glassfish.dev.java.net
>>>>> For additional commands, e-mail: users-help_at_glassfish.dev.java.net
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: users-unsubscribe_at_glassfish.dev.java.net
>>>>> For additional commands, e-mail: users-help_at_glassfish.dev.java.net
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: users-unsubscribe_at_glassfish.dev.java.net
>>>>> For additional commands, e-mail: users-help_at_glassfish.dev.java.net
>>>>>
>>>>>
>>>>>
>>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe_at_glassfish.dev.java.net
>>>> For additional commands, e-mail: users-help_at_glassfish.dev.java.net
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe_at_glassfish.dev.java.net
>>>> For additional commands, e-mail: users-help_at_glassfish.dev.java.net
>>>>
>>>>
>>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe_at_glassfish.dev.java.net
>>> For additional commands, e-mail: users-help_at_glassfish.dev.java.net
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe_at_glassfish.dev.java.net
>>> For additional commands, e-mail: users-help_at_glassfish.dev.java.net
>>>
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe_at_glassfish.dev.java.net
>> For additional commands, e-mail: users-help_at_glassfish.dev.java.net
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe_at_glassfish.dev.java.net
>> For additional commands, e-mail: users-help_at_glassfish.dev.java.net
>>
>>
>