[JBoss JIRA] (LOGMGR-122) Syslog handler is not generating correct timestamp format
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/LOGMGR-122?page=com.atlassian.jira.plugin... ]
RH Bugzilla Integration updated LOGMGR-122:
-------------------------------------------
Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1295657
Bugzilla Update: Perform
> Syslog handler is not generating correct timestamp format
> ---------------------------------------------------------
>
> Key: LOGMGR-122
> URL: https://issues.jboss.org/browse/LOGMGR-122
> Project: JBoss Log Manager
> Issue Type: Bug
> Affects Versions: 2.0.0.Final
> Environment: Wildfly 9.0.1.Final, Oracle JRE 1.8.0_11, CentOS 6
> Reporter: Ricardo Kagawa
> Assignee: James Perkins
> Fix For: 1.4.4.Final, 1.5.5.Final, 2.0.1.Final, 2.1.0.Beta1
>
>
> The Syslog handler is outputting an extra zero before the month in the header timestamp for RFC5424, specifically for October.
> Checking [Github|https://github.com/jboss-logging/jboss-logmanager/blob/master/src/...], I have noticed that the month number is tested for double digit before being offset, so a zero is added for October (month 9 for java.util.Calendar), then offset for proper display (month "10" for ISO8601), resulting in a three-digit month ("010").
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 5 months
[JBoss JIRA] (DROOLS-1016) Too much memory consumption while running code on drools6.
by Vivek Hingorani (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1016?page=com.atlassian.jira.plugi... ]
Vivek Hingorani reopened DROOLS-1016:
-------------------------------------
Please let us know the usage on heap space as that is more alarming with Drools6.
As if the number of rules increases the usage of heap space will be more and that would create problem for our application. As rules will keep on increasing with new requirements.
> Too much memory consumption while running code on drools6.
> ----------------------------------------------------------
>
> Key: DROOLS-1016
> URL: https://issues.jboss.org/browse/DROOLS-1016
> Project: Drools
> Issue Type: Bug
> Components: core engine
> Affects Versions: 6.2.0.Final
> Reporter: Vivek Hingorani
> Assignee: Mario Fusco
>
> The memory usage on drools6 is far more then drools 5. Can we run the drools6 code with Rete algorithm?
> We recently migrated our project from Drools 5.3.0.Final version to Drools 6.2.0.Final version. In production we can see a significant increase in the memory consumption per node. we are using java 1.7. We increased the permgen space as well for drools6 from 0.5 GB to 1 GB but still the increase is too much. Is there any solution for the same.
> Drools5 memory usage was 0.5GB per node with 0.5GB permgen space
> Drools6 memory usage is 1.3GB per node with 1GB permgen space.
> Node here is a jvm as we are using oracle coherence.
> If further details are needed , let me know.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 5 months
[JBoss JIRA] (DROOLS-1016) Too much memory consumption while running code on drools6.
by Thomas Leung (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1016?page=com.atlassian.jira.plugi... ]
Thomas Leung commented on DROOLS-1016:
--------------------------------------
Thanks Mario, and how about the heap size? We observed there is used heap increased from 0.5GB to 1.3GB when migrating from Drools 5 to Drools 6. Will it be caused by phreak algorithm? Or any other suggestion that we can reduce the heap consumption?
> Too much memory consumption while running code on drools6.
> ----------------------------------------------------------
>
> Key: DROOLS-1016
> URL: https://issues.jboss.org/browse/DROOLS-1016
> Project: Drools
> Issue Type: Bug
> Components: core engine
> Affects Versions: 6.2.0.Final
> Reporter: Vivek Hingorani
> Assignee: Mario Fusco
>
> The memory usage on drools6 is far more then drools 5. Can we run the drools6 code with Rete algorithm?
> We recently migrated our project from Drools 5.3.0.Final version to Drools 6.2.0.Final version. In production we can see a significant increase in the memory consumption per node. we are using java 1.7. We increased the permgen space as well for drools6 from 0.5 GB to 1 GB but still the increase is too much. Is there any solution for the same.
> Drools5 memory usage was 0.5GB per node with 0.5GB permgen space
> Drools6 memory usage is 1.3GB per node with 1GB permgen space.
> Node here is a jvm as we are using oracle coherence.
> If further details are needed , let me know.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 5 months
[JBoss JIRA] (WFLY-5931) HTTP connection is getting closed after 5 mins
by Rakesh Kumar (JIRA)
[ https://issues.jboss.org/browse/WFLY-5931?page=com.atlassian.jira.plugin.... ]
Rakesh Kumar updated WFLY-5931:
-------------------------------
Affects Version/s: 9.0.1.Final
(was: 9.0.2.Final)
> HTTP connection is getting closed after 5 mins
> ----------------------------------------------
>
> Key: WFLY-5931
> URL: https://issues.jboss.org/browse/WFLY-5931
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Affects Versions: 9.0.1.Final
> Environment: Wildfly 9.0.1 + Linux
> Reporter: Rakesh Kumar
> Assignee: Stuart Douglas
> Priority: Critical
> Fix For: 9.x.x TBD
>
>
> HTTP connection is getting closed after 5 mins with Linux + Wildfly 9.0.1 and throws broken pipe exception after the request is processed, It works fine in windows + Wildfly 9.0.1.
> I tried to increase keepalive timeout using the following alternatives.
> • Update values in httpd.conf from 300 seconds to 1500 seconds
> • Add KeepAliveTimeout response header in standalone.xml
> • Add header in response using “response.addHeader("Keep-Alive", "timeout=180000");”
> • Updated jsp to add ("Keep-Alive", "timeout=180000" ) in response header.
> None of the above alternatives worked.
> Error message :
> 2015-10-23 18:46:47,250 ERROR [default task-29] [RequestServlet] Unknown exception detected: java.io.IOException: Broken pipe
> at sun.nio.ch.FileDispatcherImpl.writev0(Native Method) [rt.jar:1.7.0_45]
> at sun.nio.ch.SocketDispatcher.writev(SocketDispatcher.java:51) [rt.jar:1.7.0_45]
> at sun.nio.ch.IOUtil.write(IOUtil.java:148) [rt.jar:1.7.0_45]
> at sun.nio.ch.SocketChannelImpl.write(SocketChannelImpl.java:524) [rt.jar:1.7.0_45]
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 5 months
[JBoss JIRA] (WFLY-5931) HTTP connection is getting closed after 5 mins
by Rakesh Kumar (JIRA)
Rakesh Kumar created WFLY-5931:
----------------------------------
Summary: HTTP connection is getting closed after 5 mins
Key: WFLY-5931
URL: https://issues.jboss.org/browse/WFLY-5931
Project: WildFly
Issue Type: Bug
Components: Web (Undertow)
Affects Versions: 9.0.2.Final
Environment: Wildfly 9.0.1 + Linux
Reporter: Rakesh Kumar
Assignee: Stuart Douglas
Priority: Critical
Fix For: 9.x.x TBD
HTTP connection is getting closed after 5 mins with Linux + Wildfly 9.0.1 and throws broken pipe exception after the request is processed, It works fine in windows + Wildfly 9.0.1.
I tried to increase keepalive timeout using the following alternatives.
• Update values in httpd.conf from 300 seconds to 1500 seconds
• Add KeepAliveTimeout response header in standalone.xml
• Add header in response using “response.addHeader("Keep-Alive", "timeout=180000");”
• Updated jsp to add ("Keep-Alive", "timeout=180000" ) in response header.
None of the above alternatives worked.
Error message :
2015-10-23 18:46:47,250 ERROR [default task-29] [RequestServlet] Unknown exception detected: java.io.IOException: Broken pipe
at sun.nio.ch.FileDispatcherImpl.writev0(Native Method) [rt.jar:1.7.0_45]
at sun.nio.ch.SocketDispatcher.writev(SocketDispatcher.java:51) [rt.jar:1.7.0_45]
at sun.nio.ch.IOUtil.write(IOUtil.java:148) [rt.jar:1.7.0_45]
at sun.nio.ch.SocketChannelImpl.write(SocketChannelImpl.java:524) [rt.jar:1.7.0_45]
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 5 months
[JBoss JIRA] (WFLY-5930) Unable to load deployments
by Hamed Abdollahpour (JIRA)
Hamed Abdollahpour created WFLY-5930:
----------------------------------------
Summary: Unable to load deployments
Key: WFLY-5930
URL: https://issues.jboss.org/browse/WFLY-5930
Project: WildFly
Issue Type: Feature Request
Components: Web Console
Affects Versions: 9.0.2.Final
Reporter: Hamed Abdollahpour
Assignee: Heiko Braun
Fail to get list of deployment on application server with this error:
12:19:40,130 ERROR [org.jboss.as.controller.management-operation] (XNIO-1 task-3) WFLYCTL0013: Operation ("read-attribute") failed - address: ([
("deployment" => "discripto-ear.ear"),
("subdeployment" => "discripto-rest.war"),
("subsystem" => "undertow"),
("servlet" => "com.wpic.discripto.rest.App")
]): java.lang.NullPointerException
at org.wildfly.extension.undertow.DeploymentServletDefinition$AbstractMetricsHandler.execute(DeploymentServletDefinition.java:121)
at org.jboss.as.controller.operations.global.ReadAttributeHandler.doExecuteInternal(ReadAttributeHandler.java:174)
at org.jboss.as.controller.operations.global.ReadAttributeHandler.doExecute(ReadAttributeHandler.java:137)
at org.jboss.as.controller.operations.global.GlobalOperationHandlers$AbstractMultiTargetHandler.execute(GlobalOperationHandlers.java:196)
at org.jboss.as.controller.operations.global.GlobalOperationHandlers$AvailableResponseWrapper.execute(GlobalOperationHandlers.java:641)
at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:803)
at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:601)
at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:354)
at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:330)
at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1183)
at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:362)
at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:218)
at org.jboss.as.domain.http.server.DomainApiHandler.handleRequest(DomainApiHandler.java:208)
at io.undertow.server.handlers.encoding.EncodingHandler.handleRequest(EncodingHandler.java:72)
at org.jboss.as.domain.http.server.security.SubjectDoAsHandler$1.run(SubjectDoAsHandler.java:72)
at org.jboss.as.domain.http.server.security.SubjectDoAsHandler$1.run(SubjectDoAsHandler.java:68)
at java.security.AccessController.doPrivileged(Native Method)
at javax.security.auth.Subject.doAs(Subject.java:415)
at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:92)
at org.jboss.as.domain.http.server.security.SubjectDoAsHandler.handleRequest(SubjectDoAsHandler.java:68)
at org.jboss.as.domain.http.server.security.SubjectDoAsHandler.handleRequest(SubjectDoAsHandler.java:63)
at io.undertow.server.handlers.BlockingHandler.handleRequest(BlockingHandler.java:56)
at org.jboss.as.domain.http.server.DomainApiCheckHandler.handleRequest(DomainApiCheckHandler.java:95)
at io.undertow.security.handlers.AuthenticationCallHandler.handleRequest(AuthenticationCallHandler.java:52)
at io.undertow.server.Connectors.executeRootHandler(Connectors.java:199)
at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:774)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:745)
12:21:20,258 ERROR [org.jboss.as.controller.management-operation] (XNIO-1 task-2) WFLYCTL0013: Operation ("read-attribute") failed - address: ([
("deployment" => "discripto-ear.ear"),
("subdeployment" => "discripto-rest.war"),
("subsystem" => "undertow"),
("servlet" => "com.wpic.discripto.rest.App")
]): java.lang.NullPointerException
at org.wildfly.extension.undertow.DeploymentServletDefinition$AbstractMetricsHandler.execute(DeploymentServletDefinition.java:121)
at org.jboss.as.controller.operations.global.ReadAttributeHandler.doExecuteInternal(ReadAttributeHandler.java:174)
at org.jboss.as.controller.operations.global.ReadAttributeHandler.doExecute(ReadAttributeHandler.java:137)
at org.jboss.as.controller.operations.global.GlobalOperationHandlers$AbstractMultiTargetHandler.execute(GlobalOperationHandlers.java:196)
at org.jboss.as.controller.operations.global.GlobalOperationHandlers$AvailableResponseWrapper.execute(GlobalOperationHandlers.java:641)
at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:803)
at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:601)
at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:354)
at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:330)
at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1183)
at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:362)
at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:218)
at org.jboss.as.domain.http.server.DomainApiHandler.handleRequest(DomainApiHandler.java:208)
at io.undertow.server.handlers.encoding.EncodingHandler.handleRequest(EncodingHandler.java:72)
at org.jboss.as.domain.http.server.security.SubjectDoAsHandler$1.run(SubjectDoAsHandler.java:72)
at org.jboss.as.domain.http.server.security.SubjectDoAsHandler$1.run(SubjectDoAsHandler.java:68)
at java.security.AccessController.doPrivileged(Native Method)
at javax.security.auth.Subject.doAs(Subject.java:415)
at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:92)
at org.jboss.as.domain.http.server.security.SubjectDoAsHandler.handleRequest(SubjectDoAsHandler.java:68)
at org.jboss.as.domain.http.server.security.SubjectDoAsHandler.handleRequest(SubjectDoAsHandler.java:63)
at io.undertow.server.handlers.BlockingHandler.handleRequest(BlockingHandler.java:56)
at org.jboss.as.domain.http.server.DomainApiCheckHandler.handleRequest(DomainApiCheckHandler.java:95)
at io.undertow.security.handlers.AuthenticationCallHandler.handleRequest(AuthenticationCallHandler.java:52)
at io.undertow.server.Connectors.executeRootHandler(Connectors.java:199)
at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:774)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:745)
It works perfect after restarting.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 5 months
[JBoss JIRA] (WFLY-5922) Cannot exclude java.orb.api module
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFLY-5922?page=com.atlassian.jira.plugin.... ]
Stuart Douglas commented on WFLY-5922:
--------------------------------------
Actually it looks like this is then re-exported from javax/ejb/api
> Cannot exclude java.orb.api module
> ----------------------------------
>
> Key: WFLY-5922
> URL: https://issues.jboss.org/browse/WFLY-5922
> Project: WildFly
> Issue Type: Bug
> Components: Class Loading
> Affects Versions: 10.0.0.CR4
> Environment: Red Hat Enterprise Linux Server release 7.1 (Maipo)
> Linux 3.10.0-229.4.2.el7.x86_64 #1 SMP Wed May 13 10:06:09 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux
> java version "1.8.0_60"
> Java(TM) SE Runtime Environment (build 1.8.0_60-b27)
> Java HotSpot(TM) 64-Bit Server VM (build 25.60-b23, mixed mode)
> Reporter: John Farrelly
> Assignee: David Lloyd
> Priority: Blocker
>
> We use Orbacus as our CORBA implementation, and in our application we wish to use CORBA classes only from the orbacus module, and not the JDK/WildFly bundled CORBA.
> In the {{jboss-deployment-structure.xml}} file of our {{ear}} file, we have the following:
> {code:xml}
> <?xml version="1.0" encoding="UTF-8"?>
> <jboss-deployment-structure>
> <ear-subdeployments-isolated>false</ear-subdeployments-isolated>
> <deployment>
> <exclusions>
> <module name="javax.orb.api" />
> <module name="org.omg.api" />
> </exclusions>
> <dependencies>
> <module name="com.ooc.orbacus" export="true"/>
> <module name="org.apache.commons.logging" export="true" />
> <module name="org.apache.commons.collections" export="true" />
> <module name="org.apache.log4j" export="true" />
> <module name="org.dom4j" export="true" />
> <module name="org.jdom" export="true" />
> <module name="javax.faces.api" slot="mojarra-2.1.23" export="true"/>
> <module name="com.sun.jsf-impl" slot="mojarra-2.1.23" export="true"/>
> <module name="org.jboss.ejb-client" export="true" />
> <module name="org.jboss.remote-naming" export="true" />
> <module name="org.jboss.remoting3" export="true" />
> <module name="org.apache.xerces" />
> <!-- dependency for richfaces -->
> <module name="com.google.guava" slot="11.0.2" export="true"/>
> </dependencies>
> </deployment>
> ...
> {code}
> However, despite excluding the {{javax.orb.api}} module, I can see that {{org.omg.PortableServer.Servant}} is loaded from that module instead of being loaded from our {{com.ooc.orbacus}} module. This causes our application to fail.
> Debugging through the jboss module loader, I can see that it considers both {{javax.orb.api}} and {{com.ooc.orbacus}} as prodivers of the {{org/omg/PortableServer}} path. I am not sure why {{javax.orb.api}} is being considered when it has been excluded in the deployment descriptor for the application.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 5 months
[JBoss JIRA] (WFLY-5922) Cannot exclude java.orb.api module
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFLY-5922?page=com.atlassian.jira.plugin.... ]
Stuart Douglas commented on WFLY-5922:
--------------------------------------
Otherwise you also need to exclude org.omg.api, as it re-exports classes from the javax.orb.api module.
> Cannot exclude java.orb.api module
> ----------------------------------
>
> Key: WFLY-5922
> URL: https://issues.jboss.org/browse/WFLY-5922
> Project: WildFly
> Issue Type: Bug
> Components: Class Loading
> Affects Versions: 10.0.0.CR4
> Environment: Red Hat Enterprise Linux Server release 7.1 (Maipo)
> Linux 3.10.0-229.4.2.el7.x86_64 #1 SMP Wed May 13 10:06:09 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux
> java version "1.8.0_60"
> Java(TM) SE Runtime Environment (build 1.8.0_60-b27)
> Java HotSpot(TM) 64-Bit Server VM (build 25.60-b23, mixed mode)
> Reporter: John Farrelly
> Assignee: David Lloyd
> Priority: Blocker
>
> We use Orbacus as our CORBA implementation, and in our application we wish to use CORBA classes only from the orbacus module, and not the JDK/WildFly bundled CORBA.
> In the {{jboss-deployment-structure.xml}} file of our {{ear}} file, we have the following:
> {code:xml}
> <?xml version="1.0" encoding="UTF-8"?>
> <jboss-deployment-structure>
> <ear-subdeployments-isolated>false</ear-subdeployments-isolated>
> <deployment>
> <exclusions>
> <module name="javax.orb.api" />
> <module name="org.omg.api" />
> </exclusions>
> <dependencies>
> <module name="com.ooc.orbacus" export="true"/>
> <module name="org.apache.commons.logging" export="true" />
> <module name="org.apache.commons.collections" export="true" />
> <module name="org.apache.log4j" export="true" />
> <module name="org.dom4j" export="true" />
> <module name="org.jdom" export="true" />
> <module name="javax.faces.api" slot="mojarra-2.1.23" export="true"/>
> <module name="com.sun.jsf-impl" slot="mojarra-2.1.23" export="true"/>
> <module name="org.jboss.ejb-client" export="true" />
> <module name="org.jboss.remote-naming" export="true" />
> <module name="org.jboss.remoting3" export="true" />
> <module name="org.apache.xerces" />
> <!-- dependency for richfaces -->
> <module name="com.google.guava" slot="11.0.2" export="true"/>
> </dependencies>
> </deployment>
> ...
> {code}
> However, despite excluding the {{javax.orb.api}} module, I can see that {{org.omg.PortableServer.Servant}} is loaded from that module instead of being loaded from our {{com.ooc.orbacus}} module. This causes our application to fail.
> Debugging through the jboss module loader, I can see that it considers both {{javax.orb.api}} and {{com.ooc.orbacus}} as prodivers of the {{org/omg/PortableServer}} path. I am not sure why {{javax.orb.api}} is being considered when it has been excluded in the deployment descriptor for the application.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 5 months
[JBoss JIRA] (WFLY-5922) Cannot exclude java.orb.api module
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFLY-5922?page=com.atlassian.jira.plugin.... ]
Stuart Douglas commented on WFLY-5922:
--------------------------------------
Have you added the exclusions to both?
A simpler way it to just exclude the iiop subsystem entirely using exclude-subsystem, which should stop the dependency being added.
> Cannot exclude java.orb.api module
> ----------------------------------
>
> Key: WFLY-5922
> URL: https://issues.jboss.org/browse/WFLY-5922
> Project: WildFly
> Issue Type: Bug
> Components: Class Loading
> Affects Versions: 10.0.0.CR4
> Environment: Red Hat Enterprise Linux Server release 7.1 (Maipo)
> Linux 3.10.0-229.4.2.el7.x86_64 #1 SMP Wed May 13 10:06:09 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux
> java version "1.8.0_60"
> Java(TM) SE Runtime Environment (build 1.8.0_60-b27)
> Java HotSpot(TM) 64-Bit Server VM (build 25.60-b23, mixed mode)
> Reporter: John Farrelly
> Assignee: David Lloyd
> Priority: Blocker
>
> We use Orbacus as our CORBA implementation, and in our application we wish to use CORBA classes only from the orbacus module, and not the JDK/WildFly bundled CORBA.
> In the {{jboss-deployment-structure.xml}} file of our {{ear}} file, we have the following:
> {code:xml}
> <?xml version="1.0" encoding="UTF-8"?>
> <jboss-deployment-structure>
> <ear-subdeployments-isolated>false</ear-subdeployments-isolated>
> <deployment>
> <exclusions>
> <module name="javax.orb.api" />
> <module name="org.omg.api" />
> </exclusions>
> <dependencies>
> <module name="com.ooc.orbacus" export="true"/>
> <module name="org.apache.commons.logging" export="true" />
> <module name="org.apache.commons.collections" export="true" />
> <module name="org.apache.log4j" export="true" />
> <module name="org.dom4j" export="true" />
> <module name="org.jdom" export="true" />
> <module name="javax.faces.api" slot="mojarra-2.1.23" export="true"/>
> <module name="com.sun.jsf-impl" slot="mojarra-2.1.23" export="true"/>
> <module name="org.jboss.ejb-client" export="true" />
> <module name="org.jboss.remote-naming" export="true" />
> <module name="org.jboss.remoting3" export="true" />
> <module name="org.apache.xerces" />
> <!-- dependency for richfaces -->
> <module name="com.google.guava" slot="11.0.2" export="true"/>
> </dependencies>
> </deployment>
> ...
> {code}
> However, despite excluding the {{javax.orb.api}} module, I can see that {{org.omg.PortableServer.Servant}} is loaded from that module instead of being loaded from our {{com.ooc.orbacus}} module. This causes our application to fail.
> Debugging through the jboss module loader, I can see that it considers both {{javax.orb.api}} and {{com.ooc.orbacus}} as prodivers of the {{org/omg/PortableServer}} path. I am not sure why {{javax.orb.api}} is being considered when it has been excluded in the deployment descriptor for the application.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 5 months
[JBoss JIRA] (WFLY-4296) remove _ds.xml deployment support
by Darryl Miles (JIRA)
[ https://issues.jboss.org/browse/WFLY-4296?page=com.atlassian.jira.plugin.... ]
Darryl Miles commented on WFLY-4296:
------------------------------------
Please write up a migration wiki like document, with links to the documentation for the previous method and the new method (these documents should enumerate all features available).
Please also post here so others looking for it can reference it before then making a comment.
I don't see a problem myself with adding datasources view CLI console, as it looks like there is support to interrogate the current config, then add new config, then reload.
> remove _ds.xml deployment support
> ---------------------------------
>
> Key: WFLY-4296
> URL: https://issues.jboss.org/browse/WFLY-4296
> Project: WildFly
> Issue Type: Feature Request
> Components: JCA
> Reporter: Stefano Maestri
>
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 5 months