Cargo

Modify JBoss implementation to support expanded war directories not ending with ".war"

Details

  • Type: Improvement Improvement
  • Status: Closed Closed
  • Priority: Major Major
  • Resolution: Won't Fix
  • Affects Version/s: 0.8
  • Fix Version/s: None
  • Component/s: JBoss
  • Labels:
    None
  • Complexity:
    Intermediate
  • Number of attachments :
    0

Description

See http://www.nabble.com/Is-it-possible-to-configure-jboss-to-tell-it-to-deploy-an-expanded-war-without-a-%22.war%22-extension--tf1971300.html

Julient Viet's answer:

You should be able to get it done by changing the configuration of the server.

edit the file
$JBOSS_HOME/server/default/deploy/jbossweb-tomcat55.sar/META-INF/jboss-service.xml

add an MBean attribute :

<attribute name="AcceptNonWarDirs">true</attribute>

by default this value is set to false.

Also it looks like the management interface of this MBean which is a model MBean now does not have the proper attribute declaration, at least for 4.0.4.GA. So with that one you should add in the file :

$JBOSS_HOME/server/default/deploy/jbossweb-tomcat55.sar/META-INF/webserver-xmbean.xml

<attribute
access="read-write"
getMethod="getAcceptNonWarDirs"
setMethod="setAcceptNonWarDirs">
<name>AcceptNonWarDirs</name>
<type>java.lang.String</type>
</attribute>

The missing management attribute looks like it could be fixed in the JBoss codebase.

Issue Links

Activity

Hide
I Nyoman Winardi added a comment -

I've tried to add it to both of the file and test it with 4.0.4.GA but the problem still exist.
The JBoss team also have raise an issue regarding this problem (http://jira.jboss.com/jira/browse/JBAS-3421)
Should we wait for the next release of JBoss (4.0.5) or implement it now?

Show
I Nyoman Winardi added a comment - I've tried to add it to both of the file and test it with 4.0.4.GA but the problem still exist. The JBoss team also have raise an issue regarding this problem (http://jira.jboss.com/jira/browse/JBAS-3421) Should we wait for the next release of JBoss (4.0.5) or implement it now?
Hide
Vincent Massol added a comment -

I think we need to support all versions of JBoss OR throw an error to the user if we don't support a version. We could be clever about it and only throw an error if the user is using JBoss 4.0.4 and using an expanded war directory with no .war in it.

This raises the question as to how long we want to support the different container versions. I think that for now we want to support them all unless they're buggy in some aspects and not working. I think for example that there are some Resin versions that do not work for example. It would be nice to add a new API to the ContainerCapability interface for returning if such version is supported or not. Then this could be checked in the verify() methods.

Show
Vincent Massol added a comment - I think we need to support all versions of JBoss OR throw an error to the user if we don't support a version. We could be clever about it and only throw an error if the user is using JBoss 4.0.4 and using an expanded war directory with no .war in it. This raises the question as to how long we want to support the different container versions. I think that for now we want to support them all unless they're buggy in some aspects and not working. I think for example that there are some Resin versions that do not work for example. It would be nice to add a new API to the ContainerCapability interface for returning if such version is supported or not. Then this could be checked in the verify() methods.
Hide
Savas Ali Tokmen added a comment -

Since this is specific to JBoss 4.0.4, closing issue.

Show
Savas Ali Tokmen added a comment - Since this is specific to JBoss 4.0.4, closing issue.

People

Vote (1)
Watch (0)

Dates

  • Created:
    Updated:
    Resolved: