March 2009 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (SECURITY-386) PolicyRegistration register policy configuration

by Anil Saldhana (JIRA)

PolicyRegistration register policy configuration ------------------------------------------------ Key: SECURITY-386 URL: https://jira.jboss.org/jira/browse/SECURITY-386 Project: JBoss Security and Identity Management Issue Type: Feature Request Security Level: Public (Everyone can see) Components: JBossSX, Security SPI Affects Versions: 2.0.3.GA Reporter: Anil Saldhana Assignee: Anil Saldhana Fix For: 2.0.3.SP1, 2.1.0.alpha1 Add a new method to PolicyRegistration to register a policy config with a predetermined configuration model for xacml/acl. -- 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

15 years, 10 months

1
1
0 / 0

[JBoss JIRA] Created: (JGRP-935) NAKACK/UNICAST: replace locks with AtomicBoolean variables

by Bela Ban (JIRA)

NAKACK/UNICAST: replace locks with AtomicBoolean variables ---------------------------------------------------------- Key: JGRP-935 URL: https://jira.jboss.org/jira/browse/JGRP-935 Project: JGroups Issue Type: Feature Request Reporter: Bela Ban Assignee: Bela Ban Fix For: 2.8 Instead of acquiring a lock on the sender window of a message, we try to set an AtomicBoolean var in a CAS operation. Whoever succeeds in setting the var, continues to remove as many messages as possible. Everybody else returns to the thread pool. The {setting of the AtomicBoolean var and the removal} and {addition} of messages are atomic with respect to each other, ie. the NakreceiverWindow.remove() method has a lock (also to be acquired by add()) when removing a message and setting the AtomicBoolean to false if no message could be removed. MOTIVATION: we don't need AtomicBoolean vars *and* locks. Removing locks should result in a small speed improvement -- 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

15 years, 10 months

1
1
0 / 0

[JBoss JIRA] Created: (JGRP-933) NAKACK/UNICAST: eager lock releasing not respected

by Bela Ban (JIRA)

NAKACK/UNICAST: eager lock releasing not respected -------------------------------------------------- Key: JGRP-933 URL: https://jira.jboss.org/jira/browse/JGRP-933 Project: JGroups Issue Type: Bug Reporter: Bela Ban Assignee: Bela Ban Fix For: 2.9 In both NAKACK and UNICAST, we have atomic booleans, which are consulted before trying to acquire the lock. So if a lock is released eagerly in a ProtocolStack.down() call, although the lock is released, the atomic var isn't, and so subsequent threads will still not be able to process different messages. A simple solution would be to release the lock *and* the atomic var in down(). OTOH, we should see whether we can use either locks or atomic vars, but not *both*. This will need to be redesigned anyway with scopes in place (https://jira.jboss.org/jira/browse/JGRP-822). -- 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

15 years, 10 months

1
4
0 / 0

[JBoss JIRA] Created: (JGRP-934) NAKACK/UNICAST: atomic boolean vars might lead to message not getting processed immediately

by Bela Ban (JIRA)

NAKACK/UNICAST: atomic boolean vars might lead to message not getting processed immediately ------------------------------------------------------------------------------------------- Key: JGRP-934 URL: https://jira.jboss.org/jira/browse/JGRP-934 Project: JGroups Issue Type: Bug Reporter: Bela Ban Assignee: Bela Ban Priority: Minor Fix For: 2.9 When we have a thread T1 adding a message and T2 removing them, the following situation might occur: - T2 removes a null message - T2 terminates remove loop - T1 adds message M1 and tries to set the atomic var to true, result is false - T2 sets the atomic boolean var from true to false - T1 returns - T2 returns ==> M1 is not getting processed until the next thread dlivers a message ! This is a very rare case, but still needs to be fixed, maybe with 2 overlapping atomic vars ? -- 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

15 years, 10 months

1
3
0 / 0

[JBoss JIRA] Created: (JBSER-113) Caching of replaced objects doesn't conform to Java serialization specification

by Ron Sigal (JIRA)

Caching of replaced objects doesn't conform to Java serialization specification ------------------------------------------------------------------------------- Key: JBSER-113 URL: https://jira.jboss.org/jira/browse/JBSER-113 Project: JBoss Serialization Issue Type: Bug Affects Versions: 1.0.3 GA Reporter: Ron Sigal Assignee: Ron Sigal Fix For: 1.1.0 Beta The Java serialization spec gives the following steps in serialization: 4. If the object has been previously replaced, as described in Step 8, write the handle of the replacement to the stream and writeObject returns. ... 8. a. .... b. ... If the original object was replaced by either one or both steps above, the mapping from the original object to the replacement is recorded for later use in Step 4. Then, Steps 3 through 7 are repeated on the new object. But JBossSerialization does this: * Apply all the replacements * If the replacement object has already been written, write its "handle". I used to think this was just an efficiency issue (why do the replacement code on an object the second time it gets processed), but one of the JBossMarshalling tests shows that there is an actual semantic difference: ArrayList<Object> testList = new ArrayList<Object>(); testList = Collections.unmodifiableList(testList); marshaller.writeObject(testList); marshaller.writeObject(testList); assertSame(unmarshaller.readObject(), unmarshaller.readObject()); The assertion will fail with JBossSerialization because Collections.unmodifiableList() returns an instance of static class UnmodifiableRandomAccessList<E> extends UnmodifiableList<E> implements RandomAccess { private Object writeReplace() { return new UnmodifiableList<E>(list); } } JBossSerialization applies UnmodifiableRandomAccessList.writeReplace() during each call to marshaller.writeObject(), so two different copies of testList get written. But in Java serialization, the second call would see that the object has already been written and a handle would get written. -- 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

15 years, 10 months

1
0
0 / 0

[JBoss JIRA] Updated: (JBAS-6535) java.lang.LinkageErrors seen during start of JBoss AS 5.1 with admin-console.war deployed

by Shelly McGowan (JIRA)

[ https://jira.jboss.org/jira/browse/JBAS-6535?page=com.atlassian.jira.plug... ] Shelly McGowan updated JBAS-6535: --------------------------------- Fix Version/s: JBossAS-5.1.0.CR1 > java.lang.LinkageErrors seen during start of JBoss AS 5.1 with admin-console.war deployed > ----------------------------------------------------------------------------------------- > > Key: JBAS-6535 > URL: https://jira.jboss.org/jira/browse/JBAS-6535 > Project: JBoss Application Server > Issue Type: Bug > Security Level: Public(Everyone can see) > Environment: JBoss AS Branch_5_x r84532, embjopr r162 > Reporter: Shelly McGowan > Assignee: Darran Lofthouse > Fix For: JBossAS-5.1.0.CR1 > > > During the inialization of the administration console, the rhq-platform-plugin gets loaded, searches jaxb.properties for a JAXB implementation and finds jaxb-impl.jar from $JBOSS_HOME/lib > 2009-02-20 15:20:41,594 INFO [org.jboss.on.embedded.BootstrapAction] (main) Bootstrapping Administration Console v1.1.1-SNAPSHOT... > 2009-02-20 15:20:41,594 DEBUG [org.jboss.on.embedded.BootstrapAction] (main) Reconfiguring JDK logging... > 2009-02-20 15:20:41,617 DEBUG [org.jboss.on.embedded.BootstrapAction] (main) Configuring Mock Scenario Loader... > 2009-02-20 15:20:41,618 INFO [org.rhq.core.pc.PluginContainer] (main) Initializing Plugin Container v1.2.0-SNAPSHOT... > 2009-02-20 15:20:41,723 DEBUG [org.rhq.core.pc.PluginContainer] (main) Starting and configuring container service: PluginManager > 2009-02-20 15:20:41,737 DEBUG [org.rhq.core.pc.plugin.PluginManager] (main) Plugin found at: jndi:/localhost/admin-console/plugins/rhq-platform-plugin-1.2.0-SNAPSHOT.jar > 2009-02-20 15:20:41,741 DEBUG [org.rhq.core.clientapi.descriptor.AgentPluginDescriptorUtil] (main) Loading plugin descriptor from plugin jar at [jndi:/localhost/admin-console/plugins/rhq-platform-plugin-1.2.0-SNAPSHOT.jar]... > 2009-02-20 15:20:41,741 FINE [javax.xml.bind] (main) Searching jaxb.properties > 2009-02-20 15:20:41,742 FINE [javax.xml.bind] (main) Searching the system property > 2009-02-20 15:20:41,742 FINE [javax.xml.bind] (main) Searching META-INF/services > 2009-02-20 15:20:41,743 FINE [javax.xml.bind] (main) Trying to load com.sun.xml.bind.v2.ContextFactory > 2009-02-20 15:20:41,744 FINE [javax.xml.bind] (main) loaded com.sun.xml.bind.v2.ContextFactory from vfszip:/home/smcgowan2/workspace/Branch_5_x/build/output/jboss-5.1.0.Beta1/lib/jaxb-impl.jar/com/sun/xml/bind/v2/ContextFactory.class > 2009-02-20 15:20:41,748 FINE [com.sun.xml.bind.v2.ContextFactory] (main) Property com.sun.xml.bind.XmlAccessorFactoryis not active. Using JAXB's implementation > 2009-02-20 15:20:41,947 FINE [com.sun.xml.bind.v2.runtime.reflect.opt.OptimizedAccessorFactory] (main) Using optimized Accessor for protected org.rhq.core.clientapi.descriptor.plugin.Version org.rhq.core.clientapi.descriptor.plugin.ResourceDescriptor.version > : > : > Next, while loading jopr-jboss-as-5-plugin, the same seach occurs but this time loading the class results in an exception: > 2009-02-20 15:20:44,006 DEBUG [org.rhq.core.pc.plugin.PluginManager] (main) Loading independent plugin [JBossAS5] from URL: jndi:/localhost/admin-console/plugins/jopr-jboss-as-5-plugin-2.2.0-SNAPSHOT.jar > 2009-02-20 15:20:44,006 DEBUG [org.rhq.core.pc.plugin.PluginManager] (main) Loading plugin from: jndi:/localhost/admin-console/plugins/jopr-jboss-as-5-plugin-2.2.0-SNAPSHOT.jar > 2009-02-20 15:20:44,026 DEBUG [org.rhq.core.pc.plugin.PluginDescriptorLoader] (main) Created classloader for plugin [jndi:/localhost/admin-console/plugins/jopr-jboss-as-5-plugin-2.2.0-SNAPSHOT.jar] > 2009-02-20 15:20:44,026 DEBUG [org.rhq.core.clientapi.descriptor.AgentPluginDescriptorUtil] (main) Loading plugin descriptor from plugin jar at [jndi:/localhost/admin-console/plugins/jopr-jboss-as-5-plugin-2.2.0-SNAPSHOT.jar]... > 2009-02-20 15:20:44,026 FINE [javax.xml.bind] (main) Searching jaxb.properties > 2009-02-20 15:20:44,027 FINE [javax.xml.bind] (main) Searching the system property > 2009-02-20 15:20:44,027 FINE [javax.xml.bind] (main) Searching META-INF/services > 2009-02-20 15:20:44,027 FINE [javax.xml.bind] (main) Trying to load com.sun.xml.bind.v2.ContextFactory > 2009-02-20 15:20:44,028 FINE [javax.xml.bind] (main) loaded com.sun.xml.bind.v2.ContextFactory from vfszip:/home/smcgowan2/workspace/Branch_5_x/build/output/jboss-5.1.0.Beta1/lib/jaxb-impl.jar/com/sun/xml/bind/v2/ContextFactory.class > 2009-02-20 15:20:44,029 FINE [com.sun.xml.bind.v2.ContextFactory] (main) Property com.sun.xml.bind.XmlAccessorFactoryis not active. Using JAXB's implementation > 2009-02-20 15:20:44,308 FINE [com.sun.xml.bind.v2.runtime.reflect.opt.Injector] (main) Unable to inject org/rhq/core/clientapi/descriptor/plugin/ResourceDescriptor$JaxbAccessorF_version > java.lang.reflect.InvocationTargetException > at sun.reflect.GeneratedMethodAccessor252.invoke(Unknown Source) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:585) > at com.sun.xml.bind.v2.runtime.reflect.opt.Injector.inject(Injector.java:181) > at com.sun.xml.bind.v2.runtime.reflect.opt.Injector.inject(Injector.java:85) > at com.sun.xml.bind.v2.runtime.reflect.opt.AccessorInjector.prepare(AccessorInjector.java:87) > at com.sun.xml.bind.v2.runtime.reflect.opt.OptimizedAccessorFactory.get(OptimizedAccessorFactory.java:165) > at com.sun.xml.bind.v2.runtime.reflect.Accessor$FieldReflection.optimize(Accessor.java:253) > at com.sun.xml.bind.v2.runtime.property.SingleElementNodeProperty.<init>(SingleElementNodeProperty.java:89) > at sun.reflect.GeneratedConstructorAccessor47.newInstance(Unknown Source) > at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27) > at java.lang.reflect.Constructor.newInstance(Constructor.java:494) > at com.sun.xml.bind.v2.runtime.property.PropertyFactory.create(PropertyFactory.java:124) > Caused by: java.lang.LinkageError: duplicate class definition: org/rhq/core/clientapi/descriptor/plugin/ResourceDescriptor$JaxbAccessorF_version > at java.lang.ClassLoader.defineClass1(Native Method) > at java.lang.ClassLoader.defineClass(ClassLoader.java:620) > at java.lang.ClassLoader.defineClass(ClassLoader.java:465) > The server does start. -- 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

15 years, 10 months

1
0
0 / 0

[JBoss JIRA] Created: (EJBTHREE-1773) Allow SFSB proxies to request non-business-method removal

by Andrew Lee Rubinger (JIRA)

Allow SFSB proxies to request non-business-method removal --------------------------------------------------------- Key: EJBTHREE-1773 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1773 Project: EJB 3.0 Issue Type: Task Components: core, proxy Reporter: Andrew Lee Rubinger Assignee: Andrew Lee Rubinger Fix For: 1.1.3 Add support to SessionProxy to enable: Object proxy = jndiContext.lookup("MyBean/remote"); SessionProxy sProxy = (SessionProxy)proxy; sProxy.removeTarget(); Additionally provide support in InvokableContext for the proxy to ask the container for removal. -- 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

15 years, 10 months

1
5
0 / 0

[JBoss JIRA] Created: (JBMESSAGING-1548) Empty Rollback on XA will cause Journal Errors

by Clebert Suconic (JIRA)

Empty Rollback on XA will cause Journal Errors ---------------------------------------------- Key: JBMESSAGING-1548 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1548 Project: JBoss Messaging Issue Type: Bug Reporter: Clebert Suconic Assignee: Clebert Suconic Say you start a XA Transaction, and immediately roll it back (without a prepare record), while using real files. the Journal will throw an exception: BasicTestXA::testEmptyXID will show this situation. (The failing part of the test will be commented out until this is fixed). The same will happen when you have non-persistent messages and rollback without adding a prepare record. Note: Since Rollbacks are supposed to be infrequent, a solution could be to force a prepare if prepare wasn't called. (To be disucssed) -- 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

15 years, 10 months

3
4
0 / 0

[JBoss JIRA] Created: (JBDEPLOY-181) Configurable EventHandler for JAXBDeployer

by Anil Saldhana (JIRA)

Configurable EventHandler for JAXBDeployer ------------------------------------------ Key: JBDEPLOY-181 URL: https://jira.jboss.org/jira/browse/JBDEPLOY-181 Project: JBoss Deployers Issue Type: Sub-task Components: deployer Reporter: Anil Saldhana Assignee: Ales Justin JAXB Unmarshalling can be a b$tch. A simple way to get validation errors during unmarshalling is by setting a custom event handler to the unmarshaller. =========================================== Set the event handler on the unmarshaller which will print out the errors to System.out as follows: um.setEventHandler(new javax.xml.bind.helpers.DefaultValidationEventHandler()); =========================================== So a configurable injection of an Event Handler bean. -- 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

15 years, 10 months

2
2
0 / 0

[JBoss JIRA] Created: (JBDEPLOY-180) Configurable schema for validation

by Anil Saldhana (JIRA)

Configurable schema for validation ---------------------------------- Key: JBDEPLOY-180 URL: https://jira.jboss.org/jira/browse/JBDEPLOY-180 Project: JBoss Deployers Issue Type: Sub-task Components: deployer Reporter: Anil Saldhana Assignee: Ales Justin -- 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

15 years, 10 months

2
3
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira March 2009