logj, EJBs, JBoss revisited (design issues)

[Stefan Puiu <st...@axetel.com>]

Hello,

We are currently developping an EJB application running on JBoss 3.2.2 
and using log4j for logging. When the project logging system was 
designed, it was decided that we were to use our own custom 
LoggerFactory (a practice that I've seen is both discouraged and 
undocumented), which led us to some trouble. First, all our apps would 
throw class loading-related exceptions when hot-redeployed - that was 
fortunately fixed with help from this list by using our own custom 
RepositorySelector. Unfortunately, that didn't make all the class loader 
issues go away, right now we get random NoClassDefFoundErrors for the 
custom logger class when using the web app part. I've attached a stack 
trace, I'm pretty sure this isn't 100% a log4j issue but is mostly 
related to log4j-JBoss interaction, but on the JBoss-user list I haven't 
had any luck with these kind of issues.

For people that have worked with JBoss, our apps are packaged as ears, I 
have a common set of logging classes (our custom Logger, LoggerFactory, 
not log4j classes) that get built in different jars (same classes, 
different descriptors) and put in each ear. To avoid classloading 
issues, the ears are scoped - JBoss creates a separate class repository, 
and classes inside the ear cannot be read by the default class loader 
(and accessed by classes loaded by it). The AccessControl class is 
inside the scoped ear, of course.

Now, I have (roughly) two questions: the first one is whether there's an 
obvious issue with the scenario above - probably not many people are 
using a similar approach, but I see LoggerFactories are pretty used by 
people on the list, so I think there's a chance that I get a response.

The second one is related to finding a different solution using log4j. 
We needed to have a custom logger for two main reasons:

1) supplementary pattern converters (besides the parameters supported by 
log4j, we need a supplementary set specific to our app)
2) logging to a database; jdbcAppender is said to be experimental and 
subject to change in future versions, so we couldn't have used it 
without risking to have to change the code with newer log4j versions.

Now, is there a solution to address these requirements without recurring 
to a custom logger and logger factory?

Re: logj, EJBs, JBoss revisited (design issues)

[Elias Ross <er...@m-qube.com>]

On Wed, 2003-11-19 at 02:08, Stefan Puiu wrote:
> 
> The second one is related to finding a different solution using log4j. 
> We needed to have a custom logger for two main reasons:
> 
> 1) supplementary pattern converters (besides the parameters supported by 
> log4j, we need a supplementary set specific to our app)
> 2) logging to a database; jdbcAppender is said to be experimental and 
> subject to change in future versions, so we couldn't have used it 
> without risking to have to change the code with newer log4j versions.


Can't you just write your own pattern converter and appender and stick
only those few (2) classes in a .jar file, deploy them in
$JBOSS_DIST/server/default/lib, and _not_ write your own Logger class?
Assuming you don't need to change these very often, it may work better
to have them static.

I'm not sure how reliable it is to have hot-redeployed appenders and
pattern converters.  People have a difficult enough time as-is without
layering on class loading complexity.




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

Re: logj, EJBs, JBoss revisited (design issues)

[Stefan Puiu <st...@axetel.com>]

Hello and thanks for replying,

Well, our design is slightly more complicated, since the logging classes 
also need database access, and the logging classes in module A uses for 
example the datasource java:/A, so as the logging part is designed right 
now you can't view the classes as a library but as an EJB component that 
is customized for each app it runs with. It's probably a bad design 
choice and a JBoss issue, after all.

[I've written and sent this reply a few days ago, but used "Reply to 
Sender Only", my mistake...]

Elias Ross wrote:

>On Wed, 2003-11-19 at 02:08, Stefan Puiu wrote:
>  
>
>>The second one is related to finding a different solution using log4j. 
>>We needed to have a custom logger for two main reasons:
>>
>>1) supplementary pattern converters (besides the parameters supported by 
>>log4j, we need a supplementary set specific to our app)
>>2) logging to a database; jdbcAppender is said to be experimental and 
>>subject to change in future versions, so we couldn't have used it 
>>without risking to have to change the code with newer log4j versions.
>>    
>>
>
>
>Can't you just write your own pattern converter and appender and stick
>only those few (2) classes in a .jar file, deploy them in
>$JBOSS_DIST/server/default/lib, and _not_ write your own Logger class?
>Assuming you don't need to change these very often, it may work better
>to have them static.
>
>I'm not sure how reliable it is to have hot-redeployed appenders and
>pattern converters.  People have a difficult enough time as-is without
>layering on class loading complexity.
>
>
>
>  
>



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