ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Holger Engels <heng...@mercatis.de>
Subject Re: Some thoughts about ejbjar
Date Tue, 18 Sep 2001 06:24:27 GMT
On Mon, 17 Sep 2001, Conor MacNeill wrote:

> Holger Engels wrote:
>
> > there are some issues with the current implementation:
> >
> > 1) dependent classes aren't found
> >
> > 2) client jars aren't supported
> >
> > 3) different DeploymentTools cannot append to the _same_ jar. This means,
> > that it is not possible to generate a jar, that works on more than one
> > appserver (is this correct?)
> >
> > 4) the naming convention <component-name>-* is not applied to
> > manifest-files.
> >
> > 5) Adding new DeploymentTools requires changes to the EjbJar class
> >
> >
> > I'd propose the following:
> >
> > 1) use BCEL to discover _all_ dependent classes. The depend-task seems to
> > not find them all. I have written a visitor for BCEL, that does find them.
> > BCEL is LGPL - I think, we should use it rather than parsing class files
> > ourself - IMHO it's a cool mature framework.
>
>
> I'd be interested to have an example of where the depend code is not
> finding all the dependencies. I have no objection to using BCEL in
> principle although it seems BCEL could not be distributed with Ant, as
> it contains GPL code, according to their website

Imagine for example, a simple property of an entity bean with a custom
type. The interface contains two methods, that use this custom class in
their signature. Actually, the custom class does not appear as a class
constant in the constant pool. However, there is an utf8 constant with the
method signature, containing the class name. If you look at classes, it's
the same. Not all referenced classes appear in the constantpool as class
constants. Take this as an example:


public interface EchoService
{
    CustomBean echoBean(CustomBean input);
}

public class EchoServiceBean
    implements EchoService

    public CustomBean echoBean(CustomBean input) {
        return input;
    }
}

If you want to find the dependent CustomBean, you have to parse the
method_infos:

//
// JVM Spec
//

ClassFile {
        u4 magic;
        u2 minor_version;
        u2 major_version;
        u2 constant_pool_count;
        cp_info constant_pool[constant_pool_count-1];
        u2 access_flags;
        u2 this_class;
        u2 super_class;
        u2 interfaces_count;
        u2 interfaces[interfaces_count];
        u2 fields_count;
        field_info fields[fields_count];
        u2 methods_count;
        method_info methods[methods_count];
        u2 attributes_count;
        attribute_info attributes[attributes_count];
    }

method_info {
        u2 access_flags;
        u2 name_index;
        u2 descriptor_index;
        u2 attributes_count;
        attribute_info attributes[attributes_count];
    }


name_index is the index into the constant pool.


> "Note that there is the FindPattern class distributed together with the
> BCEL that uses the gnu.regexp package, which itself is protected by the
> GPL. Thus this part of the distribution can not be redistributed using a
> different license." Overall I'm not sure how they distribute an LGPL
> package containing GPL code.

Required is only a subset of the BCEL framework. Fortunately, this subset
does not depend on FindPattern and thus not on the gnu.regexp package.

>
> >
> > 2) find classes that depend on home / remote / pk classes. Add server
> > specific classes and stubs, if required (not for jboss).
> >
> > 3) allow destdir-attribute in ejbjar-tag. Pack one jar, that contains all
> > classes / files of DeploymentTools
>
>
> I'm not sure how easy this will be. My original vision was to allow one
> <ejbjar> task to generate separate jars for each appserver. I wonder if
> separate appserver jars may collide. If, in the end you are just
> combining the result jars of multiple tools, why not let the user do that.

I think, collisions are not a problem .. just log a warning message. The
user (developer!) should understand that.

>
> >
> > 4) just do it - fetch manifest-files from the directories, where the
> > deployment descriptors are found
>
>
> OK. I think manifest files are more important now than they used to be.
> As far as I can tell with weblogic, ejbc just obliterated it anyway.
> That has probably changed with 6.1, but I haven't tried that yet.
>

They are important, because ejb-jars do not offer another mechanism, to
include jars, like wars do.

>
> >
> > 5) use naming convention .. the problem is the xml-parser, that does not
> > allow tags without setter- / adder-correspondents, right?
>
>
> Not the parser as such. I did have a solution for this which was for the
> introspection helper to forward any requests for nested element creation
> to the task itself if the reflection based mechanisms failed. This would
> have allowed property file based config of the supported appservers or
> some similarly dynamic mechanism. It was vetoed by Peter.
>

Thats poor. I didn't look into the code. Does the introspection helper use
the return type of the create method or does it call the create method and
reflect on the returned object. If the latter was the case, we could use
dynamic proxies ... however, this would introduce changes to the xml
structure of the task.

>
> >
> >
> > Open issues:
> >
> > 1) there are dependant classes, that cannot be found at all.
> > Implementations of interfaces, that aren't explicitely used and
> > Resource-Files. 'includefiles' of filesets, that are discovered by the
> > same naming convention like deploymnet descriptors / manifests would help.
>
>
> Yes, using the naming convention is possible. I'm not sure how popular
> the naming convention is though :-)
>
>
> >
> > 2) finding dependant classes should be a feature of filesets.
>
>
> A special type of fileset, perhaps, but not of the plain vanilla
> fileset. When Craeg had mentioned the concept of a <dependset>, this is
> what I thought he was referring to as it was soemthing I had been
> contemplating. It may also be possible to add this to the jarring code
> and have the ejb tasks use that jarring code as the method for generic
> jar construction.
>

That's, what I thought of ..

> >
> > .. we end up doing a complete redesign of the ejbjar task ..
> >
>
> As long as it is backward compatible, it is not a problem. So, we should
> develop some unit tests first.Lets go in small steps rather than
> changing everything at once.


Attached is a replacement for the current checkAndAddInherited method of
the GenericDeploymentTool along with the visitor that traverses the bcel
tree. The file required_bcel_classes.txt lists all required classes of the
bcel framework (I determined them by using the Dependencies.java). The
code seems to work well. I've already tested it on linux and windows.

Yep,

Holger


Mime
View raw message