[JBoss JIRA] (AS7-6791) Provide a way to add a description for a deployment
by Sven Plath (JIRA)
Sven Plath created AS7-6791:
-------------------------------
Summary: Provide a way to add a description for a deployment
Key: AS7-6791
URL: https://issues.jboss.org/browse/AS7-6791
Project: Application Server 7
Issue Type: Feature Request
Components: CLI
Reporter: Sven Plath
Assignee: Alexey Loubyansky
Priority: Minor
h2.Summary
It would be nice to have a feature that allows to add an *optional description* to a deployment when using the console or the web interface to deploy it.
h2.Current Situation
Currently, it is possible to deploy applications using:
{code}
deploy C:\path\to\application.jar --name=... --runtime-name=...
{code}
The _runtime-name_ is used for dependency resolution. When for example we have an application *app_A-1.0.0.jar* and deploy it using the following command_
{code}
deploy C:\path\to\application.jar --name=app_A.jar --runtime-name=app_A-1.jar
{code}
we loose the version information of that application.
* We could write the version into the _name_ argument, however it could lead to multiple deployments of the same application when the old one is not removed before updating.
* We could add the version information into the _runtime-name_ argument, but that would be problematic when updating applications to a newer version. We would have to change the deployment-descriptor.
h2.Request
When deploying applications, we could provide an additional argument, called *description*. It would allow us to do the following:
{code}
deploy C:\path\to\application-1.0.0.jar --name=application-1.jar --description="Application v1.0.0"
{code}
When doing _/deployment=application-1.jar:read-resource_, it would result in the following output:
{code}
{
"outcome" => "success",
"result" => {
"content" => [{"hash" => bytes {
0x10, 0xd6, 0x20, 0x46, 0x74, 0xcc, 0xe5, 0x39,
0x7d, 0xef, 0x2e, 0xe3, 0x26, 0x45, 0x28, 0xad,
0xa5, 0xde, 0xdd, 0x80
}}],
"enabled" => true,
"name" => "application-1.jar",
"persistent" => true,
"runtime-name" => "application-1.jar",
"description" => "Application v1.0.0",
"subdeployment" => undefined,
"subsystem" => undefined
}
}
{code}
This description information should be kept when replacing that particular deployment, so when doing:
{code}
deploy C:\path\to\application-1.0.0.jar --name=application-1.jar --force
{code}
it should replace the existing application, but without deleting the description information. That should be removed when doing:
{code}
/deployment=application-1.jar:remove
{code}
When explicitly adding the _description_ argument to the _deploy_ command, the description has to be replaced by the new one.
--
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, 1 month
[JBoss JIRA] (JGRP-1609) Poor performance of TCP/TCPGOSSIP when a node fails
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1609?page=com.atlassian.jira.plugin.... ]
Bela Ban updated JGRP-1609:
---------------------------
Fix Version/s: 3.3
> Poor performance of TCP/TCPGOSSIP when a node fails
> ---------------------------------------------------
>
> Key: JGRP-1609
> URL: https://issues.jboss.org/browse/JGRP-1609
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.1, 3.3
> Environment: Linux
> Reporter: Ramky Kandula
> Assignee: Bela Ban
> Fix For: 3.3
>
>
> I have TCP transport with TCPGOSSIP for discovery. The exact config is same as tcp.xml but has TCPGOSSIP instead of TCPPING and MERGE3 instead of MERGE2.
> When I run Mperf with this stack on nodes A,B,C and in the middle of the test, shutdown the network interface of a node, say C, C is removed from the view after FD interval but the subsequent performance is very poor, in tens of KB rather than tens to hundrend MB.
> What I observed is that the TrasnferQueueBundler in the TP keeps trying to connect to node C for every multicast and times out.
> When I disable bundling with 3.1, the Mperf sender thread gets into the same condition for every multicast.
> Logically, once the view has changed, we want the nodes A and B to continue to perform at the same rate they were doing before the network interface for C is shutdown.
> The following stack trace shows where it is doing the connect to node C with bundling enabled.
> "TransferQueueBundler,mperf,lnx1-60691" prio=10 tid=0x00002aaab4024000 nid=0x6f77 runnable [0x00000000420f7000]
> java.lang.Thread.State: RUNNABLE
> at java.net.PlainSocketImpl.socketConnect(Native Method)
> at java.net.PlainSocketImpl.doConnect(PlainSocketImpl.java:351)
> - locked <0x00000000f223f0f0> (a java.net.SocksSocketImpl)
> at java.net.PlainSocketImpl.connectToAddress(PlainSocketImpl.java:213)
> at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:200)
> at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:366)
> at java.net.Socket.connect(Socket.java:529)
> at org.jgroups.util.Util.connect(Util.java:354)
> at org.jgroups.blocks.TCPConnectionMap$TCPConnection.connect(TCPConnectionMap.java:408)
> at org.jgroups.blocks.TCPConnectionMap$Mapper.getConnection(TCPConnectionMap.java:775)
> at org.jgroups.blocks.TCPConnectionMap.send(TCPConnectionMap.java:184)
> at org.jgroups.protocols.TCP.send(TCP.java:56)
> at org.jgroups.protocols.BasicTCP.sendUnicast(BasicTCP.java:99)
> at org.jgroups.protocols.TP.sendToAllPhysicalAddresses(TP.java:1611)
> at org.jgroups.protocols.BasicTCP.sendMulticast(BasicTCP.java:94)
> at org.jgroups.protocols.TP.doSend(TP.java:1560)
> at org.jgroups.protocols.TP$TransferQueueBundler.sendBundledMessages(TP.java:2329)
> at org.jgroups.protocols.TP$TransferQueueBundler.sendMessages(TP.java:2261)
> at org.jgroups.protocols.TP$TransferQueueBundler.run(TP.java:2246)
> at java.lang.Thread.run(Thread.java:662)
> The netstat also shows it keeps trying to connect to that node C (192.20.20.33)
> [root@lnx1 ~]# netstat -an| grep 7800
> tcp 0 0 192.20.20.233:7800 0.0.0.0:* LISTEN
> tcp 0 1 192.20.20.233:53070 192.20.20.33:7800 SYN_SENT
> tcp 0 0 192.20.20.233:34237 192.20.20.133:7800 ESTABLISHED
> [root@lnx1 ~]# netstat -an| grep 7800
> tcp 0 0 192.20.20.233:7800 0.0.0.0:* LISTEN
> tcp 0 1 192.20.20.233:36345 192.20.20.33:7800 SYN_SENT
> tcp 0 0 192.20.20.233:34237 192.20.20.133:7800 ESTABLISHED
> [root@lnx1 ~]# netstat -an| grep 7800
> tcp 0 0 192.20.20.233:7800 0.0.0.0:* LISTEN
> tcp 0 1 192.20.20.233:51724 192.20.20.33:7800 SYN_SENT
> tcp 0 113287 192.20.20.233:34237 192.20.20.133:7800 ESTABLISHED
> [root@lnx1 ~]# netstat -an| grep 7800
> tcp 0 0 192.20.20.233:7800 0.0.0.0:* LISTEN
> tcp 0 1 192.20.20.233:51724 192.20.20.33:7800 SYN_SENT
> tcp 0 0 192.20.20.233:34237 192.20.20.133:7800 ESTABLISHED
> [root@lnx1 ~]# netstat -an| grep 7800
> tcp 0 0 192.20.20.233:7800 0.0.0.0:* LISTEN
> tcp 0 1 192.20.20.233:35389 192.20.20.33:7800 SYN_SENT
> tcp 0 0 192.20.20.233:34237 192.20.20.133:7800 ESTABLISHED
> With bundling disabled (had to use 3.1 version), the following stack trace shows where sender thread keeps trying to connect to node C.
> "sender-0" prio=10 tid=0x000000004cc1e800 nid=0x429 runnable [0x00002afe67973000]
> java.lang.Thread.State: RUNNABLE
> at java.net.PlainSocketImpl.socketConnect(Native Method)
> at java.net.PlainSocketImpl.doConnect(Unknown Source)
> - locked <0x00000000ec6046a0> (a java.net.SocksSocketImpl)
> at java.net.PlainSocketImpl.connectToAddress(Unknown Source)
> at java.net.PlainSocketImpl.connect(Unknown Source)
> at java.net.SocksSocketImpl.connect(Unknown Source)
> at java.net.Socket.connect(Unknown Source)
> at org.jgroups.util.Util.connect(Util.java:305)
> at org.jgroups.blocks.TCPConnectionMap$TCPConnection.<init>(TCPConnectionMap.java:388)
> at org.jgroups.blocks.TCPConnectionMap$Mapper.getConnection(TCPConnectionMap.java:785)
> at org.jgroups.blocks.TCPConnectionMap.send(TCPConnectionMap.java:174)
> at org.jgroups.protocols.TCP.send(TCP.java:56)
> at org.jgroups.protocols.BasicTCP.sendUnicast(BasicTCP.java:86)
> at org.jgroups.protocols.TP.sendToAllPhysicalAddresses(TP.java:1348)
> at org.jgroups.protocols.BasicTCP.sendMulticast(BasicTCP.java:81)
> at org.jgroups.protocols.TP.doSend(TP.java:1296)
> at org.jgroups.protocols.TP.send(TP.java:1285)
> at org.jgroups.protocols.TP.down(TP.java:1143)
> at org.jgroups.protocols.Discovery.down(Discovery.java:573)
> at org.jgroups.protocols.MERGE3.down(MERGE3.java:242)
> at org.jgroups.protocols.FD.down(FD.java:308)
> at org.jgroups.protocols.VERIFY_SUSPECT.down(VERIFY_SUSPECT.java:80)
> at org.jgroups.protocols.pbcast.NAKACK.send(NAKACK.java:667)
> at org.jgroups.protocols.pbcast.NAKACK.send(NAKACK.java:678)
> at org.jgroups.protocols.pbcast.NAKACK.down(NAKACK.java:459)
> at org.jgroups.protocols.UNICAST2.down(UNICAST2.java:531)
> at org.jgroups.protocols.pbcast.STABLE.down(STABLE.java:328)
> at org.jgroups.protocols.pbcast.GMS.down(GMS.java:968)
> at org.jgroups.protocols.FlowControl.down(FlowControl.java:351)
> at org.jgroups.protocols.MFC.handleDownMessage(MFC.java:116)
> at org.jgroups.protocols.FlowControl.down(FlowControl.java:341)
> at org.jgroups.protocols.FRAG2.down(FRAG2.java:147)
> at org.jgroups.stack.ProtocolStack.down(ProtocolStack.java:1025)
> at org.jgroups.JChannel.down(JChannel.java:729)
> at org.jgroups.JChannel.send(JChannel.java:445)
> at org.jgroups.tests.perf.MPerf$Sender.run(MPerf.java:564)
--
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, 1 month
[JBoss JIRA] (AS7-6724) method-params containing an array not correctly processed for EJB2.1 with CMT
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/AS7-6724?page=com.atlassian.jira.plugin.s... ]
Brian Stansberry updated AS7-6724:
----------------------------------
Issue Type: Bug (was: Feature Request)
> method-params containing an array not correctly processed for EJB2.1 with CMT
> -----------------------------------------------------------------------------
>
> Key: AS7-6724
> URL: https://issues.jboss.org/browse/AS7-6724
> Project: Application Server 7
> Issue Type: Bug
> Components: EJB
> Affects Versions: 7.1.3.Final (EAP), EAP 6.1.0.Alpha (7.2.0.Final)
> Environment: JBoss 7.2.0-Final Prerelease (Commit 4ed76c) and JBoss 7.1.3.Final on Win7/64 JDK 1.7.0_09
> Reporter: Robert Panzer
> Assignee: Robert Panzer
> Fix For: 8.0.0.Alpha1
>
> Attachments: cmt-never-array-params.zip
>
>
> It seems that the method-params for container transactions are not matched correctly if the contain arrays.
> I've got an EJB "First" that calls another EJB "Second". Both have the same interface containing a method void test(String[]);
> If I define the transaction attribute NEVER including method-params for "First" and without params for "Second" the test fails with
> JBAS014163: Transaction present on server in Never call (EJB3 13.6.2.6)
> I define the container transaction like this:
> <container-transaction>
> <method>
> <ejb-name>FirstWithParams</ejb-name>
> <method-intf>Local</method-intf>
> <method-name>test</method-name>
> <method-params>
> <method-param>java.lang.String[]</method-param>
> </method-params>
> </method>
> <method>
> <ejb-name>FirstWithParams</ejb-name>
> <method-intf>Local</method-intf>
> <method-name>test</method-name>
> <method-params>
> <method-param>java.lang.String</method-param>
> </method-params>
> </method>
> <method>
> <ejb-name>FirstWithParams</ejb-name>
> <method-intf>Local</method-intf>
> <method-name>test</method-name>
> <method-params>
> <method-param>int</method-param>
> </method-params>
> </method>
> <method>
> <ejb-name>Second</ejb-name>
> <method-intf>Local</method-intf>
> <method-name>test</method-name>
> </method>
> <trans-attribute>Never</trans-attribute>
> </container-transaction>
> I will attach a test case that fails at the call to test(String[]) but successfully call test(String) and test(int).
--
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, 1 month
[JBoss JIRA] (AS7-6761) Deployment replace causes invalid state in DUP
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/AS7-6761?page=com.atlassian.jira.plugin.s... ]
Stuart Douglas commented on AS7-6761:
-------------------------------------
This is now resolved for non OSGi deployments. At the moment I can't see any way to achieve the desired OSGI behaviour without a redesign of how DUP's work.
> Deployment replace causes invalid state in DUP
> ----------------------------------------------
>
> Key: AS7-6761
> URL: https://issues.jboss.org/browse/AS7-6761
> Project: Application Server 7
> Issue Type: Bug
> Components: Server
> Reporter: Thomas Diesler
> Assignee: Stuart Douglas
> Attachments: v200.jar, v201.jar, webapp-v200.war
>
>
> Webapp A depends on deployment B. Replacing B causes NPE in JPAInterceptorProcessor
> {code}
> 12:52:05,712 INFO [org.jboss.as.server.deployment] (MSC service thread 1-1) JBAS015876: Starting deployment of "v200.jar" (runtime-name: "v200.jar")
> 12:52:05,889 INFO [org.jboss.as.server] (XNIO-1 task-8) JBAS018559: Deployed "v200.jar" (runtime-name : "v200.jar")
> 12:52:37,207 INFO [org.jboss.as.server.deployment] (MSC service thread 1-5) JBAS015876: Starting deployment of "webapp-v200.war" (runtime-name: "webapp-v200.war")
> 12:52:37,349 INFO [org.jboss.web] (ServerService Thread Pool -- 52) JBAS018210: Register web context: /webapp-v200
> 12:52:37,436 INFO [org.jboss.as.server] (XNIO-1 task-3) JBAS018559: Deployed "webapp-v200.war" (runtime-name : "webapp-v200.war")
> 12:53:20,252 INFO [org.jboss.web] (ServerService Thread Pool -- 57) JBAS018224: Unregister web context: /webapp-v200
> 12:53:20,272 INFO [org.jboss.as.server.deployment] (MSC service thread 1-1) JBAS015877: Stopped deployment v200.jar (runtime-name: v200.jar) in 25ms
> 12:53:20,274 INFO [org.jboss.as.server.deployment] (MSC service thread 1-5) JBAS015876: Starting deployment of "v200.jar" (runtime-name: "v200.jar")
> 12:53:20,293 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-2) MSC000001: Failed to start service jboss.deployment.unit."webapp-v200.war".FIRST_MODULE_USE: org.jboss.msc.service.StartException in service jboss.deployment.unit."webapp-v200.war".FIRST_MODULE_USE: JBAS018733: Failed to process phase FIRST_MODULE_USE of deployment "webapp-v200.war"
> at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:127) [jboss-as-server-8.0.0.Alpha1-SNAPSHOT.jar:8.0.0.Alpha1-SNAPSHOT]
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1972) [jboss-msc-1.1.1.Final.jar:1.1.1.Final]
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1905) [jboss-msc-1.1.1.Final.jar:1.1.1.Final]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_13]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_13]
> at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_13]
> Caused by: java.lang.NullPointerException
> at org.jboss.as.jpa.processor.JPAInterceptorProcessor.deploy(JPAInterceptorProcessor.java:52)
> at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:120) [jboss-as-server-8.0.0.Alpha1-SNAPSHOT.jar:8.0.0.Alpha1-SNAPSHOT]
> ... 5 more
> {code}
> What might be happening here is that replacing B causes ModuleB to go down. Phase FIRST_MODULE_USE of A depends on ModuleB, which causes a call to undeploy() on the DUPs for A. When ModuleB becomes available again, deploy() is called on the DUPs for A again. Possibly because of the cleanup phase, necessary state is lost and we see a NPE.
> AFAICS, this is a variation of the feature request that DUPs support multiple calls to deploy/undeploy.
--
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, 1 month
[JBoss JIRA] (AS7-6761) Deployment replace causes invalid state in DUP
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/AS7-6761?page=com.atlassian.jira.plugin.s... ]
RH Bugzilla Integration commented on AS7-6761:
----------------------------------------------
Stuart Douglas <sdouglas(a)redhat.com> made a comment on [bug 924562|https://bugzilla.redhat.com/show_bug.cgi?id=924562]
If you have a deployment that dependends on another deployment (either using inter deployment dependencies or a class loading dependency) and you replace the dependee deployment then the dependent deployment will fail to restart.
> Deployment replace causes invalid state in DUP
> ----------------------------------------------
>
> Key: AS7-6761
> URL: https://issues.jboss.org/browse/AS7-6761
> Project: Application Server 7
> Issue Type: Bug
> Components: Server
> Reporter: Thomas Diesler
> Assignee: Stuart Douglas
> Attachments: v200.jar, v201.jar, webapp-v200.war
>
>
> Webapp A depends on deployment B. Replacing B causes NPE in JPAInterceptorProcessor
> {code}
> 12:52:05,712 INFO [org.jboss.as.server.deployment] (MSC service thread 1-1) JBAS015876: Starting deployment of "v200.jar" (runtime-name: "v200.jar")
> 12:52:05,889 INFO [org.jboss.as.server] (XNIO-1 task-8) JBAS018559: Deployed "v200.jar" (runtime-name : "v200.jar")
> 12:52:37,207 INFO [org.jboss.as.server.deployment] (MSC service thread 1-5) JBAS015876: Starting deployment of "webapp-v200.war" (runtime-name: "webapp-v200.war")
> 12:52:37,349 INFO [org.jboss.web] (ServerService Thread Pool -- 52) JBAS018210: Register web context: /webapp-v200
> 12:52:37,436 INFO [org.jboss.as.server] (XNIO-1 task-3) JBAS018559: Deployed "webapp-v200.war" (runtime-name : "webapp-v200.war")
> 12:53:20,252 INFO [org.jboss.web] (ServerService Thread Pool -- 57) JBAS018224: Unregister web context: /webapp-v200
> 12:53:20,272 INFO [org.jboss.as.server.deployment] (MSC service thread 1-1) JBAS015877: Stopped deployment v200.jar (runtime-name: v200.jar) in 25ms
> 12:53:20,274 INFO [org.jboss.as.server.deployment] (MSC service thread 1-5) JBAS015876: Starting deployment of "v200.jar" (runtime-name: "v200.jar")
> 12:53:20,293 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-2) MSC000001: Failed to start service jboss.deployment.unit."webapp-v200.war".FIRST_MODULE_USE: org.jboss.msc.service.StartException in service jboss.deployment.unit."webapp-v200.war".FIRST_MODULE_USE: JBAS018733: Failed to process phase FIRST_MODULE_USE of deployment "webapp-v200.war"
> at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:127) [jboss-as-server-8.0.0.Alpha1-SNAPSHOT.jar:8.0.0.Alpha1-SNAPSHOT]
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1972) [jboss-msc-1.1.1.Final.jar:1.1.1.Final]
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1905) [jboss-msc-1.1.1.Final.jar:1.1.1.Final]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_13]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_13]
> at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_13]
> Caused by: java.lang.NullPointerException
> at org.jboss.as.jpa.processor.JPAInterceptorProcessor.deploy(JPAInterceptorProcessor.java:52)
> at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:120) [jboss-as-server-8.0.0.Alpha1-SNAPSHOT.jar:8.0.0.Alpha1-SNAPSHOT]
> ... 5 more
> {code}
> What might be happening here is that replacing B causes ModuleB to go down. Phase FIRST_MODULE_USE of A depends on ModuleB, which causes a call to undeploy() on the DUPs for A. When ModuleB becomes available again, deploy() is called on the DUPs for A again. Possibly because of the cleanup phase, necessary state is lost and we see a NPE.
> AFAICS, this is a variation of the feature request that DUPs support multiple calls to deploy/undeploy.
--
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, 1 month
[JBoss JIRA] (AS7-6495) NullPointerException in InterceptorAnnotationProcessor during dependency service redeployment
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/AS7-6495?page=com.atlassian.jira.plugin.s... ]
Stuart Douglas resolved AS7-6495.
---------------------------------
Fix Version/s: 8.0.0.Alpha1
Resolution: Done
The dependee will now do a complete restart, avoiding this problem
> NullPointerException in InterceptorAnnotationProcessor during dependency service redeployment
> ---------------------------------------------------------------------------------------------
>
> Key: AS7-6495
> URL: https://issues.jboss.org/browse/AS7-6495
> Project: Application Server 7
> Issue Type: Bug
> Components: Class Loading
> Affects Versions: 7.1.1.Final
> Environment: Ubuntu 12.10 AMD64
> java version "1.7.0_09"
> OpenJDK Runtime Environment (IcedTea7 2.3.4) (7u9-2.3.4-0ubuntu1.12.10.1)
> OpenJDK 64-Bit Server VM (build 23.2-b09, mixed mode)
> JBoss AS 7.1.1 + SwitchYard 0.7.0 Bundle
> Reporter: Patrik Kullman
> Assignee: Stuart Douglas
> Labels: deployment, nullpointerexception, redeployment
> Fix For: 8.0.0.Alpha1
>
>
> If I create a deployment (a.jar) and then a second deployment (b.jar) which depends on it (deployment.a.jar in the dependencies part of the manifest), deploy them both and then re-deploy a.jar, I get:
> 16:37:13,458 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-4) MSC00001: Failed to start service jboss.deployment.unit."b.jar".POST_MODULE: org.jboss.msc.service.StartException in service jboss.deployment.unit."b.jar".POST_MODULE: Failed to process phase POST_MODULE of deployment "b.jar"
> at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:119) [jboss-as-server-7.1.1.Final.jar:7.1.1.Final]
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1811) [jboss-msc-1.0.2.GA.jar:1.0.2.GA]
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1746) [jboss-msc-1.0.2.GA.jar:1.0.2.GA]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) [rt.jar:1.7.0_09]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) [rt.jar:1.7.0_09]
> at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_09]
> Caused by: java.lang.NullPointerException
> at org.jboss.as.ee.component.deployers.InterceptorAnnotationProcessor.deploy(InterceptorAnnotationProcessor.java:43)
> at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:113) [jboss-as-server-7.1.1.Final.jar:7.1.1.Final]
> ... 5 more
> Everything else works - they deploy fine, in the right order, on startup or first deployment. Re-deploying b.jar after this error also makes b.jar deploy.
> However, a key point of the hot-deploy feature for us is to have dependency redeployment work properly.
--
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, 1 month