May 2007 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JBCACHE-1023) Inject preconfigured JGroups Channel from external implementation

by Bill Middleton (JIRA)

Inject preconfigured JGroups Channel from external implementation ----------------------------------------------------------------- Key: JBCACHE-1023 URL: http://jira.jboss.com/jira/browse/JBCACHE-1023 Project: JBoss Cache Issue Type: Feature Request Security Level: Public (Everyone can see) Components: Clustering Reporter: Bill Middleton Assigned To: Manik Surtani The current cache implementation contains and manages its own JGroups Channel. It would be useful for those of us using the Cache outside of a full app server to be able to inject our own pre-configured JChannel to the Cache. The original discussions regarding this issue occured on the dev mailing list during April 2007 http://lists.jboss.org/pipermail/jbosscache-dev/2007-April/thread.html A patch is (will be) attached which implements the desired functionality by providing an extra method in the DefaultFactory and a new constructor for CacheImpl. This makes everything "work ok for me", using either multiplexed or "ordinary" JChannels. Unknown if or whether this patch is an appropriate fix. -- 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

19 years, 2 months

4
12
0 / 0

[JBoss JIRA] Created: (JBCACHE-1050) CacheImpl.getInterceptorChain() throws NPE if invoked before create()

by Brian Stansberry (JIRA)

CacheImpl.getInterceptorChain() throws NPE if invoked before create() --------------------------------------------------------------------- Key: JBCACHE-1050 URL: http://jira.jboss.com/jira/browse/JBCACHE-1050 Project: JBoss Cache Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 2.0.0.CR1 Reporter: Brian Stansberry Assigned To: Brian Stansberry Priority: Minor Fix For: 2.0.0.CR2 Tries to pass null to Collections.unmodifiableList() which fails Question is should it: 1) Return null. 2) Return an empty list. I think null with a javadoc note that that's what will happen is probably best. -- 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

19 years, 2 months

1
2
0 / 0

[JBoss JIRA] Created: (JBCACHE-1046) CacheImpl.channel should be type Channel

by Brian Stansberry (JIRA)

CacheImpl.channel should be type Channel ---------------------------------------- Key: JBCACHE-1046 URL: http://jira.jboss.com/jira/browse/JBCACHE-1046 Project: JBoss Cache Issue Type: Sub-task Security Level: Public (Everyone can see) Affects Versions: 2.0.0.CR1 Reporter: Brian Stansberry Assigned To: Manik Surtani Priority: Minor Fix For: 2.0.0.CR2 CacheImpl.channel is of the concrete type JChannel rather than the Channel interface. JBC doesn't use any methods outside of the interface, so there is no need to use the concrete type. This is more significant now that RuntimeConfig will expose a setter for the channel. -- 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

19 years, 2 months

1
2
0 / 0

[JBoss JIRA] Created: (JBCACHE-1044) RuntimeConfig's channel factory should be type ChannelFactory not JChannelFactoryMBean

by Brian Stansberry (JIRA)

RuntimeConfig's channel factory should be type ChannelFactory not JChannelFactoryMBean -------------------------------------------------------------------------------------- Key: JBCACHE-1044 URL: http://jira.jboss.com/jira/browse/JBCACHE-1044 Project: JBoss Cache Issue Type: Sub-task Security Level: Public (Everyone can see) Components: Clustering Affects Versions: 2.0.0.CR1 Reporter: Brian Stansberry Assigned To: Brian Stansberry Fix For: 2.0.0.CR2 The org.jgroups.jmx.JChannelFactoryMBean interface is a management interface that wraps an instance of org.jgroups.ChannelFactory. JBC 2.0.0 should be pojo-based and not rely on a JMX server for integration. So, RuntimeConfig.muxChannelFactory should be of type org.jgroups.ChannelFactory. Implications: 1) If the Configuration is built programatically, the program should inject the ChannelFactory or the Channel. XmlConfigurationParser can't do that and will log a WARN if asked to handle the legacy MultiplexerService attribute. 2) If the Configuration is built via an IOC framework, the framework can build the ChannelFactory pojo, and inject it into both the JChannelFactoryMBean and the RuntimeConfig. 3) If the Configuration is built from a -service.xml via a JBoss AS 4.x ServiceController, CacheLegacyJmxWrapper will add a "MultiplexerService" attribute into which the ObjectName of the factory can be injected. This is solely to support the legacy "MultiplexerService" attribute from JBC 1.4.1.x. CacheLegacyJmxWrapper.create() will then invoke an mbean operation on the factory to create the multiplexer channel, and will pass the *Channel* into the RuntimeConfig. Thus CacheLegacyJmxWrapper and superclass CacheJmxWrapper remain as the only classes that deal with JMX operations. #3 above is an obscure use case, since AS 4.x will not work with JBC 2.x if the distributed web session or clustered EJB3 services are running. It would only apply to people who remove those services and want to run their own cache-based service using JBC 2.x. Given that, I'm tempted to drop #3 and just no longer support the legacy "MultiplexerService" attribute. -- 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

19 years, 2 months

1
1
0 / 0

[JBoss JIRA] Created: (JBCACHE-934) Remove JChannelFactory JMX lookup from CacheImpl

by Brian Stansberry (JIRA)

Remove JChannelFactory JMX lookup from CacheImpl ------------------------------------------------ Key: JBCACHE-934 URL: http://jira.jboss.com/jira/browse/JBCACHE-934 Project: JBoss Cache Issue Type: Task Security Level: Public (Everyone can see) Affects Versions: 2.0.0.ALPHA1, 2.0.0.ALPHA2 Reporter: Brian Stansberry Assigned To: Brian Stansberry Fix For: 2.0.0.BETA2 CacheImpl tries to do a JMX lookup of the JChannelFactory. The factory should only be available from the RuntimeConfig -- the CacheImpl should not look it up. Any JMX lookup should be done by a JMX integration layer, i.e. CacheJmxWrapper or CacheLegacyJmxWrapper. With this the MBeanServer property can be removed from RuntimeConfig, as it's only use is for this llokup. -- 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

19 years, 2 months

2
4
0 / 0

[JBoss JIRA] Updated: (JBAOP-265) Aspectize Java array

by Kabir Khan (JIRA)

[ http://jira.jboss.com/jira/browse/JBAOP-265?page=all ] Kabir Khan updated JBAOP-265: ----------------------------- Fix Version/s: 2.1.0.GA (was: 2.0.0.alpha5) > Aspectize Java array > -------------------- > > Key: JBAOP-265 > URL: http://jira.jboss.com/jira/browse/JBAOP-265 > Project: JBoss AOP > Issue Type: Feature Request > Reporter: Ben Wang > Fix For: 2.1.0.GA > > > For AOP, we haven't dealt with Java array. Is it possible to provide interception for array? This is required if we need to instrument Java Collection, for example, since they uses array list for internal fields. -- 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

19 years, 2 months

1
0
0 / 0

[JBoss JIRA] Created: (JBAOP-311) Update tutorial examples to work with jboss retro for jdk 1.4

by Kabir Khan (JIRA)

Update tutorial examples to work with jboss retro for jdk 1.4 ------------------------------------------------------------- Key: JBAOP-311 URL: http://jira.jboss.com/jira/browse/JBAOP-311 Project: JBoss AOP Issue Type: Sub-task Security Level: Public (Everyone can see) Reporter: Kabir Khan Assigned To: Kabir Khan Fix For: 2.0.0.alpha3 -- 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

19 years, 2 months

2
7
0 / 0

[JBoss JIRA] Created: (JBCACHE-1051) Update of expiry time does not work correctly due to Comparable/equals inconsistency in TreeSet

by Elias Ross (JIRA)

Update of expiry time does not work correctly due to Comparable/equals inconsistency in TreeSet ----------------------------------------------------------------------------------------------- Key: JBCACHE-1051 URL: http://jira.jboss.com/jira/browse/JBCACHE-1051 Project: JBoss Cache Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 2.0.0.CR1 Reporter: Elias Ross Assigned To: Manik Surtani Expiry times that change do not override the existing expiry time of an FQN. This is because the update in the TreeSet is being done by adding a new entry with the same FQN but different expiry time. Although this would work in the case of a HashSet, this fails with an ordered set which relies on the ordering of entries to navigate and update entries in the set. -- 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

19 years, 2 months

1
2
0 / 0

[JBoss JIRA] Updated: (JBAS-2315) Create an automated test for JBAS-2314

by Dimitris Andreadis (JIRA)

[ http://jira.jboss.com/jira/browse/JBAS-2315?page=all ] Dimitris Andreadis updated JBAS-2315: ------------------------------------- Fix Version/s: JBossAS-4.2.0.GA (was: JBossAS-4.2.1.CR1) The 4.2.0.GA will be retagged so changing the fix version. > Create an automated test for JBAS-2314 > -------------------------------------- > > Key: JBAS-2315 > URL: http://jira.jboss.com/jira/browse/JBAS-2315 > Project: JBoss Application Server > Issue Type: Task > Security Level: Public(Everyone can see) > Components: Web (Tomcat) service > Reporter: Brian Stansberry > Assigned To: Hany Mesha > Priority: Minor > Fix For: JBossAS-4.2.0.GA > > > I currently test the JBAS-2314 fix manually; need to automate. Basically need to add a war to web-sso.ear that has secured resources but no authenticator configured. Test should access the normal sso test war on one server, then the other, and then on the 2nd server access the war w/o authenticator, confirming that no 403 is seen. -- 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

19 years, 2 months

1
0
0 / 0

[JBoss JIRA] Created: (JBAOP-381) Finally Advices

by Flavia Rainone (JIRA)

Finally Advices --------------- Key: JBAOP-381 URL: http://jira.jboss.com/jira/browse/JBAOP-381 Project: JBoss AOP Issue Type: Feature Request Security Level: Public (Everyone can see) Reporter: Flavia Rainone Assigned To: Flavia Rainone Priority: Critical Fix For: 2.0.0.alpha5 We need to implement finally advices for genadvisor mode. Finally advice signature is the annotated-parameters one. We have the following additional rule: - if the advice receives @Return, it must also receives @Thrown as parameter, so the advice can be aware when the return value is not valid Finally will be available on all joinpoint types, because a field read can throw an exception if it is intercepted by an advice. Documentation: - make it clear how finally advices will cause both advice and joinpoint exceptions being ignored - in the tutorial example, create a new section for finally advices with the before/after example augmented (release lock in a finally block) -- 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

19 years, 2 months

1
1
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira May 2007