Rickard �berg 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?
I don't. I want it to be easy to edit those properties which should be
editable, and impossible to edit those which should not be editable.
For all of this, I don't want to have to crack the jar. I know it would
be possible to build a tool.
But if a jar file is supposed to be an inviolable unit, and if, for a
stupid example, using this tool to edit some env-entries in there causes
the, say, checksum or hash of the jar to indicate that it was modified,
isn't that a problem?
> >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.
See above.
> This is *exactly* what environment entries in the ejb-jar.xml file does.
> In what way does this *not* perform what you describe??
It requires me to edit a file inside a jar and put it back in the jar
(whether by hand or via a tool). Thus the jar becomes modified. I was
under the impression that at least the *intention* behind the spec. was
that when you got a .jar file from a bean provider it was just something
that you were not to modify. Obviously that's not the case.
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".
