I think you're most interested in how classpath works. AS7 uses a module
system. There's no traditional classpath as a list of directories/jars any
more. Instead there are modules with cross dependencies on other modules.
Classpath becomes like a tree branching out from each submodule and cross
folding back onto itself with cross-dependencies (that go out from any to
any module - so it's not really a tree, but a graph). Each module is
represented by one classloader. Class lookup always starts at one module,
looks locally at what that module provides, then if not found - tries
dependency modules - where each one repeats the lookup procedure. In effect
- each module has its own 'classpath'.
All gatein.ear/lib/*.jar have been moved to modules. Typically one .jar
becomes one module with a list of dependencies on other modules (like maven
artifact for example). But to simplify things for starters, I put many jars
into the main module that represents gatein libraries. Most can be found in
gatein/modules/org/gatein/lib/main. The plan is to more fine-grain these in
the future - exo-jcr could become it's own module, or exo-jcr-kernel,
exo-jcr-core ... could become its own module. Or these could be just
aggregation modules to provide acces to several finegrained modules at once
- each jar as its own module.
All the GateIn libs are under $JBOSS_HOME/standalone/gatein/modules which is
used as a secondary modules system root directory. This way all the GateIn
libs are nicely seperated from those that come out-of-the-box with AS7.
In the end visibility is established in such a way that no other changes to
GateIn libs were necessary except the mentioned WCI, and
exo.kernel.container.
I need to expand the README.txt with some of this info. Also AS7 support in
its initial form still needs some work and fine proofing ...
- m
On Tue, Oct 11, 2011 at 12:37 PM, Nicolas FILOTTO <
nicolas.filotto(a)exoplatform.com> wrote:
How do you deploy all the jar files of Gatein (aka kernel, core, ws,
jcr,
and gatein jars)? Let's say that we have a vanilla JBoss AS 7 instance, what
are the steps to deploy gatein successully
I still need to know the target version and the deadline
On Mon, Oct 10, 2011 at 10:16 PM, Marko Strukelj <marko.strukelj(a)gmail.com
> wrote:
>
> WCI changes introduce a jboss7 module which is only used if explicitly
> referenced in configuration - no impact on anything there. It also
> introduces a deadlock patch in wci-wci which adds an extra synchronized
> block. Without this patch a deadlock can occur (and often does occur on
> JBoss AS7) when shutting down the server. No impact on performance or memory
> usage.
>
>
> Kernel changes are limited to exo.kernel.container module where in two
> places there was a need to introduce the use of TCCL for classloading
> instead of using a local ClassLoader.
>
> The new classloading uses ‘TCCL first’ approach with fallback to the old
> behavior. The use of TCCL was necessary to allow GateIn services to properly
> startup in an environment of isolated classloaders.
>
> I added a method:
>
> org.exoplatform.container.util.ContainerUtil.class:
>
>
> public static Class loadClass(String type) throws ClassNotFoundException
> {
> ClassLoader tccl = Thread.currentThread().getContextClassLoader();
> ClassLoader localCl = ContainerUtil.class.getClassLoader();
> ClassLoader cl = tccl != null ? tccl : localCl;
> try
> {
> return cl.loadClass(type);
> }
> catch (ClassNotFoundException e)
> {
> if (cl == tccl)
> return localCl.loadClass(type);
>
> throw e;
> }
> }
>
> It is used in two places instead of Class.forName():
>
> - org/exoplatform/xml/object/XMLObject.java
> - org/exoplatform/container/jmx/MX4JComponentAdapter.java
>
>
>
> It’s possible to imagine a scenario where due to deployment archive
> packaging the same classes may be available through different .jars, .wars,
> .ears. In such a situation the new code may load the class from portlet
> application deployment archive, or portal extension deployment archive
> instead of gatein portal’s lib/*.jar (gatein.ear/lib on JBossAS5 / JBossAS6,
> $TOMCAT_HOME/lib on Tomcat).
>
>
> Actually by making it local loader first with TCCL fallback there would be
> no chance of any side effects. It may even be more appropriate as it
> prevents the accidental override of GateIn's classes due to packaging.
>
> So I'll change the method to:
>
>
> public static Class loadClass(String type) throws
> ClassNotFoundException
> {
> ClassLoader tccl = Thread.currentThread().getContextClassLoader();
> ClassLoader localCl = ContainerUtil.class.getClassLoader();
> try
> {
> return localCl.loadClass(type);
> }
> catch (ClassNotFoundException e)
> {
> if (tccl != null)
> return tccl.loadClass(type);
>
> throw e;
> }
> }
>
>
> I'll prepare a patch against exo.kernel.container trunk and attach it to
> the issue.
>
>
>
> On Mon, Oct 10, 2011 at 4:20 PM, Nicolas FILOTTO <
> nicolas.filotto(a)exoplatform.com> wrote:
>
>> Well, it depends on the expected fix version of this patch. Do you expect
>> it in eXo JCR 1.14.x or in the future version? and What would be the
>> deadline?
>>
>> Anyway I know that Marko is very good and has a good knowledge of the
>> kernel, however I still can't apply it blindly, I need to double check it to
>> ensure that we will have no regression with it, so for me it is a real task
>> that has to be planned. Thus I need your answers first to know when it can
>> be planned according to your needs and expectations and ours.
>>
>> NB: To be able to validate it, I will need a complete overview of what
>> has been done not only at kernel level but even at GateIn level. Is it
>> possible to describe a little bit all the patches that you proposed?
>>
>>
>> On Mon, Oct 10, 2011 at 1:16 PM, Boleslaw Dawidowicz <
>> boleslaw.dawidowicz(a)gmail.com> wrote:
>>
>>> Nicolas,
>>>
>>> Julien told me you will be decision person to accept such patch into the
>>> kernel. Marko can apply details about the context of those changes if
>>> needed.
>>>
>>> Bolek
>>>
>>>
>>> On Oct 6, 2011, at 8:01 PM, Marko Strukelj wrote:
>>>
>>> I had to do some classloading and logging changes for
>>> exo.kernel.container to work nicely on JBoss AS7.
>>>
>>> I'd like to get these changes from my sandbox gatein-as7 branch to
>>> exo.kernel.container trunk.
>>>
>>> Here's the diff (effectively against exo-jcr/kernel/tags/
>>> 2.3.0.GA/exo.kernel.container/src):
>>>
>>> svn diff -r 7504:7557
>>>
http://anonsvn.jboss.org/repos/gatein/sandbox/as7_support/branches/gatein...
>>>
>>> And here's the JIRA issue for it:
>>>
https://issues.jboss.org/browse/EXOJCR-1580
>>>
>>>
>>> - marko
>>> _______________________________________________
>>> gatein-dev mailing list
>>> gatein-dev(a)lists.jboss.org
>>>
https://lists.jboss.org/mailman/listinfo/gatein-dev
>>>
>>>
>>>
>>
>