Issue Details (XML | Word | Printable)

Key: CACTUS-52
Type: Bug Bug
Status: Closed Closed
Resolution: Fixed
Priority: Major Major
Assignee: Vincent Massol
Reporter: Jonathan Kovacs
Votes: 0
Watchers: 0
Operations

If you were logged in you would be able to see more operations.
Cactus

Unable to use EAR file with Orion 2.x server

Created: 28/Aug/03 11:36 PM   Updated: 17/Apr/04 03:43 PM
Return to search
Component/s: Other
Affects Version/s: 1.5-beta1
Fix Version/s: 1.5-rc1

Time Tracking:
Not Specified

Environment:
Operating System: Linux
Platform: PC

Bugzilla Id: 22794


 Description  « Hide
When attempting to call the <cactus> task with an ear file using the orion2x
container, I get the following error:

[cactus] Error initializing site Default Orion WebSite: Error finding web-app
'test' at /tmp/cactus/orion2x/@cactus.context@: No such file or directory

The problem is on line 6 of the
integration/ant/src/confs/share/orion2x/application.xml file:

     <web-module id="test" path="../@cactus.context@.war"/>

Perhaps it might be possible to update the orion support to utilize the
automated deployment from orion's admin.jar?

 All   Comments   Work Log   Change History   Subversion Commits      Sort Order: Ascending order - Click to sort in descending order
Vincent Massol added a comment - 29/Aug/03 02:37 PM
Hi Jonathan,

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

Jonathan Kovacs added a comment - 29/Aug/03 09:14 PM
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.

Vincent Massol added a comment - 30/Aug/03 12:40 AM
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

Vincent Massol added a comment - 30/Aug/03 04:13 AM
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

Jonathan Kovacs added a comment - 30/Aug/03 04:31 AM
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.

Vincent Massol added a comment - 05/Sep/03 01:40 PM
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

Perry Young added a comment - 07/Sep/03 01:19 AM
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.

Vincent Massol added a comment - 07/Sep/03 01:32 AM
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

Vincent Massol added a comment - 07/Sep/03 01:41 AM
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.

Perry Young added a comment - 07/Sep/03 02:24 AM
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>



Perry Young added a comment - 07/Sep/03 02:46 AM
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.

Vincent Massol added a comment - 08/Sep/03 03:12 AM
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!

Perry Young added a comment - 08/Sep/03 08:29 AM
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)

Vincent Massol added a comment - 08/Sep/03 02:37 PM
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

Perry Young added a comment - 10/Sep/03 12:14 AM
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).

Vincent Massol added a comment - 10/Sep/03 01:25 AM
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.

Vincent Massol added a comment - 13/Sep/03 07:09 PM
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.

Perry Young added a comment - 25/Sep/03 01:36 AM
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

Pierre De Belen added a comment - 10/Oct/03 04:41 AM
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

Vincent Massol added a comment - 23/Oct/03 08:55 PM
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

Vincent Massol added a comment - 24/Oct/03 10:30 PM
Closing this bug for now.

Vincent Massol added a comment - 25/Oct/03 11:57 PM
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

Vincent Massol added a comment - 26/Oct/03 04:12 AM
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.

Pierre De Belen added a comment - 28/Oct/03 02:23 AM
Ok, I upgraded cactus from build 20030907 to 20031023 and now it deploys !
Thank you !