Rickard �berg wrote:
> On Fri, 14 Jul 2000 09:17:42 -0400, Laird Nelson
> <[EMAIL PROTECTED]> wrote:
> Correct. And it would be very possible to make a XML editor which allows
> you to say "hey, I'm an Assembler" or "I am a Bean Developer", and then
> only some things would be editable. Why would you want to split this up?
> That would add more complexity to the whole thing, so the reasons for
> doing it would have to be very good.
Why force a tool to take apart a deployment descriptor? Why not make
one file per role? How is this more complicated?
> >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?
>
> No, why? Be more explicit about your concerns.
Certainly. I am concerned, as I mention above, that:
1. The unit of distribution of an EJB is a .jar file that is intended to
be inviolable
2. Editing the deployment descriptor breaks the inviolability of this
.jar file
I'm not arguing it's impossible, just that it's odd to force someone to
"crack" a .jar file and edit its internal contents just so you can
deploy it. I see it as being somewhat analogous to forcing someone to
install, say, a perl module by grabbing the tarball, unzipping it,
editing four files inside it, zipping it back up again and then somehow
deploying it. Or analogous to having to install a .so file on Unix by
ripping it to shreds with some kind of editor or tool to map symbol
names to their referents. It just seems like an overly bizarre
solution. Always has, from 1.0 forwards. If deployment-time
information is so important, why not specify that the output of the bean
development process is an installer of some kind? Then an Assembler
could take that installer and modify values that way.
> > 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)?
>
> This is *exactly* what environment entries in the ejb-jar.xml file does.
> In what way does this *not* perform what you describe??
Right, I'm not being clear; I obviously do understand the relationship
between <env-entry> and java:/comp/env. The thrust of this complaint is
related to my earlier why-do-I-have-to-crack-the-.jar-open comment
above. Why should I have to crack a .jar file to edit a file inside it
and edit the contents of <env-entry> elements? Why isn't the standard
pre-assembly unit an installer?
(Note that I understand that one *could* easily write such an installer
to work on a .jar file. My question is, why wasn't the behavior of such
a hypothetical installer specified as the preferred distribution
medium?)
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".
