Mike - If I intentionally bundle an orion-ejb-jar.xml file in with my EJBs, thats effectively saying that these are the parameters I care about and should not be derived by Orion. I would presume that since these are being bundled with my EJB package they are values that are somewhat global to begin with otherwise they probably shouldn't be bundled in the package. So I would maintain that changes should be incorporated immediately without having to manually remove the old file.
I can certainly see where there might be places where a deployment specific change has been hand edited in and how that would get nuked. But it still seems like it strips away the ability to drop a jar and run. Maybe the solution is what Morten suggested, a configuration file for specific deployment that is included in each overwrite. It also seems like 'always overwriting' would make rapid development easier (without using XDoclet). Magnus and Karl - theres a fat feature request here. :P Aaron -----Original Message----- From: Mike Cannon-Brookes To: Orion-Interest Sent: 12/30/01 4:35 AM Subject: RE: CMP Entity Bean Craziness 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. > > > > 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). 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
