logging in wsrp4j

[Andrew Petro <an...@yale.edu>]

What's the plan for logging in wsrp4j?

I note that wsrp4j includes its own logging API and implementation

org.apache.wsrp4j.commons.log.*

Is it the case that:

1) WSRP4j has special logging needs fulfilled by this custom logging API 
such that it benefits from and should continue to maintain its own 
logging API instead of using an off-the-shelf logging API (Commons 
Logging or log4j directly).  The advantage of using the internal API is 
the special features it provides.

2) WSRP4j has greatly reduced logging needs such that the flexibility 
and power of something like Commons logging or log4j would be overkill.  
The advantage of using the internal API is simplicity.

or

3) The project would benefit from moving to use Commons Logging 
throughout, and progress on this ist waiting for someone interested in 
making contributions of patches that accomplish this move.  The internal 
API is currently used for legacy reasons -- i.e. it's what the code did 
at some point in the past and it hasn't been changed.

Andrew

Re: logging in wsrp4j

[Elliot Metsger <em...@jhu.edu>]

The wsrp4j logging was one thing that was a little frustrating when I 
worked with wsrp4j a few months ago.  In my day to day work 
commons-logging + log4j is the logging architecture I work with most 
often, and it is rare that I see anything but that -- so for me 
commons-logging would have lowered the barrier to entry for wsrp4j.

I have installed Cocoon but haven't attempted to do much development 
with it, so I have little to no experience with Avalon/Excalibur (Cocoon 
just works, so I haven't needed to dig into it :)

I'd be willing to contribute cycles to moving towards commons-logging as 
well.

Elliot

Carsten Ziegeler wrote:
> Andrew Petro wrote:
> 
>><SNIP/>
>>
>>Thanks for answering.  I'm not looking to push hard for Commons Logging 
>>here if there are reasons for the ad-hoc logging API and developers are 
>>satisfied with that approach.
>>
> 
> I see and understand your point and somehow agree - now, recently I did
> the integration of wsrp4j into the Cocoon portal. Cocoon does not use
> commons logging but Avalon/Excalibur logging. Due to the own logging api
> of wsrp4j it was easy to make wsrp4j use the Cocoon logging system. If
> wsrp4j would have used commons logging, it would be a little bit more
> difficult.
> 
> In the end, I think there are good reasons for both solutions - I'm not
> against moving to commons logging if other developers think it makes
> more sense. So it would be good to hear more opinions.
> 
> Carsten
> 

Re: logging in wsrp4j

[Carsten Ziegeler <cz...@apache.org>]

Andrew Petro wrote:
> 
> <SNIP/>
>
> Thanks for answering.  I'm not looking to push hard for Commons Logging 
> here if there are reasons for the ad-hoc logging API and developers are 
> satisfied with that approach.
> 
I see and understand your point and somehow agree - now, recently I did
the integration of wsrp4j into the Cocoon portal. Cocoon does not use
commons logging but Avalon/Excalibur logging. Due to the own logging api
of wsrp4j it was easy to make wsrp4j use the Cocoon logging system. If
wsrp4j would have used commons logging, it would be a little bit more
difficult.

In the end, I think there are good reasons for both solutions - I'm not
against moving to commons logging if other developers think it makes
more sense. So it would be good to hear more opinions.

Carsten

-- 
Carsten Ziegeler - Open Source Group, S&N AG
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/

Re: logging in wsrp4j

[Andrew Petro <an...@yale.edu>]

Carsten,

>the portal can simply implement the wsrp4j
>logging api and all the wsrp4j logging goes to the logging system of the
>portal.
>

I see your point, that the WSRP4j logging API is an integration API.


Suppose WSRP4j used commons logging.

Then the portal could implement a log4j logger backing commons logging 
if it desires to receive the logging information from wsrp4j.

The same approach also works for other libraries the portal is using and 
the libraries the wsrp4j code uses, depends upon (to the extent that 
they use commons logging.) 

Commonly, the desired "integration" of logging is to get the library's 
logging to show up in the central portal log.  Under a "wsrp4j uses 
Commons logging" approach, the same way I get the Springramework to log 
to my portal's log would be the way I would get wsrp4j to log to my 
portal's log.

If the portal has to implement / integrate with a logging API anyway, 
it's not clear to me that integrating with a custom ad-hoc API is 
preferable to integrating with a more general logging API.  Building the 
bridge from log4j / commons logging to a portal's custom logging needs 
is probably more valuable and reusable across libraries and included 
frameworks than is building a new bridge for each dependency's custom 
logging API.

WSRP4j using Commons Logging directly rather than its own API also 
provides a more valuable baseline in the case where a particular portal 
doesn't undertake special efforts to integrate with WSRP4j's logging.

>If we would move to let's say commons logging this would force
>the portal solution to use/configure commons logging as well.
>

I don't see the efficiency.  A portal has to integrate with some logging 
API to integrate WSRP4j's logging into itself.  Why should a portal 
developer be more pleased at doing so with a custom WSRP4j API than a 
general one?  Figuring out how to configure and configuring wsrp4j's 
logging isn't that different from figuring out how to configure and 
configuring commons logging.

>As wsrp4j is a framework that has to be embedded somewhere else, it
>makes imho sense to have an own logging api to be more flexible.
>

Maybe.  A balance to be struck, perhaps, between the flexibility of an 
ad-hoc integration logging API and the effieciency of just using an 
existing API (with which a portal developer or deployer might already 
have familiarity / developer plugins to use.)

Thanks for answering.  I'm not looking to push hard for Commons Logging 
here if there are reasons for the ad-hoc logging API and developers are 
satisfied with that approach.

Andrew

>Hmm, I think, wsrp4j uses it's own logging api to be more environment
>friendly when embedded into another solution. WSRP4J can be integrated
>into a portal solution. Now, the portal can simply implement the wsrp4j
>logging api and all the wsrp4j logging goes to the logging system of the
>portal. If we would move to let's say commons logging this would force
>the portal solution to use/configure commons logging as well.
>As wsrp4j is a framework that has to be embedded somewhere else, it
>makes imho sense to have an own logging api to be more flexible.
>
>Carsten
>
>  
>

Re: logging in wsrp4j

[Carsten Ziegeler <cz...@apache.org>]

Andrew Petro wrote:
> What's the plan for logging in wsrp4j?
> 
> I note that wsrp4j includes its own logging API and implementation
> 
> org.apache.wsrp4j.commons.log.*
> 
> Is it the case that:
> 
> 1) WSRP4j has special logging needs fulfilled by this custom logging API 
> such that it benefits from and should continue to maintain its own 
> logging API instead of using an off-the-shelf logging API (Commons 
> Logging or log4j directly).  The advantage of using the internal API is 
> the special features it provides.
> 
> 2) WSRP4j has greatly reduced logging needs such that the flexibility 
> and power of something like Commons logging or log4j would be overkill.  
> The advantage of using the internal API is simplicity.
> 
> or
> 
> 3) The project would benefit from moving to use Commons Logging 
> throughout, and progress on this ist waiting for someone interested in 
> making contributions of patches that accomplish this move.  The internal 
> API is currently used for legacy reasons -- i.e. it's what the code did 
> at some point in the past and it hasn't been changed.
> 
Hmm, I think, wsrp4j uses it's own logging api to be more environment
friendly when embedded into another solution. WSRP4J can be integrated
into a portal solution. Now, the portal can simply implement the wsrp4j
logging api and all the wsrp4j logging goes to the logging system of the
portal. If we would move to let's say commons logging this would force
the portal solution to use/configure commons logging as well.
As wsrp4j is a framework that has to be embedded somewhere else, it
makes imho sense to have an own logging api to be more flexible.

Carsten

-- 
Carsten Ziegeler - Open Source Group, S&N AG
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/