Java package sealed?

[Adam Jack <aj...@mric.coop>]

This is interesting, seems either the package or the whole jar is 'sealed'
and so restricts class loading. Not sure why it affects this build, but it
does.


http://brutus.apache.org/gump/test/jakarta-cactus/jakarta-cactus-framework-12/gump_work/build_jakarta-cactus_jakarta-cactus-framework-12.html
BUILD FAILED
/usr/local/gump/test/workspace/jakarta-cactus/build-common.xml:123:
java.lang.SecurityException: sealing violation: package javax.servlet is
sealed
Not exactly sure how long this has been out there, it start into a bad start
on the 9th (and Stefano updated the JDK on the 7th, so maybe unrelated,
maybe related -- not sure).Some information:
http://java.sun.com/developer/JDCTechTips/2001/tt0130.htmlAnybody Java-savvy
enough to figure out what is occurring & what ought be fixed??regards,Adam


---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org

Re: Java package sealed?

[Stefan Bodewig <bo...@apache.org>]

On Wed, 13 Oct 2004, Stefan Bodewig <bo...@apache.org> wrote:

> My theory:  Ant loads Jetty's version of servlet.jar in addition to
> the one from Jakarta.  The first one is sealed, the second one is
> first in the class loader and so we load the class from a different
> jar than the one that sealed it.

Theory confirmed.

I've managed to get my "traditional" Gump to try and build
cactus-framework-12 by "faking" Tidy.jar.  I've found two ways to
successfully build cactus:

(1) remove the Class-Path entry from org.mortbay.jetty.jar's
    MANIFEST.MF

(2) turning the "Sealed: true" into "Sealed: false" in Jetty's
    javax.servlet.jar's MANIFEST.MF.

Option (2) could easily be achieved by a property in Jetty's build
file.

Stefan

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org

Re: Java package sealed?

["Adam R. B. Jack" <aj...@apache.org>]

> I've seen this before, but I'm not sure which of the jars the package
> gets loaded from.  Is there any way to get a temporary -debug output
> of the build?  I still haven't figured out how I can selectively build
> a single project in Gump now.

Add debug="true" (or verbose="true") as an attribute on the <ant or <maven
element.

See:    http://gump.apache.org/metadata/builder.html

regards

Adam


---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org

Re: Java package sealed?

[Stefan Bodewig <bo...@apache.org>]

On Tue, 12 Oct 2004, Adam Jack <aj...@mric.coop> wrote:

> This is interesting, seems either the package or the whole jar is
> 'sealed' and so restricts class loading. Not sure why it affects
> this build, but it does.

I've seen this before, but I'm not sure which of the jars the package
gets loaded from.  Is there any way to get a temporary -debug output
of the build?  I still haven't figured out how I can selectively build
a single project in Gump now.

> Not exactly sure how long this has been out there, it start into a
> bad start on the 9th (and Stefano updated the JDK on the 7th, so
> maybe unrelated, maybe related -- not sure).

Completely unrelated.  The problem has been there for weeks if not
months now.  Vincent even asked for help here.  I haven't managed to
figure out the problem so far either.

My personal hurdle here is that I still don't run Gump on my own
machine (well, I still run "traditional" but it's becoming more and
more irrelevant because it doesn't support Maven builds) for lack of
time.  And whenever I want to look into the jars created on Brutus I
find they've been wiped out.

We need to grab all jars passed to the cactus build and look into
their manifests to see which one seals the package.  And we need to
find out why the sealing gets violated.

OK, I think I have a trace, this is the manifest file created in
org.mortbay.jetty.jar on my machine last night:

,----
| Manifest-Version: 1.0
| Ant-Version: Apache Ant 1.7alpha
| Created-By: 1.4.2_04-b05 (Sun Microsystems Inc.)
| Sealed: true
| Built-By: bodewig
| Specification-Version: 5.1
| Implementation-Version: 5.1.RC0
| Package-Title: org.mortbay.http
| Implementation-Vendor: Mort Bay Consulting, Pty. Ltd.
| Implementation-URL: http://jetty.mortbay.org
| Main-Class: org.mortbay.http.HttpServer
| Class-Path: javax.servlet.jar
| 
| Name: org/mortbay/jetty/
| Specification-Title: Servlet/2.3
| Implementation-Title: Jetty/5.1
| 
| Name: org/mortbay/http/
| Implementation-Title: Mort Bay HTTP Server
| 
| Name: org/mortbay/util/
| Implementation-Title: Mort Bay Misc. Utilities
`----

Note two things:  (1) Jetty is sealed and (2) it contains a Class-Path
entry for javax.servlet.jar which in turn is sealed as well.

My theory:  Ant loads Jetty's version of servlet.jar in addition to
the one from Jakarta.  The first one is sealed, the second one is
first in the class loader and so we load the class from a different
jar than the one that sealed it.

Looking into Jetty's build file, the "Sealed: true" is hard-coded with
no way to override it.  We may be able to get the Jetty people to make
this a property we can override.  Anybody with good contacts into
Jetty land?

Stefan

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org