Re: orion xml's
oh cool, thats excactly what i was looking for... my bad and also thanks to mr ottinger for pointing out the same thing :) morten wilken -Original Message- From: Scott Farquhar [EMAIL PROTECTED] To: Orion-Interest [EMAIL PROTECTED] Date: 20. oktober 2001 18:07 Subject: Re: orion xml's Morten, What you ask for already exists. You can create your own orion-ejb-jar.xml files, and place them next to your ejb-jar.xml files, and they will be automatically deployed. The reason that most people edit the deployed ones is that they don't care to remember the syntax. If you let orion generate them, then you can just edit the file. Also, if you create an orion-ejb-jar.xml file, you do not need to specify all the parameters, orion will fill them in if you have missed some. One other point to watch out for, is that once an orion-ejb-jar.xml file is deployed, it will not be overwritten. So you will need to delete the existing one for it to be redeployed. Cheers, Scott -- Scott Farquhar :: [EMAIL PROTECTED] Atlassian :: http://www.atlassian.com Supporting YOUR J2EE World Morten Wilken wrote: Am i the only one who thinks that the idea that you have to edit the autogenerated files like orion-ejb-jar.xml etc. is a bit problematic? sure it can be done and it works, but i would be much happier if i could have 2 sets of xml files, the ones you edit (and you could put in your versioning system), and another set that orion generates, and that you never have to fiddle with. it seems an odd mix the way it is right now, as if it was meant to be seperated, but somehow it wasn't followed through i could be wrong, and missing the point of the structure entirely comments appreciated sincerely morten wilken
RE: ApplicationHeap
Jeff, You would need to have a very large page to cause an out of memory error. Out of memory errors are generally related to overflows due to eg infinite loops. You should check your code first. Also I've found IBM's JVM a lot more helpful with error messages. You might want to try it out. Oz -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of El Jeffo Sent: Monday, 22 October 2001 7:06 AM To: Orion-Interest Subject: ApplicationHeap I just wanted to know, if orion serves pages from a servlet that complains about not enough memory in the application heap, is it just a java option where I do on a solarios java 1.3.1 : java -Xmx128M -Xms48m -jar orion.jar to increase from the defaults of -Xmx64m -Xms2m that's 64meg max, 2 meg start or are there other orion options I missed? Much thanks! Jeff
RE: Transaction behaviour
Title: RE: Transaction behaviour Orion's implementation is quite correct in returning a method result and not throwing any exceptions, in spite of your invocation of setRollbackOnly. Personally, I only call setRollBackOnly before (re-)throwing an application exception that should definitely cause a rollback. Rolling back the transaction without throwing any exceptions will just confuse the users of my ejb's. It is probably better to just wrap such an application exception in an EJBException and let the container roll the tx back. Remember that CreateException, RemoveException and FinderException are considered to be application exceptions. If you propagate these exceptions but still want to roll the tx back, you have to catch them, call setRollbackOnly() and then rethrow them. Subclasses of Error, RuntimeException (EJBException) and RemoteException are considered to be system exceptions and will automatically cause a tx rollback. -Original Message- From: Justin Crosbie [mailto:[EMAIL PROTECTED]] Sent: 19 October 2001 05:34 To: Orion-Interest Subject: Transaction behaviour Hi all, We have implemented a session facade architecture, with session beans calling multiple entity beans. We have configured the trans-attribute as Required for everything, as normal. What is the exact criteria for a session method to rollback? Is it that it must be a system initiated exception, or else the application must call setRollBackOnly()? Its just that calling this method causes a rollback, but the the container does not come up with the Session was rolled back exception, so I'm a bit worried about it. I know this has been addressed before on this list, so I apologise for going over old stuff, but I've noticed that some applications call the setRollbackOnly method and others don't. Is it just that those ones don't care if a rollback occurs? Specificaly, we have a stateless session bean that we invoke through a statefull one (that a servlet creates and invokes). The stateless bean always tries to create the entity beans. We would like it such that if either fails to create, the method does a rollback - all or nothing. Does this mean that we must call setRollbackOnly() ? Thanks for any help on this. Justin
