[JBoss JIRA] (JGRP-1610) LockingService and rpc on the same cluster, tryLock() hangs
by Bela Ban (JIRA)
Bela Ban created JGRP-1610:
------------------------------
Summary: LockingService and rpc on the same cluster, tryLock() hangs
Key: JGRP-1610
URL: https://issues.jboss.org/browse/JGRP-1610
Project: JGroups
Issue Type: Feature Request
Reporter: Bela Ban
Assignee: Bela Ban
Fix For: 3.3
Attachments: RpcLockingTest.java
Hi,
Yes, the sequence diagram only depicted the second part of my description.
Anyway, I've attached a test file that reproduce the problem.
It contains two test cases, one where the coordinator of the lock is the one who
sends the message first, and a second case where the non-coordinator sends
the message first.
In the first case the receiver, non-coordinator, will hang in tryLock. In the second
case though, everything works fine.
Regards,
Daniel Olausson
On 25 March 2013 16:15, Bela Ban <belaban(a)yahoo.com> wrote:
Hi Daniel,
the sequence diagram differs from your description, can you submit a
test case (e.g. copy MessageDispatcherRSVPTest and modify it), so I can
take a look ?
I assume your RPCs are blocking (sync) and non-OOB ? Could be a
recursive invocation, where FIFO order (default) leads to a distributed
deadlock.
A test case would clarify what you want to do, and if I can reproduce
the problem, I can fix it.
On 3/25/13 1:54 PM, Daniel Olausson wrote:
> Hi,
>
> We trying to use the same channel for our lockingService and
> rpcDispatcher. But we are noticing some weird behavior.
>
> The end result is that lock.tryLock(lockName) never returns, which it
> should always do.
>
> This happens when we do the following:
>
> On computer A, we lock the lock.
> Do a rpc to a function on computer B, this function tries to take the
> lock(lock.tryLock(lockName)), but it can't because the lock is locked.
> This is correct behavior.
> Computer A unlocks the lock.
>
> On computer B we now do the same procedure, we lock the lock and do a
> rpc to computer A, but here is when the strange thing happens. Computer
> A tries to take the lock by executing tryLock, but it never returns.
>
> Here is a sequence diagram:
> http://www.websequencediagrams.com/cgi-bin/cdraw?lz=dGl0bGUgQXV0aGVudGljY...
>
>
> In this example we use the standard udp.xml with <CENTRAL_LOCK/> added
> on the top of the stack. Everything works if we use PEER_LOCK but then
> we need the messages to arrive in the same order everywhere, e.g. atomic
> broadcast.
>
> It also works if we use different clusters for locking and rpc, but it
> would be convenient if we could use the same cluster.
>
>
> Is it recommended to use the same channel for different services?
>
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 1 month
[JBoss JIRA] (JGRP-1610) LockingService and rpc on the same cluster, tryLock() hangs
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1610?page=com.atlassian.jira.plugin.... ]
Bela Ban updated JGRP-1610:
---------------------------
Attachment: RpcLockingTest.java
> LockingService and rpc on the same cluster, tryLock() hangs
> -----------------------------------------------------------
>
> Key: JGRP-1610
> URL: https://issues.jboss.org/browse/JGRP-1610
> Project: JGroups
> Issue Type: Feature Request
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 3.3
>
> Attachments: RpcLockingTest.java
>
>
> Hi,
> Yes, the sequence diagram only depicted the second part of my description.
> Anyway, I've attached a test file that reproduce the problem.
> It contains two test cases, one where the coordinator of the lock is the one who
> sends the message first, and a second case where the non-coordinator sends
> the message first.
> In the first case the receiver, non-coordinator, will hang in tryLock. In the second
> case though, everything works fine.
> Regards,
> Daniel Olausson
> On 25 March 2013 16:15, Bela Ban <belaban(a)yahoo.com> wrote:
> Hi Daniel,
> the sequence diagram differs from your description, can you submit a
> test case (e.g. copy MessageDispatcherRSVPTest and modify it), so I can
> take a look ?
> I assume your RPCs are blocking (sync) and non-OOB ? Could be a
> recursive invocation, where FIFO order (default) leads to a distributed
> deadlock.
> A test case would clarify what you want to do, and if I can reproduce
> the problem, I can fix it.
> On 3/25/13 1:54 PM, Daniel Olausson wrote:
> > Hi,
> >
> > We trying to use the same channel for our lockingService and
> > rpcDispatcher. But we are noticing some weird behavior.
> >
> > The end result is that lock.tryLock(lockName) never returns, which it
> > should always do.
> >
> > This happens when we do the following:
> >
> > On computer A, we lock the lock.
> > Do a rpc to a function on computer B, this function tries to take the
> > lock(lock.tryLock(lockName)), but it can't because the lock is locked.
> > This is correct behavior.
> > Computer A unlocks the lock.
> >
> > On computer B we now do the same procedure, we lock the lock and do a
> > rpc to computer A, but here is when the strange thing happens. Computer
> > A tries to take the lock by executing tryLock, but it never returns.
> >
> > Here is a sequence diagram:
> > http://www.websequencediagrams.com/cgi-bin/cdraw?lz=dGl0bGUgQXV0aGVudGljY...
> >
> >
> > In this example we use the standard udp.xml with <CENTRAL_LOCK/> added
> > on the top of the stack. Everything works if we use PEER_LOCK but then
> > we need the messages to arrive in the same order everywhere, e.g. atomic
> > broadcast.
> >
> > It also works if we use different clusters for locking and rpc, but it
> > would be convenient if we could use the same cluster.
> >
> >
> > Is it recommended to use the same channel for different services?
> >
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 1 month
[JBoss JIRA] (AS7-4910) Error deploy .EAR with. jar with relative paths on file MANIFEST.MF
by Francesco De Simone (JIRA)
[ https://issues.jboss.org/browse/AS7-4910?page=com.atlassian.jira.plugin.s... ]
Francesco De Simone commented on AS7-4910:
------------------------------------------
I solved this problem by using AS7 Class Loading. I created two modules (one for each jar) and I put the modules in jboss-deployment-structure.xml. Of course, should be removed from WEB-INF/lib folder
> Error deploy .EAR with. jar with relative paths on file MANIFEST.MF
> -------------------------------------------------------------------
>
> Key: AS7-4910
> URL: https://issues.jboss.org/browse/AS7-4910
> Project: Application Server 7
> Issue Type: Bug
> Components: EE
> Affects Versions: 7.1.1.Final
> Environment: Software
> Linux debian 2.6.32-5-686 #1 SMP Mon Jan 16 16:04:25 UTC 2012 i686 GNU/Linux
> java version "1.6.0_26"
> Java(TM) SE Runtime Environment (build 1.6.0_26-b03)
> Java HotSpot(TM) Server VM (build 20.1-b02, mixed mode)
> Eclipse Java EE IDE for Web Developers.
> Version: Indigo Service Release 1
> Build id: 20110916-0149
> JBoss Tools 3.3 (Indigo)
> Hardware
> processor : 0
> vendor_id : GenuineIntel
> cpu family : 6
> model : 15
> model name : Intel(R) Core(TM)2 Duo CPU E6750 @ 2.66GHz
> stepping : 11
> cpu MHz : 2660.399
> cache size : 4096 KB
> physical id : 0
> siblings : 2
> core id : 0
> cpu cores : 2
> apicid : 0
> initial apicid : 0
> fdiv_bug : no
> hlt_bug : no
> f00f_bug : no
> coma_bug : no
> fpu : yes
> fpu_exception : yes
> cpuid level : 10
> wp : yes
> flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov
> pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx lm constant_tsc arch_perfmon pebs bts aperfmperf pni dtes64 monitor ds_cpl vmx smx est tm2 ssse3
> cx16 xtpr pdcm lahf_lm tpr_shadow vnmi flexpriority
> bogomips : 5320.79
> clflush size : 64
> cache_alignment : 64
> address sizes : 36 bits physical, 48 bits virtual
> power management:
> processor : 1
> vendor_id : GenuineIntel
> cpu family : 6
> model : 15
> model name : Intel(R) Core(TM)2 Duo CPU E6750 @ 2.66GHz
> stepping : 11
> cpu MHz : 2660.399
> cache size : 4096 KB
> physical id : 0
> siblings : 2
> core id : 1
> cpu cores : 2
> apicid : 1
> initial apicid : 1
> fdiv_bug : no
> hlt_bug : no
> f00f_bug : no
> coma_bug : no
> fpu : yes
> fpu_exception : yes
> Reporter: Roberto Requena
> Assignee: David Lloyd
> Labels: jboss
>
> When I try to deploy a .EAR project on the server with the following files "juh-3.2.1.jar" and "jurt-3.2.1.jar" contained in the web project lib folder, the server displays the following error:
> {noformat}
> WARNING: -logmodule is deprecated. Please use the system property 'java.util.logging.manager' or the 'java.util.logging.LogManager' service loader.
> 09:31:13,183 INFO [org.jboss.modules] JBoss Modules version 1.1.1.GA
> 09:31:13,424 INFO [org.jboss.msc] JBoss MSC version 1.0.2.GA
> 09:31:13,498 INFO [org.jboss.as] JBAS015899: JBoss AS 7.1.1.Final "Brontes" starting
> 09:31:14,836 INFO [org.xnio] XNIO Version 3.0.3.GA
> 09:31:14,849 INFO [org.jboss.as.server] JBAS015888: Creating http management service using socket-binding (management-http)
> 09:31:14,860 INFO [org.xnio.nio] XNIO NIO Implementation Version 3.0.3.GA
> 09:31:14,879 INFO [org.jboss.remoting] JBoss Remoting version 3.2.3.GA
> 09:31:14,950 INFO [org.jboss.as.logging] JBAS011502: Removing bootstrap log handlers
> 09:31:14,970 INFO [org.jboss.as.configadmin] (ServerService Thread Pool -- 26) JBAS016200: Activating ConfigAdmin Subsystem
> 09:31:15,010 INFO [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 31) JBAS010280: Activating Infinispan subsystem.
> 09:31:15,062 INFO [org.jboss.as.connector] (MSC service thread 1-4) JBAS010408: Starting JCA Subsystem (JBoss IronJacamar 1.0.9.Final)
> 09:31:15,082 INFO [org.jboss.as.connector.subsystems.datasources] (ServerService Thread Pool -- 27) JBAS010403: Deploying JDBC-compliant driver class org.h2.Driver (version 1.3)
> 09:31:15,106 INFO [org.jboss.as.naming] (ServerService Thread Pool -- 38) JBAS011800: Activating Naming Subsystem
> 09:31:15,156 INFO [org.jboss.as.osgi] (ServerService Thread Pool -- 39) JBAS011940: Activating OSGi Subsystem
> 09:31:15,178 INFO [org.jboss.as.security] (ServerService Thread Pool -- 44) JBAS013101: Activating Security Subsystem
> 09:31:15,190 INFO [org.jboss.as.security] (MSC service thread 1-4) JBAS013100: Current PicketBox version=4.0.7.Final
> 09:31:15,217 INFO [org.jboss.as.naming] (MSC service thread 1-1) JBAS011802: Starting Naming Service
> 09:31:15,231 INFO [org.jboss.as.mail.extension] (MSC service thread 1-3) JBAS015400: Bound mail session [java:jboss/mail/Default]
> 09:31:15,259 INFO [org.jboss.as.webservices] (ServerService Thread Pool -- 48) JBAS015537: Activating WebServices Extension
> 09:31:15,531 INFO [org.jboss.ws.common.management.AbstractServerConfig] (MSC service thread 1-3) JBoss Web Services - Stack CXF Server 4.0.2.GA
> 09:31:15,582 INFO [org.apache.coyote.http11.Http11Protocol] (MSC service thread 1-1) Arrancando Coyote HTTP/1.1 en puerto http--127.0.0.1-8080
> 09:31:16,144 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-4) JBAS010400: Bound data source [java:jboss/datasources/ExampleDS]
> 09:31:16,306 INFO [org.jboss.as.remoting] (MSC service thread 1-3) JBAS017100: Listening on /127.0.0.1:9999
> 09:31:16,308 INFO [org.jboss.as.remoting] (MSC service thread 1-1) JBAS017100: Listening on /127.0.0.1:4447
> 09:31:16,325 INFO [org.jboss.as.server.deployment.scanner] (DeploymentScanner-threads - 1) JBAS015014: Re-attempting failed deployment TestDeploy.ear
> 09:31:16,329 INFO [org.jboss.as.server.deployment.scanner] (MSC service thread 1-4) JBAS015012: Started FileSystemDeploymentService for directory /usr/local/org.jboss/as/versions/jboss-as-7.1.1.Final/standalone/deployments
> 09:31:16,342 WARN [org.jboss.as.server.deployment.scanner] (DeploymentScanner-threads - 1) JBAS015002: Deployment of 'Download.war' requested, but the deployment is not present
> 09:31:16,343 INFO [org.jboss.as.server.deployment.scanner] (DeploymentScanner-threads - 1) JBAS015003: Found Prueba-ear.ear in deployment directory. To trigger deployment create a file called Prueba-ear.ear.dodeploy
> 09:31:16,344 INFO [org.jboss.as.server.deployment.scanner] (DeploymentScanner-threads - 1) JBAS015003: Found TestDeploy.ear in deployment directory. To trigger deployment create a file called TestDeploy.ear.dodeploy
> 09:31:16,629 INFO [org.jboss.as.server.deployment] (MSC service thread 1-3) JBAS015876: Starting deployment of "Prueba-ear.ear"
> 09:31:16,629 INFO [org.jboss.as.server.deployment] (MSC service thread 1-2) JBAS015876: Starting deployment of "TestDeploy.ear"
> 09:31:16,690 INFO [org.jboss.as.server.deployment] (MSC service thread 1-3) JBAS015876: Starting deployment of "TestDeployWeb.war"
> 09:31:16,722 INFO [org.jboss.as.server.deployment] (MSC service thread 1-4) JBAS015876: Starting deployment of "Prueba-ejb-0.0.1-SNAPSHOT.jar"
> 09:31:16,723 INFO [org.jboss.as.server.deployment] (MSC service thread 1-4) JBAS015876: Starting deployment of "Prueba-web-0.0.1-SNAPSHOT.war"
> 09:31:16,857 WARN [org.jboss.as.server.deployment] (MSC service thread 1-3) Class Path entry ridl.jar in "/usr/local/org.jboss/as/versions/jboss-as-7.1.1.Final/standalone/deployments/TestDeploy.ear/TestDeployWeb.war/WEB-INF/lib/juh-3.2.1.jar" does not point to a valid jar for a Class-Path reference.
> 09:31:16,858 WARN [org.jboss.as.server.deployment] (MSC service thread 1-3) Class Path entry jurt.jar in "/usr/local/org.jboss/as/versions/jboss-as-7.1.1.Final/standalone/deployments/TestDeploy.ear/TestDeployWeb.war/WEB-INF/lib/juh-3.2.1.jar" does not point to a valid jar for a Class-Path reference.
> 09:31:16,871 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-3) MSC00001: Failed to start service jboss.deployment.subunit."TestDeploy.ear"."TestDeployWeb.war".STRUCTURE: org.jboss.msc.service.StartException in service jboss.deployment.subunit."TestDeploy.ear"."TestDeployWeb.war".STRUCTURE: Failed to process phase STRUCTURE of subdeployment "TestDeployWeb.war" of deployment "TestDeploy.ear"
> at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:119) [jboss-as-server-7.1.1.Final.jar:7.1.1.Final]
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1811) [jboss-msc-1.0.2.GA.jar:1.0.2.GA]
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1746) [jboss-msc-1.0.2.GA.jar:1.0.2.GA]
> at java.util.concurrent.ThreadPoolExecutor$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: java.lang.IllegalArgumentException: Given parent is not an ancestor of this virtual file
> at org.jboss.vfs.VirtualFile.getPathNameRelativeTo(VirtualFile.java:116)
> at org.jboss.vfs.VirtualFile.getPathNameRelativeTo(VirtualFile.java:122)
> at org.jboss.vfs.VirtualFile.getPathNameRelativeTo(VirtualFile.java:122)
> at org.jboss.vfs.VirtualFile.getPathNameRelativeTo(VirtualFile.java:122)
> at org.jboss.vfs.VirtualFile.getPathNameRelativeTo(VirtualFile.java:122)
> at org.jboss.vfs.VirtualFile.getPathNameRelativeTo(VirtualFile.java:122)
> at org.jboss.vfs.VirtualFile.getPathNameRelativeTo(VirtualFile.java:122)
> at org.jboss.vfs.VirtualFile.getPathNameRelativeTo(VirtualFile.java:122)
> at org.jboss.vfs.VirtualFile.getPathNameRelativeTo(VirtualFile.java:122)
> at org.jboss.vfs.VirtualFile.getPathNameRelativeTo(VirtualFile.java:110)
> at org.jboss.as.server.deployment.module.ManifestClassPathProcessor.createAdditionalModule(ManifestClassPathProcessor.java:193) [jboss-as-server-7.1.1.Final.jar:7.1.1.Final]
> at org.jboss.as.server.deployment.module.ManifestClassPathProcessor.handlingExistingClassPathEntry(ManifestClassPathProcessor.java:185) [jboss-as-server-7.1.1.Final.jar:7.1.1.Final]
> at org.jboss.as.server.deployment.module.ManifestClassPathProcessor.deploy(ManifestClassPathProcessor.java:162) [jboss-as-server-7.1.1.Final.jar:7.1.1.Final]
> at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:113) [jboss-as-server-7.1.1.Final.jar:7.1.1.Final]
> ... 5 more
> 09:31:17,113 INFO [org.jboss.as.jpa] (MSC service thread 1-2) JBAS011401: Read persistence.xml for primary
> 09:31:17,188 INFO [org.jboss.weld.deployer] (MSC service thread 1-4) JBAS016002: Processing weld deployment Prueba-ear.ear
> 09:31:17,272 INFO [org.jboss.weld.deployer] (MSC service thread 1-1) JBAS016002: Processing weld deployment Prueba-ejb-0.0.1-SNAPSHOT.jar
> 09:31:17,274 INFO [org.jboss.weld.deployer] (MSC service thread 1-2) JBAS016002: Processing weld deployment Prueba-web-0.0.1-SNAPSHOT.war
> 09:31:17,287 INFO [org.jboss.as.ejb3.deployment.processors.EjbJndiBindingsDeploymentUnitProcessor] (MSC service thread 1-1) JNDI bindings for session bean named MemberRegistration in deployment unit subdeployment "Prueba-ejb-0.0.1-SNAPSHOT.jar" of deployment "Prueba-ear.ear" are as follows:
> java:global/Prueba-ear/Prueba-ejb-0.0.1-SNAPSHOT/MemberRegistration!org.prueba.controller.MemberRegistration
> java:app/Prueba-ejb-0.0.1-SNAPSHOT/MemberRegistration!org.prueba.controller.MemberRegistration
> java:module/MemberRegistration!org.prueba.controller.MemberRegistration
> java:global/Prueba-ear/Prueba-ejb-0.0.1-SNAPSHOT/MemberRegistration
> java:app/Prueba-ejb-0.0.1-SNAPSHOT/MemberRegistration
> java:module/MemberRegistration
> 09:31:17,310 INFO [org.jboss.weld.deployer] (MSC service thread 1-3) JBAS016005: Starting Services for CDI deployment: Prueba-ear.ear
> 09:31:17,343 INFO [org.jboss.weld.Version] (MSC service thread 1-3) WELD-000900 1.1.5 (AS71)
> 09:31:17,631 INFO [org.jboss.as.jpa] (MSC service thread 1-2) JBAS011402: Starting Persistence Unit Service 'Prueba-ear.ear/Prueba-ejb-0.0.1-SNAPSHOT.jar#primary'
> 09:31:17,766 INFO [org.hibernate.annotations.common.Version] (MSC service thread 1-2) HCANN000001: Hibernate Commons Annotations {4.0.1.Final}
> 09:31:17,777 INFO [org.hibernate.Version] (MSC service thread 1-2) HHH000412: Hibernate Core {4.0.1.Final}
> 09:31:17,779 INFO [org.hibernate.cfg.Environment] (MSC service thread 1-2) HHH000206: hibernate.properties not found
> 09:31:17,792 INFO [org.hibernate.cfg.Environment] (MSC service thread 1-2) HHH000021: Bytecode provider name : javassist
> 09:31:17,809 INFO [org.hibernate.ejb.Ejb3Configuration] (MSC service thread 1-2) HHH000204: Processing PersistenceUnitInfo [
> name: primary
> ...]
> 09:31:17,963 INFO [org.hibernate.service.jdbc.connections.internal.ConnectionProviderInitiator] (MSC service thread 1-2) HHH000130: Instantiating explicit connection provider: org.hibernate.ejb.connection.InjectedDataSourceConnectionProvider
> 09:31:18,282 INFO [org.hibernate.dialect.Dialect] (MSC service thread 1-2) HHH000400: Using dialect: org.hibernate.dialect.H2Dialect
> 09:31:18,287 WARN [org.hibernate.dialect.H2Dialect] (MSC service thread 1-2) HHH000431: Unable to determine H2 database version, certain features may not work
> 09:31:18,290 INFO [org.hibernate.engine.jdbc.internal.LobCreatorBuilder] (MSC service thread 1-2) HHH000423: Disabling contextual LOB creation as JDBC driver reported JDBC version [3] less than 4
> 09:31:18,300 INFO [org.hibernate.engine.transaction.internal.TransactionFactoryInitiator] (MSC service thread 1-2) HHH000268: Transaction strategy: org.hibernate.engine.transaction.internal.jta.CMTTransactionFactory
> 09:31:18,304 INFO [org.hibernate.hql.internal.ast.ASTQueryTranslatorFactory] (MSC service thread 1-2) HHH000397: Using ASTQueryTranslatorFactory
> 09:31:18,377 INFO [org.hibernate.validator.util.Version] (MSC service thread 1-2) Hibernate Validator 4.2.0.Final
> 09:31:18,689 INFO [org.hibernate.tool.hbm2ddl.SchemaExport] (MSC service thread 1-2) HHH000227: Running hbm2ddl schema export
> 09:31:18,703 ERROR [org.hibernate.tool.hbm2ddl.SchemaExport] (MSC service thread 1-2) HHH000389: Unsuccessful: drop sequence hibernate_sequence
> 09:31:18,704 ERROR [org.hibernate.tool.hbm2ddl.SchemaExport] (MSC service thread 1-2) Sequence "HIBERNATE_SEQUENCE" no encontrado
> Sequence "HIBERNATE_SEQUENCE" not found; SQL statement:
> drop sequence hibernate_sequence [90036-161]
> 09:31:18,708 INFO [org.hibernate.tool.hbm2ddl.SchemaExport] (MSC service thread 1-2) HHH000230: Schema export complete
> 09:31:18,732 INFO [org.jboss.weld.deployer] (MSC service thread 1-3) JBAS016008: Starting weld service for deployment Prueba-ear.ear
> 09:31:19,130 INFO [javax.enterprise.resource.webcontainer.jsf.config] (MSC service thread 1-1) Inicializando Mojarra 2.1.7-jbossorg-1 (20120227-1401) para el contexto '/Prueba-web'
> 09:31:20,124 INFO [org.jboss.web] (MSC service thread 1-1) JBAS018210: Registering web context: /Prueba-web
> 09:31:20,133 INFO [org.jboss.as] (MSC service thread 1-4) JBAS015951: Admin console listening on http://127.0.0.1:9990
> 09:31:20,133 ERROR [org.jboss.as] (MSC service thread 1-4) JBAS015875: JBoss AS 7.1.1.Final "Brontes" started (with errors) in 7241ms - Started 243 of 326 services (2 services failed or missing dependencies, 80 services are passive or on-demand)
> 09:31:20,334 INFO [org.jboss.as.server] (DeploymentScanner-threads - 2) JBAS015871: Deploy of deployment "Prueba-ear.ear" was rolled back with no failure message
> 09:31:20,335 INFO [org.jboss.as.server] (DeploymentScanner-threads - 2) JBAS015870: Deploy of deployment "TestDeploy.ear" was rolled back with failure message {"JBAS014671: Failed services" => {"jboss.deployment.subunit.\"TestDeploy.ear\".\"TestDeployWeb.war\".STRUCTURE" => "org.jboss.msc.service.StartException in service jboss.deployment.subunit.\"TestDeploy.ear\".\"TestDeployWeb.war\".STRUCTURE: Failed to process phase STRUCTURE of subdeployment \"TestDeployWeb.war\" of deployment \"TestDeploy.ear\""}}
> 09:31:20,355 INFO [org.jboss.as.server.deployment] (MSC service thread 1-4) JBAS015877: Stopped deployment TestDeployWeb.war in 19ms
> 09:31:20,364 INFO [org.jboss.as.server.deployment] (MSC service thread 1-1) JBAS015877: Stopped deployment TestDeploy.ear in 29ms
> 09:31:20,372 INFO [org.jboss.weld.deployer] (MSC service thread 1-1) JBAS016009: Stopping weld service for deployment Prueba-ear.ear
> 09:31:20,381 INFO [org.jboss.as.jpa] (MSC service thread 1-1) JBAS011403: Stopping Persistence Unit Service 'Prueba-ear.ear/Prueba-ejb-0.0.1-SNAPSHOT.jar#primary'
> 09:31:20,382 INFO [org.hibernate.tool.hbm2ddl.SchemaExport] (MSC service thread 1-1) HHH000227: Running hbm2ddl schema export
> 09:31:20,386 INFO [org.hibernate.tool.hbm2ddl.SchemaExport] (MSC service thread 1-1) HHH000230: Schema export complete
> 09:31:20,399 INFO [org.jboss.as.server.deployment] (MSC service thread 1-2) JBAS015877: Stopped deployment Prueba-ejb-0.0.1-SNAPSHOT.jar in 63ms
> 09:31:20,399 INFO [org.jboss.as.server.deployment] (MSC service thread 1-4) JBAS015877: Stopped deployment Prueba-web-0.0.1-SNAPSHOT.war in 64ms
> 09:31:20,402 INFO [org.jboss.as.server.deployment] (MSC service thread 1-1) JBAS015877: Stopped deployment Prueba-ear.ear in 67ms
> 09:31:20,403 INFO [org.jboss.as.controller] (DeploymentScanner-threads - 2) JBAS014774: Service status report
> JBAS014777: Services which failed to start: service jboss.deployment.subunit."TestDeploy.ear"."TestDeployWeb.war".STRUCTURE: org.jboss.msc.service.StartException in service jboss.deployment.subunit."TestDeploy.ear"."TestDeployWeb.war".STRUCTURE: Failed to process phase STRUCTURE of subdeployment "TestDeployWeb.war" of deployment "TestDeploy.ear"
> 09:31:20,406 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.\"TestDeploy.ear\".\"TestDeployWeb.war\".STRUCTURE" => "org.jboss.msc.service.StartException in service jboss.deployment.subunit.\"TestDeploy.ear\".\"TestDeployWeb.war\".STRUCTURE: Failed to process phase STRUCTURE of subdeployment \"TestDeployWeb.war\" of deployment \"TestDeploy.ear\""}}}}
> 09:31:20,407 ERROR [org.jboss.as.server.deployment.scanner] (DeploymentScanner-threads - 1) JBAS014654: Composite operation was rolled back
> {noformat}
> I could see that causing the error are claspath declared in MANIFEST.MF files of these .jar files because they contain relative paths.
> {noformat}
> juh-3.2.1.jar
> Manifest-Version: 1.0
> Class-Path: ridl.jar jurt.jar ../../lib/ ../bin/
> {noformat}
> {noformat}
> jurt-3.2.1.jar
> Manifest-Version: 1.0
> Class-Path: ridl.jar unoloader.jar ../../lib/ ../bin/
> {noformat}
> Also I could see two things:
> # When I deploy only the Web project on the server containing these .jar files the error does not occur.
> # And If I remove the contents of the MANIFEST.MF file and deploying the .ear project the error does not occur.
> I have a .EAR project for test that demonstrates the error, but did not see any option to attach files. If you wish, tell me how to send them.
> Any other thing that I can help to order. I want to use to thank Stephen Coy and Tomaz Cerar for help.
> Thanks and sorry for my English
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 1 month
[JBoss JIRA] (DROOLS-85) Accessibility of declarative models in defaultPkg
by Mario Fusco (JIRA)
[ https://issues.jboss.org/browse/DROOLS-85?page=com.atlassian.jira.plugin.... ]
Mario Fusco resolved DROOLS-85.
-------------------------------
Resolution: Rejected
Actually it works if you import defaultpkg (with lowercase p). Moreover, you have to explicitly import that package if you have a rule in a different package and this is exactly how 5.x worked, so it is not a regression.
> Accessibility of declarative models in defaultPkg
> -------------------------------------------------
>
> Key: DROOLS-85
> URL: https://issues.jboss.org/browse/DROOLS-85
> Project: Drools
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Affects Versions: 6.0.0.Alpha1
> Reporter: Michael Anstis
> Assignee: Mario Fusco
>
> Unit Tests: https://github.com/droolsjbpm/drools/commit/7f56c141a
> If a declarative model is not added to an explicit package it appears impossible to use the declarative model from any package other than the 'defaultPkg' itself.
> Tests 'testModelInDefaultPackage1' and 'testModelInDefaultPackage2' create a declarative model in the 'defaultPkg' and attempt to use the model from a rule in a different (explicit) package.
> Tests that I'd expect to pass (one or the other, or both?) are @Ignored.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 1 month
[JBoss JIRA] (AS7-6789) Move the subsystem .dmr files out of the controller module into subsystem-test
by Kabir Khan (JIRA)
[ https://issues.jboss.org/browse/AS7-6789?page=com.atlassian.jira.plugin.s... ]
Kabir Khan updated AS7-6789:
----------------------------
Description: They are part of the actual module used (controller/src/main), and are solely used in the subsystem transformer tests (was: They are part of the actual module used (controller/src/main), and are solely used in the subsystem transformer tests))
> Move the subsystem .dmr files out of the controller module into subsystem-test
> ------------------------------------------------------------------------------
>
> Key: AS7-6789
> URL: https://issues.jboss.org/browse/AS7-6789
> Project: Application Server 7
> Issue Type: Feature Request
> Components: Domain Management
> Affects Versions: EAP 6.1.0.Alpha (7.2.0.Final)
> Reporter: Kabir Khan
> Assignee: Kabir Khan
> Fix For: 8.0.0.Alpha1
>
>
> They are part of the actual module used (controller/src/main), and are solely used in the subsystem transformer tests
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 1 month
[JBoss JIRA] (DROOLS-84) Scan for drools runtime creates runtime named "lib"
by Rob Stryker (JIRA)
[ https://issues.jboss.org/browse/DROOLS-84?page=com.atlassian.jira.plugin.... ]
Rob Stryker commented on DROOLS-84:
-----------------------------------
Hey Kris:
Can you resolve the issue to confirm its merged in? :) And set a fix version. Thanks.
> Scan for drools runtime creates runtime named "lib"
> ---------------------------------------------------
>
> Key: DROOLS-84
> URL: https://issues.jboss.org/browse/DROOLS-84
> Project: Drools
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Reporter: Rob Stryker
> Assignee: Kris Verlaenen
>
> If you open the jbosstools runtime preference page, you'll see the list of detectors at the bottom half of the page. If you disable the JBoss AS detector, and the Drools detector is enabled, you will see that the discovered runtime is simply named "Lib", and then, after creation, it is named "Drools - lib".
> Fixing this is part of a cleanup for nested runtime detection.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 1 month