Orion auto-deployment issue?
Hi, We have built an entity bean that simply describes a lookup item, we have deployed it (the same classes) a number of times with different ejb-names and all seemed good, however I have just traced the root of an issue to the orion-ejb-jar.xml file, below illustrates whats happening; From the lookup beans deployment descriptor, notice that the same classes are deployed twice with different names; salutation com.chryxus.ejb.lookup.LookupHome com.chryxus.ejb.lookup.Lookup com.chryxus.ejb.lookup.LookupEJB False Container .Lookup java.lang.String uoid uoid value lmd preferredLanguage com.chryxus.ejb.lookup.LookupHome com.chryxus.ejb.lookup.Lookup com.chryxus.ejb.lookup.LookupEJB False Container .Lookup java.lang.String uoid uoid value lmd from the entity beans deployment descriptor snippet describing the relationship between contact and its preferred language; preferredLanguage ejb/preferredLanguageEntitycom.chryxus.ejb.lookup.LookupHomecom.chryxus.ejb.lookup.Lookup cut from the orion-ejb-jar.xml for the contact entity bean, notice that the entity-ref tag refers to salutation, not preferredLanguage as expected; Has anyone else seen this problem? Can anyone tell me if this is a real issue or are we in the wrong for deploying the same classes multiple times (I hope not as it save a lot of duplicated code)? It can be resolved by editing the orion-ejb-jar.xml file but I would prefer not to. Regards Evan
auto deployment in 1.5.1
Is it just me, or is auto deployment broken in version 1.5.1 ? It looks like they tried to do something about the 'error reading zipfile' message, but now it sometimes just doesn't notice that an .ear file has changed. I have to stop and start the server to trigger the auto unpacking and redeployment. Marcel
Re: Auto-deployment
Chaya Ramanujam wrote: > Can someone give me details on the auto-deployment feature in Orion? Add a the following line to the default-web-site.xml (config directory), under default-web-app line: and the following line in the server.xml (config directory), under line: > How do you go about getting an app deployed automatically? Is there a > way to turn this feature off using a tag in the orion config files? Yes. There is an argument in the web-app line, load-on-startup, which you can set to true/false. See http://www.orionserver.com/dtds/web-site.dtd for more details. > > If this feature is on by default, is it possible to have an app > installed on the server, but not deployed? > > Thanks for your help.. > > --CR. > _ > Get your FREE download of MSN Explorer at http://explorer.msn.com > > > Good luck -- --o-o-- Mark Kettner http://www.fredhopper.com Amsterdam, The Netherlands Phone: +31 20 3206203 Mobile: +31 620 209 817 fax:+31 20 8848747 E-mail: [EMAIL PROTECTED], [EMAIL PROTECTED]
Auto-deployment
Can someone give me details on the auto-deployment feature in Orion? How do you go about getting an app deployed automatically? Is there a way to turn this feature off using a tag in the orion config files? If this feature is on by default, is it possible to have an app installed on the server, but not deployed? Thanks for your help.. --CR. _ Get your FREE download of MSN Explorer at http://explorer.msn.com
"Broken pipe" with auto-deployment ?
Hellu, When I touch the ejb-jar.xml and the application.xml during operation, I always get the following error. --- Error binding to server: com.evermind.server.rmi.OrionRemoteException: IO Error: Broken pipe; nested exception is: java.io.IOException: Broken pipe --- So until now I just always killed and restarted Orion (restarting doesn't work with me with the admin.jar: it says in the STDOUT log: shutting down orion.. and it never says anyting more). But Now the time has come that I also like to kill that error. Please some advice and help ?? Eddie
auto-deployment does not clean up the previous application
I was trying to re-deploy my application in a running orion server, and discovered that orion does not terminate (or garbage collect) previously deployed instance within the VM. Is this normal? I have some opened database connections in my previous instance, and they are still open after the application re-deployment. Need a way to clean them up nicely. thanks __ Do You Yahoo!? Yahoo! Auctions - Buy the things you want at great prices. http://auctions.yahoo.com/
Re: 1.4.5 auto-deployment troubles
Jeff - I have had to go in and change the ejb-jar file in the atm app as I am looking at using SapDB for our database choice. Since SapDB requires object names to be 32 or less in length, I had to make these changes to ejb names in the atm ejb-jar file and re-deploy. I removed the application from the applications-deployments directory as well. I am using Orion 1.4.5 on Windows 2000 Server and Professional and SapDB (most recent version). It picked up my changes with no problem. I did not however, change the class files themselves. Maybe there is an issue with that aspect Cheers Ray --- Jeff Schnitzer <[EMAIL PROTECTED]> wrote: > Has anyone else noticed that 1.4.5 seems to neglect changes made to the > ejb-jar? It unpacks the ear and deploys changed war files just fine, > and if I change the ejb-jar.xml, it will unpack the ejb jar. But if I > change only the ejb class files, Orion just upacks the ear and sits. > Even restarting the server doesn't help. > > Since nobody else has mentioned it yet, I'm wondering if it's just me. > I can get 1.4.4 to work just fine, though, so I suspect not. > > I am deploying by copying the new ear over the old one. > > Jeff > __ Do You Yahoo!? Yahoo! Auctions - Buy the things you want at great prices. http://auctions.yahoo.com/
1.4.5 auto-deployment troubles
Has anyone else noticed that 1.4.5 seems to neglect changes made to the ejb-jar? It unpacks the ear and deploys changed war files just fine, and if I change the ejb-jar.xml, it will unpack the ejb jar. But if I change only the ejb class files, Orion just upacks the ear and sits. Even restarting the server doesn't help. Since nobody else has mentioned it yet, I'm wondering if it's just me. I can get 1.4.4 to work just fine, though, so I suspect not. I am deploying by copying the new ear over the old one. Jeff
