[JBoss JIRA] (WFCORE-446) Provide an 'enable' parameter to the 'full-replace-deployment' operation
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-446?page=com.atlassian.jira.plugin... ]
Brian Stansberry moved WFLY-4154 to WFCORE-446:
-----------------------------------------------
Project: WildFly Core (was: WildFly)
Key: WFCORE-446 (was: WFLY-4154)
Component/s: Domain Management
(was: Domain Management)
Fix Version/s: 1.0.0.Beta1
(was: 9.0.0.Beta1)
> Provide an 'enable' parameter to the 'full-replace-deployment' operation
> ------------------------------------------------------------------------
>
> Key: WFCORE-446
> URL: https://issues.jboss.org/browse/WFCORE-446
> Project: WildFly Core
> Issue Type: Feature Request
> Components: Domain Management
> Reporter: Heiko Braun
> Assignee: Brian Stansberry
> Fix For: 1.0.0.Beta1
>
>
> Similar to the /deployment=*:add() operation the /:full-replace-deployment() operarion should provide an 'enable' parameter that defines wether or not the deplyment should be enabled after the reaplcement.
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
9 years, 11 months
[JBoss JIRA] (WFCORE-102) Remove the need for OSH authors to deal with ServiceVerificationHandler or removal of installed services in rollback
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-102?page=com.atlassian.jira.plugin... ]
Brian Stansberry updated WFCORE-102:
------------------------------------
Git Pull Request: https://github.com/wildfly/wildfly-core/pull/182
> Remove the need for OSH authors to deal with ServiceVerificationHandler or removal of installed services in rollback
> --------------------------------------------------------------------------------------------------------------------
>
> Key: WFCORE-102
> URL: https://issues.jboss.org/browse/WFCORE-102
> Project: WildFly Core
> Issue Type: Enhancement
> Components: Domain Management
> Reporter: Brian Stansberry
> Assignee: Brian Stansberry
> Fix For: 1.0.0.Alpha9
>
>
> The various base classes OSH authors use to create handlers force the author to deal with ServiceVerificationHandler and, during rollback, with removing any services the OSH added. This task is to have the OperationContext handle these things transparently, removing the need for authors to do so.
> To preserve compatibility, the various API methods authors may have overridden that expose the SVH and the list of added ServiceControllers will be retained (but deprecated), but the SVH and the list of handlers won't be used. The API javadoc will encourage use of method variants that don't use these parameters.
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
9 years, 11 months
[JBoss JIRA] (LOGMGR-118) Support suppressed exceptions in log formatting
by David Lloyd (JIRA)
David Lloyd created LOGMGR-118:
----------------------------------
Summary: Support suppressed exceptions in log formatting
Key: LOGMGR-118
URL: https://issues.jboss.org/browse/LOGMGR-118
Project: JBoss Log Manager
Issue Type: Feature Request
Components: core
Reporter: David Lloyd
In JDK 7 and on, a Throwable bundles a list of suppressed exceptions. We should be logging these as part of our exception formatting... however we have to do so thoughtfully, because every caused-by and suppressed exception may in turn have more suppressed exceptions and caused-by.
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
9 years, 11 months
[JBoss JIRA] (WFLY-3316) Multi threaded ejb invocations via remote-naming produce EJBCLIENT000025 if the Context is closed
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-3316?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on WFLY-3316:
-----------------------------------------------
Enrique Gonzalez Martinez <egonzale(a)redhat.com> changed the Status of [bug 1094380|https://bugzilla.redhat.com/show_bug.cgi?id=1094380] from ASSIGNED to POST
> Multi threaded ejb invocations via remote-naming produce EJBCLIENT000025 if the Context is closed
> -------------------------------------------------------------------------------------------------
>
> Key: WFLY-3316
> URL: https://issues.jboss.org/browse/WFLY-3316
> Project: WildFly
> Issue Type: Bug
> Components: EJB
> Affects Versions: 8.0.0.Final
> Reporter: Wolf-Dieter Fink
> Assignee: Enrique González Martínez
> Labels: ejb, naming, remote-clients, remote-ejb-connection
> Attachments: reproducer.zip
>
>
> If a client run multi threads and each Thread use it's own InitialContext the behaviour is unexpected.
> The behaviour is as followed:
> if each invocation create it's own IC and lookup the EJB there is sometimes a EJBCLIENT000025 because one of the one thread has closed the IC until another thread try to invoke an EJB.
> If the IC is reused the failure might happen only if the first Thread has finished the invocations and close the IC during other Threads are still running.
> It looks that the underlying remote connection will be closed if the first IC is closed without respect that there are different IC's created and still in use.
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
9 years, 11 months
[JBoss JIRA] (JBJCA-1239) codegenerator fails to create ra.xml for maven-rar-plugin
by Steve Gorman (JIRA)
[ https://issues.jboss.org/browse/JBJCA-1239?page=com.atlassian.jira.plugin... ]
Steve Gorman commented on JBJCA-1239:
-------------------------------------
I am sorry it was just confusion on my part then. I saw the configuration in the pom for <raXmlFile> pointing to a file that I could find so I just assumed it was supposed to be there.
Hope I didn't cause a fire alarm.
> codegenerator fails to create ra.xml for maven-rar-plugin
> ---------------------------------------------------------
>
> Key: JBJCA-1239
> URL: https://issues.jboss.org/browse/JBJCA-1239
> Project: IronJacamar
> Issue Type: Bug
> Components: Code Generator
> Affects Versions: 1.2.0.Final
> Reporter: Steve Gorman
> Assignee: Jeff Zhang
> Labels: maven
> Fix For: 1.2.1.Final
>
>
> After generating a maven project the ra.xml file is not part of the generated code but is referenced in the pom.xml
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
9 years, 11 months
[JBoss JIRA] (WFLY-4008) MBean deployment causes javax.naming.NameNotFoundException: java:comp/BeanManager
by Amos Feng (JIRA)
[ https://issues.jboss.org/browse/WFLY-4008?page=com.atlassian.jira.plugin.... ]
Amos Feng commented on WFLY-4008:
---------------------------------
[~dlmiles], can you provide me all the codes as it looks like we meet the same issue but I don't use @MXBean annotation ?
> MBean deployment causes javax.naming.NameNotFoundException: java:comp/BeanManager
> ----------------------------------------------------------------------------------
>
> Key: WFLY-4008
> URL: https://issues.jboss.org/browse/WFLY-4008
> Project: WildFly
> Issue Type: Bug
> Components: CDI / Weld, JMX, Naming
> Affects Versions: 8.1.0.Final
> Reporter: Darryl Miles
> Assignee: Stuart Douglas
> Labels: mbean
>
> If you create an MBean in your EJB and deploy the EJB.
> <pre>
> @SuppressWarnings("serial")
> public class Monitor implements MonitorMXBean, Serializable {
> private static final Logger log = LoggerFactory.getLogger(Monitor.class);
> private Boolean enabled = Boolean.FALSE;
> private Long valueOne;
> public Monitor() {
> log.debug("CTOR");
> }
> @Override
> public Boolean isEnabled() {
> return enabled;
> }
> @Override
> public void setEnabled(Boolean enabled) {
> this.enabled = enabled;
> }
> @Override
> public Long getValueOne() {
> return valueOne;
> }
> @Override
> public void setValueOne(Long valueOne) {
> this.valueOne = valueOne;
> }
> }
> </pre>
> And JMX MXBean
> <pre>
> import javax.management.MXBean;
> @MXBean
> public interface MonitorMXBean {
> void setEnabled(Boolean enabled);
> Boolean isEnabled();
> void setValueOne(Long valueOne);
> Long getValueOne();
> }
> </pre>
> 17:34:42,455 ERROR [org.jboss.as.weld] (MSC service thread 1-1) JBAS016001: Failed to tear down Weld contexts: javax.naming.NameNotFoundException: java:comp/BeanManager
> at org.jboss.as.naming.InitialContext$DefaultInitialContext.findContext(InitialContext.java:187)
> at org.jboss.as.naming.InitialContext$DefaultInitialContext.lookup(InitialContext.java:231)
> at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:188)
> at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:184)
> at javax.naming.InitialContext.lookup(InitialContext.java:417) [rt.jar:1.8.0_25]
> at javax.naming.InitialContext.lookup(InitialContext.java:417) [rt.jar:1.8.0_25]
> at org.jboss.as.weld.arquillian.WeldContextSetup.teardown(WeldContextSetup.java:108)
> at org.jboss.as.jmx.MBeanRegistrationService.stop(MBeanRegistrationService.java:132) [wildfly-jmx-8.1.0.Final.jar:8.1.0.Final]
> at org.jboss.msc.service.ServiceControllerImpl$StopTask.stopService(ServiceControllerImpl.java:2056) [jboss-msc-1.2.2.Final.jar:1.2.2.Final]
> at org.jboss.msc.service.ServiceControllerImpl$StopTask.run(ServiceControllerImpl.java:2017) [jboss-msc-1.2.2.Final.jar:1.2.2.Final]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0_25]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0_25]
> at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_25]
> Is this related to: https://issues.jboss.org/browse/WFLY-822 ?
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
9 years, 11 months
[JBoss JIRA] (WFLY-4156) WildFly is not able to parse ejb-jar.xml of version 2.0
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-4156?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on WFLY-4156:
-----------------------------------------------
Ivo Studensky <istudens(a)redhat.com> changed the Status of [bug 1057835|https://bugzilla.redhat.com/show_bug.cgi?id=1057835] from ASSIGNED to POST
> WildFly is not able to parse ejb-jar.xml of version 2.0
> -------------------------------------------------------
>
> Key: WFLY-4156
> URL: https://issues.jboss.org/browse/WFLY-4156
> Project: WildFly
> Issue Type: Bug
> Components: EJB
> Affects Versions: 9.0.0.Alpha1
> Reporter: Ivo Studensky
> Assignee: Ivo Studensky
>
> - While using "ejb-jar.xml" of version 2.0 as following EAP/WildFly throws the parsing error:
> {code}
> <?xml version="1.0"?>
> <!DOCTYPE ejb-jar
> PUBLIC "-//Sun Microsystems, Inc.//DTD Enterprise JavaBeans 2.0//EN"
> "http://java.sun.com/dtd/ejb-jar_2_0.dtd">
> <ejb-jar>
> <enterprise-beans>
> <message-driven>
> <ejb-name>ExampleMDB</ejb-name>
> <ejb-class>test.mdb.ExampleMDB</ejb-class>
> <transaction-type>Container</transaction-type>
> <message-driven-destination>
> <destination-type>javax.jms.Queue</destination-type>
> </message-driven-destination>
> <resource-ref>
> <res-ref-name>jms/QueueConnectionFactory</res-ref-name>
> <res-type>javax.jms.QueueConnectionFactory</res-type>
> <res-auth>Container</res-auth>
> </resource-ref>
> </message-driven>
> </enterprise-beans>
> </ejb-jar>
> {code}
> - The following error is encountered at the time of deployment:
> {code}
> 17:40:04,405 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-7) MSC000001: Failed to start service jboss.deployment.unit."TestEJB.jar".PARSE: org.jboss.msc.service.StartException in service jboss.deployment.unit."TestEJB.jar".PARSE: JBAS018733: Failed to process phase PARSE of deployment "TestEJB.jar"
> at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:127) [jboss-as-server-7.3.0.Final-redhat-14.jar:7.3.0.Final-redhat-14]
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1811) [jboss-msc-1.0.4.GA-redhat-1.jar:1.0.4.GA-redhat-1]
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1746) [jboss-msc-1.0.4.GA-redhat-1.jar:1.0.4.GA-redhat-1]
> at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:895) [rt.jar:1.6.0_45]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:918) [rt.jar:1.6.0_45]
> at java.lang.Thread.run(Thread.java:662) [rt.jar:1.6.0_45]
> Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException: JBAS014185: Exception while parsing ejb-jar.xml: /content/TestEJB.jar/META-INF/ejb-jar.xml
> at org.jboss.as.ejb3.deployment.processors.EjbJarParsingDeploymentUnitProcessor.parseEjbJarXml(EjbJarParsingDeploymentUnitProcessor.java:250)
> at org.jboss.as.ejb3.deployment.processors.EjbJarParsingDeploymentUnitProcessor.deploy(EjbJarParsingDeploymentUnitProcessor.java:121)
> at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:120) [jboss-as-server-7.3.0.Final-redhat-14.jar:7.3.0.Final-redhat-14]
> ... 5 more
> Caused by: javax.xml.stream.XMLStreamException: ParseError at [row,col]:[14,10]
> Message: Unexpected element 'message-driven-destination' encountered
> at org.jboss.metadata.parser.util.MetaDataElementParser.unexpectedElement(MetaDataElementParser.java:109)
> at org.jboss.metadata.ejb.parser.spec.AbstractMetaDataParser.processElement(AbstractMetaDataParser.java:56)
> at org.jboss.metadata.ejb.parser.spec.AbstractNamedMetaDataWithDescriptionGroupParser.processElement(AbstractNamedMetaDataWithDescriptionGroupParser.java:67)
> at org.jboss.metadata.ejb.parser.spec.AbstractEnterpriseBeanMetaDataParser.processElement(AbstractEnterpriseBeanMetaDataParser.java:85)
> at org.jboss.metadata.ejb.parser.spec.AbstractMessageDrivenBeanParser.processElement(AbstractMessageDrivenBeanParser.java:94)
> at org.jboss.metadata.ejb.parser.spec.MessageDrivenBean31Parser.processElement(MessageDrivenBean31Parser.java:77)
> at org.jboss.metadata.ejb.parser.spec.MessageDrivenBean31Parser.processElement(MessageDrivenBean31Parser.java:37)
> at org.jboss.metadata.ejb.parser.spec.AbstractMetaDataParser.processElements(AbstractMetaDataParser.java:69)
> at org.jboss.metadata.ejb.parser.spec.MessageDrivenBean31Parser.parse(MessageDrivenBean31Parser.java:44)
> at org.jboss.metadata.ejb.parser.spec.EnterpriseBeansMetaDataParser.processElement(EnterpriseBeansMetaDataParser.java:99)
> at org.jboss.metadata.ejb.parser.spec.EnterpriseBeansMetaDataParser.processElement(EnterpriseBeansMetaDataParser.java:40)
> at org.jboss.metadata.ejb.parser.spec.AbstractMetaDataParser.processElements(AbstractMetaDataParser.java:69)
> at org.jboss.metadata.ejb.parser.spec.EnterpriseBeansMetaDataParser.parse(EnterpriseBeansMetaDataParser.java:75)
> at org.jboss.metadata.ejb.parser.spec.EnterpriseBeansMetaDataParser.parse(EnterpriseBeansMetaDataParser.java:68)
> at org.jboss.metadata.ejb.parser.spec.AbstractEjbJarMetaDataParser.processElement(AbstractEjbJarMetaDataParser.java:112)
> at org.jboss.metadata.ejb.parser.spec.AbstractEjbJarMetaDataParser.processElement(AbstractEjbJarMetaDataParser.java:39)
> at org.jboss.metadata.ejb.parser.spec.AbstractMetaDataParser.processElements(AbstractMetaDataParser.java:69)
> at org.jboss.metadata.ejb.parser.spec.EjbJarMetaDataParser.parseDocument(EjbJarMetaDataParser.java:110)
> at org.jboss.metadata.ejb.parser.spec.EjbJarMetaDataParser.parse(EjbJarMetaDataParser.java:54)
> at org.jboss.as.ejb3.deployment.processors.EjbJarParsingDeploymentUnitProcessor.parseEjbJarXml(EjbJarParsingDeploymentUnitProcessor.java:247)
> ... 7 more
> 17:40:04,422 ERROR [org.jboss.as.server] (DeploymentScanner-threads - 2) JBAS015870: Deploy of deployment "TestEJB.jar" was rolled back with the following failure message:
> {"JBAS014671: Failed services" => {"jboss.deployment.unit.\"TestEJB.jar\".PARSE" => "org.jboss.msc.service.StartException in service jboss.deployment.unit.\"TestEJB.jar\".PARSE: JBAS018733: Failed to process phase PARSE of deployment \"TestEJB.jar\"
> Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException: JBAS014185: Exception while parsing ejb-jar.xml: /content/TestEJB.jar/META-INF/ejb-jar.xml
> Caused by: javax.xml.stream.XMLStreamException: ParseError at [row,col]:[14,10]
> Message: Unexpected element 'message-driven-destination' encountered"}}
> {code}
> **NOTE:** According to the link [1] EJB2.0 is supported with EAP6 so ideally JBoss should be able to parse the "ejb-jar.xml" of version 2.0 DTDs.
> **NOTE:** there is a feature request seen for JBossAS7 for requesting support for ejb-jar.xml 2.0 DTDs [2]
> [1] https://access.redhat.com/site/articles/113373
> [2] https://issues.jboss.org/browse/JBMETA-354
> Version-Release number of selected component (if applicable):
> How reproducible:
> Steps to Reproduce:
> 1. Deploy an MDB based EJB jar in EAP6/WildFly and use the ejb-jar.xml as mentioned in the issue description.
> Actual results:
> - EAP6/WildFly should be able to parse the ejb-jar.xml properly and should deploy the MDB properly.
> Expected results:
> - Deployment should be successful.
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
9 years, 11 months