Quoting Mike Cannon-Brookes <[EMAIL PROTECTED]>:
> On Sun, 2001-12-30 at 07:50, Ed Brown wrote: > > > > Quoting Aaron Tavistock <[EMAIL PROTECTED]>: > > > > > Mike - > > > > > > Since this is a generated file in a deployment directory shouldn't > it > > > always > > > be overwritten if there is a change in one of the package > deployment > > > descriptors? The only reason it would be a pain in the ass is if > you > > > changed the generated file to suit your needs and did not change the > one > > > you > > > bundle with your package. > > > > Which is my thought as well. > > Apologies but that's not really the way I see it. The deployment files > are specific to _each_ deployment - for example if you deploy the same > EAR on multiple machines (ie in a cluster) you would want different > deployment files on each machine. Thus changing the one in the EAR > would > overwrite all deployment files. > > As Hani (I think) mentioned, it's easy to get XDoclet to generate your > deployment file, and Ant to remove the old one - if you're concerned > about development speed. That is fine with me. What is a big problem for me is the following. > > > > > > If this is intended behavior, IMHO it is significantly less > intuitive. > > > Its > > > kind of like saying a class should only be recompiled if you > delete > > > the > > > class before recompiling, where one would expect that changing the > > > source > > > would be enough. > > > > > > Just my two cents. > > > > Agreed. In fact, I believe that implementation stinks. Why go through > the "hassle" of writing the orion-ejb-jar.xml file and specifying the > fields if the server re-writes the file as it sees fit? > > There are some misconceptions here - the server will not 'rewrite > deployment files as it sees fit', in fact it takes any settings in > orion-ejb-jar.xml and builds ontop of those. The easiest way to build > an > orion-ejb-jar.xml file for deployment is to: > > - deploy your EAR without it > - copy the created orion-ejb-jar.xml into your source tree > - remove any sections you don't want to customise (thereby letting > Orion > autogenerate them - for example it's usually nicest to specify a > default > datasource in orion-application.xml and let Orion take care of the > datasources in orion-ejb-jar.xml automatically) > - customise any you do (ie field names, table names etc) > - delete the deployed orion-ejb-jar.xml > - redeploy > > This process only really needs to be done once. At all other times the > deployed file should work, except when you modify the > orion-ejb-jar.xml > then you delete it before redeployment (as above this is usually rare > occurrence, if not - use XDoclet to generate and Ant to delete it > every > build if you want). If I create an orion-ejb-jar.xml file first, and deploy it should add to it. That is what I expected. I had persistence-name attributes that were over written by what the Orion server expected. That should not happen but that is what happened. I had to redeploy using the orion-ejb-jar.xml that the Orion server created, with the persistence-name edited by me. That behavior kills the idea of hot deployment. > As for the class analogy it's very different. Classes are compiled > once, > and 100% autogenerated, deployment files are created and altered by > the > server continually and are not fully autogenerated (see J2EE spec > roles > definitions). Also compiled classes are the same in all occurrences > (or > should be ;)) whereas deployment files are certainly not. > > Hope this helps clear things up - I do like this healthy debate on the > topic though, please tell me if the above sounds unreasonable. > > Cheers, > Mike > > -- > Mike Cannon-Brookes :: [EMAIL PROTECTED] > > Atlassian :: http://www.atlassian.com > Supporting YOUR J2EE World > > > Ed Brown _________________________________________________________________________ This mail sent via toadmail.com, web e-mail @ ToadNet - want to go fast? http://www.toadmail.com
