[JBoss JIRA] Created: (AS7-1001) WSDeploymentActivator uses a Phase priority which isn't listed in org.jboss.as.server.deployment.Phase
by jaikiran pai (JIRA)
WSDeploymentActivator uses a Phase priority which isn't listed in org.jboss.as.server.deployment.Phase
------------------------------------------------------------------------------------------------------
Key: AS7-1001
URL: https://issues.jboss.org/browse/AS7-1001
Project: Application Server 7
Issue Type: Bug
Components: Web Services
Environment: AS7 upstream (Jun 12 2011)
Reporter: jaikiran pai
WSDeploymentActivator has code like this for registering deployment unit processors:
{code}
static void activate(final BootOperationContext updateContext) {
int priority = Phase.INSTALL_WAR_METADATA + 10;
...
updateContext.addDeploymentProcessor(Phase.INSTALL, priority++, new WSTypeDeploymentProcessor());
updateContext.addDeploymentProcessor(Phase.INSTALL, priority++, new WSModelDeploymentProcessor());
...
addDeploymentProcessors(updateContext, priority);
}
{code}
Notice that the Phase priorities have been localized to this WS code. Localizing the Phase priority to the WS code can lead to issues where some other subsystem or even WS might end up adding a duplicate Phase priority in org.jboss.as.server.deployment.Phase. The org.jboss.as.server.deployment.Phase is supposed to act as a central location where the phase priorities are listed so that such situations can be avoided.
Moving the phase priorities out of WSDeploymentActivator (and other such classes, if there are any more) is recommended.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
15 years, 1 month
[JBoss JIRA] Reopened: (AS7-670) Changes to server-config not persisted
by Rostislav Svoboda (JIRA)
[ https://issues.jboss.org/browse/AS7-670?page=com.atlassian.jira.plugin.sy... ]
Rostislav Svoboda reopened AS7-670:
-----------------------------------
Reopening,
changes of 'Auto Start' element in WebUI are not persisted into domain/configuration/host.xml file.
Tested with Web console 1.0.0.Beta9, source codes of as7 pulled this morning (2011-06-16).
Note: Change of auto-start element was persisted when I added JVM parameters and saved it.
> Changes to server-config not persisted
> --------------------------------------
>
> Key: AS7-670
> URL: https://issues.jboss.org/browse/AS7-670
> Project: Application Server 7
> Issue Type: Bug
> Components: Domain Management
> Affects Versions: 7.0.0.Beta3
> Reporter: Brian Stansberry
> Assignee: Brian Stansberry
> Fix For: 7.0.0.CR1
>
>
> Heiko Braun reports that the following changes update in-memory state, but are not persisted back to host.xml:
> {
> "operation" => "composite",
> "address" => [],
> "steps" => [
> {
> "operation" => "write-attribute",
> "address" => [
> ("host" => "local"),
> ("server-config" => "server-one")
> ],
> "name" => "socket-binding-group",
> "value" => "standard-sockets"
> },
> {
> "operation" => "write-attribute",
> "address" => [
> ("host" => "local"),
> ("server-config" => "server-one")
> ],
> "name" => "socket-binding-port-offset",
> "value" => 90
> }
> ]
> }
> The in-memory state and host.xml state can be seen:
> [localhost:9999 /] /host=local/server-config=server-one:read-resource
> {
> "outcome" => "success",
> "result" => {
> "path" => undefined,
> "system-property" => undefined,
> "interface" => undefined,
> "jvm" => {"default" => undefined},
> "socket-binding-group" => "standard-sockets",
> "socket-binding-port-offset" => 90,
> "name" => "server-one",
> "group" => "main-server-group",
> "auto-start" => true
> },
> "compensating-operation" => undefined
> }
> <server name="server-one" group="main-server-group" auto-start="true">
> <jvm name="default"/>
> </server>
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
15 years, 1 month
[JBoss JIRA] Created: (AS7-1022) AS7 build consistently fails on Windows OS
by jaikiran pai (JIRA)
AS7 build consistently fails on Windows OS
------------------------------------------
Key: AS7-1022
URL: https://issues.jboss.org/browse/AS7-1022
Project: Application Server 7
Issue Type: Bug
Components: Test Suite
Reporter: jaikiran pai
Fix For: 7.0.0.CR1
A couple of users have reported that the AS7 build is consistently failing during build during testsuite execution. Hudson (http://hudson.qa.jboss.com/hudson/view/JBoss%20AS/job/JBoss-AS-7.0.x-Wind...) too reports the same error:
{code}
Error Message
file:\W:\workspace\JBoss-AS-7.0.x-Windows\arquillian\protocol-jmx\target\jboss-as-arquillian-protocol-jmx-7.0.0.Beta4-SNAPSHOT.jar!\arquillian-service\META-INF\services\org.jboss.msc.service.ServiceActivator was not found in any available ClassLoaders
Stacktrace
java.lang.IllegalArgumentException: file:\W:\workspace\JBoss-AS-7.0.x-Windows\arquillian\protocol-jmx\target\jboss-as-arquillian-protocol-jmx-7.0.0.Beta4-SNAPSHOT.jar!\arquillian-service\META-INF\services\org.jboss.msc.service.ServiceActivator was not found in any available ClassLoaders
at org.jboss.shrinkwrap.impl.base.container.ContainerBase.addNestedJarFileResource(ContainerBase.java:624)
at org.jboss.shrinkwrap.impl.base.container.ContainerBase.addAsResource(ContainerBase.java:884)
at org.jboss.shrinkwrap.impl.base.container.ContainerBase.addAsResource(ContainerBase.java:814)
at org.jboss.shrinkwrap.impl.base.container.ContainerBase.addAsResource(ContainerBase.java:802)
at org.jboss.as.arquillian.protocol.jmx.JMXProtocolPackager.generateArquillianServiceArchive(JMXProtocolPackager.java:136)
at org.jboss.as.arquillian.protocol.jmx.JMXProtocolPackager.generateDeployment(JMXProtocolPackager.java:79)
at org.jboss.arquillian.container.test.impl.client.deployment.DeploymentGenerator.buildTestableDeployments(DeploymentGenerator.java:178)
at org.jboss.arquillian.container.test.impl.client.deployment.DeploymentGenerator.createTestableDeployments(DeploymentGenerator.java:132)
at org.jboss.arquillian.container.test.impl.client.deployment.DeploymentGenerator.generateDeployment(DeploymentGenerator.java:84)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90)
at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99)
at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81)
at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:134)
at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:114)
at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:67)
at org.jboss.arquillian.container.test.impl.client.ContainerEventController.execute(ContainerEventController.java:96)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90)
at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99)
at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81)
at org.jboss.arquillian.test.impl.TestContextHandler.createClassContext(TestContextHandler.java:68)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90)
at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
at org.jboss.arquillian.test.impl.TestContextHandler.createSuiteContext(TestContextHandler.java:54)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90)
at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:134)
at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:114)
at org.jboss.arquillian.test.impl.EventTestRunnerAdaptor.beforeClass(EventTestRunnerAdaptor.java:80)
at org.jboss.arquillian.junit.Arquillian$2.evaluate(Arquillian.java:172)
at org.jboss.arquillian.junit.Arquillian.multiExecute(Arquillian.java:305)
at org.jboss.arquillian.junit.Arquillian.access$300(Arquillian.java:45)
at org.jboss.arquillian.junit.Arquillian$3.evaluate(Arquillian.java:189)
at org.junit.runners.ParentRunner.run(ParentRunner.java:236)
at org.jboss.arquillian.junit.Arquillian.run(Arquillian.java:137)
at org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:53)
at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:119)
at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:101)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.apache.maven.surefire.booter.ProviderFactory$ClassLoaderProxy.invoke(ProviderFactory.java:103)
at $Proxy0.invoke(Unknown Source)
at org.apache.maven.surefire.booter.SurefireStarter.invokeProvider(SurefireStarter.java:150)
at org.apache.maven.surefire.booter.SurefireStarter.runSuitesInProcess(SurefireStarter.java:91)
at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:69)
{code}
Aslak pointed out on IRC that this is a ShrinkWrap bug:
{quote}
(08:55:25 IST) Jaikiran: aslak: it actually fails on windows system on both hudson and dimitris instance
(08:55:34 IST) Jaikiran: i don't really have an windows system to debug
(08:55:54 IST) aslak: aa, windows only.. hmm
(08:55:55 IST) Jaikiran: pinged you since it looked like something to do with arquillian test infrastructure
(08:55:58 IST) Jaikiran: yeah
(08:57:33 IST) aslak: Jaikiran, hehe.. shrinkwrap bug.
(08:57:52 IST) Jaikiran: i see
(08:57:58 IST) Jaikiran: what's it trying to do?
(08:58:00 IST) bstansberry: pferraro: it got reviewed by Nihility; he asked me to check how hard it would be to merge into a mega-branch i have; i said it was ok, after that I don't know
(08:58:12 IST) aslak: Jaikiran, path.indexOf("!/"), windows use "!\" of course.. should use Path.seperator
{quote}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
15 years, 1 month
[JBoss JIRA] Created: (AS7-1024) idle-timeout-minutes and blocking-timeout-millis are stored in xml but aren't recognized when parsing
by Alexey Loubyansky (JIRA)
idle-timeout-minutes and blocking-timeout-millis are stored in xml but aren't recognized when parsing
-----------------------------------------------------------------------------------------------------
Key: AS7-1024
URL: https://issues.jboss.org/browse/AS7-1024
Project: Application Server 7
Issue Type: Bug
Components: JCA
Affects Versions: 7.0.0.Beta3
Reporter: Alexey Loubyansky
Assignee: Alexey Loubyansky
These attributes can be set using operation requests and they stored in the xml, but when the server is restarted the parsing fails, e.g.
15:12:34,517 ERROR [stderr] Caused by: org.jboss.jca.common.metadata.ParserException: IJ010061: Unexpected element: blocking-timeout-millis
15:12:34,517 ERROR [stderr] at org.jboss.jca.common.metadata.ds.DsParser.parseDataSource(DsParser.java:622)
15:12:34,517 ERROR [stderr] at org.jboss.jca.common.metadata.ds.DsParser.parseDataSources(DsParser.java:165)
15:12:34,518 ERROR [stderr] at org.jboss.jca.common.metadata.ds.DsParser.parse(DsParser.java:118)
15:12:34,518 ERROR [stderr] at org.jboss.as.connector.subsystems.datasources.DataSourcesExtension$NewDataSourceSubsystemParser.readElement(DataSourcesExtension.java:652)
15:14:11,814 ERROR [stderr] Caused by: org.jboss.jca.common.metadata.ParserException: IJ010061: Unexpected element: idle-timeout-minutes
15:14:11,815 ERROR [stderr] at org.jboss.jca.common.metadata.ds.DsParser.parseDataSource(DsParser.java:622)
15:14:11,815 ERROR [stderr] at org.jboss.jca.common.metadata.ds.DsParser.parseDataSources(DsParser.java:165)
15:14:11,815 ERROR [stderr] at org.jboss.jca.common.metadata.ds.DsParser.parse(DsParser.java:118)
15:14:11,815 ERROR [stderr] at org.jboss.as.connector.subsystems.datasources.DataSourcesExtension$NewDataSourceSubsystemParser.readElement(DataSourcesExtension.java:652)
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
15 years, 1 month
[JBoss JIRA] Created: (JBMESSAGING-1879) Duplicated Message delivery in message sucking process
by Yong Hao Gao (JIRA)
Duplicated Message delivery in message sucking process
------------------------------------------------------
Key: JBMESSAGING-1879
URL: https://issues.jboss.org/browse/JBMESSAGING-1879
Project: JBoss Messaging
Issue Type: Bug
Components: JMS Clustering
Affects Versions: 1.4.8.GA, 1.4.0.SP3.CP12
Reporter: Yong Hao Gao
Assignee: Yong Hao Gao
Priority: Critical
Fix For: 1.4.0.SP3.CP13, 1.4.8.SP1
If a message is sucked over to another node and at the same time failover happens at the source node, the source node will try to claim back messages in 'S' (sucking) states. If the said message is claimed back, the message won't get sucked because eventually the moveMessage operation on the DB will fail.
But in JDBCPersistenceManager.moveReference() it doesn't properly handle this, resulting in the message can be sucked twice.
Also there is a flaw in JDBCPersistenceManager.claimMessagesInSuck(long), this statement:
msgIDs.add(new ReferenceInfo(msgId, deliveryCount, sched));
should be:
if (rows == 1)
{
msgIDs.add(new ReferenceInfo(msgId, deliveryCount, sched));
}
without the if condition, a sucked message also can be re-delivered the second time.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
15 years, 1 month
[JBoss JIRA] Created: (AS7-1023) Tests intermittently fail with 'Could not load module'
by Carlo de Wolf (JIRA)
Tests intermittently fail with 'Could not load module'
------------------------------------------------------
Key: AS7-1023
URL: https://issues.jboss.org/browse/AS7-1023
Project: Application Server 7
Issue Type: Bug
Reporter: Carlo de Wolf
Priority: Blocker
Fix For: 7.0.0.CR1
{noformat}
12:39:18,947 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-7) MSC00001: Failed to start service jboss.module.service."deployment.managedbean-example.ear".main: org.jboss.msc.service.StartException in service jboss.module.service."deployment.managedbean-example.ear".main: Failed to load module: deployment.managedbean-example.ear:main
at org.jboss.as.server.moduleservice.ModuleLoadService.start(ModuleLoadService.java:66)
at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1675)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) [:1.6.0_22]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) [:1.6.0_22]
at java.lang.Thread.run(Thread.java:679) [:1.6.0_22]
Caused by: org.jboss.modules.ModuleLoadException: Could not load module deployment.managedbean-example.ear.managedbean-example.jar:main as corresponding module spec service deployment.managedbean-example.ear.managedbean-example.jar:main was not found
at org.jboss.as.server.moduleservice.ServiceModuleLoader.findModule(ServiceModuleLoader.java:168)
at org.jboss.modules.ModuleLoader.loadModuleLocal(ModuleLoader.java:225) [:1.0.0.CR3]
at org.jboss.modules.ModuleLoader.preloadModule(ModuleLoader.java:174) [:1.0.0.CR3]
at org.jboss.as.server.moduleservice.ServiceModuleLoader.preloadModule(ServiceModuleLoader.java:157)
at org.jboss.modules.ModuleLoader.loadModule(ModuleLoader.java:156) [:1.0.0.CR3]
at org.jboss.modules.Module.linkImports(Module.java:1039) [:1.0.0.CR3]
at org.jboss.modules.Module.relink(Module.java:1151) [:1.0.0.CR3]
at org.jboss.modules.ModuleLoader.relink(ModuleLoader.java:380) [:1.0.0.CR3]
at org.jboss.as.server.moduleservice.ServiceModuleLoader.relinkModule(ServiceModuleLoader.java:202)
at org.jboss.as.server.moduleservice.ModuleLoadService.start(ModuleLoadService.java:64)
... 4 more
{noformat}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
15 years, 1 month
[JBoss JIRA] Created: (AS7-946) Persistence annotation processing is overly restrictive
by Marius Bogoevici (JIRA)
Persistence annotation processing is overly restrictive
---------------------------------------------------------
Key: AS7-946
URL: https://issues.jboss.org/browse/AS7-946
Project: Application Server 7
Issue Type: Bug
Components: JPA / Hibernate
Affects Versions: No Release
Reporter: Marius Bogoevici
If a deployment contains classes bearing the @PersistenceContext annotation, the annotation processor will fail the deployment if a persistence unit is not found. While this is correct for classes which are a target for container-driven injection, the application may contain annotated classes that are not injection targets according to the Java EE specification. This is not illegal according to the specification.
To wit, a Spring application may use @PersistenceContext for performing Spring-driven injection of Spring-managed entity manager factories.
In the past, such applications could have used the 'metadata-complete' attribute in web.xml, but this does not seem to work anymore.
Regardless, of that, the server could adopt a more lenient approach, by failing the injection only when a managed bean is actually injected with a non-existent PU/PC reference.
The other variant would be to restrict validation to classes which are actual injection targets according to the Java EE specification.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
15 years, 1 month