You are viewing a plain text version of this content. The canonical link for it is here.
Posted to xmlrpc-dev@ws.apache.org by Jason van Zyl <jv...@zenplex.com> on 2002/03/18 15:37:39 UTC
SAX classes in JAR wreaking havoc
Hi,
Why do have the SAX classes in our CVS? I just spent two hours tracking
down a 'loader constraint violation' which was the result of having the
SAX classes in the xmlrpc JAR. The package compiles just fine without
them if you have xerces in your ANT_HOME/lib.
If they need to be in the jar for embedded purposes can we please change
the build so that we have a jar without the SAX classes? say xmlrpc.jar
and xmlrpc-full.jar?
--
jvz.
Jason van Zyl
jvanzyl@apache.org
http://tambora.zenplex.org
Re: SAX classes in JAR wreaking havoc
Posted by John Wilson <tu...@wilson.co.uk>.
----- Original Message -----
From: "Jason van Zyl" <jv...@zenplex.com>
To: <rp...@xml.apache.org>
Sent: Monday, March 18, 2002 7:20 PM
Subject: Re: SAX classes in JAR wreaking havoc
[snip]
> > We need a subset of the SAX 1 classes for a stand alone XML-RPC jar with
> > MinML (the MinML distribution contains this subset). Note that moving to
a
> > later version of the SAX1 classes will cause deprecation warnings as the
SAX
> > 1 stuff has now been deprecated in favour of SAX2.
> >
> > At some point we might want to consider moving from SAX1 to SAX2 (and
from
> > MinML to MinML2). It buys us precisely nothing in terms of functionality
but
> > does not have any significant cost in terms of performance.
>
> So what does this mean now? The presence of the classes are causing
> problems. I thrown together a JAR without those classes to get the
> Turbine builds working again but this is a stopgap solution. Can we
> package the ancillary classes in a second JAR and tell people to use
> this if they need to? This is how it was originally wasn't it?
There are several options:
1/ Produce "stand alone" and "servlet" jars. The "stand alone" jar contains
all the client code, the small HTTP server and the server code plus MinML
and the SAX1 classes. The "servlet" jar contains the Servlet wrapper but not
the SAX classes or the HTTP server.
2/ Move the SAX classes into a separate jar (this would not be needed at all
if the code was run under JDK 1.4 or later).
3/ Move the SAX classes and MinML into a separate jar.
4/ Remove MinML and the SAX classes from the distribution altogether.
I quite like option 1 - I think it reflects the reality of the two distinct
classes of use of this stuff.
John Wilson
The Wilson Partnership
http://www.wilson.co.uk
Re: SAX classes in JAR wreaking havoc
Posted by Daniel Rall <dl...@finemaltcoding.com>.
Jason van Zyl <jv...@zenplex.com> writes:
> On Mon, 2002-03-18 at 14:17, John Wilson wrote:
>>
>> We need a subset of the SAX 1 classes for a stand alone XML-RPC jar with
>> MinML (the MinML distribution contains this subset). Note that moving to a
>> later version of the SAX1 classes will cause deprecation warnings as the SAX
>> 1 stuff has now been deprecated in favour of SAX2.
>>
>> At some point we might want to consider moving from SAX1 to SAX2 (and from
>> MinML to MinML2). It buys us precisely nothing in terms of functionality but
>> does not have any significant cost in terms of performance.
>
> So what does this mean now? The presence of the classes are causing
> problems. I thrown together a JAR without those classes to get the
> Turbine builds working again but this is a stopgap solution. Can we
> package the ancillary classes in a second JAR and tell people to use
> this if they need to? This is how it was originally wasn't it?
They're probably already available separately. I would be okay with
removing them from the XML-RPC JAR, since they are causing problems.
John, comments?
FWIW, I would also be in favor of moving to MinML2.
Re: SAX classes in JAR wreaking havoc
Posted by Daniel Rall <dl...@finemaltcoding.com>.
Jason van Zyl <jv...@zenplex.com> writes:
> On Mon, 2002-03-18 at 14:17, John Wilson wrote:
>>
>> We need a subset of the SAX 1 classes for a stand alone XML-RPC jar with
>> MinML (the MinML distribution contains this subset). Note that moving to a
>> later version of the SAX1 classes will cause deprecation warnings as the SAX
>> 1 stuff has now been deprecated in favour of SAX2.
>>
>> At some point we might want to consider moving from SAX1 to SAX2 (and from
>> MinML to MinML2). It buys us precisely nothing in terms of functionality but
>> does not have any significant cost in terms of performance.
>
> So what does this mean now? The presence of the classes are causing
> problems. I thrown together a JAR without those classes to get the
> Turbine builds working again but this is a stopgap solution. Can we
> package the ancillary classes in a second JAR and tell people to use
> this if they need to? This is how it was originally wasn't it?
They're probably already available separately. I would be okay with
removing them from the XML-RPC JAR, since they are causing problems.
John, comments?
FWIW, I would also be in favor of moving to MinML2.
Re: SAX classes in JAR wreaking havoc
Posted by John Wilson <tu...@wilson.co.uk>.
----- Original Message -----
From: "Jason van Zyl" <jv...@zenplex.com>
To: <rp...@xml.apache.org>
Sent: Monday, March 18, 2002 7:20 PM
Subject: Re: SAX classes in JAR wreaking havoc
[snip]
> > We need a subset of the SAX 1 classes for a stand alone XML-RPC jar with
> > MinML (the MinML distribution contains this subset). Note that moving to
a
> > later version of the SAX1 classes will cause deprecation warnings as the
SAX
> > 1 stuff has now been deprecated in favour of SAX2.
> >
> > At some point we might want to consider moving from SAX1 to SAX2 (and
from
> > MinML to MinML2). It buys us precisely nothing in terms of functionality
but
> > does not have any significant cost in terms of performance.
>
> So what does this mean now? The presence of the classes are causing
> problems. I thrown together a JAR without those classes to get the
> Turbine builds working again but this is a stopgap solution. Can we
> package the ancillary classes in a second JAR and tell people to use
> this if they need to? This is how it was originally wasn't it?
There are several options:
1/ Produce "stand alone" and "servlet" jars. The "stand alone" jar contains
all the client code, the small HTTP server and the server code plus MinML
and the SAX1 classes. The "servlet" jar contains the Servlet wrapper but not
the SAX classes or the HTTP server.
2/ Move the SAX classes into a separate jar (this would not be needed at all
if the code was run under JDK 1.4 or later).
3/ Move the SAX classes and MinML into a separate jar.
4/ Remove MinML and the SAX classes from the distribution altogether.
I quite like option 1 - I think it reflects the reality of the two distinct
classes of use of this stuff.
John Wilson
The Wilson Partnership
http://www.wilson.co.uk
Re: SAX classes in JAR wreaking havoc
Posted by Jason van Zyl <jv...@zenplex.com>.
On Mon, 2002-03-18 at 14:17, John Wilson wrote:
>
> ----- Original Message -----
> From: "Daniel Rall" <dl...@finemaltcoding.com>
> To: <rp...@xml.apache.org>
> Sent: Monday, March 18, 2002 6:41 PM
> Subject: Re: SAX classes in JAR wreaking havoc
>
>
> > Jason van Zyl <jv...@zenplex.com> writes:
> >
> > > Why do have the SAX classes in our CVS? I just spent two hours tracking
> > > down a 'loader constraint violation' which was the result of having the
> > > SAX classes in the xmlrpc JAR. The package compiles just fine without
> > > them if you have xerces in your ANT_HOME/lib.
> >
> > Oooh, that's a fun one. I've hit that too with Catalina.
> >
> > > If they need to be in the jar for embedded purposes can we please change
> > > the build so that we have a jar without the SAX classes? say xmlrpc.jar
> > > and xmlrpc-full.jar?
> >
> > I hate that -full crap -- let's do just one JAR. John, I assume
> > removing the interfaces bytecode would cause run-time problems if they
> > were not present separately? At the very least, we might want to
> > update them to a more recent version.
>
> We need a subset of the SAX 1 classes for a stand alone XML-RPC jar with
> MinML (the MinML distribution contains this subset). Note that moving to a
> later version of the SAX1 classes will cause deprecation warnings as the SAX
> 1 stuff has now been deprecated in favour of SAX2.
>
> At some point we might want to consider moving from SAX1 to SAX2 (and from
> MinML to MinML2). It buys us precisely nothing in terms of functionality but
> does not have any significant cost in terms of performance.
So what does this mean now? The presence of the classes are causing
problems. I thrown together a JAR without those classes to get the
Turbine builds working again but this is a stopgap solution. Can we
package the ancillary classes in a second JAR and tell people to use
this if they need to? This is how it was originally wasn't it?
> John Wilson
> The Wilson Partnership
> http://www.wilson.co.uk
--
jvz.
Jason van Zyl
jvanzyl@apache.org
http://tambora.zenplex.org
Re: SAX classes in JAR wreaking havoc
Posted by Jason van Zyl <jv...@zenplex.com>.
On Mon, 2002-03-18 at 14:17, John Wilson wrote:
>
> ----- Original Message -----
> From: "Daniel Rall" <dl...@finemaltcoding.com>
> To: <rp...@xml.apache.org>
> Sent: Monday, March 18, 2002 6:41 PM
> Subject: Re: SAX classes in JAR wreaking havoc
>
>
> > Jason van Zyl <jv...@zenplex.com> writes:
> >
> > > Why do have the SAX classes in our CVS? I just spent two hours tracking
> > > down a 'loader constraint violation' which was the result of having the
> > > SAX classes in the xmlrpc JAR. The package compiles just fine without
> > > them if you have xerces in your ANT_HOME/lib.
> >
> > Oooh, that's a fun one. I've hit that too with Catalina.
> >
> > > If they need to be in the jar for embedded purposes can we please change
> > > the build so that we have a jar without the SAX classes? say xmlrpc.jar
> > > and xmlrpc-full.jar?
> >
> > I hate that -full crap -- let's do just one JAR. John, I assume
> > removing the interfaces bytecode would cause run-time problems if they
> > were not present separately? At the very least, we might want to
> > update them to a more recent version.
>
> We need a subset of the SAX 1 classes for a stand alone XML-RPC jar with
> MinML (the MinML distribution contains this subset). Note that moving to a
> later version of the SAX1 classes will cause deprecation warnings as the SAX
> 1 stuff has now been deprecated in favour of SAX2.
>
> At some point we might want to consider moving from SAX1 to SAX2 (and from
> MinML to MinML2). It buys us precisely nothing in terms of functionality but
> does not have any significant cost in terms of performance.
So what does this mean now? The presence of the classes are causing
problems. I thrown together a JAR without those classes to get the
Turbine builds working again but this is a stopgap solution. Can we
package the ancillary classes in a second JAR and tell people to use
this if they need to? This is how it was originally wasn't it?
> John Wilson
> The Wilson Partnership
> http://www.wilson.co.uk
--
jvz.
Jason van Zyl
jvanzyl@apache.org
http://tambora.zenplex.org
Re: SAX classes in JAR wreaking havoc
Posted by John Wilson <tu...@wilson.co.uk>.
----- Original Message -----
From: "Daniel Rall" <dl...@finemaltcoding.com>
To: <rp...@xml.apache.org>
Sent: Monday, March 18, 2002 6:41 PM
Subject: Re: SAX classes in JAR wreaking havoc
> Jason van Zyl <jv...@zenplex.com> writes:
>
> > Why do have the SAX classes in our CVS? I just spent two hours tracking
> > down a 'loader constraint violation' which was the result of having the
> > SAX classes in the xmlrpc JAR. The package compiles just fine without
> > them if you have xerces in your ANT_HOME/lib.
>
> Oooh, that's a fun one. I've hit that too with Catalina.
>
> > If they need to be in the jar for embedded purposes can we please change
> > the build so that we have a jar without the SAX classes? say xmlrpc.jar
> > and xmlrpc-full.jar?
>
> I hate that -full crap -- let's do just one JAR. John, I assume
> removing the interfaces bytecode would cause run-time problems if they
> were not present separately? At the very least, we might want to
> update them to a more recent version.
We need a subset of the SAX 1 classes for a stand alone XML-RPC jar with
MinML (the MinML distribution contains this subset). Note that moving to a
later version of the SAX1 classes will cause deprecation warnings as the SAX
1 stuff has now been deprecated in favour of SAX2.
At some point we might want to consider moving from SAX1 to SAX2 (and from
MinML to MinML2). It buys us precisely nothing in terms of functionality but
does not have any significant cost in terms of performance.
John Wilson
The Wilson Partnership
http://www.wilson.co.uk
Re: SAX classes in JAR wreaking havoc
Posted by John Wilson <tu...@wilson.co.uk>.
----- Original Message -----
From: "Daniel Rall" <dl...@finemaltcoding.com>
To: <rp...@xml.apache.org>
Sent: Monday, March 18, 2002 6:41 PM
Subject: Re: SAX classes in JAR wreaking havoc
> Jason van Zyl <jv...@zenplex.com> writes:
>
> > Why do have the SAX classes in our CVS? I just spent two hours tracking
> > down a 'loader constraint violation' which was the result of having the
> > SAX classes in the xmlrpc JAR. The package compiles just fine without
> > them if you have xerces in your ANT_HOME/lib.
>
> Oooh, that's a fun one. I've hit that too with Catalina.
>
> > If they need to be in the jar for embedded purposes can we please change
> > the build so that we have a jar without the SAX classes? say xmlrpc.jar
> > and xmlrpc-full.jar?
>
> I hate that -full crap -- let's do just one JAR. John, I assume
> removing the interfaces bytecode would cause run-time problems if they
> were not present separately? At the very least, we might want to
> update them to a more recent version.
We need a subset of the SAX 1 classes for a stand alone XML-RPC jar with
MinML (the MinML distribution contains this subset). Note that moving to a
later version of the SAX1 classes will cause deprecation warnings as the SAX
1 stuff has now been deprecated in favour of SAX2.
At some point we might want to consider moving from SAX1 to SAX2 (and from
MinML to MinML2). It buys us precisely nothing in terms of functionality but
does not have any significant cost in terms of performance.
John Wilson
The Wilson Partnership
http://www.wilson.co.uk
Re: SAX classes in JAR wreaking havoc
Posted by Daniel Rall <dl...@finemaltcoding.com>.
Jason van Zyl <jv...@zenplex.com> writes:
> Why do have the SAX classes in our CVS? I just spent two hours tracking
> down a 'loader constraint violation' which was the result of having the
> SAX classes in the xmlrpc JAR. The package compiles just fine without
> them if you have xerces in your ANT_HOME/lib.
Oooh, that's a fun one. I've hit that too with Catalina.
> If they need to be in the jar for embedded purposes can we please change
> the build so that we have a jar without the SAX classes? say xmlrpc.jar
> and xmlrpc-full.jar?
I hate that -full crap -- let's do just one JAR. John, I assume
removing the interfaces bytecode would cause run-time problems if they
were not present separately? At the very least, we might want to
update them to a more recent version.
Dan
Re: SAX classes in JAR wreaking havoc
Posted by Daniel Rall <dl...@finemaltcoding.com>.
Jason van Zyl <jv...@zenplex.com> writes:
> Why do have the SAX classes in our CVS? I just spent two hours tracking
> down a 'loader constraint violation' which was the result of having the
> SAX classes in the xmlrpc JAR. The package compiles just fine without
> them if you have xerces in your ANT_HOME/lib.
Oooh, that's a fun one. I've hit that too with Catalina.
> If they need to be in the jar for embedded purposes can we please change
> the build so that we have a jar without the SAX classes? say xmlrpc.jar
> and xmlrpc-full.jar?
I hate that -full crap -- let's do just one JAR. John, I assume
removing the interfaces bytecode would cause run-time problems if they
were not present separately? At the very least, we might want to
update them to a more recent version.
Dan