May 2009 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JBBOOT-63) Fix Generics on org.jboss.bootstrap.spi.Bootstrap

by Andrew Lee Rubinger (JIRA)

Fix Generics on org.jboss.bootstrap.spi.Bootstrap ------------------------------------------------- Key: JBBOOT-63 URL: https://jira.jboss.org/jira/browse/JBBOOT-63 Project: JBoss Bootstrap Issue Type: Task Components: impl-as, impl-base, impl-mc, spi, spi-as Reporter: Andrew Lee Rubinger Assignee: Andrew Lee Rubinger Fix For: 0.1.2 Presently the Bootstrap start/prepareShutdown/shutdown methods take a: Server<K, T> ...where: <K extends Server<K, T>, T extends ServerConfig<T>> ...really they need to take a "K" directly. AbstractServer will need some additional support so it may pass "this" to be represented as type K. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 12 months

1
1
0 / 0

[JBoss JIRA] Created: (JBAS-6853) Pull the ServiceBindingManager out of the bootstrap

by Brian Stansberry (JIRA)

Pull the ServiceBindingManager out of the bootstrap --------------------------------------------------- Key: JBAS-6853 URL: https://jira.jboss.org/jira/browse/JBAS-6853 Project: JBoss Application Server Issue Type: Task Security Level: Public (Everyone can see) Components: ProfileService Reporter: Brian Stansberry Assignee: Brian Stansberry Fix For: JBossAS-5.1.0.GA It needs to deploy before conf/jboss-service.xml, but leaving it in the bootstrap essentially makes the SBM's ManagedObject's read-only, which is no good. So, deploy it as a subprofile before the subprofile that include conf/jboss-service.xml. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 12 months

1
2
0 / 0

[JBoss JIRA] Created: (JBRULES-2082) support for delete/modify in changesets

by Jaroslaw Kijanowski (JIRA)

support for delete/modify in changesets --------------------------------------- Key: JBRULES-2082 URL: https://jira.jboss.org/jira/browse/JBRULES-2082 Project: JBoss Drools Issue Type: Feature Request Security Level: Public (Everyone can see) Components: drools-core Affects Versions: 5.0.0.GA Reporter: Jaroslaw Kijanowski Assignee: Mark Proctor changeset supports only the "add" operation, the docs state that remove/modify will be added. Creating jira to track this. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 12 months

1
0
0 / 0

[JBoss JIRA] Created: (JBCL-101) BaseClassLoader.checkCacheAndBlackList leads to CNFEs

by Brian Stansberry (JIRA)

BaseClassLoader.checkCacheAndBlackList leads to CNFEs ----------------------------------------------------- Key: JBCL-101 URL: https://jira.jboss.org/jira/browse/JBCL-101 Project: JBoss ClassLoader Issue Type: Bug Components: ClassLoader Reporter: Brian Stansberry Assignee: Brian Stansberry Fix For: 2.0.6.GA Fix for JBCL-100 leads to CNFEs when a scoped classloader is used. Problem is the call to BaseClassLoader.checkCacheAndBlackList calls into BaseClassLoaderDomain.checkClassBlackList, which throws the CNFE if the class isn't meant to be loaded locally. This all happens as part of a loadClass(String, boolean) call, when loadClass is checking for a cached class. At this stage, the CNFE from the blacklist check should not be allowed to propagate is it just means the class isn't available from the cache and the regular classloading logic should be followed. Simple fix is to catch and trace log the CNFE then continue. A more sophisticated/performant fix might be to pass a param into the call to BaseClassLoaderDomain that results in a null return instead of a CNFE. But for now I'm going to stick with the simple fix. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 12 months

1
2
0 / 0

[JBoss JIRA] Created: (JBBOOT-60) Expose KernelDeployments from MCServer

by Andrew Lee Rubinger (JIRA)

Expose KernelDeployments from MCServer -------------------------------------- Key: JBBOOT-60 URL: https://jira.jboss.org/jira/browse/JBBOOT-60 Project: JBoss Bootstrap Issue Type: Feature Request Components: impl-mc, spi-mc Reporter: Andrew Lee Rubinger Assignee: Andrew Lee Rubinger Fix For: 0.1.2 To support legacy behaviour, MCServer must expose: Map<String, KernelDeployment> getDeployments() Add this in and make tests to confirm. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 12 months

1
1
0 / 0

[JBoss JIRA] Created: (JBAS-6860) ManagedConnectionFactoryDeployment should look for both primitive and wrapper type setters before giving up when setting attributes

by Alexey Loubyansky (JIRA)

ManagedConnectionFactoryDeployment should look for both primitive and wrapper type setters before giving up when setting attributes ----------------------------------------------------------------------------------------------------------------------------------- Key: JBAS-6860 URL: https://jira.jboss.org/jira/browse/JBAS-6860 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Components: JCA service Affects Versions: JBossAS-5.1.0.CR1 Reporter: Alexey Loubyansky Assignee: Alexey Loubyansky Fix For: JBossAS-5.1.0.GA This issue popped up after fixing JBAS-6848 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 12 months

1
1
0 / 0

[JBoss JIRA] Created: (EJBTHREE-1580) Clustered SFSB caching fails due to inability to send to cluster

by Brian Stansberry (JIRA)

Clustered SFSB caching fails due to inability to send to cluster ---------------------------------------------------------------- Key: EJBTHREE-1580 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1580 Project: EJB 3.0 Issue Type: Bug Components: Clustering, core Reporter: Brian Stansberry Assignee: Brian Stansberry Fix For: 1.0.0-CR1 Andrew found an intermittent failure on an testsuite run; see the ScopedExtendedPersistenceUnitTestCase failures at http://jboss.hudson.alrubinger.com/job/EJB3_Plugin_AS_TRUNK/203/testReport/ . Relevant part of the failure trace in each of the failed tests is: Caused by: org.jboss.cache.lock.TimeoutException: State retrieval timed out waiting for flush unblock. at org.jboss.cache.RPCManagerImpl.callRemoteMethods(RPCManagerImpl.java:455) at org.jboss.cache.RPCManagerImpl.callRemoteMethods(RPCManagerImpl.java:432) at org.jboss.cache.RPCManagerImpl.callRemoteMethods(RPCManagerImpl.java:437) at org.jboss.cache.interceptors.BaseRpcInterceptor.replicateCall(BaseRpcInterceptor.java:161) at org.jboss.cache.interceptors.BaseRpcInterceptor.replicateCall(BaseRpcInterceptor.java:135) at org.jboss.cache.interceptors.BaseRpcInterceptor.replicateCall(BaseRpcInterceptor.java:107) at org.jboss.cache.interceptors.ReplicationInterceptor.handleCrudMethod(ReplicationInterceptor.java:160) at org.jboss.cache.interceptors.ReplicationInterceptor.visitPutKeyValueCommand(ReplicationInterceptor.java:107) at org.jboss.cache.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:100) at org.jboss.cache.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:116) at org.jboss.cache.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:131) at org.jboss.cache.commands.AbstractVisitor.visitPutKeyValueCommand(AbstractVisitor.java:65) at org.jboss.cache.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:100) at org.jboss.cache.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:116) at org.jboss.cache.interceptors.TxInterceptor.attachGtxAndPassUpChain(TxInterceptor.java:284) at org.jboss.cache.interceptors.TxInterceptor.handleDefault(TxInterceptor.java:271) at org.jboss.cache.commands.AbstractVisitor.visitPutKeyValueCommand(AbstractVisitor.java:65) at org.jboss.cache.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:100) at org.jboss.cache.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:116) at org.jboss.cache.interceptors.CacheMgmtInterceptor.visitPutKeyValueCommand(CacheMgmtInterceptor.java:119) at org.jboss.cache.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:100) at org.jboss.cache.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:116) at org.jboss.cache.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:178) at org.jboss.cache.interceptors.InvocationContextInterceptor.visitPutKeyValueCommand(InvocationContextInterceptor.java:82) at org.jboss.cache.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:100) at org.jboss.cache.interceptors.InterceptorChain.invoke(InterceptorChain.java:265) at org.jboss.cache.invocation.CacheInvocationDelegate.put(CacheInvocationDelegate.java:560) at org.jboss.ha.cachemanager.CacheManagerManagedCache.put(CacheManagerManagedCache.java:285) at org.jboss.ejb3.cache.tree.StatefulTreeCache.putInCache(StatefulTreeCache.java:511) at org.jboss.ejb3.cache.tree.StatefulTreeCache.create(StatefulTreeCache.java:123) ... 70 more This is really more of a JBC or JGroups issue, but I'm raising it here as what appears to have been a failure during the cache startup phase did not result in a deployment failure of the target bean. Need to understand why not. I'm opening a thread on jbosscache-dev(a)lists.jboss.org to discuss the underlying JBC issue. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 12 months

3
6
0 / 0

[JBoss JIRA] Created: (EJBTHREE-1818) Embedded should not impose version range constraints

by Carlo de Wolf (JIRA)

Embedded should not impose version range constraints ---------------------------------------------------- Key: EJBTHREE-1818 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1818 Project: EJB 3.0 Issue Type: Bug Components: embedded Reporter: Carlo de Wolf Assignee: Carlo de Wolf Fix For: embedded-1.0.0-alpha-2 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 12 months

1
1
0 / 0

[JBoss JIRA] Created: (EJBTHREE-1816) Undeployment of EJBs fails because Ejb3Registrar is already undeployed

by Carlo de Wolf (JIRA)

Undeployment of EJBs fails because Ejb3Registrar is already undeployed ---------------------------------------------------------------------- Key: EJBTHREE-1816 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1816 Project: EJB 3.0 Issue Type: Bug Components: embedded Reporter: Carlo de Wolf Assignee: Carlo de Wolf Fix For: embedded-1.0.0-alpha-2 08:18:14,362 INFO [SessionSpecContainer] Stopping jboss.j2ee:jar=tests-classes,name=GreeterBean,service=EJB3 08:18:14,362 WARN [StartStopLifecycleAction] Error during stop for jboss.j2ee:jar=tests-classes,name=GreeterBean,service=EJB3 org.jboss.ejb3.common.registrar.spi.NotBoundException: Could not retrieve Ejb3Registrar as a registrar implementation has not yet been bound. at org.jboss.ejb3.common.registrar.spi.Ejb3RegistrarLocator.locateRegistrar(Ejb3RegistrarLocator.java:85) at org.jboss.ejb3.session.SessionContainer.getJndiRegistrar(SessionContainer.java:319) at org.jboss.ejb3.session.SessionContainer.lockedStop(SessionContainer.java:239) at org.jboss.ejb3.session.SessionSpecContainer.lockedStop(SessionSpecContainer.java:600) at org.jboss.ejb3.stateless.StatelessContainer.lockedStop(StatelessContainer.java:276) at org.jboss.ejb3.EJBContainer.stop(EJBContainer.java:923) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 12 months

1
3
0 / 0

[JBoss JIRA] Created: (JGRP-659) Merge and UNICAST sequencing problem

by Vladimir Blagojevic (JIRA)

Merge and UNICAST sequencing problem ------------------------------------ Key: JGRP-659 URL: http://jira.jboss.com/jira/browse/JGRP-659 Project: JGroups Issue Type: Bug Affects Versions: 2.6, 2.5, 2.4 Reporter: Vladimir Blagojevic Assigned To: Bela Ban The problem is related to trashing of connection table in UNICAST during merge. Consider following scenario: There are 4 nodes in a cluster A,B,C, and D. After network split we have two islands A,B and C,D. When the network healing starts eventually MergeView gets installed in both islands. MergeView installation causes trashing of UNICAST connection table [1]. However if we have a scenario where MergeView gets installed in A,B island at time T and it gets installed in island C,D at time T+N msec and a node from island A,B sends a unicast message in this N msec time window then we'll run into problems with unicast sequencing at C and D. Why? Because next message coming from island A,B into C,D will be will with sequence number > 1 and sequencing in UNICAST of C,D after connection trashing (from merge) expects starting sequence of 1. This causes UNICAST in C and/or D to wait forever for missing messages. Final outcome is thus that no more unicast message coming from A and/or B will ever be delivered at C and/or D! [1]http://jira.jboss.com/jira/browse/JGRP-348 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 12 months

3
16
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira May 2009