ant-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Donnie Hale" <don...@haleonline.net>
Subject RE: Adding/extending a manifest using <ejbjar>
Date Wed, 16 Jan 2002 02:20:53 GMT
Glad it worked out for you. One way you can check this yourself is to use
some code like the following:

        File clientFile = new File(clientJar);
        JarFile clientJarFile = new JarFile(clientFile);
        Manifest mf = clientJarFile.getManifest();
        if (mf != null)
        {
            // Now get the Class-Path entry from the manifest
            Attributes attrs = mf.getMainAttributes();
            String cp = attrs.getValue(Attributes.Name.CLASS_PATH);
            if ((cp != null) && (cp.length() > 0))
            {
                // Tokenize the attribute to the individual entries and get
their URLs
                StringTokenizer tokens = new StringTokenizer(cp);
                while (tokens.hasMoreTokens())
                {
                    String cpEntry = tokens.nextToken();

                    // the rule is: if it ends with a "/", it's a classpath
directory;
                    // otherwise it's some kind of .jar file. we don't care
about
                    // directory entries
                    if (cpEntry.endsWith("/"))
                    {
                        continue;
                    }

                    cpFile = new File(cpEntry);
                    if ((!cpFile.exists()) || (!cpFile.isFile()))
                    {
                        continue;
                    }

                    cpURLs.add(cpFile.toURL());
                }
            }
        }

The line with "attrs.getValue(Attributes.Name.CLASS_PATH)" gets the
Class-Path: entry from the manifest. When you get it, it's already been
turned back into the original single-line form of the entry.

FWIW...

Donnie


> -----Original Message-----
> From: Eddie Bernard [mailto:ebernard@digitalthink.com]
> Sent: Tuesday, January 15, 2002 7:12 PM
> To: 'Ant Users List'
> Subject: RE: Adding/extending a manifest using <ejbjar>
>
>
> Again, thanks to all who replied...
>
> Donnie, you're correct and I do stand corrected.
>
> It turns out that the split occurs in the middle of a jar reference but it
> does not affect the classpath constructed.
>
> I was able to successfully deploy the beans I created with the modified
> manifest without any problem.
>
>
> Cheers!
> Eddie
>
> -----Original Message-----
> From: DONNIE HALE [mailto:DHALE@longaberger.com]
> Sent: Tuesday, January 15, 2002 12:06 PM
> To: ant-user@jakarta.apache.org
> Subject: RE: Adding/extending a manifest using <ejbjar>
>
>
> If you read the jar spec, you'll see that lines beginning with a single
> space character are treated as continuations of the previous line. I have
> much more than 72 characters worth of Class-Path. I keep it all
> as a single
> line within my on-disk manifest. When put into a jar using <jar>, the line
> gets wrapped into lines of no more than 72 characters. My J2EE
> container has
> no problem with these wrapped lines within the manifest in my
> ejb.jar file.
>
> To be specific, my on-disk manifest has this line:
>
> Class-Path: lib/omapp.jar lib/leaf.jar lib/tlcutils.jar lib/log4j.jar
> lib/com.ibm.mq.jar lib/lasClient.jar etc/
>
> That's 112 characters. The manifest inside my .jar file looks like:
>
> Class-Path: lib/omapp.jar lib/leaf.jar lib/tlcutils.jar lib/log4j.jar
>  lib/com.ibm.mq.jar lib/lasClient.jar etc/
>
> It's coincidental, I believe, that the 72nd character for me is a
> space. I'm
> pretty sure I've seen it split in the middle of a .jar file name without
> problems.
>
> Hope that helps,
>
> Donnie
>
>
> >>> ebernard@digitalthink.com 01/15/02 01:48PM >>>
> After many hours of research and scouring over the java specs,
> here's what I
> found out ... just thought I'd post this so others don't lose sleep over
> this ;).
>
> If you specify your own manifest file, you *must* provide the
> "Manifest-Version" name/value pair, otherwise it will generate an "empty"
> (actually <cr><lf><cr><lf>) manifest.
>
> This is a restriction noted in the java specification for creating a
> manifest.
>
> Moreover (and on a separate note), a manifest line *cannot*
> exceed 72 bytes
> per specification.
>
> This means that if you're adding a "Class-Path: " attribute
> (which consumes
> 12 of the 72 bytes allocated leaving you with only 60), you can
> only add 60
> characters or bytes worth of additional classpath information
> such as jars,
> zips, classes, etc.  In my case, I have over 120 bytes of information I
> wanted to add to this attribute but now I'm unable to do so due to this
> restriction.
>
> I don't understand why this is a restriction considering the need for J2EE
> components to define its own classpath requirements.  Nonetheless, it's
> something to consider.
>
> What I'm going to have to do is add my additional third party
> components to
> the system classpath of the J2EE server (in this case WebLogic) and limit
> the manifest classpath construct to only the components that I'm
> building/generating (i.e. only one jar file).
>
> Thanks to everyone for their help on this.  If anyone has
> something else to
> lend to this, please do so -- it will be of great value to everyone
> concerned :).
>
>
>
> Cheers!
> Eddie
>
> -----Original Message-----
> From: Todd Chambery [mailto:tchambery@hotmail.com]
> Sent: Saturday, January 12, 2002 7:35 AM
> To: Ant Users List
> Subject: Re: Adding/extending a manifest using <ejbjar>
>
>
>
> ----- Original Message -----
> From: "Eddie Bernard" <ebernard@digitalthink.com>
> To: "'Ant Users List'" <ant-user@jakarta.apache.org>
> Sent: Friday, January 11, 2002 5:30 PM
> Subject: RE: Adding/extending a manifest using <ejbjar>
>
>
> > Todd-
> >
> > Thanks again!  I did manage to find the file in CVS and I've downloaded
> it.
> > However, I'm still getting an empty manifest when I use it.
> >
> > I inferred from looking at the code that the "manifest" attribute is not
> > required as it will pick it up automagically from the location you've
> > specified.  Is this a correct assumption?  IF I add the "manifest"
> > attribute, I get an empty manifest.  If I leave it out, I get
> the default
> > manifest.
>
> The manifest attribute has to be an absolute path to a single
> manifest file:
>     <ejbjar
>         manifest    ="d:\foo\bar\MANIFEST.MF"
>         ...
>
> This manifest will be used for each of the ejbjars in the descriptors
> directory.  In my case, each ejbjar had its own manifest, so
> obviously this
> didn't work.  The CVS GDT adds this:
>
>         protected void writeJar(..) {
>                 ...
>                 File manifestFile = new File(getConfig().descriptorDir,
> baseName + "-manifest.mf")
>
> which looks in the root of the descriptor directory for a manifest with a
> filename prepended with the jar name of its associated descriptor.
>
>      descriptor_root/
>          basejarname-manifest.mf
>          basejarname_1-manifest.mf
>          basejarname_2-manifest.mf
>
>          basejarname_bean/
>              META-INF/
>                  basejarname-ejb-jar.xml   <- (you don't have to use this
> naming convention)
>          basejarname_1_bean/
>              META-INF/
>                  basejarname_1-ejb-jar.xml
>          basejarname_2_bean/
>              META-INF/
>                  basejarname_2-ejb-jar.xml
>
>
> Todd
>
> >
> > Nonetheless, it looks like if this does work it will accomplish what I
> need.
> >
> > Any thoughts on how I can get this to work?
> >
> >
> > Cheers!
> > Eddie
> >
> >
> > -----Original Message-----
> > From: Todd Chambery [mailto:tchambery@hotmail.com]
> > Sent: Friday, January 11, 2002 6:25 AM
> > To: Ant Users List
> > Subject: Re: Adding/extending a manifest using <ejbjar>
> >
> >
> > Eddie,
> >
> > The most current version of the GDT in CVS looks in the descriptor root
> > directory for the renamed manifest. So,
> >
> >     descriptor_root/
> >         basejarname-manifest.mf
> >         basjarname_bean/
> >             META-INF/
> >                 ejb-jar.xml
> >
> > This depends kind of on what's specified in the 'naming'
> attribute of the
> > <ejbjar> task, but you get the idea.  Case is important
> > (assuming you're not on a win box).
> >
> > I don't think this is very intuitive, so I submitted a patch
> (actually 2,
> > but the first one sucked) that makes the GDT look in the
> > current descriptor dir (in the above example,
> > descriptor_root/basejarname_bean/META-INF/) for "manifest.mf".  I don't
> know
> > how the
> > Ant people will respond, but I can mail it to you if you want.
> >
> > Todd
> >
> >
> >
> >
> > ----- Original Message -----
> > From: "Eddie Bernard" <ebernard@digitalthink.com>
> > To: "'Ant Users List'" <ant-user@jakarta.apache.org>
> > Sent: Friday, January 11, 2002 3:05 AM
> > Subject: RE: Adding/extending a manifest using <ejbjar>
> >
> >
> > > Todd-
> > >
> > > So, if are you saying that the manifest file name must have
> the name of
> > the
> > > EJB as specified in the deployment descriptor?
> > >
> > > If so, then does the name of the manifest and directory structure look
> > like:
> > >
> > > META-INF/
> > >    ejb-jar.xml
> > >    MyBeanName-manifest.mf
> > >
> > > or does the manifest simply need to be "Manifest.mf".  Better yet, is
> this
> > > case-sensitive?
> > >
> > >
> > >
> > > Cheers!
> > > Eddie
> > >
> > > -----Original Message-----
> > > From: Todd Chambery [mailto:tchambery@hotmail.com]
> > > Sent: Wednesday, January 09, 2002 5:41 PM
> > > To: Ant Users List
> > > Subject: Re: Adding/extending a manifest using <ejbjar>
> > >
> > >
> > > Howdy,
> > >
> > > The GenericDeploymentTool in CVS
> > >
> >iet an empty manifest.  If I leave it ou
> (http://cvs.apache.org/viewcvs/jakarta-ant/src/main/org/apache/too
> ls/ant/tas
>
> > > kdefs/optional/ejb/GenericDeploymentTool.java) has a
> workaround in which
> > > <ejbjar> will pick up your manifest if it is named with
> > >
> > >     descriptor_root_dir/base_name-manifest.mf
> > >
> > > .
> > >
> > > I don't quite understand why GDT doesn't just look to see if a
> > "manifest.mf"
> > > exists in the current descriptor directory, and if it does, add it to
> the
> > > jar.  If one isn't there, put in the empty Ant default.  I'm going to
> make
> > > an attempt at submitting a patch (I think it's a very simple fix).
> > >
> > > hope that helps,
> > >
> > > Todd
> > >
> > >
> > >
> > > ----- Original Message -----
> > > From: "Eddie Bernard" <ebernard@digitalthink.com>
> > > To: <ant-user@jakarta.apache.org>
> > > Sent: Wednesday, January 09, 2002 7:54 PM
> > > Subject: Adding/extending a manifest using <ejbjar>
> > >
> > >
> > > > OK, I've haven't completely given up on using <ejbjar> for
> my WebLogic
> > 6.1
> > > > project.
> > > >
> > > > The reason I want to use it is that I have approximately 75
> EJBs that
> I
> > > want
> > > > to build and the target I've created that uses <ejbjar>
> neatly creates
> > > each
> > > > EJB with only one target.   Using some of the other
> suggested methods
> > > > (which, again, I appreciate the responses) would require me
> to have a
> > > target
> > > > for virutally every bean and even worst add more targets if
> more beans
> > are
> > > > added to the project.
> > > >
> > > > Now with all tht said, I'm in the process of creating an Enterprise
> > > Archive,
> > > > but I'm having a deployment problem -- again unrelated to
> Ant itself.
> > > > However, after reading some BEA white papers and the J2EE
> specifications
> > > for
> > > > Application Deployment, it allows the addition of the
> name:value pair:
> > > >
> > > > Class-Path: list-of-jars-separated-by-spaces
> > > >
> > > > Example:
> > > >
> > > > Class-Path: lib/my_support_classes.jar
> > > >
> > > > Now the Ant-related problem... It seems that <ejbjar> extends the
> <jar>
> > > task
> > > > meaning that it inherits the "manifest" attribute.  If I use <jar>
> with
> > my
> > > > manifest addition it works just fine.  However, with <ejbjar> it
> > generates
> > > a
> > > > "near empty" file (actually, it has a set of cr/lf).
> > > >
> > > > Has anybody else come across this problem or have any ideas
> what I can
> > do?
> > > >
> > > >
> > > >
> > > > --
> > > > To unsubscribe, e-mail:
> > <mailto:ant-user-unsubscribe@jakarta.apache.org>
> > > > For additional commands, e-mail:
> > <mailto:ant-user-help@jakarta.apache.org>
> > > >
> > > >
> > >
> > > --
> > > To unsubscribe, e-mail:
> <mailto:ant-user-unsubscribe@jakarta.apache.org>
> > > For additional commands, e-mail:
> <mailto:ant-user-help@jakarta.apache.org>
> > >
> > > --
> > > To unsubscribe, e-mail:
> <mailto:ant-user-unsubscribe@jakarta.apache.org>
> > > For additional commands, e-mail:
> <mailto:ant-user-help@jakarta.apache.org>
> > >
> > >
> >
> > --
> > To unsubscribe, e-mail:
> <mailto:ant-user-unsubscribe@jakarta.apache.org>
> > For additional commands, e-mail:
> <mailto:ant-user-help@jakarta.apache.org>
> >
> > --
> > To unsubscribe, e-mail:
> <mailto:ant-user-unsubscribe@jakarta.apache.org>
> > For additional commands, e-mail:
> <mailto:ant-user-help@jakarta.apache.org>
> >
> >
>
> --
> To unsubscribe, e-mail:   <mailto:ant-user-unsubscribe@jakarta.apache.org>
> For additional commands, e-mail: <mailto:ant-user-help@jakarta.apache.org>
>
> --
> To unsubscribe, e-mail:   <mailto:ant-user-unsubscribe@jakarta.apache.org>
> For additional commands, e-mail: <mailto:ant-user-help@jakarta.apache.org>
>
>
> --
> To unsubscribe, e-mail:   <mailto:ant-user-unsubscribe@jakarta.apache.org>
> For additional commands, e-mail: <mailto:ant-user-help@jakarta.apache.org>
>
> --
> To unsubscribe, e-mail:   <mailto:ant-user-unsubscribe@jakarta.apache.org>
> For additional commands, e-mail: <mailto:ant-user-help@jakarta.apache.org>
>
>


--
To unsubscribe, e-mail:   <mailto:ant-user-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:ant-user-help@jakarta.apache.org>


Mime
View raw message