Return-Path: Delivered-To: apmail-geronimo-dev-archive@www.apache.org Received: (qmail 68609 invoked from network); 23 Nov 2009 08:37:13 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3) by minotaur.apache.org with SMTP; 23 Nov 2009 08:37:13 -0000 Received: (qmail 87644 invoked by uid 500); 23 Nov 2009 08:37:12 -0000 Delivered-To: apmail-geronimo-dev-archive@geronimo.apache.org Received: (qmail 87545 invoked by uid 500); 23 Nov 2009 08:37:12 -0000 Mailing-List: contact dev-help@geronimo.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: List-Post: Reply-To: dev@geronimo.apache.org List-Id: Delivered-To: mailing list dev@geronimo.apache.org Received: (qmail 87537 invoked by uid 99); 23 Nov 2009 08:37:12 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 23 Nov 2009 08:37:12 +0000 X-ASF-Spam-Status: No, hits=-2.6 required=5.0 tests=AWL,BAYES_00,HTML_MESSAGE,UNPARSEABLE_RELAY X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: local policy) Received: from [98.136.44.56] (HELO smtp101.prem.mail.sp1.yahoo.com) (98.136.44.56) by apache.org (qpsmtpd/0.29) with SMTP; Mon, 23 Nov 2009 08:37:09 +0000 Received: (qmail 18322 invoked from network); 23 Nov 2009 08:36:49 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Received:X-Yahoo-SMTP:X-YMail-OSG:X-Yahoo-Newman-Property:Message-Id:From:To:In-Reply-To:Content-Type:Mime-Version:Subject:Date:References:X-Mailer; b=VvMrXH/VjJDLVN8zVITtn6nCyWV/DbF9PXpf1RQ4MzdSMunmSkdZC636YWsuOLLixfrRylMLXZlO9W0BwErVS3/6CwgxCkTz95M77XP/Z4kIEj57e/Gae0lkjeEqddSATCkjeCM/DOi4yypn93NREQBs0RZETOt3h3wslH6PW+8= ; Received: from 076-076-148-215.pdx.net (david_jencks@76.76.148.215 with plain) by smtp101.prem.mail.sp1.yahoo.com with SMTP; 23 Nov 2009 00:36:48 -0800 PST X-Yahoo-SMTP: .9oIUzyswBANsYgUm_5uPui0skTnzGJXJQ-- X-YMail-OSG: E5GTdWgVM1mLyx_USbR3JXJLXCPkyxf.PRM2QVaxQtmgqQ2fTrqNLvOYkL4zUu1xMLdDigTDI8_Qd1BrdXGQHfaT41wLlAflIaQQgJcldFMIDQ.9J3oWnR4NWgtG4beWil_2Y2vBSvTIsvY_YlwyJ_W16ghI9DCrpNWIe58MDb5TpAoZbA7l33lORQZKyqPnvF37p3qzmfrPDOPZU4.tnWWWdaBkfCi7Sc272N.C4g_qkdmG7.D9C3z547Nj_eRDRJ_5Ek.rps56lmk0t6Yz5IRbVkEBTnwMoyMf3vdEDLFfWgFejf8oIZKK1PKSEXm_t6Rn X-Yahoo-Newman-Property: ymail-3 Message-Id: <989FC52D-61AD-4EB7-AD44-9D09D929640E@yahoo.com> From: David Jencks To: dev@geronimo.apache.org In-Reply-To: Content-Type: multipart/alternative; boundary=Apple-Mail-12--662150602 Mime-Version: 1.0 (Apple Message framework v936) Subject: Re: ee apps in trunk Date: Mon, 23 Nov 2009 00:36:47 -0800 References: <739150D7-F444-482C-B582-5FB4834EEBE4@yahoo.com> <45f744e40911221801g723384fco4983001caf24e5a1@mail.gmail.com> <0C6F3DCA-F02E-41BF-8900-DFD46A09F42F@yahoo.com> X-Mailer: Apple Mail (2.936) --Apple-Mail-12--662150602 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit On Nov 23, 2009, at 12:12 AM, Delos wrote: > My two cents: > > Seems EAR is a complicated case.I think "Fragment Bundle" in OSGI > may help. A fragment don't have its own classloader except that of > host bundle.If so, EAR may be a host bundle, while ejb jars and WARs > are all fragments. I'm not sure how that would help. We have no problem constructing a single bundle with everything from the ear inside it -- we already unpack ears to this format, we'd just need to add more entries to the bundle classpath for the wars. The problem is how to have several bundles each with its own classloader for the individual wars. I suspect we'll have to just set up more than one bundle from such an ear. thanks david jencks > > Thanks! > > 2009/11/23 David Jencks > > On Nov 22, 2009, at 6:01 PM, Ivan wrote: > >> For a EJB/WAR, I could see what Bundle-ClassPath contains. But for >> an EAR package, what does it contain, all the jar files in the >> libraries, ejb jars and web related classes ? I am just thinking >> what the classloader structure of an EE application, especially for >> an EAR application. In the classic environment, for an EAR contains >> libraries and webapplications, we usually create a parent >> classloader for the EAR, and create a classloader for WAR package. >> Then, in the OSGI environment, how should it be ? >> If only a bundle classloader is created and the bundle-classpath >> contains all the embedded jar files/classes, will it break the EE >> rules ? How about dividing the ear package into more than one >> bundle ? >> Thanks ! > > > There are two issues I know of: > > 1. osgi allows only one level of nesting of jars, whereas ee allows > 2 (jars inside rars and wars). This isn't really a problem for us > since we repackage the ear anyway so we can (continue to) unpack as > many nesting levels as we want (as we do now). > > 2. Currently wars are set up as semi-independent configurations. I > guess we will want to have them as additional bundles. I haven't > figured out a good plan for this yet. We've thought about deploying > ejb modules and rar modules as separate configurations also, perhaps > this will turn out to be an easy thing to do. > > Right now I'm concentrating on getting a single war or rar to > deploy.... then we can think more about ears. > > BTW at the moment I'm putting the osgi info into the Environment > object and generating the manifest from that. > > thanks > david jencks > >> >> >> 2009/11/21 David Jencks >> I've played with the welcome app servers a bit and found that the >> next significant problem is that we aren't setting the Bundle- >> ClassPath manifest header in our car bundles. This shouldn't be an >> obstacle for ejb jars, but is for anything else. >> >> My plan is to solve this as part of GERONIMO-4911 by storing all >> the manifest info in the ConfigurationData. Perhaps this can >> replace some of the info in the environment field, although that is >> also used to figure out which plugins need to be started before the >> current one. >> >> comments welcome... >> >> thanks >> david jencks >> >> >> >> >> -- >> Ivan > > > > > -- > Best Regards, > > Delos --Apple-Mail-12--662150602 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable
On Nov 23, 2009, = at 12:12 AM, Delos wrote:

My two = cents:

Seems EAR is a complicated case.I think "Fragment Bundle" = in OSGI may help. A fragment don't have its own classloader except that = of host bundle.If so, EAR may be a host bundle, while ejb jars and WARs = are all fragments.

I'm not sure how that = would help.  We have no problem constructing a single bundle with = everything from the ear inside it  -- we already unpack ears to = this format, we'd just need to add more entries to the bundle classpath = for the wars.  The problem is how to have several bundles each with = its own classloader for the individual wars.  I suspect we'll have = to just set up more than one bundle from such an = ear.

thanks
david = jencks


Thanks!

2009/11/23 David Jencks <david_jencks@yahoo.com>

On Nov 22, 2009, at 6:01 PM, = Ivan wrote:

For a EJB/WAR, I could = see what Bundle-ClassPath contains. But for an EAR package, what does it = contain, all the jar files in the libraries, ejb jars and web related = classes ? I am just thinking what the classloader structure of an EE = application, especially for an EAR application. In the classic = environment, for an EAR contains libraries and webapplications, we = usually create a parent classloader for the EAR, and create a = classloader for WAR package.  Then, in the OSGI environment, how = should it be ?
If only a bundle classloader is created and the = bundle-classpath contains all the embedded jar files/classes, will it = break the EE rules ? How about dividing the ear package into more than = one bundle ?
Thanks !
=


There are two issues I know = of:

1. osgi allows only one level of nesting of = jars, whereas ee allows 2 (jars inside rars and wars).  This isn't = really a problem for us since we repackage the ear anyway so we can = (continue to) unpack as many nesting levels as we want (as we do = now).

2. Currently wars are set up as = semi-independent configurations.  I guess we will want to have them = as additional bundles.  I haven't figured out a good plan for this = yet.  We've thought about deploying ejb modules and rar modules as = separate configurations also, perhaps this will turn out to be an easy = thing to do.

Right now I'm concentrating on = getting a single war or rar to deploy.... then we can think more about = ears.

BTW at the moment I'm putting the osgi = info into the Environment object and generating the manifest from = that.

thanks
david jencks

 

2009/11/21 David Jencks <david_jencks@yahoo.com>
I've= played with the welcome app servers a bit and found that the next = significant problem is that we aren't setting the Bundle-ClassPath = manifest header in our car bundles.  This shouldn't be an obstacle = for ejb jars, but is for anything else.

My plan is = to solve this as part of GERONIMO-4911 by storing all the = manifest info in the ConfigurationData.  Perhaps this can replace = some of the info in the environment field, although that is also used to = figure out which plugins need to be started before the current = one.

comments = welcome...

thanks
david = jencks




--
Ivan
=




-- =
Best Regards,

Delos

= --Apple-Mail-12--662150602--