[JBoss JIRA] (DROOLS-49) Improve Drools project to support deploymet on JBoss Fuse (Apache Karaf) platform
by Charles Moulliard (JIRA)
Charles Moulliard created DROOLS-49:
---------------------------------------
Summary: Improve Drools project to support deploymet on JBoss Fuse (Apache Karaf) platform
Key: DROOLS-49
URL: https://issues.jboss.org/browse/DROOLS-49
Project: Drools
Issue Type: Enhancement
Security Level: Public (Everyone can see)
Affects Versions: 5.5
Reporter: Charles Moulliard
Assignee: Mark Proctor
Existing Drools project has already been modified to support OSGI but the work done is incomplete, buggy and cannot be deployed like that on Apache Karaf (JBoss Fuse).
In order to allow Drools deployment on Karaf container, I suggest that first we prepare a uberjar bundle of Drools project (1) before to decide strategy to adopt to deploy Drools on OSGI platform and expose OSGI service (2)
Description done
1) Add maven-felix bundle, packaging = bundle & define package to be imported/exported for drools-spring, drools-camel, drools-persistence-jpa, drools-decision-tables
2) Create a provisioning feature file to deploy Drools project on Apache Karaf 2.3.0
3) Create a itest project validating approach on Karaf with pax-exam & drools example
--
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 Tomas Remes (JIRA)
[ https://issues.jboss.org/browse/AS7-6583?page=com.atlassian.jira.plugin.s... ]
Tomas Remes edited comment on AS7-6583 at 2/22/13 6:45 AM:
-----------------------------------------------------------
I actually think that both could be helpful. Anyway check the mentioned commit once again and notice the really first change in LoggingExtension class (omitting import stuff) from ContextClassLoaderLogContextSelector to ClassLoaderLogContextSelector. These classes resides in org.jboss.logmanager (1.4.0.Final). Now look at the implementation of getLogContext method in both. I guess this method is the crucial one, because is called pretty often. IMHO the for cycle from this method from ClassLoaderLogContextSelector is the clue. You can also check that in attached jprofiler6 snapshots. For the good version I simply replaced method's implementation with the ContextClassLoaderLogContextSelector's one. The snapshots are taken locally and are corresponding to one Numberguess game. At the end some numbers (time is in microseconds):
||-||-||Total time||Invocations||Average time||
|old|org.jboss.logmanager.ClassLoaderLogContextSelector.getLogContext()|24638|1130|21|
|new|org.jboss.logmanager.ClassLoaderLogContextSelector.getLogContext()|424546|1082|392|
I am going to verify this once again in big load of 2000 sessions, but I am pretty sure.
was (Author: tremes):
I actually think that both could be helpful. Anyway check the mentioned commit once again and notice the really first change (omitting import stuff) from ContextClassLoaderLogContextSelector to ClassLoaderLogContextSelector. These classes resides in org.jboss.logmanager (1.4.0.Final). Now look at the implementation of getLogContext method in both. I guess this method is the crucial one, because is called pretty often. IMHO the for cycle from this method from ClassLoaderLogContextSelector is the clue. You can also check that in attached jprofiler6 snapshots. For the good version I simply replaced method's implementation with the ContextClassLoaderLogContextSelector's one. The snapshots are taken locally and are corresponding to one Numberguess game. At the end some numbers (time is in microseconds):
||-||-||Total time||Invocations||Average time||
|old|org.jboss.logmanager.ClassLoaderLogContextSelector.getLogContext()|24638|1130|21|
|new|org.jboss.logmanager.ClassLoaderLogContextSelector.getLogContext()|424546|1082|392|
I am going to verify this once again in big load of 2000 sessions, but I am pretty sure.
> 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
> Attachments: AS7-snapshot-good.jps, AS7-snapshot-wrong.jps
>
>
> 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-3199) RESTEasy: Can't deploy WebApp if more than one subclass of javax.ws.rs.Application is present
by Ondrej Zizka (JIRA)
[ https://issues.jboss.org/browse/AS7-3199?page=com.atlassian.jira.plugin.s... ]
Ondrej Zizka commented on AS7-3199:
-----------------------------------
Just for the record - I have hit this when deploying a Spring-based app targetted for Tomcat. Personally, I'd like to see as much compatibility as possible. I remember the discussion in the early days of AS 7 development about compatibility with Tomcat, ending with "if they want compatibility with Tomcat, let them deploy on Tomcat", which makes sense unless you develop for JBoss AS, but also want to deploy other apps to the same server. In which case, issues such like this makes Joe Average SysAdmin complain about how JBoss can't deploy basic apps which other AS can. Which is IMO pity, my2c, YMMV etc.
> RESTEasy: Can't deploy WebApp if more than one subclass of javax.ws.rs.Application is present
> ---------------------------------------------------------------------------------------------
>
> Key: AS7-3199
> URL: https://issues.jboss.org/browse/AS7-3199
> Project: Application Server 7
> Issue Type: Bug
> Components: REST
> Affects Versions: 7.1.0.CR1b
> Reporter: Pavel Janousek
> Attachments: ExampleJAXRS.war
>
>
> If I packed WAR WebApp with more that one subclass of javax.ws.rs.Application, deployment fails with "JBAS011232: Only one JAX-RS Application Class allowed."
> This is not correct because it is against JAX-RS 1.1. specs where invalid situation (in section 2.3.2) is only when "It is a n error for
> more than one application to be deployed +at the same effective servlet mapping+".
> If you have any objections, please compare to reference JEE6 and JAX-RS implementation represented by the GlassFish Prelude 3.1.1 application server with already +fully JEE6 platform support+.
--
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-6605) Replicating JNDI tree to another server
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/AS7-6605?page=com.atlassian.jira.plugin.s... ]
RH Bugzilla Integration updated AS7-6605:
-----------------------------------------
Bugzilla Update: Perform
Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=913618
> Replicating JNDI tree to another server
> ----------------------------------------
>
> Key: AS7-6605
> URL: https://issues.jboss.org/browse/AS7-6605
> Project: Application Server 7
> Issue Type: Feature Request
> Components: Naming
> Affects Versions: 7.1.2.Final (EAP)
> Reporter: Miroslav Novak
> Assignee: Eduardo Martins
> Priority: Critical
> Fix For: 7.2.0.CR1
>
>
> Description of problem:
> This use case is taken from one of our user which we were able to handle using HA-JNDI in EAP 5:
> 1. JMS Client will create Context with two URL (node1, node2) (java.naming.provider.url property)
> 2. For some reason client is connected to node2 first which will have no JMS admin objects registered in JNDI (this happens when this node is configured as HornetQ backup)
> 3. Node2 has replicated JNDI tree from node1. So connection factory will connect client to node1 and queue/topics are deployed on node1.
> Can be this functionality provided in EAP 6, please?
--
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-6606) CLONE - ISPN000136: Execution error: java.lang.NullPointerException -> JBAS018079: Failed to passivate session
by Radoslav Husar (JIRA)
Radoslav Husar created AS7-6606:
-----------------------------------
Summary: CLONE - ISPN000136: Execution error: java.lang.NullPointerException -> JBAS018079: Failed to passivate session
Key: AS7-6606
URL: https://issues.jboss.org/browse/AS7-6606
Project: Application Server 7
Issue Type: Bug
Components: Clustering
Affects Versions: 7.1.3.Final (EAP)
Reporter: Radoslav Husar
Assignee: Radoslav Husar
Fix For: 7.2.0.Alpha1
As seen in org.jboss.as.test.clustering.cluster.web.passivation.AttributeBasedSessionPassivationTestCase (SYNC, tcp)
(test is disabled)
{noformat}
12:38:48,421 ERROR [org.infinispan.interceptors.InvocationContextInterceptor] (ContainerBackgroundProcessor[StandardEngine[jboss.web]]) ISPN000136: Execution error: java.lang.NullPointerException
at org.infinispan.context.impl.AbstractTxInvocationContext.clearLockedKeys(AbstractTxInvocationContext.java:100)
at org.infinispan.util.concurrent.locks.LockManagerImpl.unlockAll(LockManagerImpl.java:116)
at org.infinispan.interceptors.locking.AbstractTxLockingInterceptor.visitEvictCommand(AbstractTxLockingInterceptor.java:86)
at org.infinispan.commands.write.EvictCommand.acceptVisitor(EvictCommand.java:47)
at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:116)
at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:130)
at org.infinispan.commands.AbstractVisitor.visitEvictCommand(AbstractVisitor.java:87)
at org.infinispan.commands.write.EvictCommand.acceptVisitor(EvictCommand.java:47)
at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:116)
at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:130)
at org.infinispan.commands.AbstractVisitor.visitEvictCommand(AbstractVisitor.java:87)
at org.infinispan.commands.write.EvictCommand.acceptVisitor(EvictCommand.java:47)
at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:116)
at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:130)
at org.infinispan.commands.AbstractVisitor.visitEvictCommand(AbstractVisitor.java:87)
at org.infinispan.commands.write.EvictCommand.acceptVisitor(EvictCommand.java:47)
at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:116)
at org.infinispan.interceptors.CacheMgmtInterceptor.visitEvictCommand(CacheMgmtInterceptor.java:86)
at org.infinispan.commands.write.EvictCommand.acceptVisitor(EvictCommand.java:47)
at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:116)
at org.infinispan.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:132)
at org.infinispan.interceptors.InvocationContextInterceptor.handleDefault(InvocationContextInterceptor.java:91)
at org.infinispan.commands.AbstractVisitor.visitEvictCommand(AbstractVisitor.java:87)
at org.infinispan.commands.write.EvictCommand.acceptVisitor(EvictCommand.java:47)
at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:116)
at org.infinispan.interceptors.BatchingInterceptor.handleDefault(BatchingInterceptor.java:80)
at org.infinispan.commands.AbstractVisitor.visitEvictCommand(AbstractVisitor.java:87)
at org.infinispan.commands.write.EvictCommand.acceptVisitor(EvictCommand.java:47)
at org.infinispan.interceptors.InterceptorChain.invoke(InterceptorChain.java:345)
at org.infinispan.CacheImpl.evict(CacheImpl.java:382)
at org.infinispan.CacheImpl.evict(CacheImpl.java:375)
at org.infinispan.AbstractDelegatingCache.evict(AbstractDelegatingCache.java:60)
at org.infinispan.AbstractDelegatingCache.evict(AbstractDelegatingCache.java:60)
at org.jboss.as.clustering.web.infinispan.DistributedCacheManager$4.invoke(DistributedCacheManager.java:306)
at org.jboss.as.clustering.web.infinispan.DistributedCacheManager$4.invoke(DistributedCacheManager.java:303)
at org.jboss.as.clustering.infinispan.invoker.SimpleCacheInvoker.invoke(SimpleCacheInvoker.java:34)
at org.jboss.as.clustering.infinispan.invoker.BatchCacheInvoker.invoke(BatchCacheInvoker.java:48)
at org.jboss.as.clustering.infinispan.invoker.RetryingCacheInvoker.invoke(RetryingCacheInvoker.java:81)
at org.jboss.as.clustering.web.infinispan.DistributedCacheManager$ForceSynchronousCacheInvoker.invoke(DistributedCacheManager.java:531)
at org.jboss.as.clustering.web.infinispan.DistributedCacheManager.evictSession(DistributedCacheManager.java:310)
at org.jboss.as.web.session.DistributableSessionManager.processSessionPassivation(DistributableSessionManager.java:511) [jboss-as-web-7.1.3.Final-SNAPSHOT.jar:7.1.3.Final-SNAPSHOT]
at org.jboss.as.web.session.DistributableSessionManager.access$600(DistributableSessionManager.java:84) [jboss-as-web-7.1.3.Final-SNAPSHOT.jar:7.1.3.Final-SNAPSHOT]
at org.jboss.as.web.session.DistributableSessionManager$PassivationCheck.passivate(DistributableSessionManager.java:1557) [jboss-as-web-7.1.3.Final-SNAPSHOT.jar:7.1.3.Final-SNAPSHOT]
at org.jboss.as.web.session.DistributableSessionManager$PassivationCheck.access$300(DistributableSessionManager.java:1529) [jboss-as-web-7.1.3.Final-SNAPSHOT.jar:7.1.3.Final-SNAPSHOT]
at org.jboss.as.web.session.DistributableSessionManager.processExpirationPassivation(DistributableSessionManager.java:1293) [jboss-as-web-7.1.3.Final-SNAPSHOT.jar:7.1.3.Final-SNAPSHOT]
at org.jboss.as.web.session.AbstractSessionManager.processExpires(AbstractSessionManager.java:136) [jboss-as-web-7.1.3.Final-SNAPSHOT.jar:7.1.3.Final-SNAPSHOT]
at org.apache.catalina.session.ManagerBase.backgroundProcess(ManagerBase.java:375) [jbossweb-7.0.17.Final.jar:]
at org.apache.catalina.core.ContainerBase.backgroundProcess(ContainerBase.java:1317) [jbossweb-7.0.17.Final.jar:]
at org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processChildren(ContainerBase.java:1605) [jbossweb-7.0.17.Final.jar:]
at org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processChildren(ContainerBase.java:1617) [jbossweb-7.0.17.Final.jar:]
at org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processChildren(ContainerBase.java:1617) [jbossweb-7.0.17.Final.jar:]
at org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.run(ContainerBase.java:1591) [jbossweb-7.0.17.Final.jar:]
at java.lang.Thread.run(Thread.java:662) [rt.jar:1.6.0_35]
12:38:48,437 ERROR [org.apache.catalina.session.ManagerBase] (ContainerBackgroundProcessor[StandardEngine[jboss.web]]) JBAS018079: Failed to passivate session TkrU3mliw9NWrmpu86+XbehQ: java.lang.NullPointerException
at org.infinispan.context.impl.AbstractTxInvocationContext.clearLockedKeys(AbstractTxInvocationContext.java:100)
at org.infinispan.util.concurrent.locks.LockManagerImpl.unlockAll(LockManagerImpl.java:116)
at org.infinispan.interceptors.locking.AbstractTxLockingInterceptor.visitEvictCommand(AbstractTxLockingInterceptor.java:86)
at org.infinispan.commands.write.EvictCommand.acceptVisitor(EvictCommand.java:47)
at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:116)
at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:130)
at org.infinispan.commands.AbstractVisitor.visitEvictCommand(AbstractVisitor.java:87)
at org.infinispan.commands.write.EvictCommand.acceptVisitor(EvictCommand.java:47)
at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:116)
at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:130)
at org.infinispan.commands.AbstractVisitor.visitEvictCommand(AbstractVisitor.java:87)
at org.infinispan.commands.write.EvictCommand.acceptVisitor(EvictCommand.java:47)
at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:116)
at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:130)
at org.infinispan.commands.AbstractVisitor.visitEvictCommand(AbstractVisitor.java:87)
at org.infinispan.commands.write.EvictCommand.acceptVisitor(EvictCommand.java:47)
at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:116)
at org.infinispan.interceptors.CacheMgmtInterceptor.visitEvictCommand(CacheMgmtInterceptor.java:86)
at org.infinispan.commands.write.EvictCommand.acceptVisitor(EvictCommand.java:47)
at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:116)
at org.infinispan.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:132)
at org.infinispan.interceptors.InvocationContextInterceptor.handleDefault(InvocationContextInterceptor.java:91)
at org.infinispan.commands.AbstractVisitor.visitEvictCommand(AbstractVisitor.java:87)
at org.infinispan.commands.write.EvictCommand.acceptVisitor(EvictCommand.java:47)
at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:116)
at org.infinispan.interceptors.BatchingInterceptor.handleDefault(BatchingInterceptor.java:80)
at org.infinispan.commands.AbstractVisitor.visitEvictCommand(AbstractVisitor.java:87)
at org.infinispan.commands.write.EvictCommand.acceptVisitor(EvictCommand.java:47)
at org.infinispan.interceptors.InterceptorChain.invoke(InterceptorChain.java:345)
at org.infinispan.CacheImpl.evict(CacheImpl.java:382)
at org.infinispan.CacheImpl.evict(CacheImpl.java:375)
at org.infinispan.AbstractDelegatingCache.evict(AbstractDelegatingCache.java:60)
at org.infinispan.AbstractDelegatingCache.evict(AbstractDelegatingCache.java:60)
at org.jboss.as.clustering.web.infinispan.DistributedCacheManager$4.invoke(DistributedCacheManager.java:306)
at org.jboss.as.clustering.web.infinispan.DistributedCacheManager$4.invoke(DistributedCacheManager.java:303)
at org.jboss.as.clustering.infinispan.invoker.SimpleCacheInvoker.invoke(SimpleCacheInvoker.java:34)
at org.jboss.as.clustering.infinispan.invoker.BatchCacheInvoker.invoke(BatchCacheInvoker.java:48)
at org.jboss.as.clustering.infinispan.invoker.RetryingCacheInvoker.invoke(RetryingCacheInvoker.java:81)
at org.jboss.as.clustering.web.infinispan.DistributedCacheManager$ForceSynchronousCacheInvoker.invoke(DistributedCacheManager.java:531)
at org.jboss.as.clustering.web.infinispan.DistributedCacheManager.evictSession(DistributedCacheManager.java:310)
at org.jboss.as.web.session.DistributableSessionManager.processSessionPassivation(DistributableSessionManager.java:511) [jboss-as-web-7.1.3.Final-SNAPSHOT.jar:7.1.3.Final-SNAPSHOT]
at org.jboss.as.web.session.DistributableSessionManager.access$600(DistributableSessionManager.java:84) [jboss-as-web-7.1.3.Final-SNAPSHOT.jar:7.1.3.Final-SNAPSHOT]
at org.jboss.as.web.session.DistributableSessionManager$PassivationCheck.passivate(DistributableSessionManager.java:1557) [jboss-as-web-7.1.3.Final-SNAPSHOT.jar:7.1.3.Final-SNAPSHOT]
at org.jboss.as.web.session.DistributableSessionManager$PassivationCheck.access$300(DistributableSessionManager.java:1529) [jboss-as-web-7.1.3.Final-SNAPSHOT.jar:7.1.3.Final-SNAPSHOT]
at org.jboss.as.web.session.DistributableSessionManager.processExpirationPassivation(DistributableSessionManager.java:1293) [jboss-as-web-7.1.3.Final-SNAPSHOT.jar:7.1.3.Final-SNAPSHOT]
at org.jboss.as.web.session.AbstractSessionManager.processExpires(AbstractSessionManager.java:136) [jboss-as-web-7.1.3.Final-SNAPSHOT.jar:7.1.3.Final-SNAPSHOT]
at org.apache.catalina.session.ManagerBase.backgroundProcess(ManagerBase.java:375) [jbossweb-7.0.17.Final.jar:]
at org.apache.catalina.core.ContainerBase.backgroundProcess(ContainerBase.java:1317) [jbossweb-7.0.17.Final.jar:]
at org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processChildren(ContainerBase.java:1605) [jbossweb-7.0.17.Final.jar:]
at org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processChildren(ContainerBase.java:1617) [jbossweb-7.0.17.Final.jar:]
at org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processChildren(ContainerBase.java:1617) [jbossweb-7.0.17.Final.jar:]
at org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.run(ContainerBase.java:1591) [jbossweb-7.0.17.Final.jar:]
at java.lang.Thread.run(Thread.java:662) [rt.jar:1.6.0_35]
{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
[JBoss JIRA] (AS7-3199) RESTEasy: Can't deploy WebApp if more than one subclass of javax.ws.rs.Application is present
by Ondrej Zizka (JIRA)
[ https://issues.jboss.org/browse/AS7-3199?page=com.atlassian.jira.plugin.s... ]
Ondrej Zizka commented on AS7-3199:
-----------------------------------
Pavel, this is a workaround for community, for cases when someone simply deploys an app to AS 7 and it fails deploying.
Of course I'd rather see RestEasy fixed. Not sure why Bill says it's low priority. Invite folks around you to vote on RESTEASY-650 :)
> RESTEasy: Can't deploy WebApp if more than one subclass of javax.ws.rs.Application is present
> ---------------------------------------------------------------------------------------------
>
> Key: AS7-3199
> URL: https://issues.jboss.org/browse/AS7-3199
> Project: Application Server 7
> Issue Type: Bug
> Components: REST
> Affects Versions: 7.1.0.CR1b
> Reporter: Pavel Janousek
> Attachments: ExampleJAXRS.war
>
>
> If I packed WAR WebApp with more that one subclass of javax.ws.rs.Application, deployment fails with "JBAS011232: Only one JAX-RS Application Class allowed."
> This is not correct because it is against JAX-RS 1.1. specs where invalid situation (in section 2.3.2) is only when "It is a n error for
> more than one application to be deployed +at the same effective servlet mapping+".
> If you have any objections, please compare to reference JEE6 and JAX-RS implementation represented by the GlassFish Prelude 3.1.1 application server with already +fully JEE6 platform support+.
--
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-6605) Replicating JNDI tree to another server
by Miroslav Novak (JIRA)
Miroslav Novak created AS7-6605:
-----------------------------------
Summary: Replicating JNDI tree to another server
Key: AS7-6605
URL: https://issues.jboss.org/browse/AS7-6605
Project: Application Server 7
Issue Type: Feature Request
Components: Naming
Affects Versions: 7.1.2.Final (EAP)
Reporter: Miroslav Novak
Assignee: Eduardo Martins
Priority: Critical
Fix For: 7.2.0.CR1
Description of problem:
This use case is taken from one of our user which we were able to handle using HA-JNDI in EAP 5:
1. JMS Client will create Context with two URL (node1, node2) (java.naming.provider.url property)
2. For some reason client is connected to node2 first which will have no JMS admin objects registered in JNDI (this happens when this node is configured as HornetQ backup)
3. Node2 has replicated JNDI tree from node1. So connection factory will connect client to node1 and queue/topics are deployed on node1.
Can be this functionality provided in EAP 6, please?
--
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