|
Yes, the warfile deployment works fine.
As for using the admin.jar interface, here's a URL which should help... http://www.orionserver.com/docs/application-deployment.html#commandDeploy Later on in the same document, they also list an ant deploy target which looks like this: <target name="deploy" depends="init"> <java classname="com.evermind.client.orion.OrionConsoleAdmin" fork="yes"> <arg value="${deploy.ormi}" /> <arg value="${deploy.username}" /> <arg value="${deploy.password}" /> <arg value="-deploy" /> <arg value="-file" /> <arg value="${build.dir}/${name}.ear" /> <arg value="-deploymentName" /> <arg value="${name}" /> <classpath> <pathelement location="${orion.dir}/orion.jar" /> <pathelement location="${orion.dir}/ejb.jar" /> <pathelement location="${orion.dir}/jndi.jar" /> </classpath> </java> </target> Hope this helps. I think I have fixed the problem in CVS HEAD of Cactus (there was indeed a
problem for earfiles). However, as we have no functional test for your use case yet, I haven't been able to test it fully (only ran a unit test on it). I'm working on providing you with a nightly build to test it. I'll have that ready in a few minutes. Thanks -Vincent ok, I've uploaded a manual build containing the fix to
http://cvs.apache.org/builds/jakarta-cactus/nightly/2003-08-29-manual/ Do you think you can try and verify it solves your problem? Thanks I've downloaded the snapshot, and I'll test it this weekend. I'll have an
answer for you by Tuesday afternoon at the latest. Hi Jonathan,
I'd like to close this issue and release Cactus 1.5RC1. Can you please tell us whether the fix I committed worked for you? Thanks -Vincent Vincent, I just ran into this problem today and saw this bug report.
After downloading jakarta-cactus-13-1.6dev-20030831, the @cactus.context@ is now being replaced in orion's conf/application.xml file, however, it is not being replaced with the war name that is specified in my ear's meta- inf/application.xml file. As a result, the web-app 'test' cannot be found. Hi Peter,
Yeah, this is a known limitation. ATM, the context is taken from the war file name. If you define a context-root different from your war file name it won't work. However, the problem is not so easy to solve, because even if we parse the application.xml, there might be several war defined. I think we should add an optional attribute to the <cactus> task: "context". It would work as follows: When using the warfile atrtibute: 1/ if the "context" attribute is defined, use it 2/ if no "context" is used, then use the war file name as the context When using the earfile attribute: 1/ if the "context" attribute is defined, use it 2/ if no "context" is used, then check application.xml for a war defintion a/ if more than one is found, raise an error and tell the user to use "context" b/ if only one war definition exists, use context-root as the context name What do you think? Thanks Actually, while looking at the code, it seems Chris had already started
implementing this. The way he did it is even better from what I described: he searches for a Cactus redirector in the war archives that are inside the EAR. I now need to read the code more to understand how all that works. Hi Vincent,
I like the context idea - it would work fine for me. I do have some more more comments, though.. I just tried the war file deployment, figuring that I can find a way to deploy my ejbs with ant after the <orion2x> task and before my tests are exec'd. However, the web app would not start because I have defined a jdbc resource in my web.xml that requires the data source defined in my ${my-orion- dir}/config/data-sources.xml. I'm not sure if this is non-j2ee standard, but orion lets you define a context- param element that will expose a JNDI resource (EJB or DataSource) when matched with a resource-ref element. This lets my load-on-startup struts plug-ins to get a new InitialContext() and lookup my db resource without defining a datasource specifically for the web component. Here's the orion page - http://www.orionserver.com/docs/web.xml.html. The comments at the <context-param> and <resource-ref> explain it. The fix may be as simple as copying over the original orion data-sources.xml file. This could default to ${my-orion-dir}/config/data-sources.xml, or there could be an optional param that lets you specify the location of the file. Would that be possible? Thanks, Perry Just for the record, here's a snippet of my web.xml file.. ... <context-param> <param-name>myProjectDB-res-ref-name</param-name> <param-value>jdbc/myProjectDB</param-value> </context-param> ... <resource-ref> <res-ref-name>myProjectDB-res-ref-name</res-ref-name> <res-type>javax.sql.DataSource</res-type> <res-auth>Container</res-auth> </resource-ref> Actually, the data-sources.xml file doesn't really need to be copied. In the
application.xml file that cactus creates for the test app, it just needs an entry for the data sources that points to the file. I think I have fixed everything for EAR deployments... :-) The <cactus> task
will automatically guess the correct webapp context. Can you please try it so that I can close this bug report? I've uploaded a manual build at http://cvs.apache.org/builds/jakarta- cactus/nightly/2003-09-07-manual/ Thanks! Vincent, thanks for the efforts. Unfortunately, I now get an NPE when running
the <cactus> task... cact: [cactus] ----------------------------------------------------------------- [cactus] Running tests against Orion 2.x [cactus] ----------------------------------------------------------------- java.lang.NullPointerException at java.util.Hashtable.put(Hashtable.java:389) at org.apache.tools.ant.filters.ReplaceTokens.addConfiguredToken (ReplaceTokens.java:255) at org.apache.cactus.integration.ant.container.AbstractContainer.createFilterChain (AbstractContainer.java:3 34) at org.apache.cactus.integration.ant.container.orion.AbstractOrionContainer.prepare (AbstractOrionContainer. java:217) at org.apache.cactus.integration.ant.container.orion.Orion2xContainer.startUp (Orion2xContainer.java:90) at org.apache.cactus.integration.ant.container.ContainerRunner$1.run (ContainerRunner.java:185) at java.lang.Thread.run(Thread.java:536) Hi Perry,
We'll succeed one day. Ok, I missed one check for null and I've fixed this in CVS. But that's not the problem. The problem is that Cactus is not able to find out the context path and it returns null. This should not happen. Could you please give me more information about your EAR: how many WARs are there inside? In these WARs, are you sure there's at least one that has a ServletRedirector definition? (this is what Cactus is looking for). Thanks Vincent, it's just one war file in the ear, but the war and ear have different
names. The ear file is myproj.ear, which contains myproj-web.war (which has been successfully cactified and contains the ServletRedirector def). Perry, would you mind either attaching you EAR or sending it to me (you can
remove the java classes as it won't matter)? I have tested it with an EAR with different war name and it works fine here. Thanks. Ok. I think I've fixed everything... At least your scenario works here. I'd
like to close this issue and release Cactus 1.5 rc1. Can you check it is ok? Thanks. Vincent, sorry for being MIA - I have been away for a couple of weeks. I will
try to test this weekend. Thanks for your patience. -Perry I downloaded the 1.6 version and the @cactus.context@ doesn't appear anymore.
Thanks :) However, in my case, the ear is never deployed because <application name="default" path="pathtofilename.ear" /> doesn't appear in server.xml as a result I have this error : [cactus] Error initializing site Default Orion WebSite: Error finding web- app 'test' at C:\temp\dep\knowledge: No such file or directory Pierre,
I have added an EJB sample application in the Cactus distribution. It deploys an EAR containing a WAR file. It works fine for me using Orion 2.0.2. Do you think you could have a look and see what is different from your use case? You can download it at http://cvs.apache.org/builds/jakarta- cactus/nightly/2003-10-23-manual/jakarta-cactus-13-1.6dev-20031023.zip There's no <application name="default" path="pathtofilename.ear" /> in our server.xml file because we are using the auto deploy feature: <application-server application-auto-deploy-directory="../applications" deployment-directory="../application-deployments"> Thanks -Vincent Perry, as I mentioned in an email I just sent to you, I think I have found the
problem. In your application.xml you specify a web-uri but no context-root element. I'm not sure this is allowed. However, I've modified Cactus to support this use case. If no context-root is specified, Cactus will now use the web-uri without a possible leading slash and without the extension. Thanks -Vincent Reverted previous change according to Chris's comment that Cactus is a quality
tool and thus should enforce best practices. <context-root> is not optional. Ok, I upgraded cactus from build 20030907 to 20031023 and now it deploys !
Thank you ! |
|||||||||||||||||||||||||||||||||||||||||||||||||||||
Thanks for the bug report. I've tried with Orion 2.x and a war deployment and
the cactus.context gets replaced fine. So I guess this is an issue only when
using the earfile attribute. I still need to try it.
What is the automated deployment from orion's admin.jar? Can you help us to
set that up?
Thanks
-Vincent