RE: CMP Entity Bean Craziness
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
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
Re: CMP Entity Bean Craziness
i've asked about this on the list in the past... it seems like there is a number of annoying things about this way of doing things. ie. if i have 2 entitybeans that needs to use 2 differend datasources... from what ive seen it is impossible to set the datasource at the bean level, only as an application default, so i have to deploy the beans (which creates the tables in hypersonic) and then edit the orion-ejb-jar.xml and set the correct datasources... why do i have to create tables in hypersonic to do this? my suggestion was to have 3 xml files, one standard j2ee ejb-jar.xml, one orion specific and then let orion create the one it uses (what today is orion-ejb-jar.xml) and yes, let the orion-ejb-jar.xml reflect changes in the other 2 sincerely Morten Wilken - Original Message - From: Ed Brown [EMAIL PROTECTED] To: Orion-Interest [EMAIL PROTECTED] Sent: Saturday, December 29, 2001 9:50 PM Subject: RE: CMP Entity Bean Craziness 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. 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? Ed Brown _ This mail sent via toadmail.com, web e-mail @ ToadNet - want to go fast? http://www.toadmail.com
RE: CMP Entity Bean Craziness
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
RE: CMP Entity Bean Craziness
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. 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? Ed Brown _ This mail sent via toadmail.com, web e-mail @ ToadNet - want to go fast? http://www.toadmail.com
RE: CMP Entity Bean Craziness
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. 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. Aaron Tavistock -Original Message- From: Mike Cannon-Brookes [mailto:[EMAIL PROTECTED]] Sent: Friday, December 21, 2001 2:13 AM To: Orion-Interest Subject: Re: CMP Entity Bean Craziness You're not special at all (well you may be - but that's a different story ;)) - what you describe is exactly the intended behaviour of the server. You're editing the deployment files in your EAR which are only used _IF AND ONLY IF_ there is no existing deployment file. Otherwise the existing deployment file is used, and the one in the EAR ignored. This behaviour is as it should be because otherwise you'd end up overwriting your deployment settings all the time which would be a royal pain in the ass. HOWEVER to do what you want, simply delete the deployment directory and your edited files will be copied and used. You will see a message on the console telling you that the deployment file has been copied. Hope this helps clear things up. Cheers, Mike -- Mike Cannon-Brookes :: [EMAIL PROTECTED] Atlassian :: http://www.atlassian.com Supporting YOUR J2EE World On Fri, 2001-12-21 at 15:01, Ed Brown wrote: Okay, here is the situation. Database: Oracle on Solaris Orion server: 1.5.2 on Windows 2000 Operating System: Windows 2000 I have a database table named FOO. I want to create different entity beans to provide different views of the table named FOO. FOO is a table with many columns. (Sure, I could create one entity bean, and then create wrapper classes that provides the views of table FOO that I want, but I didn't want to do that). Many of those column names contain underscores. When I created the first CMP entity bean, I mapped all column names and used the table name as the entity bean name. I wrote the appropriate ejb-jar.xml and orion-ejb-jar.xml and packaged them. In the orion-ejb-jar.xml file, I used the persistence-name to map the Java attribute to the proper table column. For all attributes that mapped to a column name with an underscore, I removed the underscore and uppercased the next character. (A column named long_col_name would map to the attribute longColName). So I deployed the entity bean and there were deployment errors. Orion complained about illegal column names. Much later after going around in circles, I looked at the ejb-jar.xml file that Orion generated and I noticed that the values for the persistence-name mapped exactly to the column names of the database table. It *IGNORED* what I had placed there. I had to edit the deployed xml file to get the mapping correct and properly deployed. Now, that's not very nice. Next, I created another CMP entity bean to give a different view of table FOO. I used the entity name FooTimeView and used the table attribute of entity-deployment in the orion-ejb-jar.xml to map the entity to the FOO table. I deployed it and, again, I got errors. I had to edit the deployed xml file to get the correct mappings. I deployed again and it still failed. Only this time, it tried to create a table named FOOTIMEVIEW. (Actually, it *DID* create the table). That's not what I expected to happen. So, I looked at the deployed xml file again and I noticed that the table name had been changed from what I specified. This time, I also looked at the query that was generated and noticed that the column names with underscores had the underscores removed. Now, that's not very nice. I edited that and restarted the server. Now all is well. Okay, now I *KNOW* what I described should not happen. I want to know why it did happen. Has this happened to anyone else, or am I special? Ed Brown _ This mail sent via toadmail.com, web e-mail @ ToadNet - want to go fast? http://www.toadmail.com -- Cheers, Mike -- Mike Cannon-Brookes :: [EMAIL PROTECTED] Atlassian :: http://www.atlassian.com Supporting YOUR J2EE World
Re: CMP Entity Bean Craziness
Aaron, The idea is that one application may be deployed on many servers, and therefore the deployment descriptor is *per app, per server*. The deployment descriptors are used to customise a deployment on that server. This notion fits in with sun's idea of J2EE roles (ppl who help develop the application.) Read about roles here: http://java.sun.com/j2ee/tutorial/1_3-fcs/doc/Overview5.html#65592 If you had your deployment files working, and then you upgraded the application (ie installed a newer version - perhaps a web-app version of your ejbs) you would not want the deployment descriptors overridden except where they dont exist (for the new parts of the application). If in development you feel that this is a problem - then add another ant target to delete the deployment descriptors from the deployment directory. Cheers, Scott -- Scott Farquhar :: [EMAIL PROTECTED] Atlassian :: http://www.atlassian.com Supporting YOUR J2EE World Aaron Tavistock wrote: 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. 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. Aaron Tavistock -Original Message- From: Mike Cannon-Brookes [mailto:[EMAIL PROTECTED]] Sent: Friday, December 21, 2001 2:13 AM To: Orion-Interest Subject: Re: CMP Entity Bean Craziness You're not special at all (well you may be - but that's a different story ;)) - what you describe is exactly the intended behaviour of the server. You're editing the deployment files in your EAR which are only used _IF AND ONLY IF_ there is no existing deployment file. Otherwise the existing deployment file is used, and the one in the EAR ignored. This behaviour is as it should be because otherwise you'd end up overwriting your deployment settings all the time which would be a royal pain in the ass. HOWEVER to do what you want, simply delete the deployment directory and your edited files will be copied and used. You will see a message on the console telling you that the deployment file has been copied. Hope this helps clear things up. Cheers, Mike
Re: CMP Entity Bean Craziness
You're not special at all (well you may be - but that's a different story ;)) - what you describe is exactly the intended behaviour of the server. You're editing the deployment files in your EAR which are only used _IF AND ONLY IF_ there is no existing deployment file. Otherwise the existing deployment file is used, and the one in the EAR ignored. This behaviour is as it should be because otherwise you'd end up overwriting your deployment settings all the time which would be a royal pain in the ass. HOWEVER to do what you want, simply delete the deployment directory and your edited files will be copied and used. You will see a message on the console telling you that the deployment file has been copied. Hope this helps clear things up. Cheers, Mike -- Mike Cannon-Brookes :: [EMAIL PROTECTED] Atlassian :: http://www.atlassian.com Supporting YOUR J2EE World On Fri, 2001-12-21 at 15:01, Ed Brown wrote: Okay, here is the situation. Database: Oracle on Solaris Orion server: 1.5.2 on Windows 2000 Operating System: Windows 2000 I have a database table named FOO. I want to create different entity beans to provide different views of the table named FOO. FOO is a table with many columns. (Sure, I could create one entity bean, and then create wrapper classes that provides the views of table FOO that I want, but I didn't want to do that). Many of those column names contain underscores. When I created the first CMP entity bean, I mapped all column names and used the table name as the entity bean name. I wrote the appropriate ejb-jar.xml and orion-ejb-jar.xml and packaged them. In the orion-ejb-jar.xml file, I used the persistence-name to map the Java attribute to the proper table column. For all attributes that mapped to a column name with an underscore, I removed the underscore and uppercased the next character. (A column named long_col_name would map to the attribute longColName). So I deployed the entity bean and there were deployment errors. Orion complained about illegal column names. Much later after going around in circles, I looked at the ejb-jar.xml file that Orion generated and I noticed that the values for the persistence-name mapped exactly to the column names of the database table. It *IGNORED* what I had placed there. I had to edit the deployed xml file to get the mapping correct and properly deployed. Now, that's not very nice. Next, I created another CMP entity bean to give a different view of table FOO. I used the entity name FooTimeView and used the table attribute of entity-deployment in the orion-ejb-jar.xml to map the entity to the FOO table. I deployed it and, again, I got errors. I had to edit the deployed xml file to get the correct mappings. I deployed again and it still failed. Only this time, it tried to create a table named FOOTIMEVIEW. (Actually, it *DID* create the table). That's not what I expected to happen. So, I looked at the deployed xml file again and I noticed that the table name had been changed from what I specified. This time, I also looked at the query that was generated and noticed that the column names with underscores had the underscores removed. Now, that's not very nice. I edited that and restarted the server. Now all is well. Okay, now I *KNOW* what I described should not happen. I want to know why it did happen. Has this happened to anyone else, or am I special? Ed Brown _ This mail sent via toadmail.com, web e-mail @ ToadNet - want to go fast? http://www.toadmail.com -- Cheers, Mike -- Mike Cannon-Brookes :: [EMAIL PROTECTED] Atlassian :: http://www.atlassian.com Supporting YOUR J2EE World
CMP Entity Bean Craziness
Okay, here is the situation. Database: Oracle on Solaris Orion server: 1.5.2 on Windows 2000 Operating System: Windows 2000 I have a database table named FOO. I want to create different entity beans to provide different views of the table named FOO. FOO is a table with many columns. (Sure, I could create one entity bean, and then create wrapper classes that provides the views of table FOO that I want, but I didn't want to do that). Many of those column names contain underscores. When I created the first CMP entity bean, I mapped all column names and used the table name as the entity bean name. I wrote the appropriate ejb-jar.xml and orion-ejb-jar.xml and packaged them. In the orion-ejb-jar.xml file, I used the persistence-name to map the Java attribute to the proper table column. For all attributes that mapped to a column name with an underscore, I removed the underscore and uppercased the next character. (A column named long_col_name would map to the attribute longColName). So I deployed the entity bean and there were deployment errors. Orion complained about illegal column names. Much later after going around in circles, I looked at the ejb-jar.xml file that Orion generated and I noticed that the values for the persistence-name mapped exactly to the column names of the database table. It *IGNORED* what I had placed there. I had to edit the deployed xml file to get the mapping correct and properly deployed. Now, that's not very nice. Next, I created another CMP entity bean to give a different view of table FOO. I used the entity name FooTimeView and used the table attribute of entity-deployment in the orion-ejb-jar.xml to map the entity to the FOO table. I deployed it and, again, I got errors. I had to edit the deployed xml file to get the correct mappings. I deployed again and it still failed. Only this time, it tried to create a table named FOOTIMEVIEW. (Actually, it *DID* create the table). That's not what I expected to happen. So, I looked at the deployed xml file again and I noticed that the table name had been changed from what I specified. This time, I also looked at the query that was generated and noticed that the column names with underscores had the underscores removed. Now, that's not very nice. I edited that and restarted the server. Now all is well. Okay, now I *KNOW* what I described should not happen. I want to know why it did happen. Has this happened to anyone else, or am I special? Ed Brown _ This mail sent via toadmail.com, web e-mail @ ToadNet - want to go fast? http://www.toadmail.com
