You are viewing a plain text version of this content. The canonical link for it is here.
Posted to server-dev@james.apache.org by Bernd Fondermann <bf...@brainlounge.de> on 2008/04/15 21:13:51 UTC
non-conforming Manifest.MF in spice libs
Hi,
There are three spice libs we are using which cause problems:
spice-configkit-1.1.2.jar
spice-loggerstore-0.5.jar
spice-classman-1.0.jar
They all have Extension-List values which do not conform to the
Manifest.MF spec [1]. They separate entries with colons instead of spaces.
This causes Tomcat to throw exceptions [2]. Jetty is fine.
Possible solutions:
1.
There are newer versions of the lib available at spice.codehaus.org with
corrected manifests.
But those are incompatible in terms of package names, which have been
changed from their original home (realityforge.org) to their new home's.
So using them is not an option I guess, since they are used by Phoenix
directly.
2. We could not support Tomcat with our WAR deployment, which is poor
(or good, depending on your attitude towards embedding James within
Servlet Containers :-) ).
3. We could approach the Tomcat people to make it behave more gracefully.
4. We could change the JAR's Manifests.
I'd prefer 4. because it would be the low-hanging fruit.
WDYT?
Bernd
[1] http://java.sun.com/j2se/1.4.2/docs/guide/jar/jar.html#Main%20Attributes
[2]
http://issues.apache.org/jira/browse/JAMES-834?focusedCommentId=12587885#action_12587885
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: non-conforming Manifest.MF in spice libs
Posted by Robert Burrell Donkin <ro...@gmail.com>.
On Wed, Apr 16, 2008 at 8:10 PM, Bernd Fondermann
<be...@googlemail.com> wrote:
>
> On Wed, Apr 16, 2008 at 3:27 PM, Robert Burrell Donkin
> <ro...@gmail.com> wrote:
> > On Tue, Apr 15, 2008 at 8:13 PM, Bernd Fondermann <bf...@brainlounge.de> wrote:
<snip>
> > > 3. We could approach the Tomcat people to make it behave more gracefully.
> >
> > think it's a spec compliance thing
>
> yeah, but maybe could be ignored (as does Jetty). since they removed
> the related entries from the libs, cannot be that important.
not sure whether jetty is TCK'd
> > > 4. We could change the JAR's Manifests.
> >
> > seems the most expedient solution. would probably cause headaches for
> > maven users.
>
> oops. didn't think of that. :-/
>
>
> > 5. do we really need them at all ;-) ?
> >
> > i'd much prefer to support servlet containers by using generic
> > servlets for the transport (rather than the avalon-based JAMES
> > handler). this would probably mean that the war deployment would be
> > spring only.
>
> but this means a completely different, much more complex
> spring-deployment than what we currently have.
>
>
> > IMO people using a servlet container are willing to compromise a
> > little on specification compliance for interoperability. using a
> > servlet for the socket layer is not gaurateed to be as compliant as
> > the well tested JAMES transport layer but IMHO this is a price which
> > many people would think worth paying.
>
> would also need them paying me the man-month doing it ;-)
:-)
i suggest just continuing with jetty for now: we can tell tomcat users
to edit the manifest themselves
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: non-conforming Manifest.MF in spice libs
Posted by Bernd Fondermann <be...@googlemail.com>.
On Wed, Apr 16, 2008 at 3:27 PM, Robert Burrell Donkin
<ro...@gmail.com> wrote:
> On Tue, Apr 15, 2008 at 8:13 PM, Bernd Fondermann <bf...@brainlounge.de> wrote:
> > Hi,
> >
> > There are three spice libs we are using which cause problems:
> >
> > spice-configkit-1.1.2.jar
> > spice-loggerstore-0.5.jar
> > spice-classman-1.0.jar
> >
> > They all have Extension-List values which do not conform to the Manifest.MF
> > spec [1]. They separate entries with colons instead of spaces.
> > This causes Tomcat to throw exceptions [2]. Jetty is fine.
> >
> > Possible solutions:
> >
> > 1.
> >
> > There are newer versions of the lib available at spice.codehaus.org with
> > corrected manifests.
> > But those are incompatible in terms of package names, which have been
> > changed from their original home (realityforge.org) to their new home's.
> >
> > So using them is not an option I guess, since they are used by Phoenix
> > directly.
>
> could use bytecode, i suppose
>
>
> > 2. We could not support Tomcat with our WAR deployment, which is poor (or
> > good, depending on your attitude towards embedding James within Servlet
> > Containers :-) ).
>
> prefer to support tomcat
>
>
> > 3. We could approach the Tomcat people to make it behave more gracefully.
>
> think it's a spec compliance thing
yeah, but maybe could be ignored (as does Jetty). since they removed
the related entries from the libs, cannot be that important.
> > 4. We could change the JAR's Manifests.
>
> seems the most expedient solution. would probably cause headaches for
> maven users.
oops. didn't think of that. :-/
> 5. do we really need them at all ;-) ?
>
> i'd much prefer to support servlet containers by using generic
> servlets for the transport (rather than the avalon-based JAMES
> handler). this would probably mean that the war deployment would be
> spring only.
but this means a completely different, much more complex
spring-deployment than what we currently have.
> IMO people using a servlet container are willing to compromise a
> little on specification compliance for interoperability. using a
> servlet for the socket layer is not gaurateed to be as compliant as
> the well tested JAMES transport layer but IMHO this is a price which
> many people would think worth paying.
would also need them paying me the man-month doing it ;-)
Bernd
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: non-conforming Manifest.MF in spice libs
Posted by Robert Burrell Donkin <ro...@gmail.com>.
On Tue, Apr 15, 2008 at 8:13 PM, Bernd Fondermann <bf...@brainlounge.de> wrote:
> Hi,
>
> There are three spice libs we are using which cause problems:
>
> spice-configkit-1.1.2.jar
> spice-loggerstore-0.5.jar
> spice-classman-1.0.jar
>
> They all have Extension-List values which do not conform to the Manifest.MF
> spec [1]. They separate entries with colons instead of spaces.
> This causes Tomcat to throw exceptions [2]. Jetty is fine.
>
> Possible solutions:
>
> 1.
>
> There are newer versions of the lib available at spice.codehaus.org with
> corrected manifests.
> But those are incompatible in terms of package names, which have been
> changed from their original home (realityforge.org) to their new home's.
>
> So using them is not an option I guess, since they are used by Phoenix
> directly.
could use bytecode, i suppose
> 2. We could not support Tomcat with our WAR deployment, which is poor (or
> good, depending on your attitude towards embedding James within Servlet
> Containers :-) ).
prefer to support tomcat
> 3. We could approach the Tomcat people to make it behave more gracefully.
think it's a spec compliance thing
> 4. We could change the JAR's Manifests.
seems the most expedient solution. would probably cause headaches for
maven users.
5. do we really need them at all ;-) ?
i'd much prefer to support servlet containers by using generic
servlets for the transport (rather than the avalon-based JAMES
handler). this would probably mean that the war deployment would be
spring only.
IMO people using a servlet container are willing to compromise a
little on specification compliance for interoperability. using a
servlet for the socket layer is not gaurateed to be as compliant as
the well tested JAMES transport layer but IMHO this is a price which
many people would think worth paying.
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org