Re: [jonas-team] Re: [enhydra] Moving XMLC from BCEL to ASM

["Slobodan Vujasinovic" <slobodan@xxxxxxxxxxxxx>]

Hi David,

Since JOnAS team is planning to use ASM (as I understood, in next JOnAS
release) version conflict is possible.

I suppose that they will load ASM through JOnAS 'Commons class loader'.
EAF (together with XMLC), till now, in Enhydra Enterprise is also loaded by
this class loader.
We did that by placing binaries (shared between applications) in JOnAS
'lib/ext' directory.

Now (in new JOnAS version), 'lib/ext' extension mechanism is deprecated and
we should place additional JARs directly in the classloader directory
(options are commons, apps and tools).
Logical choice would be to place EAF binaries (together with XMLC and ASM)
in 'lib/apps' directory to be loaded by 'Application class loader' - shared
between all deployed applications.  The application class loader is a
JOnAS-specific class loader that will load all application classes required
by the user applications.  This class loader has the commons class loader as
parent class loader.

By default, when class is to be loaded JOnAS behaves like this:
- first it is looked for in 'Commons class loader'
- then it is searched for in 'Application class loader'
- and after that comes 'Web class loader'

If a specific jar is needed for a web application (i.e., need to use a
version of a jar file which is different than a version loaded by JOnAS), we
can change the compliance of the web application classloader to the java 2
delegation model which can be done by using the jonas-web.xml file (jonas
deployment descriptor).

But, when this (additional) configuration is done class loading hierarchy
goes like this:
- first it is looked for in 'Web class loader'
- then it is searched for in 'Commons class loader'
- and after that (at last) comes 'Application class loader'

NOTE: maybe it goes 'Web class loader' -> 'Application class loader' ->
'Commons class loader' and 'Application class loader' is implemented that
way that first it looks in its parent class loader - I don't know. But in
practice 'Commons class loader' always comes before 'Application class
loader'.

That means that ASM if loaded by 'Commons class loader' will never be loaded
from our 'Application class loader' and JOnAS version will always be
applied.

If we place ASM together with EAF (XMLC) in directory which will be loaded
by 'Commons class loader' either we will override JOnAS's ASM or he will
override ours!

The problem can be easily resolved (I suppose) with EAF binary loaded by
'Web class loader' (binaries placed in WAR file) but that leads to EAF
binary redundancy (in case of multiple enhydra applications) - every
application will come with its own set of EAF (XMLC-ASM) jar files.

Regards,
     Slobodan Vujasinovic
Enhydra Development Team


----- Original Message -----
From: "David Li" <taweili@xxxxxxxxx>
To: <xmlc@xxxxxxxxxxxxx>
Cc: "jonas-team" <jonas-team@xxxxxxxxxxxxx>; <enhydra@xxxxxxxxxxxxx>
Sent: Thursday, January 27, 2005 8:34 PM
Subject: Re: [jonas-team] Re: [enhydra] Moving XMLC from BCEL to ASM


Hi  Slobodan,

   I think the problem should be less a concern with JOnAS if the
classloading of the servlet container are done per Servlet Spec.

Version 2.4, SRV 9.5 states:

The Web application classloader must load classes from the
WEB-INF/classes directory first, and then from library JARs in the
WEB-INF/lib directory.

 From 9.7.1 talking about container library loading:

The files placed within this directory must be available across all Web
applications. The location of this directory is container-specific.The
classloader the servlet container uses for loading these library files
must be the same for all Web applications within the same JVM. This
classloader instance must be some where in the chain of parent class
loaders of the Web application class loader.

If I read this correctly, if a ASM jar exists in WEB-INF/lib, it should
have precedence over the one used by the container. Sounds like there
shouldn't be problem using different version of ASM in XMLC (goes to
WEB-INF) and container's library.

However, XMLC is exposed in Enhydra as system wide service, this may be
a problem.

On Jan 27, 2005, at 6:36 PM, Gérard Vandome wrote:

>  Hello Slobodan,
>
>  I am not sure of the answer, so through this reply I post it also on
> jonas-team (thanks to jonas-team members to give more infos on the use
> of BCEL if needed, and when they have some time to investigate the
> way to move to ASM if this is feasible).
>
>  Please don't hesitate to send any message with any question related
> to jonas on the jonas-team mailing list (please subscribe to the
> jonas-team mailing list if not already done in order to avoid to be
> moderated).I think this will help us to work more together.
>
>
>  Slobodan Vujasinovic wrote:
> Hi,
>
> We, in Enhydra and Enhydra Enterprise, are not using BCEL explicitly,
> but
> some of our components (integrated tools) are (like XMLC)!
>
> JOnAS: Some Ant tasks in JOnAS use BCEL (building of JOnAS examples,
> recompilation of the Axis package from the source and I think that
> they have
> dependency in their 'GenericDeploymenTool')!
>
>
>
> Barracuda: BCEL is actually used, as I know, just through XMLC
> (deferred
> parsing)!
>
> Ant: Library dependencies (bcel.jar) - classfileset data type,
> JavaClassHelper used by the ClassConstants filter reader and
> optionally used
> by ejbjar for dependency determination.
>
> MX4J: BCELMBeanInvoker -  It uses the BCEL to generate the required
> bytecode
> on-the-fly.  MBeanInvoker that generates on-the-fly implementations to
> call
> standard MBeans directly, instead of using reflection.
>
>
> Therefore, the conclusion would be that we have no reason to oppose
> your
> decision to move (from BCEL) to ASM.
> To keep this Enhydra Components (JOnAS, Ant and MX4J) fully functional
> we
> will leave current BCEL version present in Enhydra.
> And, since we are not using ASM in Enhydra (jet) you don't need to
> have any
> concerns regarding version conflicts!
>
> Regards,
>     Slobodan Vujasinovic
> Enhydra Development Team
>
>
> ----- Original Message -----
> From: "David Li" <taweili@xxxxxxxxx>
> To: <xmlc@xxxxxxxxxxxxx>
> Cc: <enhydra@xxxxxxxxxxx>
> Sent: Wednesday, January 26, 2005 9:30 PM
> Subject: [enhydra] Moving XMLC from BCEL to ASM
>
>
>
> Hi,
>
>    I am planning on moving XMLC from BECL to ASM. I'd like to know if
> anyone has concern about this, especially the guys from Enhydra team.
> Are you using ASM for anything in Enhydra? I am trying to avoid a
> version and dependency conflict.
>
> David
>
>
>
>
>
> -----------------------------------------------------------------------
> -----
> ----
>
>
>
> --
> You receive this message as a subscriber of the enhydra@xxxxxxxxxxxxx
>
> mailing list.
>
> To unsubscribe: mailto:enhydra-unsubscribe@xxxxxxxxxxxxx
> For general help: mailto:sympa@xxxxxxxxxxxxx?subject=help
> ObjectWeb mailing lists service home page: http://www.objectweb.org/wws
>
>
>
>
>
>
> --
> You receive this message as a subscriber of the enhydra@xxxxxxxxxxxxx
> mailing list.
> To unsubscribe: mailto:enhydra-unsubscribe@xxxxxxxxxxxxx
> For general help: mailto:sympa@xxxxxxxxxxxxx?subject=help
> ObjectWeb mailing lists service home page: http://www.objectweb.org/wws
>
>
>
>
> --
> Gérard Vandôme                          JOnAS Project Manager
>  Gerard.Vandome@xxxxxxxxxxxxx             http://jonas.objectweb.org
> Take action against software patents    http://swpat.ffii.org
>
>
>
>
> --
> You receive this message as a subscriber of the
> jonas-team@xxxxxxxxxxxxx mailing list.
> To unsubscribe: mailto:jonas-team-unsubscribe@xxxxxxxxxxxxx
> For general help: mailto:sympa@xxxxxxxxxxxxx?subject=help
> ObjectWeb mailing lists service home page: http://www.objectweb.org/wws





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


>
> --
> You receive this message as a subscriber of the enhydra@xxxxxxxxxxxxx
mailing list.
> To unsubscribe: mailto:enhydra-unsubscribe@xxxxxxxxxxxxx
> For general help: mailto:sympa@xxxxxxxxxxxxx?subject=help
> ObjectWeb mailing lists service home page: http://www.objectweb.org/wws
>