On Mon, 17 Jul 2000 09:21:44 -0400, Laird Nelson
<[EMAIL PROTECTED]> wrote:
>Why force a tool to take apart a deployment descriptor?
Well, it's not exactly difficult, so why not.
> Why not make
> one file per role? How is this more complicated?
The container is only interested in the sum of all prior roles, so for
the container splitting it up would not be a good idea. For people
having several roles at once it becomes more work "ok, so first I have
to put on this hat and put this in that file, and then that there, and
then..". That is more work, and more complex.
On the contrary, if there is only one file (as it is now) one person can
have several roles at once, but it is at the same time easy for a tool
to enforce only one at a time should it be required.
>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
A .jar as it is now is inviolable. If you are talking about signed jars,
then consider this: if I was a bean developer who signed my work (i.e.
jars) then I wouldn't want my name to stick if some Assembler added more
beans. From that point it is the Assembler who should sign it for
credibility. It's a chain of contracts sort of.
>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?
Well, in a sense it is. The installer is just packaged in a .jar or .ear
file, that's all, which you can then easily install by handing over to
your application server.
> Then an Assembler
> could take that installer and modify values that way.
Well, IMHO the "end of the line" is the deployer. The result of the
deployers work is an "installer" if you will; a .jar file. How that is
handled on the way from the bean developer isn't terribly important.
And after all, there *are* tools available that let you take the
installer (the .jar) and modify the values, my EJX tool being one of
them.
>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?
In a sense a .jar is 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?)
An example of the tool you describe is my EJX program which allows you
to edit the deployment descriptor while it is contained in a .jar.
Don't see the problem the way you do I guess.. sorry..
/Rickard
--
Rickard �berg
@home: +46 13 177937
Email: [EMAIL PROTECTED]
http://www.telkel.com
http://www.jboss.org
http://www.dreambean.com
===========================================================================
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".
