[JBoss JIRA] (AS7-6585) too many classes on classpath break RAR deployments without deployment descriptor
by Marcel Šebek (JIRA)
Marcel Šebek created AS7-6585:
---------------------------------
Summary: too many classes on classpath break RAR deployments without deployment descriptor
Key: AS7-6585
URL: https://issues.jboss.org/browse/AS7-6585
Project: Application Server 7
Issue Type: Bug
Components: JCA
Affects Versions: 7.1.4.Final (EAP)
Reporter: Marcel Šebek
Assignee: Jesper Pedersen
An EAR containing a RAR and a large number of classes cannot be deployed, the exception depends on jboss version. For example, the latest 7.1 snapshot produces the following:
14:37:57,354 INFO [org.jboss.as.server.deployment] (MSC service thread 1-1) JBAS015876: Starting deployment of "test-ear.ear"
14:37:57,499 INFO [org.jboss.as.server.deployment] (MSC service thread 1-4) JBAS015876: Starting deployment of "test-rar-2.0.0-SNAPSHOT.rar"
14:37:57,499 INFO [org.jboss.as.server.deployment] (MSC service thread 1-2) JBAS015876: Starting deployment of "test-ejb-2.0.0-SNAPSHOT.jar"
14:37:57,807 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-2) MSC00001: Failed to start service jboss.deployment.subunit."test-ear.ear"."test-rar-2.0.0-SNAPSHOT.rar".INSTALL: org.jboss.msc.service.StartException in service jboss.deployment.subunit."test-ear.ear"."test-rar-2.0.0-SNAPSHOT.rar".INSTALL: JBAS018733: Failed to process phase INSTALL of subdeployment "test-rar-2.0.0-SNAPSHOT.rar" of deployment "test-ear.ear"
at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:123) [jboss-as-server-7.1.4.Final-SNAPSHOT.jar:7.1.4.Final-SNAPSHOT]
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: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: org.jboss.as.server.deployment.DeploymentUnitProcessingException: java.lang.NullPointerException
at org.jboss.as.connector.deployers.ra.processors.ParsedRaDeploymentProcessor.deploy(ParsedRaDeploymentProcessor.java:185)
at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:116) [jboss-as-server-7.1.4.Final-SNAPSHOT.jar:7.1.4.Final-SNAPSHOT]
... 5 more
Caused by: java.lang.NullPointerException
at org.jboss.jca.common.metadata.ra.common.ResourceAdapter1516Impl.validate(ResourceAdapter1516Impl.java:351)
at org.jboss.jca.common.metadata.ra.common.ConnectorAbstractmpl.validate(ConnectorAbstractmpl.java:332)
at org.jboss.as.connector.deployers.ra.processors.ParsedRaDeploymentProcessor.deploy(ParsedRaDeploymentProcessor.java:142)
... 6 more
14:37:58,104 INFO [org.jboss.as.server] (DeploymentScanner-threads - 2) JBAS015870: Deploy of deployment "test-ear.ear" was rolled back with failure message {"JBAS014671: Failed services" => {"jboss.deployment.subunit.\"test-ear.ear\".\"test-rar-2.0.0-SNAPSHOT.rar\".INSTALL" => "org.jboss.msc.service.StartException in service jboss.deployment.subunit.\"test-ear.ear\".\"test-rar-2.0.0-SNAPSHOT.rar\".INSTALL: JBAS018733: Failed to process phase INSTALL of subdeployment \"test-rar-2.0.0-SNAPSHOT.rar\" of deployment \"test-ear.ear\"
Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException: java.lang.NullPointerException
Caused by: java.lang.NullPointerException"},"JBAS014771: Services with missing/unavailable dependencies" => ["jboss.deployment.subunit.\"test-ear.ear\".\"test-ejb-2.0.0-SNAPSHOT.jar\".moduleDeploymentRuntimeInformation Missing[JBAS014861: <one or more transitive dependencies>]","jboss.deployment.unit.\"test-ear.ear\".CLEANUP Missing[JBAS014861: <one or more transitive dependencies>]","jboss.deployment.subunit.\"test-ear.ear\".\"test-ejb-2.0.0-SNAPSHOT.jar\".component.InboundMDB.CREATE Missing[jboss.ra.\"test-ear.ear#test-rar-2.0.0-SNAPSHOT\"]","jboss.deployment.subunit.\"test-ear.ear\".\"test-ejb-2.0.0-SNAPSHOT.jar\".CLEANUP Missing[JBAS014861: <one or more transitive dependencies>]","jboss.deployment.subunit.\"test-ear.ear\".\"test-ejb-2.0.0-SNAPSHOT.jar\".component.InboundMDB.START Missing[JBAS014861: <one or more transitive dependencies>]","jboss.deployment.subunit.\"test-ear.ear\".\"test-ejb-2.0.0-SNAPSHOT.jar\".component.InboundMDB.TimedObjectInvoker Missing[JBAS014861: <one or more transitive dependencies>]","jboss.deployment.subunit.\"test-ear.ear\".\"test-ejb-2.0.0-SNAPSHOT.jar\".component.InboundMDB.ejb3.timerService Missing[JBAS014861: <one or more transitive dependencies>]","jboss.deployment.subunit.\"test-ear.ear\".\"test-ejb-2.0.0-SNAPSHOT.jar\".component.InboundMDB.VIEW.\"test.TestEventListener\".MESSAGE_ENDPOINT Missing[JBAS014861: <one or more transitive dependencies>]"]}
14:37:58,141 INFO [org.jboss.as.server.deployment] (MSC service thread 1-2) JBAS015877: Stopped deployment test-ejb-2.0.0-SNAPSHOT.jar in 38ms
14:37:58,142 INFO [org.jboss.as.server.deployment] (MSC service thread 1-5) JBAS015877: Stopped deployment test-rar-2.0.0-SNAPSHOT.rar in 39ms
14:37:58,149 INFO [org.jboss.as.server.deployment] (MSC service thread 1-4) JBAS015877: Stopped deployment test-ear.ear in 46ms
14:37:58,152 ERROR [org.jboss.as.server.deployment.scanner] (DeploymentScanner-threads - 1) {"JBAS014653: Composite operation failed and was rolled back. Steps that failed:" => {"Operation step-2" => {"JBAS014671: Failed services" => {"jboss.deployment.subunit.\"test-ear.ear\".\"test-rar-2.0.0-SNAPSHOT.rar\".INSTALL" => "org.jboss.msc.service.StartException in service jboss.deployment.subunit.\"test-ear.ear\".\"test-rar-2.0.0-SNAPSHOT.rar\".INSTALL: JBAS018733: Failed to process phase INSTALL of subdeployment \"test-rar-2.0.0-SNAPSHOT.rar\" of deployment \"test-ear.ear\"
Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException: java.lang.NullPointerException
Caused by: java.lang.NullPointerException"},"JBAS014771: Services with missing/unavailable dependencies" => ["jboss.deployment.subunit.\"test-ear.ear\".\"test-ejb-2.0.0-SNAPSHOT.jar\".moduleDeploymentRuntimeInformation Missing[JBAS014861: <one or more transitive dependencies>]","jboss.deployment.unit.\"test-ear.ear\".CLEANUP Missing[JBAS014861: <one or more transitive dependencies>]","jboss.deployment.subunit.\"test-ear.ear\".\"test-ejb-2.0.0-SNAPSHOT.jar\".component.InboundMDB.CREATE Missing[jboss.ra.\"test-ear.ear#test-rar-2.0.0-SNAPSHOT\"]","jboss.deployment.subunit.\"test-ear.ear\".\"test-ejb-2.0.0-SNAPSHOT.jar\".CLEANUP Missing[JBAS014861: <one or more transitive dependencies>]","jboss.deployment.subunit.\"test-ear.ear\".\"test-ejb-2.0.0-SNAPSHOT.jar\".component.InboundMDB.START Missing[JBAS014861: <one or more transitive dependencies>]","jboss.deployment.subunit.\"test-ear.ear\".\"test-ejb-2.0.0-SNAPSHOT.jar\".component.InboundMDB.TimedObjectInvoker Missing[JBAS014861: <one or more transitive dependencies>]","jboss.deployment.subunit.\"test-ear.ear\".\"test-ejb-2.0.0-SNAPSHOT.jar\".component.InboundMDB.ejb3.timerService Missing[JBAS014861: <one or more transitive dependencies>]","jboss.deployment.subunit.\"test-ear.ear\".\"test-ejb-2.0.0-SNAPSHOT.jar\".component.InboundMDB.VIEW.\"test.TestEventListener\".MESSAGE_ENDPOINT Missing[JBAS014861: <one or more transitive dependencies>]"]}}}
However, the same event (with slightly more readable exception) occurs in 7.2 snapshot too. An EAR that exhibits this is attached. If you comment out maven dependencies, you will be able to deploy the same EAR. If you put different dependencies, you will get the same error again. The problem seems to depend only on the classpath size, more classes causes the problem to occur more likely.
The problem is that when JCA container builds ra.xml from JCA 1.6 annotations, for some reason the content of <resourceadapter-class> tag is null (the string "null"). As a workaround for resource adapters with large classpath, one can supply a deployment descriptor with just <resourceadapter-class> tag containing the correct value.
--
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, 2 months
[JBoss JIRA] (AS7-5476) Complete support for OSGi JPA
by Steve Ebersole (JIRA)
[ https://issues.jboss.org/browse/AS7-5476?page=com.atlassian.jira.plugin.s... ]
Steve Ebersole commented on AS7-5476:
-------------------------------------
HHH-7527 is more on the persistence provider side.
AS probably still needs the container contracts, which would be done here I guess. Stuff like aggregated PUIs, etc.
> Complete support for OSGi JPA
> -----------------------------
>
> Key: AS7-5476
> URL: https://issues.jboss.org/browse/AS7-5476
> Project: Application Server 7
> Issue Type: Feature Request
> Components: JPA / Hibernate, OSGi
> Reporter: Thomas Diesler
> Assignee: Scott Marlow
>
> h6. 127.3.1 Services
> _Entity Manager Factory Builder service_ - The Entity Manager Factory Builder service provides the capability of creating an EntityManagerFactory object with additional configuration properties
> Add EntityManagerFactory service properties
> * osgi.unit.name - The name of the Persistence Unit (done)
> * osgi.unit.version - The version of the associated Persistence Bundle
> * osgi.unit.provider - The implementation class name of the JPA Provider
> h6. 127.3.4 Custom Configured Entity Manager
> If a Client Bundle needs to provide configuration properties for the creation of an Entity Manager Factory it should use the Entity Manager Factory Builder service. This can for example be used to provide the database selection properties when the Persistence Unit is incomplete or if the database selection needs to be overridden.
> Once an Entity Manager Factory is created the specified Data Source becomes associated with the Entity Manager Factory. It is therefore not possible to re-associate an Entity Manager Factory with another Data Source by providing different properties. A JPA Provider must throw an Exception when an attempt is made to re-specify the database properties.
> h6. 127.4.2 Meta Persistence Header
> Support non-default persistence descriptors through the Meta-Persistence header
> For example: _Meta-Persistence: META-INF/jpa.xml, persistence/jpa.xml_
> h6. 127.4.3 Processing
> The JPA Provider must validate the Persistence Bundle. A valid Persistence Bundle must:
> * Have no parsing errors of the Persistence Descriptors
> * Validate all Persistence Descriptors against their schemas
> * Have at least one assigned Persistence Unit
> * Have all entity classes mentioned in the assigned Persistence Units on the Persistence Bundles JAR.
> If any validation fails, then this is an error and should be logged. Such a bundle is ignored completely even if it also contains valid assigned Persistence Units. Only a bundle update can recover from this
> state.
> h6. 127.4.8 Stopping
> If a Persistence Bundle is being stopped, then the JPA Provider must ensure that any resources allocated on behalf of the Persistence Bundle are cleaned up and all open connections are closed. This cleanup must happen synchronously with the STOPPING event. Any Exceptions being thrown while cleaning up should be logged but must not stop any further clean up.
> If the JPA Provider is being stopped, the JPA Provider must unregister all JPA Services that it registered through the Persistence Bundles and clean up as if those bundles were stopped.
> h6. 127.5.3 Data Source Factory Service Matching
> Providers must use the javax.persistence.jdbc.driver property, as defined in JDBC Access in JPA on page 406, to obtain a Data Source Factory service. The Data Source Factory is specified in JDBC Service Specification on page 375. The javax.persistence.jdbc.driver property must be matched with the value of the Data Source Factory service property named osgi.jdbc.driver.class.
> h6. 127.5.4 Rebinding
> In this specification, the Entity Manager Factory service is only registered when the Persistence Unit is complete and a matching Data Source Factory service is available. However, the API of the Entity
> Manager Factory allows the creation of an Entity Manager with configuration properties. Those configuration properties could contain the JDBC properties to bind to another Data Source Factory service than it had already selected.
> This case must not be supported by a JPA Provider, an Illegal Argument Exception must be thrown.
> h6. 127.6 Static Access
> A Static Persistence Bundle must provide static access from the Persistence class to the JPA Services.
> This issue is complete when the TCK passes
--
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, 2 months
[JBoss JIRA] (AS7-5476) Complete support for OSGi JPA
by Thomas Diesler (JIRA)
[ https://issues.jboss.org/browse/AS7-5476?page=com.atlassian.jira.plugin.s... ]
Thomas Diesler commented on AS7-5476:
-------------------------------------
Yes, we still want to make ASx Enterprise OSGi JPA compliant.
> Complete support for OSGi JPA
> -----------------------------
>
> Key: AS7-5476
> URL: https://issues.jboss.org/browse/AS7-5476
> Project: Application Server 7
> Issue Type: Feature Request
> Components: JPA / Hibernate, OSGi
> Reporter: Thomas Diesler
> Assignee: Scott Marlow
>
> h6. 127.3.1 Services
> _Entity Manager Factory Builder service_ - The Entity Manager Factory Builder service provides the capability of creating an EntityManagerFactory object with additional configuration properties
> Add EntityManagerFactory service properties
> * osgi.unit.name - The name of the Persistence Unit (done)
> * osgi.unit.version - The version of the associated Persistence Bundle
> * osgi.unit.provider - The implementation class name of the JPA Provider
> h6. 127.3.4 Custom Configured Entity Manager
> If a Client Bundle needs to provide configuration properties for the creation of an Entity Manager Factory it should use the Entity Manager Factory Builder service. This can for example be used to provide the database selection properties when the Persistence Unit is incomplete or if the database selection needs to be overridden.
> Once an Entity Manager Factory is created the specified Data Source becomes associated with the Entity Manager Factory. It is therefore not possible to re-associate an Entity Manager Factory with another Data Source by providing different properties. A JPA Provider must throw an Exception when an attempt is made to re-specify the database properties.
> h6. 127.4.2 Meta Persistence Header
> Support non-default persistence descriptors through the Meta-Persistence header
> For example: _Meta-Persistence: META-INF/jpa.xml, persistence/jpa.xml_
> h6. 127.4.3 Processing
> The JPA Provider must validate the Persistence Bundle. A valid Persistence Bundle must:
> * Have no parsing errors of the Persistence Descriptors
> * Validate all Persistence Descriptors against their schemas
> * Have at least one assigned Persistence Unit
> * Have all entity classes mentioned in the assigned Persistence Units on the Persistence Bundles JAR.
> If any validation fails, then this is an error and should be logged. Such a bundle is ignored completely even if it also contains valid assigned Persistence Units. Only a bundle update can recover from this
> state.
> h6. 127.4.8 Stopping
> If a Persistence Bundle is being stopped, then the JPA Provider must ensure that any resources allocated on behalf of the Persistence Bundle are cleaned up and all open connections are closed. This cleanup must happen synchronously with the STOPPING event. Any Exceptions being thrown while cleaning up should be logged but must not stop any further clean up.
> If the JPA Provider is being stopped, the JPA Provider must unregister all JPA Services that it registered through the Persistence Bundles and clean up as if those bundles were stopped.
> h6. 127.5.3 Data Source Factory Service Matching
> Providers must use the javax.persistence.jdbc.driver property, as defined in JDBC Access in JPA on page 406, to obtain a Data Source Factory service. The Data Source Factory is specified in JDBC Service Specification on page 375. The javax.persistence.jdbc.driver property must be matched with the value of the Data Source Factory service property named osgi.jdbc.driver.class.
> h6. 127.5.4 Rebinding
> In this specification, the Entity Manager Factory service is only registered when the Persistence Unit is complete and a matching Data Source Factory service is available. However, the API of the Entity
> Manager Factory allows the creation of an Entity Manager with configuration properties. Those configuration properties could contain the JDBC properties to bind to another Data Source Factory service than it had already selected.
> This case must not be supported by a JPA Provider, an Illegal Argument Exception must be thrown.
> h6. 127.6 Static Access
> A Static Persistence Bundle must provide static access from the Persistence class to the JPA Services.
> This issue is complete when the TCK passes
--
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, 2 months
[JBoss JIRA] (AS7-6582) Classloader leaking in JPA module
by Scott Marlow (JIRA)
[ https://issues.jboss.org/browse/AS7-6582?page=com.atlassian.jira.plugin.s... ]
Scott Marlow commented on AS7-6582:
-----------------------------------
Brent, thanks for reporting this issue. Could you tell us a little more about what is keeping the deployments JPA service in memory, after undeployment? Are you using the EclipseMemoryAnalzer (MAT) tool? There should be a button that you can click to run the full garbage collector.
I'm not saying your wrong, I'm just not seeing the entire picture yet. Your seeing that the SerializableValidatorFactory is referencing your deployments classes. What is referencing the SerializableValidatorFactory that keeps the SerializableValidatorFactory in memory?
> Classloader leaking in JPA module
> ---------------------------------
>
> Key: AS7-6582
> URL: https://issues.jboss.org/browse/AS7-6582
> Project: Application Server 7
> Issue Type: Bug
> Components: JPA / Hibernate
> Affects Versions: 7.1.3.Final (EAP)
> Environment: Fedora 17, Oracle jdk 7u9
> CentOS 6.3, Oracle jdk 7u11
> Reporter: Brent Douglas
> Assignee: Scott Marlow
>
> PersistenceUnitServiceHandler retains references to deployment classes after the service is stopped through SerializableValidatorFactory.
--
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, 2 months
[JBoss JIRA] (AS7-6583) Performance regression comparing to previous release
by David Lloyd (JIRA)
[ https://issues.jboss.org/browse/AS7-6583?page=com.atlassian.jira.plugin.s... ]
David Lloyd commented on AS7-6583:
----------------------------------
I'd say it's not the selector. It's the fact that if you create new loggers over and over again, things are *going* to be slow. Don't do that - just keep them in a static field. If you refuse to do that, at least inject them into some kind of singleton application scope or something.
> Performance regression comparing to previous release
> ----------------------------------------------------
>
> Key: AS7-6583
> URL: https://issues.jboss.org/browse/AS7-6583
> Project: Application Server 7
> Issue Type: Bug
> Components: CDI / Weld, Logging
> Affects Versions: 7.2.0.Alpha1
> Environment: 7.2.0.Final (prerelease-1 tag)
> Reporter: Tomas Remes
> Assignee: James Perkins
> Priority: Critical
> Labels: performance
>
> There is significant performance regression in 7.2.0 prerelease. I discovered it in my Weld performance load tests (testing simple Weld numberguess example application), but I am quite sure that's not Weld issue at all. I did some investigations and it seems that problem occurred in org/jboss/as/logging module.
--
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, 2 months
[JBoss JIRA] (AS7-6583) Performance regression comparing to previous release
by James Perkins (JIRA)
[ https://issues.jboss.org/browse/AS7-6583?page=com.atlassian.jira.plugin.s... ]
James Perkins commented on AS7-6583:
------------------------------------
I haven't looked at the commits yet, but it's likely the change using a different {{LogContextSelector}} that's causing it. I wouldn't say the performance issue though is on the logging side as much as either on the application or a different dependency. If something is invoking {{Logger.getLogger()}} a lot, that will create a performance hit.
> Performance regression comparing to previous release
> ----------------------------------------------------
>
> Key: AS7-6583
> URL: https://issues.jboss.org/browse/AS7-6583
> Project: Application Server 7
> Issue Type: Bug
> Components: CDI / Weld, Logging
> Affects Versions: 7.2.0.Alpha1
> Environment: 7.2.0.Final (prerelease-1 tag)
> Reporter: Tomas Remes
> Assignee: James Perkins
> Priority: Critical
> Labels: performance
>
> There is significant performance regression in 7.2.0 prerelease. I discovered it in my Weld performance load tests (testing simple Weld numberguess example application), but I am quite sure that's not Weld issue at all. I did some investigations and it seems that problem occurred in org/jboss/as/logging module.
--
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, 2 months
[JBoss JIRA] (AS7-6567) Hang in ProfileTransformersTestCase ModelTestModelControllerService.waitForSetup
by Kabir Khan (JIRA)
[ https://issues.jboss.org/browse/AS7-6567?page=com.atlassian.jira.plugin.s... ]
Kabir Khan commented on AS7-6567:
---------------------------------
I see you actually did rebase, and that your comment was about using the artifact :-) The maven artifact is only used when setting up the classloader for the legacy controller in the transformers tests, in all other cases the artifacts are indeed from the current build.
> Hang in ProfileTransformersTestCase ModelTestModelControllerService.waitForSetup
> --------------------------------------------------------------------------------
>
> Key: AS7-6567
> URL: https://issues.jboss.org/browse/AS7-6567
> Project: Application Server 7
> Issue Type: Bug
> Components: Domain Management, Test Suite
> Reporter: Carlo de Wolf
> Assignee: Kabir Khan
> Attachments: AS7-6567-threaddump.txt
>
>
> {noformat}
> "main" prio=10 tid=0x00007fa1a8009000 nid=0x7f2 waiting on condition [0x00007fa1b1b13000]
> java.lang.Thread.State: WAITING (parking)
> at sun.misc.Unsafe.park(Native Method)
> - parking to wait for <0x00000007acdbe350> (a java.util.concurrent.CountDownLatch$Sync)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:186)
> at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:834)
> at java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:994)
> at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1303)
> at java.util.concurrent.CountDownLatch.await(CountDownLatch.java:236)
> at org.jboss.as.model.test.ModelTestModelControllerService.waitForSetup(ModelTestModelControllerService.java:190)
> at org.jboss.as.core.model.test.AbstractKernelServicesImpl.create(AbstractKernelServicesImpl.java:108)
> at org.jboss.as.core.model.bridge.impl.ChildFirstClassLoaderKernelServicesFactory.create(ChildFirstClassLoaderKernelServicesFactory.java:63)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:601)
> at org.jboss.as.core.model.bridge.local.ScopedKernelServicesBootstrap.createChildClassLoaderKernelServices(ScopedKernelServicesBootstrap.java:77)
> at org.jboss.as.core.model.bridge.local.ScopedKernelServicesBootstrap.createKernelServices(ScopedKernelServicesBootstrap.java:51)
> at org.jboss.as.core.model.test.CoreModelTestDelegate$LegacyKernelServicesInitializerImpl.install(CoreModelTestDelegate.java:565)
> at org.jboss.as.core.model.test.CoreModelTestDelegate$LegacyKernelServicesInitializerImpl.access$300(CoreModelTestDelegate.java:526)
> at org.jboss.as.core.model.test.CoreModelTestDelegate$KernelServicesBuilderImpl.build(CoreModelTestDelegate.java:493)
> at org.jboss.as.core.model.test.profile.ProfileTransformersTestCase.testProfilesTransformer(ProfileTransformersTestCase.java:66)
> {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, 2 months