[JBoss JIRA] (AS7-5311) Deployment of multiple .rar's with ironjacamar.xml
by Aristides Neto (JIRA)
[ https://issues.jboss.org/browse/AS7-5311?page=com.atlassian.jira.plugin.s... ]
Aristides Neto commented on AS7-5311:
-------------------------------------
Hi, I´ve just downloaded the latest nightly build from https://ci.jboss.org/hudson/view/JBoss%20AS/job/JBoss-AS-7.0.x/
Acoording to the AS7-5311 it should be resolved. But I´m sorry to say that this problem still ocurrs, my deployment structure is simple:
App.ear
KernelConector.rar
META-INF
ironjacamar.xml
RFConector.rar
META-INF
ironjacamar.xml
Ejbs.jar
If I use one ironjacamar.xml at a time, then it works, but when I put then both like described in the structure above I get the same error:
12:39:56,952 ERROR [org.jboss.msc.service] (MSC service thread 1-7) MSC00002: Invocation of listener "org.jboss.as.connector.deployers.ra.processors.ParsedRaDeploymentProcessor$1@89bc0ef" failed: java.lang.IllegalArgumentException: JBAS014809: A node is already registered at '(deployment => *)(subdeployment => *)(subsystem => resource-adapters)(ironjacamar => ironjacamar)'
at org.jboss.as.controller.registry.ConcreteResourceRegistration.registerSubModel(ConcreteResourceRegistration.java:112) [jboss-as-controller-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
at org.jboss.as.connector.deployers.ra.processors.ParsedRaDeploymentProcessor$1.registerIronjacamar(ParsedRaDeploymentProcessor.java:133) [jboss-as-connector-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
at org.jboss.as.connector.deployers.ra.processors.AbstractResourceAdapterDeploymentServiceListener.transition(AbstractResourceAdapterDeploymentServiceListener.java:153) [jboss-as-connector-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
at org.jboss.msc.service.ServiceControllerImpl.invokeListener(ServiceControllerImpl.java:1416) [jboss-msc-1.0.2.GA.jar:1.0.2.GA]
at org.jboss.msc.service.ServiceControllerImpl.access$2700(ServiceControllerImpl.java:49) [jboss-msc-1.0.2.GA.jar:1.0.2.GA]
at org.jboss.msc.service.ServiceControllerImpl$ListenerTask.run(ServiceControllerImpl.java:1954) [jboss-msc-1.0.2.GA.jar:1.0.2.GA]
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [rt.jar:1.6.0_37]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [rt.jar:1.6.0_37]
at java.lang.Thread.run(Thread.java:662) [rt.jar:1.6.0_37]
> Deployment of multiple .rar's with ironjacamar.xml
> --------------------------------------------------
>
> Key: AS7-5311
> URL: https://issues.jboss.org/browse/AS7-5311
> Project: Application Server 7
> Issue Type: Bug
> Components: JCA
> Affects Versions: 7.1.2.Final (EAP)
> Reporter: Jesper Pedersen
> Assignee: Stefano Maestri
> Priority: Critical
> Fix For: 7.1.3.Final (EAP), 7.2.0.Alpha1
>
>
> Deploying an .ear with multiple .rar's, which all have an ironjacamar.xml file results in
> {noformat}
> 11:17:24,899 ERROR [org.jboss.msc.service] (MSC service thread 1-14) MSC000002: Invocation of listener "org.jboss.as.connector.deployers.ra.processors.ParsedRaDeploymentProcessor$1@16c5f7e" failed: java.lang.IllegalArgumentException: JBAS014809: Ein Knoten ist bereits registriert unter '(deployment => *)(subdeployment => *)(subsystem => resource-adapters)(ironjacamar => ironjacamar)'
> at org.jboss.as.controller.registry.ConcreteResourceRegistration.registerSubModel(ConcreteResourceRegistration.java:108) [jboss-as-controller-7.1.2.Final-redhat-1.jar:7.1.2.Final-redhat-1]
> at org.jboss.as.controller.registry.AbstractResourceRegistration.registerSubModel(AbstractResourceRegistration.java:68) [jboss-as-controller-7.1.2.Final-redhat-1.jar:7.1.2.Final-redhat-1]
> at org.jboss.as.connector.subsystems.resourceadapters.IronJacamarRegistrator.invoke(IronJacamarRegistrator.java:33) [jboss-as-connector-7.1.2.Final-redhat-1.jar:7.1.2.Final-redhat-1]
> at org.jboss.as.connector.deployers.ra.processors.ParsedRaDeploymentProcessor$1.registerIronjacamar(ParsedRaDeploymentProcessor.java:158) [jboss-as-connector-7.1.2.Final-redhat-1.jar:7.1.2.Final-redhat-1]
> at org.jboss.as.connector.deployers.ra.processors.AbstractResourceAdapterDeploymentServiceListener.transition(AbstractResourceAdapterDeploymentServiceListener.java:131) [jboss-as-connector-7.1.2.Final-redhat-1.jar:7.1.2.Final-redhat-1]
> at org.jboss.msc.service.ServiceControllerImpl.invokeListener(ServiceControllerImpl.java:1416) [jboss-msc-1.0.2.GA-redhat-1.jar:1.0.2.GA-redhat-1]
> at org.jboss.msc.service.ServiceControllerImpl.access$2700(ServiceControllerImpl.java:49) [jboss-msc-1.0.2.GA-redhat-1.jar:1.0.2.GA-redhat-1]
> at org.jboss.msc.service.ServiceControllerImpl$ListenerTask.run(ServiceControllerImpl.java:1954) [jboss-msc-1.0.2.GA-redhat-1.jar:1.0.2.GA-redhat-1]
> at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [rt.jar:1.6.0_31]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [rt.jar:1.6.0_31]
> at java.lang.Thread.run(Thread.java:662) [rt.jar:1.6.0_31]
> {noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 4 months
[JBoss JIRA] (AS7-6246) Naming context read-only during legacy SAR deployment
by Eduardo Martins (JIRA)
[ https://issues.jboss.org/browse/AS7-6246?page=com.atlassian.jira.plugin.s... ]
Eduardo Martins commented on AS7-6246:
--------------------------------------
NP, and thanks for your contribution ;)
> Naming context read-only during legacy SAR deployment
> -----------------------------------------------------
>
> Key: AS7-6246
> URL: https://issues.jboss.org/browse/AS7-6246
> Project: Application Server 7
> Issue Type: Bug
> Components: JMX, Naming
> Affects Versions: 7.2.0.Alpha1
> Reporter: Philippe Marschall
> Assignee: Eduardo Martins
> Labels: jmx, jndi, naming, sar
>
> When the {{#startService()}} and {{#stopService()}} methods of a sublass of {{ServiceMBeanSupport}} are invoked the JNDI context is read only.
> Consider the following MBean:
> {code}
> public class LegacySample extends ServiceMBeanSupport implements LegacySampleMBean {
> private static final String NAME = "java:global/env/foo/legacy";
> private static final String VALUE = "BAR";
> private static final Logger LOG = Logger.getLogger("sar-legacy");
> public LegacySample() {
> super();
> }
> @Override
> protected void startService() throws Exception {
> InitialContext ic = new InitialContext();
> ic.rebind(NAME, VALUE);
> LOG.info("started");
> }
> @Override
> protected void stopService() throws Exception {
> InitialContext ic = new InitialContext();
> ic.unbind(NAME);
> LOG.info("stopped");
> }
> @Override
> public String getMessage() {
> return "legacy";
> }
> }
> {code}
> This will fail.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 4 months
[JBoss JIRA] (AS7-5444) runtime-name is used when logging deploy and undeploy
by Chao Wang (JIRA)
[ https://issues.jboss.org/browse/AS7-5444?page=com.atlassian.jira.plugin.s... ]
Chao Wang updated AS7-5444:
---------------------------
Attachment: AS7-5444.patch
patch to replace runtime-name
> runtime-name is used when logging deploy and undeploy
> -----------------------------------------------------
>
> Key: AS7-5444
> URL: https://issues.jboss.org/browse/AS7-5444
> Project: Application Server 7
> Issue Type: Bug
> Components: Domain Management
> Affects Versions: 7.1.2.Final (EAP)
> Reporter: Cheng Fang
> Assignee: Chao Wang
> Fix For: 7.2.0.Alpha1
>
> Attachments: AS7-5444.patch
>
>
> deploy a war and specify its runtime-name, and undeploy it:
> {noformat}
> deploy --runtime-name=nnn.war /Users/cfang/tmp/hello.war
> undeploy hello.war
> {noformat}
> In the server log it used the runtime-name to refer to the deployed and undeployed war, whereas I think the name (hello.war) should be used for this purpose.
> {noformat}
> 10:21:45,598 INFO [org.jboss.as.server.deployment] (MSC service thread 1-6) JBAS015876: Starting deployment of "nnn"
> 10:21:45,853 INFO [org.jboss.as.server] (management-handler-thread - 1) JBAS018559: Deployed "nnn"
> 10:22:19,016 INFO [org.jboss.as.server.deployment] (MSC service thread 1-7) JBAS015877: Stopped deployment nnn in 25ms
> 10:22:19,021 INFO [org.jboss.as.repository] (management-handler-thread - 1) JBAS014901: Content removed from location /Users/cfang/as/standalone/data/content/33/6fe6448f88e335b46336d8509869c990c700fc/content
> 10:22:19,021 INFO [org.jboss.as.server] (management-handler-thread - 1) JBAS018558: Undeployed "nnn"
> {noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 4 months
[JBoss JIRA] (AS7-5444) runtime-name is used when logging deploy and undeploy
by Chao Wang (JIRA)
[ https://issues.jboss.org/browse/AS7-5444?page=com.atlassian.jira.plugin.s... ]
Chao Wang reassigned AS7-5444:
------------------------------
Assignee: Chao Wang
> runtime-name is used when logging deploy and undeploy
> -----------------------------------------------------
>
> Key: AS7-5444
> URL: https://issues.jboss.org/browse/AS7-5444
> Project: Application Server 7
> Issue Type: Bug
> Components: Domain Management
> Affects Versions: 7.1.2.Final (EAP)
> Reporter: Cheng Fang
> Assignee: Chao Wang
> Fix For: 7.2.0.Alpha1
>
>
> deploy a war and specify its runtime-name, and undeploy it:
> {noformat}
> deploy --runtime-name=nnn.war /Users/cfang/tmp/hello.war
> undeploy hello.war
> {noformat}
> In the server log it used the runtime-name to refer to the deployed and undeployed war, whereas I think the name (hello.war) should be used for this purpose.
> {noformat}
> 10:21:45,598 INFO [org.jboss.as.server.deployment] (MSC service thread 1-6) JBAS015876: Starting deployment of "nnn"
> 10:21:45,853 INFO [org.jboss.as.server] (management-handler-thread - 1) JBAS018559: Deployed "nnn"
> 10:22:19,016 INFO [org.jboss.as.server.deployment] (MSC service thread 1-7) JBAS015877: Stopped deployment nnn in 25ms
> 10:22:19,021 INFO [org.jboss.as.repository] (management-handler-thread - 1) JBAS014901: Content removed from location /Users/cfang/as/standalone/data/content/33/6fe6448f88e335b46336d8509869c990c700fc/content
> 10:22:19,021 INFO [org.jboss.as.server] (management-handler-thread - 1) JBAS018558: Undeployed "nnn"
> {noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 4 months
[JBoss JIRA] (AS7-5444) runtime-name is used when logging deploy and undeploy
by Chao Wang (JIRA)
[ https://issues.jboss.org/browse/AS7-5444?page=com.atlassian.jira.plugin.s... ]
Chao Wang commented on AS7-5444:
--------------------------------
Its the name and runtime-name in deployers we choose to log message,
For example : use ServerLogger.ROOT_LOGGER.deploymentDeployed(deploymentUnitName); Or ServerLogger.ROOT_LOGGER.deploymentDeployed(managementName);
However, it looks like all LOG messages used deploymentUnitName instead of managementName, Isn't it the expected action to use runtime-name here?
> runtime-name is used when logging deploy and undeploy
> -----------------------------------------------------
>
> Key: AS7-5444
> URL: https://issues.jboss.org/browse/AS7-5444
> Project: Application Server 7
> Issue Type: Bug
> Components: Domain Management
> Affects Versions: 7.1.2.Final (EAP)
> Reporter: Cheng Fang
> Fix For: 7.2.0.Alpha1
>
>
> deploy a war and specify its runtime-name, and undeploy it:
> {noformat}
> deploy --runtime-name=nnn.war /Users/cfang/tmp/hello.war
> undeploy hello.war
> {noformat}
> In the server log it used the runtime-name to refer to the deployed and undeployed war, whereas I think the name (hello.war) should be used for this purpose.
> {noformat}
> 10:21:45,598 INFO [org.jboss.as.server.deployment] (MSC service thread 1-6) JBAS015876: Starting deployment of "nnn"
> 10:21:45,853 INFO [org.jboss.as.server] (management-handler-thread - 1) JBAS018559: Deployed "nnn"
> 10:22:19,016 INFO [org.jboss.as.server.deployment] (MSC service thread 1-7) JBAS015877: Stopped deployment nnn in 25ms
> 10:22:19,021 INFO [org.jboss.as.repository] (management-handler-thread - 1) JBAS014901: Content removed from location /Users/cfang/as/standalone/data/content/33/6fe6448f88e335b46336d8509869c990c700fc/content
> 10:22:19,021 INFO [org.jboss.as.server] (management-handler-thread - 1) JBAS018558: Undeployed "nnn"
> {noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 4 months
[JBoss JIRA] (JASSIST-128) GetRefClasses() for anonymous inner classes incorrect
by Shigeru Chiba (JIRA)
[ https://issues.jboss.org/browse/JASSIST-128?page=com.atlassian.jira.plugi... ]
Shigeru Chiba closed JASSIST-128.
---------------------------------
> GetRefClasses() for anonymous inner classes incorrect
> -----------------------------------------------------
>
> Key: JASSIST-128
> URL: https://issues.jboss.org/browse/JASSIST-128
> Project: Javassist
> Issue Type: Bug
> Affects Versions: 3.12.0.GA
> Reporter: Jesper Pedersen
> Assignee: Shigeru Chiba
> Fix For: 3.14.0.GA
>
>
> When getting the referenced classes from an anonymous inner class it incorrectly list a .{Name} reference:
> CLZ=org.jboss.shrinkwrap.impl.base.container.ContainerBase$1
> Collection c = ctClz.getRefClasses();
> R=org.jboss.shrinkwrap.impl.base.container.ContainerBase$1
> R=org.jboss.shrinkwrap.impl.base.container.ContainerBase
> R=org.jboss.shrinkwrap.impl.base.container.ContainerBase.1 <-- incorrect
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 4 months
[JBoss JIRA] (JASSIST-125) Compilation fails with "javassist.bytecode.BadBytecode: jsr at 406" WebLogic 10.3 JTA data source class
by Shigeru Chiba (JIRA)
[ https://issues.jboss.org/browse/JASSIST-125?page=com.atlassian.jira.plugi... ]
Shigeru Chiba closed JASSIST-125.
---------------------------------
> Compilation fails with "javassist.bytecode.BadBytecode: jsr at 406" WebLogic 10.3 JTA data source class
> -------------------------------------------------------------------------------------------------------
>
> Key: JASSIST-125
> URL: https://issues.jboss.org/browse/JASSIST-125
> Project: Javassist
> Issue Type: Bug
> Affects Versions: 3.12.0.GA
> Environment: Reproduced on Linux x86 and Windows XP (x86).
> Reporter: Mooky Grand
> Assignee: Shigeru Chiba
> Fix For: 3.13.0.GA
>
>
> Trying to add code at the beginning of the method getConnection in the class weblogic.jdbc.jta.DataSource I got the following error:
> Exception in thread "main" javassist.CannotCompileException: by javassist.bytecode.BadBytecode: jsr at 399
> at javassist.CtBehavior.insertBefore(CtBehavior.java:728)
> at javassist.CtBehavior.insertBefore(CtBehavior.java:685)
> at Test.main(Test.java:26)
> Caused by: javassist.bytecode.BadBytecode: jsr at 399
> at javassist.bytecode.stackmap.Tracer.throwBadBytecode(Tracer.java:144)
> at javassist.bytecode.stackmap.Tracer.visitJSR(Tracer.java:133)
> at javassist.bytecode.stackmap.Tracer.doOpcode148_201(Tracer.java:563)
> at javassist.bytecode.stackmap.Tracer.doOpcode(Tracer.java:101)
> at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:182)
> at javassist.bytecode.stackmap.MapMaker.traceException(MapMaker.java:213)
> at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:175)
> at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:192)
> at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:141)
> at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:96)
> at javassist.bytecode.MethodInfo.rebuildStackMap(MethodInfo.java:416)
> at javassist.bytecode.MethodInfo.rebuildStackMapIf6(MethodInfo.java:398)
> at javassist.CtBehavior.insertBefore(CtBehavior.java:719)
> ... 2 more
> I've created a small program that simulates this problem outside the Weblogic container.
> The class can be found inside <Weblogic home>\modules\com.bea.core.datasource6_1.4.0.0.jar.
> And additional dependency which is required in order to load this class (although it is not needed in order to modify the byte codes) is <Weblogic home>\modules\com.bea.core.transaction_2.5.0.0.jar.
> Both of these files are available when installing Weblogic 10.3.
> I suspect this might be some sort of collision with WebLogic's Diagnostic framework. I'm not sure how calls to WLDF are added, but it is possible they were added by some other tool for manipulating byte codes (at compile time), in which case this issue is a bit more interesting (could indicate collisions with certain other AOP tools).
> Just for the sake of pin pointing the source of the problem, I also used AspectJ to add code to the method. It worked fine with no errors.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 4 months
[JBoss JIRA] (JASSIST-129) getRefClasses() fails for some of the inner classes defined in java.util
by Shigeru Chiba (JIRA)
[ https://issues.jboss.org/browse/JASSIST-129?page=com.atlassian.jira.plugi... ]
Shigeru Chiba closed JASSIST-129.
---------------------------------
> getRefClasses() fails for some of the inner classes defined in java.util
> ------------------------------------------------------------------------
>
> Key: JASSIST-129
> URL: https://issues.jboss.org/browse/JASSIST-129
> Project: Javassist
> Issue Type: Bug
> Affects Versions: 3.13.0.GA
> Reporter: Maciej Kokocinski
> Assignee: Shigeru Chiba
> Fix For: 3.14.0.GA
>
>
> CtClass.getRefClasses() reports not existing classes in some cases.
> One out of many examples is "java.util.LinkedList$DescendingIterator". getRefClasses() for this class returns, as one of the resulting list elements, "istItr" which is obviously wrong as there is no such class.
> There is a field inside this class named itr of type 'java.util.LinkedList$ListItr". If we get fieldInfo for this field its descriptor is "Ljava/util/LinkedList$ListItr;", however if we take its SignatureAttribute, then its signature is "Ljava/util/LinkedList<TE;>.ListItr;". When this string is parsed during AttributeInfo.renameClass(List, ClassMap) then a class named "istItr" is 'found'.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 4 months
[JBoss JIRA] (JASSIST-123) Explicit class import support for compiler (not whole packages)
by Shigeru Chiba (JIRA)
[ https://issues.jboss.org/browse/JASSIST-123?page=com.atlassian.jira.plugi... ]
Shigeru Chiba closed JASSIST-123.
---------------------------------
> Explicit class import support for compiler (not whole packages)
> ---------------------------------------------------------------
>
> Key: JASSIST-123
> URL: https://issues.jboss.org/browse/JASSIST-123
> Project: Javassist
> Issue Type: Patch
> Reporter: Ivan Prisiazhnyy
> Assignee: Shigeru Chiba
> Labels: compiler, import
> Fix For: 3.14.0.GA
>
>
> This is patch for MemberResolver class for Javassist 3.12.GA
> It adds support for compiler to understand importing of certain classes in packages, not the whole packages.
> With this patch the following code will do its job:
> ClassPool x = ClassPool.getDefault();
> x.importPackage("java.io.File");
> Patch it self:
> *** MemberResolver.java 2010-04-04 02:21:30.000000000 +0300
> --- MemberResolver.java 2010-06-10 14:38:03.000000000 +0300
> ***************
> *** 429,434 ****
> --- 429,445 ----
> }
> catch (NotFoundException e) {
> classPool.recordInvalidClassName(fqName);
> +
> + try {
> + if (pac.endsWith(orgName)) {
> + CtClass cc = classPool.get(pac);
> + // if the class is found,
> + classPool.recordInvalidClassName(orgName);
> + return cc;
> + }
> + } catch (NotFoundException ee) {
> + classPool.recordInvalidClassName(pac);
> + }
> }
> }
> }
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 4 months