Hi!
Michael Lepine wrote:
> > Well, logging is not a good example, since that would
> > typically be done
> > through the jBoss server. jBoss allows you to log all bean
> > invocations,
> > and if you do System.out.println's these will be redirected to the
> > server logging system, which you can attach a filter to log
> > bean output
> > to a file. No coding involved.
>
> Sounds good, but how would I go about attaching the filter.
Add this to your jboss.conf:
<MLET CODE = "org.jboss.logging.FileLogging" ARCHIVE="jboss.jar"
CODEBASE="../lib/ext/">
<ARG TYPE="java.lang.String" VALUE="Information,Warning,Error,Debug">
<ARG TYPE="java.lang.String" VALUE="<{0}><{1}><{2}><{3}><{4}>">
<ARG TYPE="java.lang.String" VALUE="Account,Customer">
<ARG TYPE="java.lang.String" VALUE="myapp.log">
</MLET>
First arg is what to include. System.out/err calls will give you
"Information"/"Error" messages (so yes, you can minimize it t
"Information,Error").
The second arg is log format. {n} represents parameters from log
message. Experiment to find out what they are.
Third arg is a source filter. Put your bean names here.
And fourth is log file name. Directory will be /log (or wherever in your
classpath that log.properties is located).
> Before I started upgrading my application to incorporate EJB, I reassigned
> the standard output and error streams, so they would write to my log file.
> So would the filter just create the file locally or how would it tie into
> the scheme? Sorry if I'm trying to make this too complex (I should probably
> just look at the code and figure this out).
The default configuration will cause the log file to be created in /log.
The log directory is located by finding the "log.properties" file in
classpath, so you can move that around for more control over where files
end up. Same thing with db.properties
> > For these purposes we have a special singleton pool for stateless
> > session beans. Make a stateless session bean, and choose the singleton
> > container configuration for it. jBoss will only create one instance of
> > this bean, which you can use for id's.
>
> Okay, but in order to keep the code portable from any EJB server to any
> other EJB server, is there an independent solution.
For true singletons this is the best we can do. However, for any given
case there might be more portable solutions. For example, id generators
doesn't *have* to be singletons, and if you only have read-only cached
data in your singleton you can use statics.
> I was thinking of just
> creating an RMI object which I would then use JNDI to locate. Sound crazy?
Well, there's no way for you to bind an RMI object in JNDI, at least not
if you want to stay pure J2EE. Which I'd recommend.
/Rickard
--
Rickard �berg
@home: +46 13 177937
Email: [EMAIL PROTECTED]
http://www.telkel.com
http://www.jboss.org
http://www.dreambean.com
--
--------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Problems?: [EMAIL PROTECTED]
