[JBoss JIRA] (JBRULES-3713) UnsupportedOperationException from BaseLeftTuple.getBlocker
by Ryan Crumley (JIRA)
Ryan Crumley created JBRULES-3713:
-------------------------------------
Summary: UnsupportedOperationException from BaseLeftTuple.getBlocker
Key: JBRULES-3713
URL: https://issues.jboss.org/browse/JBRULES-3713
Project: JBRULES
Issue Type: Bug
Security Level: Public (Everyone can see)
Affects Versions: 5.5.0.Final
Reporter: Ryan Crumley
Assignee: Mark Proctor
I am occasionally running into the follow exception after upgrading from 5.4.0-Final to 5.5.0-Final:
Caused by: java.lang.UnsupportedOperationException
at org.drools.reteoo.BaseLeftTuple.getBlocker(BaseLeftTuple.java:556)
at org.drools.reteoo.NotNode.modifyLeftTuple(NotNode.java:234)
at org.drools.reteoo.LeftTupleSource.doModifyLeftTuple(LeftTupleSource.java:304)
at org.drools.reteoo.LeftTupleSource.modifyLeftTuple(LeftTupleSource.java:278)
at org.drools.reteoo.SingleLeftTupleSinkAdapter.doPropagateModifyLeftTuple(SingleLeftTupleSinkAdapter.java:205)
at org.drools.reteoo.SingleLeftTupleSinkAdapter.propagateModifyObject(SingleLeftTupleSinkAdapter.java:235)
at org.drools.reteoo.LeftInputAdapterNode.modifyObject(LeftInputAdapterNode.java:170)
at org.drools.reteoo.SingleObjectSinkAdapter.propagateModifyObject(SingleObjectSinkAdapter.java:68)
at org.drools.reteoo.AlphaNode.modifyObject(AlphaNode.java:157)
at org.drools.reteoo.CompositeObjectSinkAdapter.doPropagateModifyObject(CompositeObjectSinkAdapter.java:507)
at org.drools.reteoo.CompositeObjectSinkAdapter.propagateModifyObject(CompositeObjectSinkAdapter.java:432)
at org.drools.reteoo.ObjectTypeNode.modifyObject(ObjectTypeNode.java:314)
at org.drools.reteoo.EntryPointNode.modifyObject(EntryPointNode.java:265)
at org.drools.common.NamedEntryPoint.update(NamedEntryPoint.java:483)
at org.drools.common.NamedEntryPoint.update(NamedEntryPoint.java:383)
at org.drools.base.DefaultKnowledgeHelper.update(DefaultKnowledgeHelper.java:337)
Please let me know what else I can provide to help debug. I can provide a small project to reproduce if needed.
--
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, 6 months
[JBoss JIRA] (AS7-4776) Error during (re) adding connection factory using CLI
by Stefano Maestri (JIRA)
[ https://issues.jboss.org/browse/AS7-4776?page=com.atlassian.jira.plugin.s... ]
Stefano Maestri resolved AS7-4776.
----------------------------------
Resolution: Done
> Error during (re) adding connection factory using CLI
> -----------------------------------------------------
>
> Key: AS7-4776
> URL: https://issues.jboss.org/browse/AS7-4776
> Project: Application Server 7
> Issue Type: Bug
> Components: JCA
> Affects Versions: 7.1.2.Final (EAP)
> Reporter: Stefano Maestri
> Assignee: Stefano Maestri
> Priority: Critical
> Labels: EAP6_Needs_Triage
> Fix For: 7.2.0.Alpha1, 7.1.3.Final (EAP)
>
> Attachments: MDB.jar
>
>
> /subsystem=resource-adapters/resource-adapter=wsDS:add(archive=teiid-connector-ws.rar, transaction-support=NoTransaction)
> /subsystem=resource-adapters/resource-adapter=wsDS/connection-definitions=wsDS:add(jndi-name=java:/wsDS, class-name=org.teiid.resource.adapter.ws.WSManagedConnectionFactory, enabled=true, use-java-context=true)
> /subsystem=resource-adapters/resource-adapter=wsDS/connection-definitions=wsDS/config-properties=EndPoint:add(value={end_point})
> /subsystem=resource-adapters/resource-adapter=wsDS:activate
> /subsystem=resource-adapters/resource-adapter=wsDS:remove
> 20:48:02,169 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-1) MSC00001: Failed to start service jboss.ra.deployment."teiid-connector-ws.rar_1": org.jboss.msc.service.StartException in service jboss.ra.deployment."teiid-connector-ws.rar_1": org.jboss.jca.core.spi.mdr.NotFoundException: IJ000855: teiid-connector-ws isn't registered
> at org.jboss.as.connector.metadata.deployment.ResourceAdapterXmlDeploymentService.start(ResourceAdapterXmlDeploymentService.java:127)
> 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$Worker.runTask(ThreadPoolExecutor.java:886) [rt.jar:1.6.0_26]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [rt.jar:1.6.0_26]
> at java.lang.Thread.run(Thread.java:662) [rt.jar:1.6.0_26]
> Caused by: org.jboss.jca.core.spi.mdr.NotFoundException: IJ000855: teiid-connector-ws isn't registered
> at org.jboss.jca.core.mdr.SimpleMetadataRepository.getResourceAdapter(SimpleMetadataRepository.java:150)
> at org.jboss.as.connector.metadata.deployment.ResourceAdapterXmlDeploymentService.start(ResourceAdapterXmlDeploymentService.java:87)
> ... 5 more
> The problem is present when there is only one RA definitions (added and activated explicitly by :activate operation after deployment of rar) and it's removed.
--
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, 6 months
[JBoss JIRA] (AS7-4913) Server sends "big integer <val>" for config entries when a reload is needed
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/AS7-4913?page=com.atlassian.jira.plugin.s... ]
Brian Stansberry resolved AS7-4913.
-----------------------------------
Resolution: Done
jboss-dmr 1.1.4 with this fix in it is integrated in AS master.
> Server sends "big integer <val>" for config entries when a reload is needed
> ---------------------------------------------------------------------------
>
> Key: AS7-4913
> URL: https://issues.jboss.org/browse/AS7-4913
> Project: Application Server 7
> Issue Type: Bug
> Components: Domain Management, JCA
> Affects Versions: 7.1.2.Final (EAP)
> Reporter: Heiko Rupp
> Assignee: David Lloyd
> Priority: Minor
> Labels: rhq
> Fix For: 7.2.0.Alpha1
>
>
> RHQ sends JSON like this to change e.g. the max-pool-size setting of a data source:
> {"operation":"composite","steps":[{"operation":"write-attribute","address":[{"subsystem":"datasources"},{"data-source":"ExampleDS"}],"name":"max-pool-size","value":75},{"operation":"write-attribute","address":[{"subsystem":"datasources"},{"data-source":"ExampleDS"}],"name":"use-fast-fail","value":false}],"address":[]}
> Server returns success.
> When I directly go to the cli afterwards I see:
> [standalone@localhost:9999 /] /subsystem=datasources/data-source=ExampleDS:read-attribute(name=max-pool-size)
> {
> "outcome" => "success",
> "result" => big integer 75,
> "response-headers" => {"process-state" => "restart-required"}
> }
> Note the "big integer"
> [standalone@localhost:9999 /] /:reload
> {"outcome" => "success"}
> [standalone@localhost:9999 /] /subsystem=datasources/data-source=ExampleDS:read-attribute(name=max-pool-size)
> {
> "outcome" => "success",
> "result" => 75
> }
> [standalone@localhost:9999 /]
> Now the server acts as always.
--
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, 6 months
[JBoss JIRA] (AS7-6314) Expose ProcessType via ExtensionParsingContext
by Brian Stansberry (JIRA)
Brian Stansberry created AS7-6314:
-------------------------------------
Summary: Expose ProcessType via ExtensionParsingContext
Key: AS7-6314
URL: https://issues.jboss.org/browse/AS7-6314
Project: Application Server 7
Issue Type: Enhancement
Components: Domain Management
Reporter: Brian Stansberry
Assignee: Brian Stansberry
Fix For: 7.2.0.Alpha1
A master HostController may have different parsing requirements from a standalone server. For example, support for legacy attributes used on legacy slaves. For an Extension to implement different behavior it needs access to the ProcessType.
--
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, 6 months
[JBoss JIRA] (AS7-5255) Deployed log4j.properties does not affect non log4j logging systems
by James Perkins (JIRA)
[ https://issues.jboss.org/browse/AS7-5255?page=com.atlassian.jira.plugin.s... ]
James Perkins commented on AS7-5255:
------------------------------------
Pull request changed to not hold a strong reference. Add a strong reference to LogContext as an option, https://github.com/jboss-logging/jboss-logmanager/commit/69b3977218daebfa....
> Deployed log4j.properties does not affect non log4j logging systems
> -------------------------------------------------------------------
>
> Key: AS7-5255
> URL: https://issues.jboss.org/browse/AS7-5255
> Project: Application Server 7
> Issue Type: Bug
> Components: Logging
> Affects Versions: 7.1.2.Final (EAP)
> Reporter: Patrick Ruckstuhl
> Assignee: James Perkins
> Priority: Blocker
> Fix For: 7.2.0.Alpha1
>
>
> If I create the file
> my.ear/META-INF/log4j.properties
> with
> log4j.rootLogger=DEBUG, FA
> log4j.appender.FA=org.apache.log4j.FileAppender
> log4j.appender.FA.File=/tmp/my.log
> log4j.appender.FA.layout=org.apache.log4j.PatternLayout
> log4j.appender.FA.layout.ConversionPattern= %-4r [%t] %-5p %c %x - %m%n
> this results in nothing in the server.log and an empty /tmp/my.log
> but if I create a
> my.ear/META-INF/logging.properties
> this results in everything beeing logged to /tmp/my.log
> We're using SLF4J in our application and also using a library that uses COMMONS-LOGGING
> I also did a test with doing an additional log statement using the log4j api directly and this one (and only this one) did get logged to /tmp/my.log
--
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, 6 months
[JBoss JIRA] (AS7-5722) Backward compatibility issue with JMS clients
by Jeff Mesnil (JIRA)
[ https://issues.jboss.org/browse/AS7-5722?page=com.atlassian.jira.plugin.s... ]
Jeff Mesnil commented on AS7-5722:
----------------------------------
I'll use miroslav test tomorrow to check that the issue has been fixed.
> Backward compatibility issue with JMS clients
> ---------------------------------------------
>
> Key: AS7-5722
> URL: https://issues.jboss.org/browse/AS7-5722
> Project: Application Server 7
> Issue Type: Bug
> Components: JMS
> Reporter: Miroslav Novak
> Assignee: Jeff Mesnil
> Priority: Critical
> Fix For: 7.2.0.Alpha1
>
>
> When standalone jms client is trying to connect with "old" jboss-client.jar from AS 7.1.2.Final (HornetQ 2.2.16.Final) to AS 7.2.0.Alpha1 (HornetQ 2.3.0.Beta1) then ClassNotFoundException it thrown:
> Console log of jms client:
> {code}
> [jbossqa@station4 as7-with-hq-replicated]$ java -cp /home/jbossqa/hornetq_eap6_testsuite/as7-with-hq-replicated/client-1.0-SNAPSHOT.jar:/home/jbossqa/hornetq_eap6_testsuite/server1/jboss-eap-6.0/bin/client/jboss-client.jar org.jboss.jms.client.TestProducer 192.168.40.1 jms/queue/testQueue0 10
> remote://192.168.40.1:4447
> Oct 10, 2012 11:44:41 AM org.xnio.Xnio <clinit>
> INFO: XNIO Version 3.0.6.GA-redhat-1
> Oct 10, 2012 11:44:41 AM org.xnio.nio.NioXnio <clinit>
> INFO: XNIO NIO Implementation Version 3.0.6.GA-redhat-1
> Oct 10, 2012 11:44:41 AM org.jboss.remoting3.EndpointImpl <clinit>
> INFO: JBoss Remoting version 3.2.8.SP1-redhat-1
> Oct 10, 2012 11:44:42 AM org.jboss.naming.remote.protocol.v1.RemoteNamingStoreV1$MessageReceiver handleEnd
> ERROR: Channel end notification received, closing channel Channel ID f6fa08e1 (outbound) of Remoting connection 2a0ab444 to /192.168.40.1:4447
> org.jboss.naming.remote.protocol.NamingIOException: Failed to lookup [Root exception is java.io.IOException: java.lang.ClassNotFoundException: org.hornetq.api.core.BroadcastEndpointFactoryConfiguration]
> at org.jboss.naming.remote.client.ClientUtil.namingException(ClientUtil.java:49)
> at org.jboss.naming.remote.protocol.v1.Protocol$1.execute(Protocol.java:104)
> at org.jboss.naming.remote.protocol.v1.RemoteNamingStoreV1.lookup(RemoteNamingStoreV1.java:78)
> at org.jboss.naming.remote.client.HaRemoteNamingStore$1.operation(HaRemoteNamingStore.java:227)
> at org.jboss.naming.remote.client.HaRemoteNamingStore.namingOperation(HaRemoteNamingStore.java:119)
> at org.jboss.naming.remote.client.HaRemoteNamingStore.lookup(HaRemoteNamingStore.java:223)
> at org.jboss.naming.remote.client.RemoteContext.lookup(RemoteContext.java:79)
> at org.jboss.naming.remote.client.RemoteContext.lookup(RemoteContext.java:83)
> at javax.naming.InitialContext.lookup(InitialContext.java:409)
> at org.jboss.jms.client.TestProducer.startClient(TestProducer.java:47)
> at org.jboss.jms.client.TestProducer.main(TestProducer.java:28)
> Caused by: java.io.IOException: java.lang.ClassNotFoundException: org.hornetq.api.core.BroadcastEndpointFactoryConfiguration
> at org.jboss.naming.remote.protocol.v1.Protocol$1$3.read(Protocol.java:159)
> at org.jboss.naming.remote.protocol.v1.BaseProtocolCommand.readResult(BaseProtocolCommand.java:60)
> at org.jboss.naming.remote.protocol.v1.Protocol$1.handleClientMessage(Protocol.java:149)
> at org.jboss.naming.remote.protocol.v1.RemoteNamingStoreV1$MessageReceiver$1.run(RemoteNamingStoreV1.java:210)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
> at java.lang.Thread.run(Thread.java:679)
> Caused by: java.lang.ClassNotFoundException: org.hornetq.api.core.BroadcastEndpointFactoryConfiguration
> at java.net.URLClassLoader$1.run(URLClassLoader.java:217)
> at java.security.AccessController.doPrivileged(Native Method)
> at java.net.URLClassLoader.findClass(URLClassLoader.java:205)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:321)
> at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:294)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:266)
> at java.lang.Class.forName0(Native Method)
> at java.lang.Class.forName(Class.java:264)
> at org.jboss.marshalling.AbstractClassResolver.loadClass(AbstractClassResolver.java:135)
> at org.jboss.marshalling.AbstractClassResolver.resolveClass(AbstractClassResolver.java:116)
> at org.jboss.marshalling.river.RiverUnmarshaller.doReadClassDescriptor(RiverUnmarshaller.java:871)
> at org.jboss.marshalling.river.RiverUnmarshaller.doReadClassDescriptor(RiverUnmarshaller.java:903)
> at org.jboss.marshalling.river.RiverUnmarshaller.doReadClassDescriptor(RiverUnmarshaller.java:903)
> at org.jboss.marshalling.river.RiverUnmarshaller.doReadNewObject(RiverUnmarshaller.java:1205)
> at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:272)
> at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:209)
> at org.jboss.marshalling.river.RiverUnmarshaller.readFields(RiverUnmarshaller.java:1678)
> at org.jboss.marshalling.river.RiverUnmarshaller.doInitSerializable(RiverUnmarshaller.java:1594)
> at org.jboss.marshalling.river.RiverUnmarshaller.doInitSerializable(RiverUnmarshaller.java:1558)
> at org.jboss.marshalling.river.RiverUnmarshaller.doReadNewObject(RiverUnmarshaller.java:1236)
> at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:272)
> at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:209)
> at org.jboss.marshalling.AbstractObjectInput.readObject(AbstractObjectInput.java:37)
> at org.jboss.naming.remote.protocol.v1.Protocol$1$3.read(Protocol.java:156)
> ... 6 more
> Oct 10, 2012 11:44:42 AM org.jboss.naming.remote.protocol.v1.RemoteNamingStoreV1$MessageReceiver handleEnd
> ERROR: Channel end notification received, closing channel Channel ID dac0f594 (outbound) of Remoting connection 16e1eea8 to /192.168.40.1:4447
> {code}
> How to reproduce:
> 1) Download reproducer.zip from QA Lab and unzip reproducer.zip: {code}scp -r messaging-18.jbm.lab.bos.redhat.com:/home/mnovak/reproducer-backward-compatibility .{code}
> 2) Start AS7 server:{code}cd jboss-as-7.2.0.Alpha1-SNAPSHOT/bin;sh standalone.sh -c standalone-full-ha.xml -b localhost{code}
> 3) Start jms producer:{code}java -cp $PWD/client-1.0-SNAPSHOT.jar:$PWD/jboss-old-hq226-client.jar org.jboss.jms.client.TestProducer localhost jms/queue/testQueue0 10{code}
--
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, 6 months
[JBoss JIRA] (AS7-6202) Deploying to a 7.2 DC with a 7.1.2 or 7.1.3 slave fails in OSGi
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/AS7-6202?page=com.atlassian.jira.plugin.s... ]
Brian Stansberry commented on AS7-6202:
---------------------------------------
Workaround added.
> Deploying to a 7.2 DC with a 7.1.2 or 7.1.3 slave fails in OSGi
> ---------------------------------------------------------------
>
> Key: AS7-6202
> URL: https://issues.jboss.org/browse/AS7-6202
> Project: Application Server 7
> Issue Type: Bug
> Components: OSGi
> Affects Versions: 7.1.2.Final (EAP), 7.1.3.Final (EAP)
> Reporter: Kabir Khan
> Assignee: Thomas Diesler
> Fix For: 7.1.4.Final (EAP)
>
> Attachments: domain.xml, host.xml
>
>
> I noticed this when working on the mixed-domain tests. The attached domain.xml and host.xml contain adjustments for the older slave to work (replacing the MERGE3 jgroups protocol with MERGE2, since 7.1.x does not have that version), and makes all its servers auto-start="false".
> To reproduce, start up a DC built from master using those files. Then start up a slave HC built from 7.1.2.Final or 7.1.3.Final using a command like:
> ./build/target/jboss-as-7.1.3.Final/bin/domain.sh --host-config=host-slave.xml -Djboss.domain.master.address=127.0.0.1 -Djboss.management.native.port=19999
> Now in CLI:
> {code}
> [domain@localhost:9999 /] /deployment=test.war:add(content=[{"url" => "file:/Users/kabir/sourcecontrol/jboss-as7/git/jboss-as/testsuite/mixed-domain/target/deployments/MixedDomainDeployment_7_1_2_Final_TestCase/archives/test.war"}]
> {
> "outcome" => "success",
> "result" => undefined,
> "server-groups" => undefined
> }
> [domain@localhost:9999 /] /deployment=test.war:remove [domain@localhost:9999 /] /server-group=main-server-group/deployment=test.war:add(enabled=true)
> {
> "outcome" => "failed",
> "result" => undefined,
> "failure-description" => "JBAS010839: Operation failed or was rolled back on all servers.",
> "rolled-back" => true,
> "server-groups" => {"main-server-group" => {"host" => {"kabirs-macbook-pro.local" => {"server-one" => {"response" => {
> "outcome" => "failed",
> "result" => undefined,
> "failure-description" => {"JBAS014771: Services with missing/unavailable dependencies" => ["jboss.osgi.as.module.registration.\"deployment.test.war:main\" Missing[jbosgi.Environment]"]},
> "rolled-back" => true
> }}}}}}
> }
> {code}
> The console log for the slave shows
> {code}
> [Server:server-one] 17:21:22,201 INFO [org.jboss.as.server.deployment] (MSC service thread 1-4) JBAS015876: Starting deployment of "test.war"
> [Server:server-one] 17:21:22,556 INFO [org.jboss.web] (MSC service thread 1-7) JBAS018210: Registering web context: /test
> [Server:server-one] 17:21:22,771 INFO [org.jboss.as.server] (host-controller-connection-threads - 1) JBAS015870: Deploy of deployment "test.war" was rolled back with failure message {"JBAS014771: Services with missing/unavailable dependencies" => ["jboss.osgi.as.module.registration.\"deployment.test.war:main\" Missing[jbosgi.Environment]"]}
> [Server:server-one] 17:21:22,814 INFO [org.jboss.as.server.deployment] (MSC service thread 1-3) JBAS015877: Stopped deployment test.war in 42ms
> {code}
> The deployment is very simple, and just contains an html file:
> {code}
> $unzip -l testsuite/mixed-domain/target/deployments/MixedDomainDeployment_7_1_2_Final_TestCase/archives/test.war
> Archive: testsuite/mixed-domain/target/deployments/MixedDomainDeployment_7_1_2_Final_TestCase/archives/test.war
> Length Date Time Name
> -------- ---- ---- ----
> 210 12-17-12 16:34 index.html
> -------- -------
> 210 1 file
> {code}
--
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, 6 months
[JBoss JIRA] (AS7-6202) Deploying to a 7.2 DC with a 7.1.2 or 7.1.3 slave fails in OSGi
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/AS7-6202?page=com.atlassian.jira.plugin.s... ]
Brian Stansberry updated AS7-6202:
----------------------------------
Workaround Description:
Make sure your domain.xml includes the following in the socket-binding-group config for all socket binding groups used by server groups that have servers running 7.1.x:
<socket-binding name="osgi-http" interface="management" port="8090"/>
Workaround: Workaround Exists
> Deploying to a 7.2 DC with a 7.1.2 or 7.1.3 slave fails in OSGi
> ---------------------------------------------------------------
>
> Key: AS7-6202
> URL: https://issues.jboss.org/browse/AS7-6202
> Project: Application Server 7
> Issue Type: Bug
> Components: OSGi
> Affects Versions: 7.1.2.Final (EAP), 7.1.3.Final (EAP)
> Reporter: Kabir Khan
> Assignee: Thomas Diesler
> Fix For: 7.1.4.Final (EAP)
>
> Attachments: domain.xml, host.xml
>
>
> I noticed this when working on the mixed-domain tests. The attached domain.xml and host.xml contain adjustments for the older slave to work (replacing the MERGE3 jgroups protocol with MERGE2, since 7.1.x does not have that version), and makes all its servers auto-start="false".
> To reproduce, start up a DC built from master using those files. Then start up a slave HC built from 7.1.2.Final or 7.1.3.Final using a command like:
> ./build/target/jboss-as-7.1.3.Final/bin/domain.sh --host-config=host-slave.xml -Djboss.domain.master.address=127.0.0.1 -Djboss.management.native.port=19999
> Now in CLI:
> {code}
> [domain@localhost:9999 /] /deployment=test.war:add(content=[{"url" => "file:/Users/kabir/sourcecontrol/jboss-as7/git/jboss-as/testsuite/mixed-domain/target/deployments/MixedDomainDeployment_7_1_2_Final_TestCase/archives/test.war"}]
> {
> "outcome" => "success",
> "result" => undefined,
> "server-groups" => undefined
> }
> [domain@localhost:9999 /] /deployment=test.war:remove [domain@localhost:9999 /] /server-group=main-server-group/deployment=test.war:add(enabled=true)
> {
> "outcome" => "failed",
> "result" => undefined,
> "failure-description" => "JBAS010839: Operation failed or was rolled back on all servers.",
> "rolled-back" => true,
> "server-groups" => {"main-server-group" => {"host" => {"kabirs-macbook-pro.local" => {"server-one" => {"response" => {
> "outcome" => "failed",
> "result" => undefined,
> "failure-description" => {"JBAS014771: Services with missing/unavailable dependencies" => ["jboss.osgi.as.module.registration.\"deployment.test.war:main\" Missing[jbosgi.Environment]"]},
> "rolled-back" => true
> }}}}}}
> }
> {code}
> The console log for the slave shows
> {code}
> [Server:server-one] 17:21:22,201 INFO [org.jboss.as.server.deployment] (MSC service thread 1-4) JBAS015876: Starting deployment of "test.war"
> [Server:server-one] 17:21:22,556 INFO [org.jboss.web] (MSC service thread 1-7) JBAS018210: Registering web context: /test
> [Server:server-one] 17:21:22,771 INFO [org.jboss.as.server] (host-controller-connection-threads - 1) JBAS015870: Deploy of deployment "test.war" was rolled back with failure message {"JBAS014771: Services with missing/unavailable dependencies" => ["jboss.osgi.as.module.registration.\"deployment.test.war:main\" Missing[jbosgi.Environment]"]}
> [Server:server-one] 17:21:22,814 INFO [org.jboss.as.server.deployment] (MSC service thread 1-3) JBAS015877: Stopped deployment test.war in 42ms
> {code}
> The deployment is very simple, and just contains an html file:
> {code}
> $unzip -l testsuite/mixed-domain/target/deployments/MixedDomainDeployment_7_1_2_Final_TestCase/archives/test.war
> Archive: testsuite/mixed-domain/target/deployments/MixedDomainDeployment_7_1_2_Final_TestCase/archives/test.war
> Length Date Time Name
> -------- ---- ---- ----
> 210 12-17-12 16:34 index.html
> -------- -------
> 210 1 file
> {code}
--
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, 6 months
[JBoss JIRA] (AS7-6313) Add deployement restart feature to console
by Radim Kolář (JIRA)
Radim Kolář created AS7-6313:
--------------------------------
Summary: Add deployement restart feature to console
Key: AS7-6313
URL: https://issues.jboss.org/browse/AS7-6313
Project: Application Server 7
Issue Type: Feature Request
Components: Console
Affects Versions: 7.1.3.Final (EAP)
Reporter: Radim Kolář
Assignee: Heiko Braun
Add restart button to JBOSS - Runtime - Manage deployements just next to enable disable and other buttons.
Rationale:
If application needs to be restarted then some application takes considerable amount of time to stop (click on disable) and start (click on enable). It will greatly enhance administrator productivity if he could just click on restart and move on.
--
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, 6 months
[JBoss JIRA] (AS7-6202) Deploying to a 7.2 DC with a 7.1.2 or 7.1.3 slave fails in OSGi
by Joe Pl (JIRA)
[ https://issues.jboss.org/browse/AS7-6202?page=com.atlassian.jira.plugin.s... ]
Joe Pl commented on AS7-6202:
-----------------------------
I've run into this error in a non-mixed setup (domain+host controller on same machine, 7.1.3.Final). It's not very clear to me from this description what the underlying cause it but I was wondering if there are any known workarounds for 7.1.3.Final?
> Deploying to a 7.2 DC with a 7.1.2 or 7.1.3 slave fails in OSGi
> ---------------------------------------------------------------
>
> Key: AS7-6202
> URL: https://issues.jboss.org/browse/AS7-6202
> Project: Application Server 7
> Issue Type: Bug
> Components: OSGi
> Affects Versions: 7.1.2.Final (EAP), 7.1.3.Final (EAP)
> Reporter: Kabir Khan
> Assignee: Thomas Diesler
> Fix For: 7.1.4.Final (EAP)
>
> Attachments: domain.xml, host.xml
>
>
> I noticed this when working on the mixed-domain tests. The attached domain.xml and host.xml contain adjustments for the older slave to work (replacing the MERGE3 jgroups protocol with MERGE2, since 7.1.x does not have that version), and makes all its servers auto-start="false".
> To reproduce, start up a DC built from master using those files. Then start up a slave HC built from 7.1.2.Final or 7.1.3.Final using a command like:
> ./build/target/jboss-as-7.1.3.Final/bin/domain.sh --host-config=host-slave.xml -Djboss.domain.master.address=127.0.0.1 -Djboss.management.native.port=19999
> Now in CLI:
> {code}
> [domain@localhost:9999 /] /deployment=test.war:add(content=[{"url" => "file:/Users/kabir/sourcecontrol/jboss-as7/git/jboss-as/testsuite/mixed-domain/target/deployments/MixedDomainDeployment_7_1_2_Final_TestCase/archives/test.war"}]
> {
> "outcome" => "success",
> "result" => undefined,
> "server-groups" => undefined
> }
> [domain@localhost:9999 /] /deployment=test.war:remove [domain@localhost:9999 /] /server-group=main-server-group/deployment=test.war:add(enabled=true)
> {
> "outcome" => "failed",
> "result" => undefined,
> "failure-description" => "JBAS010839: Operation failed or was rolled back on all servers.",
> "rolled-back" => true,
> "server-groups" => {"main-server-group" => {"host" => {"kabirs-macbook-pro.local" => {"server-one" => {"response" => {
> "outcome" => "failed",
> "result" => undefined,
> "failure-description" => {"JBAS014771: Services with missing/unavailable dependencies" => ["jboss.osgi.as.module.registration.\"deployment.test.war:main\" Missing[jbosgi.Environment]"]},
> "rolled-back" => true
> }}}}}}
> }
> {code}
> The console log for the slave shows
> {code}
> [Server:server-one] 17:21:22,201 INFO [org.jboss.as.server.deployment] (MSC service thread 1-4) JBAS015876: Starting deployment of "test.war"
> [Server:server-one] 17:21:22,556 INFO [org.jboss.web] (MSC service thread 1-7) JBAS018210: Registering web context: /test
> [Server:server-one] 17:21:22,771 INFO [org.jboss.as.server] (host-controller-connection-threads - 1) JBAS015870: Deploy of deployment "test.war" was rolled back with failure message {"JBAS014771: Services with missing/unavailable dependencies" => ["jboss.osgi.as.module.registration.\"deployment.test.war:main\" Missing[jbosgi.Environment]"]}
> [Server:server-one] 17:21:22,814 INFO [org.jboss.as.server.deployment] (MSC service thread 1-3) JBAS015877: Stopped deployment test.war in 42ms
> {code}
> The deployment is very simple, and just contains an html file:
> {code}
> $unzip -l testsuite/mixed-domain/target/deployments/MixedDomainDeployment_7_1_2_Final_TestCase/archives/test.war
> Archive: testsuite/mixed-domain/target/deployments/MixedDomainDeployment_7_1_2_Final_TestCase/archives/test.war
> Length Date Time Name
> -------- ---- ---- ----
> 210 12-17-12 16:34 index.html
> -------- -------
> 210 1 file
> {code}
--
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, 6 months