Rickard �berg wrote:
> In this particular case I don't see a problem, since the kind of things
> we use properties files for (name/value mappings) is available through
> the ejb-jar.xml file (environment settings).
As kind of a side note, the deployment descriptor solution--which Sun is
littering throughout the J2EE--seems a bit odd in that it tries to do
two (at least) two things:
1. Communicate to the Application Deployer various immutable qualities
about the thing it describes (i.e. I am a stateless session bean, I am a
distributable web application, I rely on these notional roles)
2. Provide a spot for the Application Assembler? Deployer? to edit
things (i.e. env-entries, various performance-enhancing, vendor-specific
stuff, etc.)
Given that the preferred distribution mechanism for an EJB (or a web
app) is a suitably packaged .jar file, and given that the deployment
descriptor is in the jar file, and given that this archive is
essentially supposed to be treated as a unit, and finally given (2)
above, isn't the deployment descriptor an odd place to put configurable
information? For env-entries and the like, wouldn't some standard
binding in the JNDI tree have been a better choice (I know beans can
read from java:/comp/env, but I mean wouldn't something in the spec.
that said "if you want to edit application properties do so by sticking
them in the JNDI tree in the following standard manner" have been a
better idea)?
Oh well, thoughts for the morning.
Cheers,
Laird
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff EJB-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
