You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by Remy Maucherat <re...@apache.org> on 2006/10/04 17:15:10 UTC
Package renaming
Hi,
I think Tomcat would be more robust if commons-logging was package
renamed (this is the last commons- which is not package renamed at the
moment, BTW), so I propose doing that.
It would mean integration with alternate loggers in Tomcat is more
difficult (the wrapper would have to be package renamed too), but OTOH
it would avoid classloading issues with the webapp. The implementation
which could be used is the one from tomcat-lite (since it's small and
robust).
It's a bit power/flexibility vs robustness, here.
Comments ?
Rémy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Package renaming
Posted by Remy Maucherat <re...@apache.org>.
Peter Rossbach wrote:
> Hi!
>
> At which tomcat release you want to change it? 6.0
Of course.
> You want use the commons-logging 1.1 code base?
No, probably use what is in the sandbox to start with.
Rémy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Package renaming
Posted by Peter Rossbach <pr...@objektpark.de>.
Hi!
At which tomcat release you want to change it? 6.0
That change can be break subclasses or components from other people,
not nice.
Has you talk with Boris and future usage of his x4juli lib?
But I also see your arguments to do that. Hmm!
You want use the commons-logging 1.1 code base?
Regards
Peter
Am 04.10.2006 um 17:15 schrieb Remy Maucherat:
> Hi,
>
> I think Tomcat would be more robust if commons-logging was package
> renamed (this is the last commons- which is not package renamed at
> the moment, BTW), so I propose doing that.
>
> It would mean integration with alternate loggers in Tomcat is more
> difficult (the wrapper would have to be package renamed too), but
> OTOH it would avoid classloading issues with the webapp. The
> implementation which could be used is the one from tomcat-lite
> (since it's small and robust).
>
> It's a bit power/flexibility vs robustness, here.
>
> Comments ?
>
> Rémy
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
>
Re: Package renaming
Posted by "William L. Thomson Jr." <wl...@gentoo.org>.
On Wed, 2006-10-04 at 21:52 +0200, Remy Maucherat wrote:
> William L. Thomson Jr. wrote:
> > I have no foreseeable solution to building that jar on Gentoo at this
> > time. I have discussed it extensively with others, and we are likely to
> > have to do some package specific hacks or etc to build that jar. In the
> > mean time, those needing that jar are having to fetch it from the a
> > binary release.
>
> Ok, but you don't really have to care that much about that JAR: Tomcat
> is still perfectly usable using the regular commons-dbcp, etc.
Sure, and most JDBC drivers have their own factories as well. It's just
users freak at first and is one of the little annoying pains. I have
never been effected by it missing, but many that don't specify a factory
at all. Tend to need that jar, since it's the default factory used when
non are specified.
Really only reasons I care about the jar is
1. To be like upstream releases (for the most part)
2. So users don't get cnfe or etc when the jar is mia
> It's not the same situation here, so you won't run into any problem. An
> implementation of commons-logging (I thought the one Costin did in
> tomcat-lite could be reasonable to start with) would be included in the
> Tomcat source and built along with the rest.
Terrific :)
I have no problem with any sources bundled with Tomcat. Nor Tomcat's
deps on binaries the sources do not ship with. It's just dependencies on
sources Tomcat does not ship with is my pain/gripe atm.
I appreciate you all being receptive to this coming from downstream :)
--
William L. Thomson Jr.
Gentoo/Java
Re: Package renaming
Posted by Remy Maucherat <re...@apache.org>.
William L. Thomson Jr. wrote:
> I have no foreseeable solution to building that jar on Gentoo at this
> time. I have discussed it extensively with others, and we are likely to
> have to do some package specific hacks or etc to build that jar. In the
> mean time, those needing that jar are having to fetch it from the a
> binary release.
Ok, but you don't really have to care that much about that JAR: Tomcat
is still perfectly usable using the regular commons-dbcp, etc.
It's not the same situation here, so you won't run into any problem. An
implementation of commons-logging (I thought the one Costin did in
tomcat-lite could be reasonable to start with) would be included in the
Tomcat source and built along with the rest.
Rémy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Package renaming
Posted by "William L. Thomson Jr." <wl...@gentoo.org>.
On Wed, 2006-10-04 at 11:21 -0400, Yoav Shapira wrote:
> Hi,
> Pure neutral zero on this one, so I guess I'm not being particularly
> helpful. On one hand I hate the renaming thing because it feels like
> an ugly hack and it makes life more difficult for downstream
> packagers.
Please, please, please, keep downstream packagers in mind when making
decisions like this.
> On the other hand, we haven't had any DBCP-related
> complaints (besides the one from the downstream repackager last month)
I can't say how big of a problem building that jar is at the present
time on Gentoo given our build systems. Tomcat is one of the few java
apps that we are unable to build all aspects of. Due to repackage
sources, not binaries, from other projects into the final binary result.
I have no foreseeable solution to building that jar on Gentoo at this
time. I have discussed it extensively with others, and we are likely to
have to do some package specific hacks or etc to build that jar. In the
mean time, those needing that jar are having to fetch it from the a
binary release.
I would think re-packaging sources from other Java apps into other
binaries, jars etc would be far from ideal. However if it was
re-packaging, overloading, or etc binaries, that's another story. Much
less of an issue.
Otherwise I would suggest Tomcat package any sources used during
compilation. Even if they are sources from another project. Instead of
pulling them down via ant at build time if they are not present.
Thanks
Also FYI, we had a 0 day release of Tomcat 5.5.20 on Gentoo :)
Along with a 0 day release of mod_jk 1.2.19 as well. Both are still are
keyworded experimental/unstable. In 30 or so days will be stable barring
any major bug reports.
--
William L. Thomson Jr.
Gentoo/Java
Re: Package renaming
Posted by Remy Maucherat <re...@apache.org>.
Yoav Shapira wrote:
> Hi,
> Pure neutral zero on this one, so I guess I'm not being particularly
> helpful. On one hand I hate the renaming thing because it feels like
> an ugly hack and it makes life more difficult for downstream
> packagers. On the other hand, we haven't had any DBCP-related
> complaints (besides the one from the downstream repackager last month)
> since we started repackaging it, which is nice.
At least, the technique has predictable results :/
Rémy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Package renaming
Posted by Yoav Shapira <yo...@apache.org>.
Hi,
Pure neutral zero on this one, so I guess I'm not being particularly
helpful. On one hand I hate the renaming thing because it feels like
an ugly hack and it makes life more difficult for downstream
packagers. On the other hand, we haven't had any DBCP-related
complaints (besides the one from the downstream repackager last month)
since we started repackaging it, which is nice.
Yoav
On 10/4/06, Remy Maucherat <re...@apache.org> wrote:
> Hi,
>
> I think Tomcat would be more robust if commons-logging was package
> renamed (this is the last commons- which is not package renamed at the
> moment, BTW), so I propose doing that.
>
> It would mean integration with alternate loggers in Tomcat is more
> difficult (the wrapper would have to be package renamed too), but OTOH
> it would avoid classloading issues with the webapp. The implementation
> which could be used is the one from tomcat-lite (since it's small and
> robust).
>
> It's a bit power/flexibility vs robustness, here.
>
> Comments ?
>
> Rémy
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Package renaming
Posted by Filip Hanik - Dev Lists <de...@hanik.com>.
I'm all for it, I don't like it, but it prevents version issues when
users slap add in their own versions, hence it makes tomcat itself more
manageable.
Filip
Remy Maucherat wrote:
> Hi,
>
> I think Tomcat would be more robust if commons-logging was package
> renamed (this is the last commons- which is not package renamed at the
> moment, BTW), so I propose doing that.
>
> It would mean integration with alternate loggers in Tomcat is more
> difficult (the wrapper would have to be package renamed too), but OTOH
> it would avoid classloading issues with the webapp. The implementation
> which could be used is the one from tomcat-lite (since it's small and
> robust).
>
> It's a bit power/flexibility vs robustness, here.
>
> Comments ?
>
> Rémy
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org