[RT] JMX inspired JAR Repository

[Berin Loritsch <bl...@apache.org>]

Anyhoo, inspired by the simplicity of the work that Leo has done with the
attributes, and wondering what the most generic way to work with JAR files
and still be productive, the answer came to me from the JMX specs for Advanced
Dynamic ClassLoading.  The specs as written take care of the hard stuff, which
is a good starting point.  If we combine this with the Attributes, then we
should have a winning combination.

The basic crux of the solution is to have JAR files loaded into a repository.
The classloading process follows the following logic:

1. If the class is not already loaded from this JAR, try to load it from the
    parent class loader. (same as always)

2. If the parent class loader can't find it, delegate to the repository.

3. The repository attempts to load the classes from each assembly (a classloader
    representing the individual JAR file), in order.

4. If the class is never found, throw a ClassNotFoundException.  If the class is
    found, return it.

Pretty simple, huh?

There is an addendum to that in the current spec where the class repository will
give up as soon as it encounters the requesting classloader.  The reason is to
avoid a potential deadlock in the classloader mechanism.  The specs outline the
precise conditions on which that would happen.

Now, this is a good start.  There are several features not present that make
sense when we start talking about a JAR repository.  We are all fully aware of
the implications of dependencies and how to sort a list of objects so that there
are no circular dependencies and the most needed objects are at the head of the
list.

Where is this information kept?  Traditionally in the Manifest.  Each JAR has
its own manifest, which can be reused.  To that end, we need to be able to load
and parse the manifest file so that we can get all the attributes for the JAR.
While we are at it, we can also grab a list of the entries found in
META-INF/services.  Both of these things can be done without altering the known
specs or inordinately affecting startup time.  If the library assembles the list
of services, then we don't have to have a particular file named "services.list"
that is part of the Fortress spec.  Also, if the manifest information is made
available generically we can support the Merlin way of doing things.

How does this sound?

-- 

"They that give up essential liberty to obtain a little temporary safety
  deserve neither liberty nor safety."
                 - Benjamin Franklin


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org

Re: [RT] JMX inspired JAR Repository

[hammett <ho...@cimcorp.com.br>]

----- Original Message -----
From: "Berin Loritsch" <bl...@apache.org>

> I am talking about inter-JAR dependencies.

Good. But the assembly metaphor is not represing a self contained unit ready
for deployment/execution, right?
I'm working in a project that an kind of assembly is necessary. So it
includes directions about itself in the manifest. Those information
represents:

- Which classes are Tasks (implement Task interface)
- Which external libs/jar it depends on (xerces, et all)
- Scripts that should be applied to database at deployment phase - among
other things

I'm thinking about maven (and centipede) way of obtain external
dependencies. Then we'll have a system without limitations for auto-update.

Now I realized that Avalon is not worring about this self-unit-capable
feature.


hammett


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org

Re: [RT] JMX inspired JAR Repository

[Berin Loritsch <bl...@apache.org>]

hammett wrote:

<snip/>

> 
> 
> Sounds simple. But when you talk about dependencies, which dependency you're
> talking about?
> 
> I could have a service named CodeGenerator that depends on ParserEngine
> service to be able to run. In other hand I could have a ParserEngine that
> uses Xerces to parse Xml files. Which level of dependency we are talking?

I am talking about inter-JAR dependencies.

For example, Merlin has a runtime dependency on Avalon Framework.  By providing
a way of declaring the inter-jar dependency, when the repository loads the
Merlin JAR, it will place it after the Avalon Framework JAR in its list of
assemblies.

Those types of dependencies.

Of course there will always be JAR files that don't specify dependency
information, and there is little we can do about it for the time being
other than respect the load order that they were added to the repository.
IOW, it would fall back to the JMX way of doing things.

-- 

"They that give up essential liberty to obtain a little temporary safety
  deserve neither liberty nor safety."
                 - Benjamin Franklin


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org

Re: [RT] JMX inspired JAR Repository

[hammett <ho...@cimcorp.com.br>]

----- Original Message -----
From: "Berin Loritsch" <bl...@apache.org>

> Where is this information kept?  Traditionally in the Manifest.  Each JAR
has
> its own manifest, which can be reused.  To that end, we need to be able to
load
> and parse the manifest file so that we can get all the attributes for the
JAR.
> While we are at it, we can also grab a list of the entries found in
> META-INF/services.  Both of these things can be done without altering the
known
> specs or inordinately affecting startup time.  If the library assembles
the list
> of services, then we don't have to have a particular file named
"services.list"
> that is part of the Fortress spec.  Also, if the manifest information is
made
> available generically we can support the Merlin way of doing things.
>
> How does this sound?

Sounds simple. But when you talk about dependencies, which dependency you're
talking about?

I could have a service named CodeGenerator that depends on ParserEngine
service to be able to run. In other hand I could have a ParserEngine that
uses Xerces to parse Xml files. Which level of dependency we are talking?


hammett


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org