You are viewing a plain text version of this content. The canonical link for it is here.
Posted to -deprecated@jakarta.apache.org by Sam Ruby <ru...@us.ibm.com> on 2001/02/21 14:44:59 UTC
Re: logging in pool.jar
Jon Stevens wrote:
>
> Martin Poeschl wrote:
>
> > the pool.jar includes util.Log but it doesn't include services.logging.
*
> >
> > should the logging-service be included??
> >
> > martin
>
> Ug. Yucky *necessary* dependencies. I'm starting to feel like the
> pool.jar cannot be abstracted from Turbine any longer. That bugs
> me and I don't know a solution other than to disable logging in
> the pool. After all of the discussion on general@jakarta, I'm
> starting to feel like no one in J2EE land is interested in this
> pool any longer anyway. Anyone have other ideas, suggestions or
> comments?
Either:
1) We need to make the abstraction for logging independent of Turbine and a
Jakarta "standard".
2) Standardize Jakarta on a single concrete implementation
(jakarta-log4j?).
or
3) as you stated, not do logging in reusable components. (YUCK).
I'm copying the library-dev mailing list as the people there will obviously
need to grapple with these types of issues.
- Sam Ruby
Re: logging in pool.jar
Posted by Ceki Gülcü <cg...@qos.ch>.
At 02:05 22.02.2001 +1100, you wrote:
>At 09:39 21/2/01 -0500, Ted Husted wrote:
>>Sam Ruby wrote:
>>> 1) We need to make the abstraction for logging independent of Turbine and a
>>> Jakarta "standard".
>>>
>>> 2) Standardize Jakarta on a single concrete implementation
>>> (jakarta-log4j?).
>>
>>I'd say we do (1) based on (2), and the propose (1) as a Sun JSR. Log4j
>>then becomes the reference implementation ;0)
>
>There is already a logging JSR but log4j does not implement it ;)
AFAIK, JSR47 is an implementation not an interface. I have asked Graham Hamilton to let me peek at JSR47's implementation but he did not reply. It is also not clear to what extent JSR47 is tied to JDK 1.4. Log4j is compatible with JDK 1.1.
JSR47 and log4j are very similar at the architectural level. They differ in small and even minute details. The problem is that as far as the Java compiler is concerned they are not interchangeable.
I am not sure it makes sense for us to re-implement JSR47 with log4j underneath. What good would that do? Some JSR47 fields rely on JDK 1.4. I don't have access to Merlin nor to JSR 47 code.
What would make sense is to adapt log4j configurators, appenders and layouts to JSR47 when it comes out. That's where 90% percent of the code is.
JSR47 is OK on paper. However, I do not see anyone from Sun talking to us to see if we can work together. They are doing their thing and hope that the rest of the world will follow. Cheers, Ceki
Re: logging in pool.jar
Posted by Ceki Gülcü <cg...@qos.ch>.
At 02:05 22.02.2001 +1100, you wrote:
>At 09:39 21/2/01 -0500, Ted Husted wrote:
>>Sam Ruby wrote:
>>> 1) We need to make the abstraction for logging independent of Turbine and a
>>> Jakarta "standard".
>>>
>>> 2) Standardize Jakarta on a single concrete implementation
>>> (jakarta-log4j?).
>>
>>I'd say we do (1) based on (2), and the propose (1) as a Sun JSR. Log4j
>>then becomes the reference implementation ;0)
>
>There is already a logging JSR but log4j does not implement it ;)
AFAIK, JSR47 is an implementation not an interface. I have asked Graham Hamilton to let me peek at JSR47's implementation but he did not reply. It is also not clear to what extent JSR47 is tied to JDK 1.4. Log4j is compatible with JDK 1.1.
JSR47 and log4j are very similar at the architectural level. They differ in small and even minute details. The problem is that as far as the Java compiler is concerned they are not interchangeable.
I am not sure it makes sense for us to re-implement JSR47 with log4j underneath. What good would that do? Some JSR47 fields rely on JDK 1.4. I don't have access to Merlin nor to JSR 47 code.
What would make sense is to adapt log4j configurators, appenders and layouts to JSR47 when it comes out. That's where 90% percent of the code is.
JSR47 is OK on paper. However, I do not see anyone from Sun talking to us to see if we can work together. They are doing their thing and hope that the rest of the world will follow. Cheers, Ceki
Re: logging in pool.jar
Posted by Peter Donald <do...@apache.org>.
At 09:39 21/2/01 -0500, Ted Husted wrote:
>Sam Ruby wrote:
>> 1) We need to make the abstraction for logging independent of Turbine and a
>> Jakarta "standard".
>>
>> 2) Standardize Jakarta on a single concrete implementation
>> (jakarta-log4j?).
>
>I'd say we do (1) based on (2), and the propose (1) as a Sun JSR. Log4j
>then becomes the reference implementation ;0)
There is already a logging JSR but log4j does not implement it ;)
Cheers,
Pete
*-----------------------------------------------------*
| "Faced with the choice between changing one's mind, |
| and proving that there is no need to do so - almost |
| everyone gets busy on the proof." |
| - John Kenneth Galbraith |
*-----------------------------------------------------*
Re: logging in pool.jar
Posted by Peter Donald <do...@apache.org>.
At 09:39 21/2/01 -0500, Ted Husted wrote:
>Sam Ruby wrote:
>> 1) We need to make the abstraction for logging independent of Turbine and a
>> Jakarta "standard".
>>
>> 2) Standardize Jakarta on a single concrete implementation
>> (jakarta-log4j?).
>
>I'd say we do (1) based on (2), and the propose (1) as a Sun JSR. Log4j
>then becomes the reference implementation ;0)
There is already a logging JSR but log4j does not implement it ;)
Cheers,
Pete
*-----------------------------------------------------*
| "Faced with the choice between changing one's mind, |
| and proving that there is no need to do so - almost |
| everyone gets busy on the proof." |
| - John Kenneth Galbraith |
*-----------------------------------------------------*
Re: logging in pool.jar
Posted by Ted Husted <ne...@husted.com>.
Sam Ruby wrote:
> 1) We need to make the abstraction for logging independent of Turbine and a
> Jakarta "standard".
>
> 2) Standardize Jakarta on a single concrete implementation
> (jakarta-log4j?).
I'd say we do (1) based on (2), and the propose (1) as a Sun JSR. Log4j
then becomes the reference implementation ;0)
In practice, we are doing a similar thing with Struts and Taglibs. In
effect, these products are doing practical research for JSR#052. When
the standard set of tags is release, Struts will move quickly to fall in
line, since our users expect us to support the standards first. People
are already using Struts as a standards-compatabilty test for their
containers. I think that's a good rep for a Jakarta product to have.
To take a page from Apache XML:
"to provide feedback to standards bodies from an implementation
perspective".
-T.
Re: logging in pool.jar
Posted by Ted Husted <ne...@husted.com>.
Sam Ruby wrote:
> 1) We need to make the abstraction for logging independent of Turbine and a
> Jakarta "standard".
>
> 2) Standardize Jakarta on a single concrete implementation
> (jakarta-log4j?).
I'd say we do (1) based on (2), and the propose (1) as a Sun JSR. Log4j
then becomes the reference implementation ;0)
In practice, we are doing a similar thing with Struts and Taglibs. In
effect, these products are doing practical research for JSR#052. When
the standard set of tags is release, Struts will move quickly to fall in
line, since our users expect us to support the standards first. People
are already using Struts as a standards-compatabilty test for their
containers. I think that's a good rep for a Jakarta product to have.
To take a page from Apache XML:
"to provide feedback to standards bodies from an implementation
perspective".
-T.
Re: logging in pool.jar
Posted by Peter Donald <do...@apache.org>.
Hi,
this is the *exact* thing I was concerned about in my previous email in
regarding the approach for developing components. At a certain stage when
components are complex enough they begin relying on infrastructure. In this
case the need to integrate with the turbine service directory and the
logging service. They already integrate with the config and component model.
Basically before we proceed we need to decide what we would od in a case
like this?
At 08:44 21/2/01 -0500, Sam Ruby wrote:
>Jon Stevens wrote:
>>
>> Martin Poeschl wrote:
>>
>> > the pool.jar includes util.Log but it doesn't include services.logging.
>*
>> >
>> > should the logging-service be included??
>> >
>> > martin
>>
>> Ug. Yucky *necessary* dependencies. I'm starting to feel like the
>> pool.jar cannot be abstracted from Turbine any longer. That bugs
>> me and I don't know a solution other than to disable logging in
>> the pool. After all of the discussion on general@jakarta, I'm
>> starting to feel like no one in J2EE land is interested in this
>> pool any longer anyway. Anyone have other ideas, suggestions or
>> comments?
>
>
>Either:
>
>1) We need to make the abstraction for logging independent of Turbine and a
>Jakarta "standard".
>
>2) Standardize Jakarta on a single concrete implementation
>(jakarta-log4j?).
>
>or
>
>3) as you stated, not do logging in reusable components. (YUCK).
>
>I'm copying the library-dev mailing list as the people there will obviously
>need to grapple with these types of issues.
>
>- Sam Ruby
>
>
Cheers,
Pete
*-----------------------------------------------------*
| "Faced with the choice between changing one's mind, |
| and proving that there is no need to do so - almost |
| everyone gets busy on the proof." |
| - John Kenneth Galbraith |
*-----------------------------------------------------*
Connection Pooling (was: Re: logging in pool.jar)
Posted by Jon Stevens <jo...@latchkey.com>.
on 2/21/01 5:44 AM, "Sam Ruby" <ru...@us.ibm.com> wrote:
> Jon Stevens wrote:
>>
>> Martin Poeschl wrote:
>>
>>> the pool.jar includes util.Log but it doesn't include services.logging.
> *
>>>
>>> should the logging-service be included??
>>>
>>> martin
>>
>> Ug. Yucky *necessary* dependencies. I'm starting to feel like the
>> pool.jar cannot be abstracted from Turbine any longer. That bugs
>> me and I don't know a solution other than to disable logging in
>> the pool. After all of the discussion on general@jakarta, I'm
>> starting to feel like no one in J2EE land is interested in this
>> pool any longer anyway. Anyone have other ideas, suggestions or
>> comments?
>
>
> Either:
>
> 1) We need to make the abstraction for logging independent of Turbine and a
> Jakarta "standard".
>
> 2) Standardize Jakarta on a single concrete implementation
> (jakarta-log4j?).
>
> or
>
> 3) as you stated, not do logging in reusable components. (YUCK).
>
> I'm copying the library-dev mailing list as the people there will obviously
> need to grapple with these types of issues.
>
> - Sam Ruby
Or, #4. Excuse my French: F*ck it.
Getting a connection from a Connection pool really is a thing of the past in
Turbine land (and potentially other lands when people finally get a clue
(tm)).
The reason is that tools like Turbine's Peer model completely abstract the
necessity of getting a Connection to a database and the need to return it.
It becomes something that the developer never has to worry about because the
underlying system takes care of it for you.
Therefore, it really does not matter how or where you get the
connection...just that the Peer object can get a connection. The
"old-non-j2ee" style that we are currently using in Turbine works perfectly
fine and even if we do need to plug in a different connection mechanism in
the future, it simply means changing some auto generated code. Not a big
deal. I don't see a reason at this point to change it or even switch to
something else. I really don't see the need to have JNDI or Container
managed connections.
Prove me wrong.
thanks,
-jon
--
If you come from a Perl or PHP background, JSP is a way to take
your pain to new levels. --Anonymous
<http://jakarta.apache.org/velocity/> && <http://java.apache.org/turbine/>
Re: logging in pool.jar
Posted by Peter Donald <do...@apache.org>.
Hi,
this is the *exact* thing I was concerned about in my previous email in
regarding the approach for developing components. At a certain stage when
components are complex enough they begin relying on infrastructure. In this
case the need to integrate with the turbine service directory and the
logging service. They already integrate with the config and component model.
Basically before we proceed we need to decide what we would od in a case
like this?
At 08:44 21/2/01 -0500, Sam Ruby wrote:
>Jon Stevens wrote:
>>
>> Martin Poeschl wrote:
>>
>> > the pool.jar includes util.Log but it doesn't include services.logging.
>*
>> >
>> > should the logging-service be included??
>> >
>> > martin
>>
>> Ug. Yucky *necessary* dependencies. I'm starting to feel like the
>> pool.jar cannot be abstracted from Turbine any longer. That bugs
>> me and I don't know a solution other than to disable logging in
>> the pool. After all of the discussion on general@jakarta, I'm
>> starting to feel like no one in J2EE land is interested in this
>> pool any longer anyway. Anyone have other ideas, suggestions or
>> comments?
>
>
>Either:
>
>1) We need to make the abstraction for logging independent of Turbine and a
>Jakarta "standard".
>
>2) Standardize Jakarta on a single concrete implementation
>(jakarta-log4j?).
>
>or
>
>3) as you stated, not do logging in reusable components. (YUCK).
>
>I'm copying the library-dev mailing list as the people there will obviously
>need to grapple with these types of issues.
>
>- Sam Ruby
>
>
Cheers,
Pete
*-----------------------------------------------------*
| "Faced with the choice between changing one's mind, |
| and proving that there is no need to do so - almost |
| everyone gets busy on the proof." |
| - John Kenneth Galbraith |
*-----------------------------------------------------*
Re: logging in pool.jar
Posted by Ceki Gülcü <cg...@qos.ch>.
At 08:44 21.02.2001 -0500, Sam Ruby wrote:
>Either:
>
>1) We need to make the abstraction for logging independent of Turbine and a
>Jakarta "standard".
>
>2) Standardize Jakarta on a single concrete implementation
>(jakarta-log4j?).
>
>or
>
>3) as you stated, not do logging in reusable components. (YUCK).
Doing nothing, that is option 3, is always a possibility but boils down to ignoring the problem which at times is the best approach.
Option 2 would be the most favorable to log4j. The log4j package offers a very simple logging paradigm:
A) Get a named category instance
B) Log a message using the category instance retrieved previously.
Step B can be repeated as many times as desired without redoing step B.
Logging parameters are configured using a configuration file that can be interpreted at any time, in particular while the application is still running. Thus, using the same category instance it is possible to log to a file in one configuration and yet in another configuration it is possible to collect logs in a buffer and send the buffer as an email message when an error occurs, output the logs to multiple files, to another server, or to the Unix syslog among a gazillion other targets.
Many projects encapsulate log4j in wrappers. I guess that approach is similar to option 1. The wrapper is the interface and the underlying implementation is log4j. As far as I know, Turbine is doing exactly that. However, I don't think Turbine is using log4j configuration files. In case just let me know if you need any changes made to log4j. Cheers, Ceki
----
Ceki Gülcü Web: http://qos.ch
av. de Rumine 5 email: cgu@qos.ch (preferred)
CH-1005 Lausanne ceki_gulcu@yahoo.com
Switzerland Tel: ++41 21 351 23 15
Re: logging in pool.jar
Posted by Ceki Gülcü <cg...@qos.ch>.
At 08:44 21.02.2001 -0500, Sam Ruby wrote:
>Either:
>
>1) We need to make the abstraction for logging independent of Turbine and a
>Jakarta "standard".
>
>2) Standardize Jakarta on a single concrete implementation
>(jakarta-log4j?).
>
>or
>
>3) as you stated, not do logging in reusable components. (YUCK).
Doing nothing, that is option 3, is always a possibility but boils down to ignoring the problem which at times is the best approach.
Option 2 would be the most favorable to log4j. The log4j package offers a very simple logging paradigm:
A) Get a named category instance
B) Log a message using the category instance retrieved previously.
Step B can be repeated as many times as desired without redoing step B.
Logging parameters are configured using a configuration file that can be interpreted at any time, in particular while the application is still running. Thus, using the same category instance it is possible to log to a file in one configuration and yet in another configuration it is possible to collect logs in a buffer and send the buffer as an email message when an error occurs, output the logs to multiple files, to another server, or to the Unix syslog among a gazillion other targets.
Many projects encapsulate log4j in wrappers. I guess that approach is similar to option 1. The wrapper is the interface and the underlying implementation is log4j. As far as I know, Turbine is doing exactly that. However, I don't think Turbine is using log4j configuration files. In case just let me know if you need any changes made to log4j. Cheers, Ceki
----
Ceki Gülcü Web: http://qos.ch
av. de Rumine 5 email: cgu@qos.ch (preferred)
CH-1005 Lausanne ceki_gulcu@yahoo.com
Switzerland Tel: ++41 21 351 23 15
Connection Pooling (was: Re: logging in pool.jar)
Posted by Jon Stevens <jo...@latchkey.com>.
on 2/21/01 5:44 AM, "Sam Ruby" <ru...@us.ibm.com> wrote:
> Jon Stevens wrote:
>>
>> Martin Poeschl wrote:
>>
>>> the pool.jar includes util.Log but it doesn't include services.logging.
> *
>>>
>>> should the logging-service be included??
>>>
>>> martin
>>
>> Ug. Yucky *necessary* dependencies. I'm starting to feel like the
>> pool.jar cannot be abstracted from Turbine any longer. That bugs
>> me and I don't know a solution other than to disable logging in
>> the pool. After all of the discussion on general@jakarta, I'm
>> starting to feel like no one in J2EE land is interested in this
>> pool any longer anyway. Anyone have other ideas, suggestions or
>> comments?
>
>
> Either:
>
> 1) We need to make the abstraction for logging independent of Turbine and a
> Jakarta "standard".
>
> 2) Standardize Jakarta on a single concrete implementation
> (jakarta-log4j?).
>
> or
>
> 3) as you stated, not do logging in reusable components. (YUCK).
>
> I'm copying the library-dev mailing list as the people there will obviously
> need to grapple with these types of issues.
>
> - Sam Ruby
Or, #4. Excuse my French: F*ck it.
Getting a connection from a Connection pool really is a thing of the past in
Turbine land (and potentially other lands when people finally get a clue
(tm)).
The reason is that tools like Turbine's Peer model completely abstract the
necessity of getting a Connection to a database and the need to return it.
It becomes something that the developer never has to worry about because the
underlying system takes care of it for you.
Therefore, it really does not matter how or where you get the
connection...just that the Peer object can get a connection. The
"old-non-j2ee" style that we are currently using in Turbine works perfectly
fine and even if we do need to plug in a different connection mechanism in
the future, it simply means changing some auto generated code. Not a big
deal. I don't see a reason at this point to change it or even switch to
something else. I really don't see the need to have JNDI or Container
managed connections.
Prove me wrong.
thanks,
-jon
--
If you come from a Perl or PHP background, JSP is a way to take
your pain to new levels. --Anonymous
<http://jakarta.apache.org/velocity/> && <http://java.apache.org/turbine/>