You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Anton Tagunov <at...@mail.cnt.ru> on 2003/07/01 10:08:44 UTC
Re[2]: Logging packaging questions
Hello Nicolas!
AT> Now, did I get it right that _despite_ jakarta-logging will be shipped
AT> as a single jar all your stuff _will_ work okay since jakarta-logging
AT> will detect what is available on the classpath and what is not?
NM> Basically if/when we had split the backends we'd had provided a backends
NM> symlinks pointing either to log4j, jvm or build-in (with automated
NM> priorities). This symlink would have been added to all the logging users
NM> classpaths/jer directories
NM> So we would have insured there was always a backend on the system,
NM> without duplicating classes.
NM> The current solution will be the death of log4j since no one will take
NM> the pain to put it manually in the classpath (as it would have, if the
NM> split had proceeded)
I'm sorry, Nicolas, I do not get you.
What is the difference between putting
jakarta-logging-log4j.jar
into the classpath that automatically pulls in log4j.jar
and putting there
log4j
jar directly?
What has changed? Why one is more difficult for users of your
framework then the other?
-Anton
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re[6]: [JPackage-discuss] Re[2]: Logging packaging questions
Posted by Anton Tagunov <at...@mail.cnt.ru>.
Hello Nicolas!
AT> Just hold on a minute, and if the user wanted to use Jdk14 logging
AT> where would the common-loggin-backend point to?
NM> To the in-jvm jar that provides logging - that works for jdbc, jsse,
NM> jndi , etc.
Uggghhmmm... I thought it was the case with 1.3 -- al this was
added via additional jars. As for 1.4 all is in rt.jar, isn't it?
Then you would probably need some very simplistic (empty)
dummy.jar to wire your dangling links too, I think.
See my mail on the other thread, probably the clue to your
problem is there!
Good luck! :-)
-Anton
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: Re[4]: [JPackage-discuss] Re[2]: Logging packaging questions
Posted by Nicolas Mailhot <Ni...@laposte.net>.
Le mar 01/07/2003 à 12:07, Anton Tagunov a écrit :
> Hi!
>
> NM> A symlink points to whatever logging-commons-backend jar is installed
> NM> (more complex than that but lets just say the symlink *will* exist and
> NM> point to the jar with the highest priority)
> AT>
> AT> Would this symlink point to commons-logging-log4j.jar or to log4j.jar?
>
> NM> If we do the full split we'd have
> NM> - common-loggin main jar
> NM> - common-loggin-glue symlink
> NM> - common-loggin-backend symlink
>
> NM> with common-loggin-glue & common-loggin-backend synchronized so if
> NM> common-loggin-backend points to log4j common-loggin-glue points to the
> NM> log4j glue in common-loggin
>
> NM> One or two symlinks - that's peanuts.
> NM> What we can not handle is one jar present in some cases (log4j) and not
> NM> in others. We need the symlinks to always point to something - dangling
> NM> symlinks make tomcat crash
>
> Just hold on a minute, and if the user wanted to use Jdk14 logging
> where would the common-loggin-backend point to?
To the in-jvm jar that provides logging - that works for jdbc, jsse,
jndi , etc.
Cheers,
--
Nicolas Mailhot
Re[4]: [JPackage-discuss] Re[2]: Logging packaging questions
Posted by Anton Tagunov <at...@mail.cnt.ru>.
Hi!
NM> A symlink points to whatever logging-commons-backend jar is installed
NM> (more complex than that but lets just say the symlink *will* exist and
NM> point to the jar with the highest priority)
AT>
AT> Would this symlink point to commons-logging-log4j.jar or to log4j.jar?
NM> If we do the full split we'd have
NM> - common-loggin main jar
NM> - common-loggin-glue symlink
NM> - common-loggin-backend symlink
NM> with common-loggin-glue & common-loggin-backend synchronized so if
NM> common-loggin-backend points to log4j common-loggin-glue points to the
NM> log4j glue in common-loggin
NM> One or two symlinks - that's peanuts.
NM> What we can not handle is one jar present in some cases (log4j) and not
NM> in others. We need the symlinks to always point to something - dangling
NM> symlinks make tomcat crash
Just hold on a minute, and if the user wanted to use Jdk14 logging
where would the common-loggin-backend point to?
-Anton
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: Re[2]: [JPackage-discuss] Re[2]: Logging packaging questions
Posted by Nicolas Mailhot <Ni...@laposte.net>.
Le mar 01/07/2003 à 11:37, Anton Tagunov a écrit :
> Hello Nicolas!
>
> NM> A symlink points to whatever logging-commons-backend jar is installed
> NM> (more complex than that but lets just say the symlink *will* exist and
> NM> point to the jar with the highest priority)
>
> Would this symlink point to commons-logging-log4j.jar or to log4j.jar?
> (Just thinking your worlds over)
If we do the full split we'd have
- common-loggin main jar
- common-loggin-glue symlink
- common-loggin-backend symlink
with common-loggin-glue & common-loggin-backend synchronized so if
common-loggin-backend points to log4j common-loggin-glue points to the
log4j glue in common-loggin
One or two symlinks - that's peanuts.
What we can not handle is one jar present in some cases (log4j) and not
in others. We need the symlinks to always point to something - dangling
symlinks make tomcat crash
Regards,
--
Nicolas Mailhot
Re[2]: [JPackage-discuss] Re[2]: Logging packaging questions
Posted by Anton Tagunov <at...@mail.cnt.ru>.
Hello Nicolas!
NM> A symlink points to whatever logging-commons-backend jar is installed
NM> (more complex than that but lets just say the symlink *will* exist and
NM> point to the jar with the highest priority)
Would this symlink point to commons-logging-log4j.jar or to log4j.jar?
(Just thinking your worlds over)
-Anton
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [JPackage-discuss] Re[2]: Logging packaging questions
Posted by Nicolas Mailhot <Ni...@laposte.net>.
Le mar 01/07/2003 à 10:08, Anton Tagunov a écrit :
> Hello Nicolas!
>
> AT> Now, did I get it right that _despite_ jakarta-logging will be shipped
> AT> as a single jar all your stuff _will_ work okay since jakarta-logging
> AT> will detect what is available on the classpath and what is not?
>
> NM> Basically if/when we had split the backends we'd had provided a backends
> NM> symlinks pointing either to log4j, jvm or build-in (with automated
> NM> priorities). This symlink would have been added to all the logging users
> NM> classpaths/jer directories
>
> NM> So we would have insured there was always a backend on the system,
> NM> without duplicating classes.
>
> NM> The current solution will be the death of log4j since no one will take
> NM> the pain to put it manually in the classpath (as it would have, if the
> NM> split had proceeded)
>
> I'm sorry, Nicolas, I do not get you.
> What is the difference between putting
> jakarta-logging-log4j.jar
> into the classpath that automatically pulls in log4j.jar
> and putting there
> log4j
> jar directly?
>
> What has changed? Why one is more difficult for users of your
> framework then the other?
With a properly modularized setup we can do :
package logging-commons requires logging-commons-backend
split build-in, log4j, jvm, provide logging-commons-backend
A symlink points to whatever logging-commons-backend jar is installed
(more complex than that but lets just say the symlink *will* exist and
point to the jar with the highest priority)
All apps are packaged so they have the symlink in their classpath or
their jar repository.
log4j have > priority than other backends for the symlink.
So if log4j is installed, it'll be used by every app.
Now since we do not have this symlink people have to add log4j manually
if they absolutely want it, and since they are as lazy as the next guy
they won't.
Goodbye log4j. RIP
Regards,
--
Nicolas Mailhot
Re: [JPackage-discuss] Re[2]: Logging packaging questions
Posted by Nicolas Mailhot <Ni...@laposte.net>.
Le mar 01/07/2003 à 10:08, Anton Tagunov a écrit :
> Hello Nicolas!
>
> AT> Now, did I get it right that _despite_ jakarta-logging will be shipped
> AT> as a single jar all your stuff _will_ work okay since jakarta-logging
> AT> will detect what is available on the classpath and what is not?
>
> NM> Basically if/when we had split the backends we'd had provided a backends
> NM> symlinks pointing either to log4j, jvm or build-in (with automated
> NM> priorities). This symlink would have been added to all the logging users
> NM> classpaths/jer directories
>
> NM> So we would have insured there was always a backend on the system,
> NM> without duplicating classes.
>
> NM> The current solution will be the death of log4j since no one will take
> NM> the pain to put it manually in the classpath (as it would have, if the
> NM> split had proceeded)
>
> I'm sorry, Nicolas, I do not get you.
> What is the difference between putting
> jakarta-logging-log4j.jar
> into the classpath that automatically pulls in log4j.jar
> and putting there
> log4j
> jar directly?
>
> What has changed? Why one is more difficult for users of your
> framework then the other?
With a properly modularized setup we can do :
package logging-commons requires logging-commons-backend
split build-in, log4j, jvm, provide logging-commons-backend
A symlink points to whatever logging-commons-backend jar is installed
(more complex than that but lets just say the symlink *will* exist and
point to the jar with the highest priority)
All apps are packaged so they have the symlink in their classpath or
their jar repository.
log4j have > priority than other backends for the symlink.
So if log4j is installed, it'll be used by every app.
Now since we do not have this symlink people have to add log4j manually
if they absolutely want it, and since they are as lazy as the next guy
they won't.
Goodbye log4j. RIP
Regards,
--
Nicolas Mailhot