> > 2) Log4j > > The best way to do logging for a bean (at the moment) > > private static final Category log = Category.newInstance(MyClass.class); > > > >The following accomplishes the same thing, and can be cut and pasted from >one source to the next. > > private static final Category log = >Category.getInstance(getClass().getName());
Blind leading the Blind :-) Of course, it is getInstance() not newInstance() But you cannot use getClass() from a static context, you need an object for that :-( The reason for static is to avoid serialization problems. And the ejb spec requires all static attributes to be final. > > > 3) run.bat > > Don't put anything in the classpath of run.bat, especially not > > something that uses Class.forName() to load classes. > > Put your jars in jboss/lib/ext > >I would disagree with this. I prefer to keep the JBoss directories >"virgin", and add whatever I need extra to an external directory. I then >modify run.sh to put my extra jars on JBoss's classpath. You can probably >accomplish the same thing with classpath extensions. By doing this, >upgrading from one version of JBoss to the next is easier. I try to follow >this same philosophy with other packages (e.g., Tomcat.) > The lib/myext is better. In the future the JBoss3 branch will keep track of which deployments use each jar for automatic dependency checking. This could also lead to hot-deploying util jars that use a JBoss classloader. If you load from the classpath in run.sh, it can't do this :-( > > >_______________________________________________ >JBoss-user mailing list >[EMAIL PROTECTED] >https://lists.sourceforge.net/lists/listinfo/jboss-user Regards, Adrian _________________________________________________________________ Send and receive Hotmail on your mobile device: http://mobile.msn.com _______________________________________________ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user
