|
Replies:
9
-
Last Post:
Apr 25, 2007 5:04 PM
by: Tim Quinn
|
|
|
|
|
|
|
relationship between two applications
Posted:
Apr 23, 2007 11:43 AM
|
|
|
Hi,
I'm currently trying to deploy our application into glassfish (Sun Java System Application Server Platform Edition 9.0_01 (build b02-p01).
This application is running successfully in OracleAS, JBOSS4.x and SAP Netweaver. The application consists of a core-app and several dependent application which use this core (and classes contained in this core). OracleAS has a special parent-relationship for specifying this, Netweaver has a reference option allowin the same and JBOSS seems not to have a very strict class loader.
But I haven't managed so far to get one of the applications to access the core app in glassfish. Is there any way to specify this or to weaken the classloader to allow access to the core application?
kind regards,
Ingo
|
|
|
|
|
|
|
Re: relationship between two applications
Posted:
Apr 23, 2007 2:48 PM
in response to: irockel
|
|
|
glassfish@javadesktop.org wrote:
> Hi,
>
> I'm currently trying to deploy our application into glassfish (Sun Java System Application Server Platform Edition 9.0_01 (build b02-p01).
>
> This application is running successfully in OracleAS, JBOSS4.x and SAP Netweaver. The application consists of a core-app and several dependent application which use this core (and classes contained in this core). OracleAS has a special parent-relationship for specifying this, Netweaver has a reference option allowin the same and JBOSS seems not to have a very strict class loader.
>
> But I haven't managed so far to get one of the applications to access the core app in glassfish. Is there any way to specify this or to weaken the classloader to allow access to the core application?
>
I don't think we have a way to do this in GlassFish. And I think
it is better not to have such "facilities" because applications are
supposed to be sandboxes and they have their own class loader
hierarchy.
A hack would be to make the classes of the core application a part
of server platform by placing those classes in proper package structure
in a jar in <domain-dir>/lib/classes. But note that in that case the
classes in that core application are available to every application
deployed.
Do you have to do this, this way?
Kedar
> kind regards,
>
> Ingo
> [Message sent by forum member 'irockel' (irockel)]
>
> http://forums.java.net/jive/thread.jspa?messageID=213805
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
> For additional commands, e-mail: users-help@glassfish.dev.java.net
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
For additional commands, e-mail: users-help@glassfish.dev.java.net
|
|
|
|
|
|
|
|
|
Re: relationship between two applications
Posted:
Apr 23, 2007 7:34 PM
in response to: kedar
|
|
|
>
> glassfish@javadesktop.org wrote:
>
>> Hi,
>>
>> I'm currently trying to deploy our application into glassfish (Sun
>> Java System Application Server Platform Edition 9.0_01 (build b02-p01).
>> This application is running successfully in OracleAS, JBOSS4.x and
>> SAP Netweaver. The application consists of a core-app and several
>> dependent application which use this core (and classes contained in
>> this core). OracleAS has a special parent-relationship for specifying
>> this, Netweaver has a reference option allowin the same and JBOSS
>> seems not to have a very strict class loader.
>> But I haven't managed so far to get one of the applications to access
>> the core app in glassfish. Is there any way to specify this or to
>> weaken the classloader to allow access to the core application?
>
Since the core app and its dependent apps are related, you could bundle
them in an EAR file and
deploy them as such.
This would give the dependent apps access to the libs in the core app.
In other words, you would leverage a feature that has been
misinterpreted as a bug
in the past, see:
https://glassfish.dev.java.net/issues/show_bug.cgi?id=2830
("Libs in one war are "bleeding" into other web apps in the same ear")
Jan
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
For additional commands, e-mail: users-help@glassfish.dev.java.net
|
|
|
|
|
|
|
|
|
Re: relationship between two applications
Posted:
Apr 24, 2007 4:43 AM
in response to: Jan Luehe
|
|
|
Thanks for the hints. I don't want to do any hacks, the "reference" and "parent" tags in OracleAS and Sap-Netweaver are regular features. So I see, I need to always deploy the core and all sub-applications as sumo-ear in glassfish. I already did this successfully with my two apps. But now I have some strange spring-problem which I will continue in a new Thread
Thanx and kind regards,
Ingo
|
|
|
|
|
|
|
|
|
Re: relationship between two applications
Posted:
Apr 24, 2007 10:25 AM
in response to: irockel
|
|
|
glassfish@javadesktop.org wrote On 04/24/07 04:43 AM,:
>Thanks for the hints. I don't want to do any hacks, the "reference" and "parent" tags in OracleAS and Sap-Netweaver are regular features. So I see, I need to always deploy the core and all sub-applications as sumo-ear in glassfish. I already did this successfully with my two apps.
>
Great!
I've done some research to find out how you would designate one webapp
as the parent of another with Oracle's appserver. I found that you can
do this at the deployment command line, by specifying the -parent
option, or by using the "parent" attribute of the <application>
element in server.xml.
The closest feature that GlassFish offers in this respect is the --libraries
option of the "asadmin deploy" command, which allows you to specify a
list of
JAR files that will be made visible to the application being deployed.
In your case,
you would specify the JAR files of the parent webapp when deploying any
of its
"child" apps.
Still, the only *portable* solution I can see is to bundle the parent
and its dependent "child" webapps inside an EAR file, which you've
confirmed works for you.
Thanks,
Jan
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
For additional commands, e-mail: users-help@glassfish.dev.java.net
|
|
|
|
|
|
|
|
|
Re: relationship between two applications
Posted:
Apr 24, 2007 11:39 AM
in response to: Jan Luehe
|
|
|
Hi Jan,
> The closest feature that GlassFish offers in this respect is the
> --libraries
> option of the "asadmin deploy" command, which allows you to specify a
> list of
> JAR files that will be made visible to the application being deployed.
> In your case,
> you would specify the JAR files of the parent webapp when deploying
> any of its
> "child" apps.
>
You mean one should specify the jar files from within web-app that's
deployed
onto server? What would be the syntax of deploy command line?
> Still, the only *portable* solution I can see is to bundle the parent
> and its dependent "child" webapps inside an EAR file, which you've
> confirmed works for you.
>
I agree with this. I am not sure how classes bundled in one app (i.e.
well defined .ear files) be seen by other apps in a portable
manner. Bill -- do you know?
Kedar
> Thanks,
>
>
> Jan
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
> For additional commands, e-mail: users-help@glassfish.dev.java.net
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
For additional commands, e-mail: users-help@glassfish.dev.java.net
|
|
|
|
|
|
|
|
|
Re: relationship between two applications
Posted:
Apr 24, 2007 2:01 PM
in response to: kedar
|
|
|
Hi Kedar,
kedar wrote On 04/24/07 11:39 AM,:
> Hi Jan,
>
>> The closest feature that GlassFish offers in this respect is the
>> --libraries
>> option of the "asadmin deploy" command, which allows you to specify a
>> list of
>> JAR files that will be made visible to the application being
>> deployed. In your case,
>> you would specify the JAR files of the parent webapp when deploying
>> any of its
>> "child" apps.
>>
> You mean one should specify the jar files from within web-app that's
> deployed
> onto server? What would be the syntax of deploy command line?
I was thinking of referencing the parent webapp's JAR files as JAR URLs,
like this:
* jar:file*:/<path-to-parent-war>!/WEB-INF/lib/<name-of-jar>
<path-to-parent-war> would be the path to the parent webapp prior to its
deployment
(so that you don't need to know any GlassFish internals about the
location of the deployed
bits).
I haven't verified if "asadmin deploy --libraries xxx" supports the
above syntax.
If it doesn't, we should fix it.
Jan
>> Still, the only *portable* solution I can see is to bundle the parent
>> and its dependent "child" webapps inside an EAR file, which you've
>> confirmed works for you.
>>
> I agree with this. I am not sure how classes bundled in one app (i.e.
> well defined .ear files) be seen by other apps in a portable
> manner. Bill -- do you know?
>
>
> Kedar
>
>> Thanks,
>>
>>
>> Jan
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
>> For additional commands, e-mail: users-help@glassfish.dev.java.net
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
> For additional commands, e-mail: users-help@glassfish.dev.java.net
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
For additional commands, e-mail: users-help@glassfish.dev.java.net
|
|
|
|
|
|
|
|
|
Re: relationship between two applications
Posted:
Apr 25, 2007 2:33 PM
in response to: Jan Luehe
|
|
|
Jan Luehe wrote On 04/24/07 02:01 PM,:
> Hi Kedar,
>
> kedar wrote On 04/24/07 11:39 AM,:
>
>> Hi Jan,
>>
>>> The closest feature that GlassFish offers in this respect is the
>>> --libraries
>>> option of the "asadmin deploy" command, which allows you to specify
>>> a list of
>>> JAR files that will be made visible to the application being
>>> deployed. In your case,
>>> you would specify the JAR files of the parent webapp when deploying
>>> any of its
>>> "child" apps.
>>>
>> You mean one should specify the jar files from within web-app that's
>> deployed
>> onto server? What would be the syntax of deploy command line?
>
>
>
> I was thinking of referencing the parent webapp's JAR files as JAR URLs,
> like this:
>
> * jar:file*:/<path-to-parent-war>!/WEB-INF/lib/<name-of-jar>
>
> <path-to-parent-war> would be the path to the parent webapp prior to
> its deployment
> (so that you don't need to know any GlassFish internals about the
> location of the deployed
> bits).
>
> I haven't verified if "asadmin deploy --libraries xxx" supports the
> above syntax.
> If it doesn't, we should fix it.
I've filed this enhancement issue:
https://glassfish.dev.java.net/issues/show_bug.cgi?id=2917
(Add support for nested JAR files to <sun-web-app><class-loader>'s
extra-class-path attribute and to "asadmin deploy --libraries")
More generally, one should be able to list full URLs as the value of
the extra-class-path attribute in sun-web.xml or the --libraries argument
to "asadmin deploy". For backwards compatibility, any values that don't
start with a URL protocol identifier will be treated as file paths.
Couple of observations:
- After fixing the web container's classloader configuration logic to
no longer treat
jar:file:x1.war!/x2.jar
as a file path, but as a URL, the WebappClassLoader, which is a
subclass of URLClassLoader, still fails to load any classes from the
nested x2.jar.
I found that this is a known J2SE issue, see:
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4735639
("URLClassLoader does not work with jar: URLs")
which has this comment in its evaluation section:
It seems that with the advent of ear, rar, and war files from J2EE
such
nested JAR files are not uncommon, and it would be useful to be able
to load resources from them without having to extract individual
archive
members first.
This bug was filed back in 2002, so I'm not very confident this will
get fixed any time soon. I'll ping the responsible engineer for an
estimate.
Support for nested JAR files in GlassFish has a dependency on this bug
getting fixed.
- The extra-class-path attribute of the class-loader element in
sun-web.xml, as well as the --libraries argument to "asadmin deploy",
expect a list of JAR files separated by File.pathSeparatorChar, which is
equal to ':' on UNIX and will conflict with a URL's protocol separator,
which therefore will need to be escaped.
Jan
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
For additional commands, e-mail: users-help@glassfish.dev.java.net
|
|
|
|
|
|
|
|
|
Re: relationship between two applications
Posted:
Apr 25, 2007 5:04 PM
in response to: Jan Luehe
|
|
|
Jan's comments about nested JAR class loading hit close to home for me.
We have had a similar issue with app client support. To help support
persistence units in app clients - and also as a way to resolve some
other things - we had to alter the format of the generated app client
JAR file so that it contains nested JARs. The app client must have the
nested JARs in its class path, so the app client container must expand
the app client JAR into a temporary directory (which is marked for
delete-on-exit). The JARs in that resulting temp directory are no longer
nested so they can be added to a class loader's class path routinely.
A while ago I looked for ways of avoiding the expansion step to avoid
the performance penalty that the expansion imposes. Among a number of
Java SE forum threads were people noting that one could write a custom
class loader that knew how to work with nested JARs. But some of those
notes pointed out that performance in loading classes and resource from
the nested JARs would be quite bad. If I remember correctly, the index
of a regular JAR file can be read directly, but a nested JAR is
compressed and one poster claimed that the entire nested JAR would have
to be expanded to gain access to the index and whatever internal
addressing scheme is used in JARs to locate particular entries.
I never investigated these claims or details myself, so I cannot vouch
for the accuracy of this description. I'm just describing what I read.
And I say all this only to reinforce Jan's feeling that it may be quite
some time before we see any changes in Java SE along these lines. I
hope I'm wrong about that!
- Tim
Jan Luehe wrote:
>
>
> Jan Luehe wrote On 04/24/07 02:01 PM,:
>
>> Hi Kedar,
>>
>> kedar wrote On 04/24/07 11:39 AM,:
>>
>>> Hi Jan,
>>>
>>>> The closest feature that GlassFish offers in this respect is the
>>>> --libraries
>>>> option of the "asadmin deploy" command, which allows you to specify
>>>> a list of
>>>> JAR files that will be made visible to the application being
>>>> deployed. In your case,
>>>> you would specify the JAR files of the parent webapp when deploying
>>>> any of its
>>>> "child" apps.
>>>>
>>> You mean one should specify the jar files from within web-app that's
>>> deployed
>>> onto server? What would be the syntax of deploy command line?
>>
>>
>>
>> I was thinking of referencing the parent webapp's JAR files as JAR URLs,
>> like this:
>>
>> * jar:file*:/<path-to-parent-war>!/WEB-INF/lib/<name-of-jar>
>>
>> <path-to-parent-war> would be the path to the parent webapp prior to
>> its deployment
>> (so that you don't need to know any GlassFish internals about the
>> location of the deployed
>> bits).
>>
>> I haven't verified if "asadmin deploy --libraries xxx" supports the
>> above syntax.
>> If it doesn't, we should fix it.
>
>
>
> I've filed this enhancement issue:
>
> https://glassfish.dev.java.net/issues/show_bug.cgi?id=2917
> (Add support for nested JAR files to <sun-web-app><class-loader>'s
> extra-class-path attribute and to "asadmin deploy --libraries")
>
> More generally, one should be able to list full URLs as the value of
> the extra-class-path attribute in sun-web.xml or the --libraries argument
> to "asadmin deploy". For backwards compatibility, any values that don't
> start with a URL protocol identifier will be treated as file paths.
>
> Couple of observations:
>
> - After fixing the web container's classloader configuration logic to
> no longer treat
>
> jar:file:x1.war!/x2.jar
>
> as a file path, but as a URL, the WebappClassLoader, which is a
> subclass of URLClassLoader, still fails to load any classes from the
> nested x2.jar.
>
> I found that this is a known J2SE issue, see:
>
> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4735639
> ("URLClassLoader does not work with jar: URLs")
>
> which has this comment in its evaluation section:
>
> It seems that with the advent of ear, rar, and war files from
> J2EE such
> nested JAR files are not uncommon, and it would be useful to be able
> to load resources from them without having to extract individual
> archive
> members first.
>
> This bug was filed back in 2002, so I'm not very confident this will
> get fixed any time soon. I'll ping the responsible engineer for an
> estimate.
> Support for nested JAR files in GlassFish has a dependency on this bug
> getting fixed.
>
> - The extra-class-path attribute of the class-loader element in
> sun-web.xml, as well as the --libraries argument to "asadmin deploy",
> expect a list of JAR files separated by File.pathSeparatorChar, which is
> equal to ':' on UNIX and will conflict with a URL's protocol separator,
> which therefore will need to be escaped.
>
>
> Jan
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
> For additional commands, e-mail: users-help@glassfish.dev.java.net
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
For additional commands, e-mail: users-help@glassfish.dev.java.net
|
|
|
|
|
|
|
|
|
Re: relationship between two applications
Posted:
Apr 24, 2007 12:38 PM
in response to: Jan Luehe
|
|
|
These parent-relationship just is a convienence option. We use it to just deploy our core stand-alone and allow our customers to deploy own applications which use the core's api.
Btw. OracleAS still uses a own ClassLoader for each app and loads the jars of the core into the applications so there isn't a real shared class loader it just simulates this behaviour for the applications which use the parent flag.
As we use spring and no EJB our ears only consist of simple web applications, so deploying a big ear with all the wars in it just might do the trick.
regards,
Ingo
|
|
|
|
|
java.net RSS
