Re: cvs commit: jakarta-turbine/src/java/org/apache/turbine/services/xmlrpc/util FileTransfer.java

[Jon Stevens <jo...@latchkey.com>]

on 7/17/01 4:01 PM, "jvanzyl@apache.org" <jv...@apache.org> wrote:

> - using a separate Log.java file in the services to help decouple
>   until we have a better way to pass on parent application information/objects
>   to components. will probably borrow ideas from avalon but use log4j
>   for logging.

How about making the BaseService class responsible for providing methods for
logging? That way, all the Services just inherit it and the initialization
of the services can depend on being passed in a Log4J logging object?

I'm not really that fond of having duplicate classes all over the place.

-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/ymtd/ymtd.html>


---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org

Re: cvs commit: jakarta-turbine/src/java/org/apache/turbine/services/xmlrpc/util FileTransfer.java

[Jason van Zyl <jv...@apache.org>]

On 7/17/01 7:13 PM, "Jon Stevens" <jo...@latchkey.com> wrote:

> on 7/17/01 4:01 PM, "jvanzyl@apache.org" <jv...@apache.org> wrote:
> 
>> - using a separate Log.java file in the services to help decouple
>>   until we have a better way to pass on parent application
>> information/objects
>>   to components. will probably borrow ideas from avalon but use log4j
>>   for logging.
> 
> How about making the BaseService class responsible for providing methods for
> logging? That way, all the Services just inherit it and the initialization
> of the services can depend on being passed in a Log4J logging object?

The BaseService already has methods for providing logging, take a look. The
category is provided by the ServiceBroker, and this code is used throughout
the services code with a service implementation:
getCategory.debug("message").

The problem is not with the service code, the problem is with utilities
used by the services. The DB service is a good example where there are
lots of utility classes that leverage the Log.X() static methods. These
methods might be useful outside the services. Again it's a question
of coupling, we could easily have a reference to the ServiceBroker in
all of these classes to get hold of a category for logging but that doesn't
sound very appealing to me.

I think we either go the component way like Avalon where you have a base
component and it might have methods like:

setCategory(Category category)

So that a component can log independently of the services if it's used
somewhere else. We could also use the standard log4j way of using
Category.getInstance(X) where X is some place in the logging hierarchy.
 
> I'm not really that fond of having duplicate classes all over the place.

As I said it says in the code it's a stop gap so that I can separate
the services. Once they are separated I hope that more people will look
at them and help find an elegant solution for logging in classes that
are useful on their own but utilized by the services. It gets me another
step closer to decoupling without having to change a lot of the service
code. That code won't be living long.
 
> -jon

-- 

jvz.

Jason van Zyl

http://tambora.zenplex.org
http://jakarta.apache.org/turbine
http://jakarta.apache.org/velocity
http://jakarta.apache.org/alexandria
http://jakarta.apache.org/commons



---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org