[JBoss JIRA] (AS7-6248) Missing file from Nexus preventing build of Arquillian TestNG Integration
by Michael Van Geertruy (JIRA)
[ https://issues.jboss.org/browse/AS7-6248?page=com.atlassian.jira.plugin.s... ]
Michael Van Geertruy updated AS7-6248:
--------------------------------------
Attachment: 0001-Moved-testng-integration-to-the-base-directory-and-m.patch
Implements option 2 of this ticket. Released under ASF2.0 license.
> Missing file from Nexus preventing build of Arquillian TestNG Integration
> -------------------------------------------------------------------------
>
> Key: AS7-6248
> URL: https://issues.jboss.org/browse/AS7-6248
> Project: Application Server 7
> Issue Type: Bug
> Components: Build System
> Affects Versions: 7.2.0.Alpha1
> Environment: CentOS 6.3, Intel X86-64
> Reporter: Michael Van Geertruy
> Assignee: Paul Gier
> Labels: Arquillian
> Attachments: 0001-Moved-testng-integration-to-the-base-directory-and-m.patch, AS7-6248-patch.txt
>
>
> After downloading the most recent codebase from git for jbossAS 7.2.0.SNAPSHOT, I recieved the following error:
> [INFO] ------------------------------------------------------------------------
> [INFO] Building JBoss Application Server: Arquillian TestNG Integration 7.2.0.Alpha1-SNAPSHOT
> [INFO] ------------------------------------------------------------------------
> Downloading: http://repository.jboss.org/nexus/content/groups/public/org/jboss/as/jbos...
> Downloading: http://repository.jboss.org/nexus/content/groups/public/org/jboss/as/jbos...
> [WARNING] The POM for org.jboss.as:jboss-as-spec-api:pom:7.2.0.Alpha1-SNAPSHOT is missing, no dependency information available
> [INFO] ------------------------------------------------------------------------
> [INFO] Reactor Summary:
> [INFO]
> [INFO] JBoss Application Server: Arquillian .............. SUCCESS [3.091s]
> [INFO] JBoss Application Server: Arquillian TestEnricher MSC SUCCESS [7.331s]
> [INFO] JBoss Application Server: Arquillian Common ....... SUCCESS [7.461s]
> [INFO] JBoss Application Server: Arquillian Embedded Container SUCCESS [18.654s]
> [INFO] JBoss Application Server: Arquillian Protocol JMX . SUCCESS [3.766s]
> [INFO] JBoss Application Server: Arquillian Managed Container SUCCESS [19.634s]
> [INFO] JBoss Application Server: Arquillian Remote Container SUCCESS [2.147s]
> [INFO] JBoss Application Server: Arquillian TestNG Integration FAILURE [3.535s]
> [INFO] JBoss Application Server: Arquillian Common Domain SKIPPED
> [INFO] JBoss Application Server: Arquillian Remote Domain Container SKIPPED
> [INFO] JBoss Application Server: Arquillian Managed Domain Container SKIPPED
> [INFO] ------------------------------------------------------------------------
> [INFO] BUILD FAILURE
> [INFO] ------------------------------------------------------------------------
> [INFO] Total time: 1:08.150s
> [INFO] Finished at: Sat Dec 22 23:43:21 PST 2012
> [INFO] Final Memory: 51M/317M
> [INFO] ------------------------------------------------------------------------
> [ERROR] Failed to execute goal on project jboss-as-arquillian-testng-integration: Could not resolve dependencies for project org.jboss.as:jboss-as-arquillian-testng-integration:jar:7.2.0.Alpha1-SNAPSHOT
> Indeed after looking at the jboss nexus repository I came across this link:
> https://repository.jboss.org/nexus/content/groups/public/org/jboss/as/jbo...
> There do not appear to be any entries for 7.2.0.Alpha1-SNAPSHOT.
--
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
11 years, 8 months
[JBoss JIRA] (AS7-6248) Missing file from Nexus preventing build of Arquillian TestNG Integration
by Michael Van Geertruy (JIRA)
[ https://issues.jboss.org/browse/AS7-6248?page=com.atlassian.jira.plugin.s... ]
Michael Van Geertruy edited comment on AS7-6248 at 12/27/12 3:57 AM:
---------------------------------------------------------------------
Please disregard the first patch. It did not capture the move of the module. I will submit a new patch that captures this change and submit it later on today.
was (Author: mikevan):
Patch for the second option moving testng-integration to be a peer to spec-api. This is released under the ASF2.0 license.
> Missing file from Nexus preventing build of Arquillian TestNG Integration
> -------------------------------------------------------------------------
>
> Key: AS7-6248
> URL: https://issues.jboss.org/browse/AS7-6248
> Project: Application Server 7
> Issue Type: Bug
> Components: Build System
> Affects Versions: 7.2.0.Alpha1
> Environment: CentOS 6.3, Intel X86-64
> Reporter: Michael Van Geertruy
> Assignee: Paul Gier
> Labels: Arquillian
> Attachments: AS7-6248-patch.txt
>
>
> After downloading the most recent codebase from git for jbossAS 7.2.0.SNAPSHOT, I recieved the following error:
> [INFO] ------------------------------------------------------------------------
> [INFO] Building JBoss Application Server: Arquillian TestNG Integration 7.2.0.Alpha1-SNAPSHOT
> [INFO] ------------------------------------------------------------------------
> Downloading: http://repository.jboss.org/nexus/content/groups/public/org/jboss/as/jbos...
> Downloading: http://repository.jboss.org/nexus/content/groups/public/org/jboss/as/jbos...
> [WARNING] The POM for org.jboss.as:jboss-as-spec-api:pom:7.2.0.Alpha1-SNAPSHOT is missing, no dependency information available
> [INFO] ------------------------------------------------------------------------
> [INFO] Reactor Summary:
> [INFO]
> [INFO] JBoss Application Server: Arquillian .............. SUCCESS [3.091s]
> [INFO] JBoss Application Server: Arquillian TestEnricher MSC SUCCESS [7.331s]
> [INFO] JBoss Application Server: Arquillian Common ....... SUCCESS [7.461s]
> [INFO] JBoss Application Server: Arquillian Embedded Container SUCCESS [18.654s]
> [INFO] JBoss Application Server: Arquillian Protocol JMX . SUCCESS [3.766s]
> [INFO] JBoss Application Server: Arquillian Managed Container SUCCESS [19.634s]
> [INFO] JBoss Application Server: Arquillian Remote Container SUCCESS [2.147s]
> [INFO] JBoss Application Server: Arquillian TestNG Integration FAILURE [3.535s]
> [INFO] JBoss Application Server: Arquillian Common Domain SKIPPED
> [INFO] JBoss Application Server: Arquillian Remote Domain Container SKIPPED
> [INFO] JBoss Application Server: Arquillian Managed Domain Container SKIPPED
> [INFO] ------------------------------------------------------------------------
> [INFO] BUILD FAILURE
> [INFO] ------------------------------------------------------------------------
> [INFO] Total time: 1:08.150s
> [INFO] Finished at: Sat Dec 22 23:43:21 PST 2012
> [INFO] Final Memory: 51M/317M
> [INFO] ------------------------------------------------------------------------
> [ERROR] Failed to execute goal on project jboss-as-arquillian-testng-integration: Could not resolve dependencies for project org.jboss.as:jboss-as-arquillian-testng-integration:jar:7.2.0.Alpha1-SNAPSHOT
> Indeed after looking at the jboss nexus repository I came across this link:
> https://repository.jboss.org/nexus/content/groups/public/org/jboss/as/jbo...
> There do not appear to be any entries for 7.2.0.Alpha1-SNAPSHOT.
--
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
11 years, 8 months
[JBoss JIRA] (JBRULES-3108) problems with concurrent process executions, constraints, and multiple sessions
by J Xmith (JIRA)
[ https://issues.jboss.org/browse/JBRULES-3108?page=com.atlassian.jira.plug... ]
J Xmith commented on JBRULES-3108:
----------------------------------
I am using jbpm 5.3.0.Final, and I am facing the same problem:
I have a fairly simple business process with one rule-group (Guvnor TaskType=Business Rule). The rule-group does validations on process variables. To provide separation between facts from different requests, each processing request creates its own stateful knowledge session which in turns creates its own business process. Everything works well with one process execution (one request at a time).
When 2 almost concurrent requests are tried (each one running in its own thread), the first one reaching the rule-group leave an entry/record inside the EVENTTYPES table (containing the businessProcessId and the ruleflow group's name), and when the second business process reaches the rule-group it gets as event the one stored in the EVENTTYPES table. From that moment onwards, the second thread continues its execution on the first business process. The end result is, the first business process get executed twice.
Removing the rule-group makes the concurrent requests to work well.
I was thinking in a similar solution to the one proposed here by Jordi Alvarez (using the knowledge session Id as an extra identifier, etc), however I realised this Jira issue has been open for too long now, and not updates since then. What is the intended behaviour of the EVENTTYPES table, and why the knowledge session Id is not already used to distinguish between multiple concurrent requests?
> problems with concurrent process executions, constraints, and multiple sessions
> -------------------------------------------------------------------------------
>
> Key: JBRULES-3108
> URL: https://issues.jboss.org/browse/JBRULES-3108
> Project: JBRULES
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: drools-core (flow)
> Affects Versions: 5.1.1.FINAL, 5.2.0.Final
> Environment: Independent of OS, JVM, and Application Server. Reproduced in a windows development environment with a Sun JVM. Also reproduced in linux. Also database independent: reproduced with Oracle RDBMS and HSQLDB.
> Reporter: Jordi Alvarez
> Assignee: Kris Verlaenen
>
> The context is as follows:
> 1. We have drools flow configured with JPA and Hibernate, accessing an Oracle / HSQLDB database (depending on the environment).
> 2. We do have several concurrent stateful sessions in which different instances of the same kind of processes are running. These stateful sessions are persisted in the same database schema.
> 3. We do use wait states (also reproduced with rule nodes) that have constraints that wait for a fact to be inserted into the stateful session.
> 4. Whenever the fact that makes the constraint to satisfy is inserted for one process in a given stateful session; if there are other processes waiting in that wait state/constraint (in other different stateful sessions), the stateful session tries also to continue those process executions, even when they are not part of it.
> A solution has been implemented temporally over drools source code (in order to get our context working): the solution is briefly described in the forum url below. For completeness a summary is included here:
> - Adding a new attribute to org.drools.persistence.processinstance.ProcessInstanceInfo POJO identifying the stateful session to which the process instance corresponds (and the corresponding DB column).
> - modifying the ProcessInstancesWaitingForEvent query (in orm.xml) in order to take into account the session id as a (new) second parameter.
> - modify the class org.drools.persistence.processinstance.JPASignalManager in order to execute the query with both parameters.
> - as a quick way to have the session id, we have a threadlocal.
--
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
11 years, 8 months
[JBoss JIRA] (AS7-6248) Missing file from Nexus preventing build of Arquillian TestNG Integration
by Michael Van Geertruy (JIRA)
[ https://issues.jboss.org/browse/AS7-6248?page=com.atlassian.jira.plugin.s... ]
Michael Van Geertruy updated AS7-6248:
--------------------------------------
Attachment: AS7-6248-patch.txt
Patch for the second option moving testng-integration to be a peer to spec-api. This is released under the ASF2.0 license.
> Missing file from Nexus preventing build of Arquillian TestNG Integration
> -------------------------------------------------------------------------
>
> Key: AS7-6248
> URL: https://issues.jboss.org/browse/AS7-6248
> Project: Application Server 7
> Issue Type: Bug
> Components: Build System
> Affects Versions: 7.2.0.Alpha1
> Environment: CentOS 6.3, Intel X86-64
> Reporter: Michael Van Geertruy
> Assignee: Paul Gier
> Labels: Arquillian
> Attachments: AS7-6248-patch.txt
>
>
> After downloading the most recent codebase from git for jbossAS 7.2.0.SNAPSHOT, I recieved the following error:
> [INFO] ------------------------------------------------------------------------
> [INFO] Building JBoss Application Server: Arquillian TestNG Integration 7.2.0.Alpha1-SNAPSHOT
> [INFO] ------------------------------------------------------------------------
> Downloading: http://repository.jboss.org/nexus/content/groups/public/org/jboss/as/jbos...
> Downloading: http://repository.jboss.org/nexus/content/groups/public/org/jboss/as/jbos...
> [WARNING] The POM for org.jboss.as:jboss-as-spec-api:pom:7.2.0.Alpha1-SNAPSHOT is missing, no dependency information available
> [INFO] ------------------------------------------------------------------------
> [INFO] Reactor Summary:
> [INFO]
> [INFO] JBoss Application Server: Arquillian .............. SUCCESS [3.091s]
> [INFO] JBoss Application Server: Arquillian TestEnricher MSC SUCCESS [7.331s]
> [INFO] JBoss Application Server: Arquillian Common ....... SUCCESS [7.461s]
> [INFO] JBoss Application Server: Arquillian Embedded Container SUCCESS [18.654s]
> [INFO] JBoss Application Server: Arquillian Protocol JMX . SUCCESS [3.766s]
> [INFO] JBoss Application Server: Arquillian Managed Container SUCCESS [19.634s]
> [INFO] JBoss Application Server: Arquillian Remote Container SUCCESS [2.147s]
> [INFO] JBoss Application Server: Arquillian TestNG Integration FAILURE [3.535s]
> [INFO] JBoss Application Server: Arquillian Common Domain SKIPPED
> [INFO] JBoss Application Server: Arquillian Remote Domain Container SKIPPED
> [INFO] JBoss Application Server: Arquillian Managed Domain Container SKIPPED
> [INFO] ------------------------------------------------------------------------
> [INFO] BUILD FAILURE
> [INFO] ------------------------------------------------------------------------
> [INFO] Total time: 1:08.150s
> [INFO] Finished at: Sat Dec 22 23:43:21 PST 2012
> [INFO] Final Memory: 51M/317M
> [INFO] ------------------------------------------------------------------------
> [ERROR] Failed to execute goal on project jboss-as-arquillian-testng-integration: Could not resolve dependencies for project org.jboss.as:jboss-as-arquillian-testng-integration:jar:7.2.0.Alpha1-SNAPSHOT
> Indeed after looking at the jboss nexus repository I came across this link:
> https://repository.jboss.org/nexus/content/groups/public/org/jboss/as/jbo...
> There do not appear to be any entries for 7.2.0.Alpha1-SNAPSHOT.
--
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
11 years, 8 months
[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
11 years, 8 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
11 years, 8 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
11 years, 8 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
11 years, 8 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
11 years, 8 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
11 years, 8 months