classloading in 3.0

[Radim Kolar <hs...@sendmail.cz>]

I propose to make classloading in 3.0 entirely different. Give user 
aplication access to javax.* stuff and other required J2EE 6 apis and 
nothing else unless told otherwise by deployment descriptor.

If user includes springs in WAR then use them instead springs in 
geronimo (emulate parent last classloading). Because almost no apps are 
using J2EE 6 now, people can try G2.2 vs G3 if they have problems with 
classloading and they are not willing to write deployment descriptors.

Re: classloading in 3.0

[Radim Kolar <hs...@sendmail.cz>]

> What I'd actually like to see is that, instead of arbitrarily importing any particular set of classes, we run bnd on the application classes to determine the Import-Packages needed.
This method is not that bad. but you need to be sure import javax.* 
classes from app server not from included jars. For example grails apps 
ships with jta api and it caused problems in G 2.1 and G 2.2 if this api 
was loaded from war and not from app server.

Do you ignore packages already included in WAR and dont import them 
again? Because on 3.0 spring applications fails with NPE. they not 
initialized properly, most likely because springs from geronimo are used.

Exploring classes leads to very slow deploys.

Probably best long term solution is to switch app development from WAR 
to WAB and use something simple like eclipse virgo or karaf.

Re: classloading in 3.0

[Radim Kolar <hs...@sendmail.cz>]

Dne 10.11.2011 9:43, Ivan napsal(a):
> Guess that you mean that " You can repackage included components into 
> api and impl clasess" :-)
In OSGI there is equivalent of EARs, bundles inside can have cyclic 
dependences.
> Yes, in a ideal environment, those components should work in that way. 
> While the real world is so complex, you may find that jsf API and impl 
> are bundled in one jar file, as there maybe issues if divided them 
> into two bundles.
You can also import packages, not entire bundles. I dont know if osgi 
didnt import entire bundle anyway.

Re: classloading in 3.0

[Ivan <xh...@gmail.com>]

Guess that you mean that " You can repackage included components into api
and impl clasess" :-)
Yes, in a ideal environment, those components should work in that way.
While the real world is so complex, you may find that jsf API and impl are
bundled in one jar file, as there maybe issues if divided them into two
bundles.
Also, some 3rd components think that they could load classes with the
current context classloader, which is also the classloader of the deployed
application, If only spec APIs are imported, then bang ! That's why I say
that we need to check each 3rd component in Geronimo.

2011/11/10 Radim Kolar <hs...@sendmail.cz>

> Dne 8.11.2011 4:04, Ivan napsal(a):
>
>  Agree, but as we discussed in the past, we need to validate each
>> component one by one, to make the context classloader and resource
>> searching work.
>>
> You can not repackage included components into api and impl classes and
> then:
>
> A: API CLASSES
> B: IMPL
>
> U: USER APP
>
> B imports A, and U imports A
>



-- 
Ivan

Re: classloading in 3.0

[Radim Kolar <hs...@sendmail.cz>]

Dne 8.11.2011 4:04, Ivan napsal(a):
> Agree, but as we discussed in the past, we need to validate each 
> component one by one, to make the context classloader and resource 
> searching work.
You can not repackage included components into api and impl classes and 
then:

A: API CLASSES
B: IMPL

U: USER APP

B imports A, and U imports A

Re: classloading in 3.0

[Ivan <xh...@gmail.com>]

Agree, but as we discussed in the past, we need to validate each component
one by one, to make the context classloader and resource searching work.

2011/11/8 David Jencks <da...@yahoo.com>

>
> On Nov 7, 2011, at 5:03 AM, Kevan Miller wrote:
>
> >
> > On Nov 4, 2011, at 3:42 PM, David Jencks wrote:
> >
> >>
> >> On Nov 4, 2011, at 12:07 PM, Radim Kolar wrote:
> >>
> >>> I propose to make classloading in 3.0 entirely different. Give user
> aplication access to javax.* stuff and other required J2EE 6 apis and
> nothing else unless told otherwise by deployment descriptor.
> >>
> >> I'd like this too.  How do you propose to get this to work?  I've been
> working on several ideas that end up requiring major modifications to
> geronimo that I haven't been able to get to work.  Any ideas you might have
> would be great to see.
> >
> > Agreed. We'd discussed this previously, IIRC.
> >
> >>
> >> What I'd actually like to see is that, instead of arbitrarily importing
> any particular set of classes, we run bnd on the application classes to
> determine the Import-Packages needed.
> >
> > Are you saying you don't want to arbitrarily import spec api classes? Or
> are you suggesting we use BND to dynamically determine Import-Packages for
> non-spec classes? I assume the latter would be filtering (not importing)
> packages that are already included in the application archive?
>
> I imagine we can figure out how to configure bnd to not generate
> import-package for anything in the application.  It might be a little
> different from the maven-bundle-plugin since maven will be missing.
>
> >
> > Automatically importing a default set of spec api classes would be a
> good first step, IMO. And require explicit Import-Packages -- at least
> initially.
>
> I'd like there to be no default import-packages and all imports, spec or
> anything else, be determined by byte-code analysis by bnd.  If you need
> more (e.g. dynamic class loading) you can specify bnd instructions.  I
> don't think this will really work until we get everything in the server to
> work as a bundle extender, but maybe I'm being too pessimistic.
>
> david jencks
>
> >
> > --kevan
>
>


-- 
Ivan

Re: classloading in 3.0

[David Jencks <da...@yahoo.com>]

On Nov 7, 2011, at 5:03 AM, Kevan Miller wrote:

> 
> On Nov 4, 2011, at 3:42 PM, David Jencks wrote:
> 
>> 
>> On Nov 4, 2011, at 12:07 PM, Radim Kolar wrote:
>> 
>>> I propose to make classloading in 3.0 entirely different. Give user aplication access to javax.* stuff and other required J2EE 6 apis and nothing else unless told otherwise by deployment descriptor.
>> 
>> I'd like this too.  How do you propose to get this to work?  I've been working on several ideas that end up requiring major modifications to geronimo that I haven't been able to get to work.  Any ideas you might have would be great to see.
> 
> Agreed. We'd discussed this previously, IIRC.
> 
>> 
>> What I'd actually like to see is that, instead of arbitrarily importing any particular set of classes, we run bnd on the application classes to determine the Import-Packages needed.
> 
> Are you saying you don't want to arbitrarily import spec api classes? Or are you suggesting we use BND to dynamically determine Import-Packages for non-spec classes? I assume the latter would be filtering (not importing) packages that are already included in the application archive?

I imagine we can figure out how to configure bnd to not generate import-package for anything in the application.  It might be a little different from the maven-bundle-plugin since maven will be missing.

> 
> Automatically importing a default set of spec api classes would be a good first step, IMO. And require explicit Import-Packages -- at least initially.

I'd like there to be no default import-packages and all imports, spec or anything else, be determined by byte-code analysis by bnd.  If you need more (e.g. dynamic class loading) you can specify bnd instructions.  I don't think this will really work until we get everything in the server to work as a bundle extender, but maybe I'm being too pessimistic.

david jencks

> 
> --kevan

Re: classloading in 3.0

[Kevan Miller <ke...@gmail.com>]

On Nov 4, 2011, at 3:42 PM, David Jencks wrote:

> 
> On Nov 4, 2011, at 12:07 PM, Radim Kolar wrote:
> 
>> I propose to make classloading in 3.0 entirely different. Give user aplication access to javax.* stuff and other required J2EE 6 apis and nothing else unless told otherwise by deployment descriptor.
> 
> I'd like this too.  How do you propose to get this to work?  I've been working on several ideas that end up requiring major modifications to geronimo that I haven't been able to get to work.  Any ideas you might have would be great to see.

Agreed. We'd discussed this previously, IIRC.

> 
> What I'd actually like to see is that, instead of arbitrarily importing any particular set of classes, we run bnd on the application classes to determine the Import-Packages needed.

Are you saying you don't want to arbitrarily import spec api classes? Or are you suggesting we use BND to dynamically determine Import-Packages for non-spec classes? I assume the latter would be filtering (not importing) packages that are already included in the application archive?

Automatically importing a default set of spec api classes would be a good first step, IMO. And require explicit Import-Packages -- at least initially.

--kevan

Re: classloading in 3.0

[David Jencks <da...@yahoo.com>]

On Nov 4, 2011, at 12:07 PM, Radim Kolar wrote:

> I propose to make classloading in 3.0 entirely different. Give user aplication access to javax.* stuff and other required J2EE 6 apis and nothing else unless told otherwise by deployment descriptor.

I'd like this too.  How do you propose to get this to work?  I've been working on several ideas that end up requiring major modifications to geronimo that I haven't been able to get to work.  Any ideas you might have would be great to see.

What I'd actually like to see is that, instead of arbitrarily importing any particular set of classes, we run bnd on the application classes to determine the Import-Packages needed.

thanks
david jencks

> 
> If user includes springs in WAR then use them instead springs in geronimo (emulate parent last classloading). Because almost no apps are using J2EE 6 now, people can try G2.2 vs G3 if they have problems with classloading and they are not willing to write deployment descriptors.