RE: Unsubscribe
Yeah. Likewise. I've been trying to get off this list for 6 months. Sending mail to Magnus didn't work either. [EMAIL PROTECTED] ([EMAIL PROTECTED]) wrote: Me too. The unsubscribe doesn't seem to work :( Quoting Dan Hoyal [EMAIL PROTECTED]: Please remove me as well. I've also tried several times. Thank you, Dan -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Matthew Pullen Sent: Monday, December 17, 2001 7:11 AM To: Orion-Interest Subject: Unsubsribe Even i tried to unsubscribe at the specifed address.It did not work.Please remove my name from the list. Thank you, Matthew
EJB2.0 spec or implementation?
I've toyed with EJBs for quite a while, all the way back to 1.0. But so far its been too cumbersome and offered little gain in most environments I've been working in (e.g. the overhead of remote calls, etc, outweighed the potential benefits). Now with the 2.0 spec its gotten to a good place where I feel like it will really offer some improvements to almost any environment. But I have a major gripe about CMP that I'd like to hear if anyone can 'justify'. So heres the story - database field names are case insensitive, so common parlance for representing a space is an underscore (e.g. 'this_field'). In Java, case is available and useful, here common parlance is representing a space by a capital letter (e.g. 'thisField'). Unfortunately with the typical CMP EJB implementation of accessor-methods are a bastardization of both of these schools (e.g. 'getThis_field'), which is not only ugly but also makes it much more difficult to move from typical javabean-style Java into EJB. Since the 2.0 spec already requires abstract classes where the engine builds the concrete class, it seems like it would be a no brainer to map 'getThisField()' to the 'this_field' database field and preserve conventions on both sides of the fence. I'm sure people can come up with cases where this appears impractical, or a way to change some generated config file in orion after the EJBs have been deployed, but does anyone have any good ideas on why this is not the default behavior?
Re: [orion-interest]EJB2.0 spec or implementation?
On 28/12/01 12:56 pm, Aaron Tavistock [EMAIL PROTECTED] wrote: So heres the story - database field names are case insensitive, so common parlance for representing a space is an underscore (e.g. 'this_field'). Nope. MS SQLServer is not case insensitive. You could always tweak orion-ejb-jar.xml to map it to whatever column names your heart desires
Re: [orion-interest]EJB2.0 spec or implementation?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Neither is Oracle. Oracle actually stores all its DB Fields upper case, but it doesn't matter how you refer to then, meaning select column1 from Table or select Column1 from table or select COLUMN1 FROM TABLE Doesn't make a difference. R At 01:25 PM 12/28/2001 -0500, you wrote: On 28/12/01 12:56 pm, Aaron Tavistock [EMAIL PROTECTED] wrote: So heres the story - database field names are case insensitive, so common parlance for representing a space is an underscore (e.g. 'this_field'). Nope. MS SQLServer is not case insensitive. You could always tweak orion-ejb-jar.xml to map it to whatever column names your heart desires -BEGIN PGP SIGNATURE- Version: PGPfreeware 6.5.3 for non-commercial use http://www.pgp.com iQA/AwUBPCzNZMCgz9HsAj5wEQI/awCfapbiZcITG3/twcV+IIpjlN3O15wAnAiJ yMf5L47Q9eFh9Y2ASuuwkIjT =Mwke -END PGP SIGNATURE-
RE: [orion-interest]EJB2.0 spec or implementation?
I'm fairly sure that the SQL-92 spec calls for case insensitive column names (but don't quote me on that cause I'm not 100% sure). Also, since I'm in a UNIX shop switching to Microsoft is not really an option (even *if* I wanted to) - but thats not really the point. More importantly, I'm aware I can change the post-deployment descriptor created by Orion but thats a major pain-in-da-behind if I'm doing development and want to redeploy several times. When I've tried putting an partial orion-ejb-jar.xml into the package, its never worked right, implying that I need to copy a previously deployed version to modify - again extremely cumbersome. I was hoping that there was some way to do this without slicing up the post-deployment orion generated files. -Original Message- From: Hani Suleiman [mailto:[EMAIL PROTECTED]] Sent: Friday, December 28, 2001 10:26 AM To: Orion-Interest [EMAIL PROTECTED]; Aaron Tavistock Subject: Re: [orion-interest]EJB2.0 spec or implementation? On 28/12/01 12:56 pm, Aaron Tavistock [EMAIL PROTECTED] wrote: So heres the story - database field names are case insensitive, so common parlance for representing a space is an underscore (e.g. 'this_field'). Nope. MS SQLServer is not case insensitive. You could always tweak orion-ejb-jar.xml to map it to whatever column names your heart desires
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: [orion-interest]EJB2.0 spec or implementation?
You think fugly? It already does fugly reflection and decapitalization for the first letter just to match the accessor to a column name. Why is it any more fugly to process underscores? I do suppose that databases that do identify case within the column name could make things a little wierd (e.g. would getThisField() translate to 'this_field' or 'thisField'?). But still I believe the SQL-92 spec is for case insensitive column names. From a perfromance standpoint, its practically no difference (all happens when the concrete class is created at deployment time). I'll try the orion-ejb-jar.xml, but I'm guessing I'm going to need to provide a complete orion-ejb-jar.xml file, not just the hierarchy required for the cmp-field-mapping fields. Theres a lot of junk in there I don't want to follow and if I'm doing quick development I will need to far more than makes sense. Which definately makes our existing persistence, caching, and coding paradigm easier to use than CMP EJB, once again seems to indicate that EJB might still not be needed for most serverside applications (still more hype and 'neat' technology than is practical in the majority of situations, IMHO). -Original Message- From: Hani Suleiman [mailto:[EMAIL PROTECTED]] Sent: Friday, December 28, 2001 12:32 PM To: Aaron Tavistock; Orion-Interest [EMAIL PROTECTED] Subject: Re: [orion-interest]EJB2.0 spec or implementation? On 28/12/01 3:20 pm, Aaron Tavistock [EMAIL PROTECTED] wrote: More importantly, I'm aware I can change the post-deployment descriptor created by Orion but thats a major pain-in-da-behind if I'm doing development and want to redeploy several times. When I've tried putting an partial orion-ejb-jar.xml into the package, its never worked right, implying that I need to copy a previously deployed version to modify - again extremely cumbersome. Well, this IS the correct way to do it. I don't see why you can't just do it once. Having a partial orion-ejb-jar.xml certainly does work. You just need to make sure it has sufficient information in it and is usable. Start off with a complete one and start trimming things, and check it works after every trim! Adding an automatic underscoring thing is too too fugly!
RE: [orion-interest]EJB2.0 spec or implementation?
Might I recommend xdoclet then? xdoclet.sourceforge.net At 12:20 PM 12/28/2001 -0800, Aaron Tavistock wrote: I'm fairly sure that the SQL-92 spec calls for case insensitive column names (but don't quote me on that cause I'm not 100% sure). Also, since I'm in a UNIX shop switching to Microsoft is not really an option (even *if* I wanted to) - but thats not really the point. More importantly, I'm aware I can change the post-deployment descriptor created by Orion but thats a major pain-in-da-behind if I'm doing development and want to redeploy several times. When I've tried putting an partial orion-ejb-jar.xml into the package, its never worked right, implying that I need to copy a previously deployed version to modify - again extremely cumbersome. I was hoping that there was some way to do this without slicing up the post-deployment orion generated files. -Original Message- From: Hani Suleiman [mailto:[EMAIL PROTECTED]] Sent: Friday, December 28, 2001 10:26 AM To: Orion-Interest [EMAIL PROTECTED]; Aaron Tavistock Subject: Re: [orion-interest]EJB2.0 spec or implementation? On 28/12/01 12:56 pm, Aaron Tavistock [EMAIL PROTECTED] wrote: So heres the story - database field names are case insensitive, so common parlance for representing a space is an underscore (e.g. 'this_field'). Nope. MS SQLServer is not case insensitive. You could always tweak orion-ejb-jar.xml to map it to whatever column names your heart desires
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
Cocoon2 + Orion Integration Instructions
Instructions on how to bring Cocoon2 alive on the Orion Web Server can be found at: http://www.candlelightsoftware.com/orion-cocoon.html Sincerely: Steven P. Punte Steven P. Punte Candlelight Software By Candlelight If Necessary! [EMAIL PROTECTED] http://www.candlelightsoftware.com __ Do You Yahoo!? Send your FREE holiday greetings online! http://greetings.yahoo.com
