December 2007 - jboss-jira - Jboss List Archives

[JBoss JIRA] Updated: (JBCACHE-207) Intercept direct access to Nodes

by Manik Surtani (JIRA)

[ http://jira.jboss.com/jira/browse/JBCACHE-207?page=all ] Manik Surtani updated JBCACHE-207: ---------------------------------- Fix Version/s: 2.1.0.GA (was: 2.2.0.GA) > Intercept direct access to Nodes > -------------------------------- > > Key: JBCACHE-207 > URL: http://jira.jboss.com/jira/browse/JBCACHE-207 > Project: JBoss Cache > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Affects Versions: 1.2.3 > Reporter: Bela Ban > Assigned To: Manik Surtani > Fix For: 2.1.0.GA > > > Node.put() currently doesn't pass through an interceptor chain, therefore cache loading, locking, modification recording etc is not provided. > If we want to continue offering navigation via Nodes, we will need to support direct modifications to Nodes. > Idea is to have a (singleton) interceptor chain for *all* nodes and reuse existing interceptors -- 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

18 years

1
0
0 / 0

[JBoss JIRA] Created: (JBAS-4228) Preferred server HASingletonElectionPolicy

by Brian Stansberry (JIRA)

Preferred server HASingletonElectionPolicy ------------------------------------------ Key: JBAS-4228 URL: http://jira.jboss.com/jira/browse/JBAS-4228 Project: JBoss Application Server Issue Type: Feature Request Security Level: Public (Everyone can see) Components: Clustering Reporter: Brian Stansberry Assigned To: Brian Stansberry An HASingletonElectionPolicy impl that allows configurable specification of a "preferred server". If the preferred server is running, it's the master, otherwise the master is deterministically selected based on the standard policy. 1) Determine if you are the preferred server by comparing you node name to the configured "preferred server" value. 2) When you get a view change, check if preferred server is in the view. If yes, and you're the preferred server, become master, otherwise don't. If preferred server is not in view, fall back on the base policy. Have to make sure the mechanism of identifying and matching the "preferred server" is bullet proof (machine names vs. configuration-specified names vs. IP addresses, plus ports.) -- 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

18 years

2
2
0 / 0

[JBoss JIRA] Created: (JBRULES-1110) Rules with 'From' condition with another not using From causes problem

by Arjun Dhar (JIRA)

Rules with 'From' condition with another not using From causes problem ---------------------------------------------------------------------- Key: JBRULES-1110 URL: http://jira.jboss.com/jira/browse/JBRULES-1110 Project: JBoss Rules Issue Type: Bug Security Level: Public (Everyone can see) Components: Decision tables, Reteoo Affects Versions: 4.0.0.GA Environment: Any Reporter: Arjun Dhar Assigned To: Mark Proctor Test case: Write a Rule that uses a From clause and on another object does not use a from clause: example: #From row number: 28 rule "Rules_28" when cntct: Contact(initialized==true) config: BooleanConfiguration(value==true) from meta.getConfiguration(cntct.getClient(), "Param1") pref: Relation(contact==cntct, type=="old") or (eval(false==true) and not Relation(contact==cntct, type=="old")) then System.out.println("Fired 28"); end If All 3 are true: 1. Delete Condition 2 --> Rule fires 2. Delete COnditon 3 (But keep 2) --> Rule fires 3. Keep 2 & 3 (with 1) --> Rule does not fire Whats strage is that conditon 1 does not use from and it works with condition 2 without any problem, but when 2 & 3 are there together the rule does not work. Please see if it is a bug -- 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

18 years

2
5
0 / 0

[JBoss JIRA] Created: (EJBTHREE-1158) Newly persisted entites many-to-one accessors return null.

by Gunnar Grim (JIRA)

Newly persisted entites many-to-one accessors return null. ---------------------------------------------------------- Key: EJBTHREE-1158 URL: http://jira.jboss.com/jira/browse/EJBTHREE-1158 Project: EJB 3.0 Issue Type: Bug Affects Versions: AS 4.2.1.GA Environment: Linux, SuSE 9.3 Reporter: Gunnar Grim After persisting a new entity all accessors for one-to-many relationships are null instead of an empty set. The accessors are tagged with @OneToMany and FetchType.LAZY. The same application behaves correctly on Sun AS 9.1 with toplink. -- 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

18 years

2
1
0 / 0

[JBoss JIRA] Created: (JBAS-4642) Fix org.jboss.test.xml.mbeanserver.XMBean2UnitTestCase

by Dimitris Andreadis (JIRA)

Fix org.jboss.test.xml.mbeanserver.XMBean2UnitTestCase ------------------------------------------------------ Key: JBAS-4642 URL: http://jira.jboss.com/jira/browse/JBAS-4642 Project: JBoss Application Server Issue Type: Sub-task Security Level: Public (Everyone can see) Components: Test Suite Reporter: Dimitris Andreadis Assigned To: Scott M Stark Fix For: JBossAS-5.0.0.Beta3 The error message doesn't look very helpful: testJavaBeanSchemaInitializerInterceptor Failure description expected:<...eanSchemaInitializer[ ]> but was:<...eanSchemaInitializer[]> junit.framework.ComparisonFailure: description expected:<...eanSchemaInitializer[ ]> but was:<...eanSchemaInitializer[]> at org.jboss.test.xml.mbeanserver.XMBean2UnitTestCase.testJavaBeanSchemaInitializerInterceptor(XMBean2UnitTestCase.java:129) log snipet ... 2007-08-28 20:02:49,906 DEBUG [org.jboss.xb.binding.parser.sax.SaxJBossXBParser] http://apache.org/xml/features/validation/dynamic set to: true 2007-08-28 20:02:49,906 DEBUG [org.jboss.xb.binding.parser.sax.SaxJBossXBParser] Using parser: org.apache.xerces.jaxp.SAXParserImpl@c79809, isNamespaceAware: true, isValidating: true, isXIncludeAware: true 2007-08-28 20:02:49,921 DEBUG [org.jboss.xb.binding.parser.sax.SaxJBossXBParser] Created parser: org.apache.xerces.jaxp.SAXParserImpl@1ce784b, isNamespaceAware: true, isValidating: true, isXIncludeAware: true 2007-08-28 20:02:49,921 DEBUG [org.jboss.xb.binding.parser.sax.SaxJBossXBParser] http://xml.org/sax/features/validation set to: true 2007-08-28 20:02:49,921 DEBUG [org.jboss.xb.binding.parser.sax.SaxJBossXBParser] http://xml.org/sax/features/namespaces set to: true 2007-08-28 20:02:49,921 DEBUG [org.jboss.xb.binding.parser.sax.SaxJBossXBParser] http://apache.org/xml/features/validation/dynamic set to: true 2007-08-28 20:02:49,921 DEBUG [org.jboss.xb.binding.parser.sax.SaxJBossXBParser] Using parser: org.apache.xerces.jaxp.SAXParserImpl@1ce784b, isNamespaceAware: true, isValidating: true, isXIncludeAware: true 2007-08-28 20:02:49,968 DEBUG [org.jboss.mx.metadata.xb.DescriptorSupportContainer] addChild, {urn:jboss-test:xmbean:2.0}interceptors,org.jboss.mx.metadata.xb.InterceptorsHolder@9934d4 2007-08-28 20:02:49,968 DEBUG [org.jboss.mx.metadata.xb.ModelMBeanConstructorInfoContainer] addChild, {urn:jboss-test:xmbean:2.0}name,JNDIBindingService 2007-08-28 20:02:49,968 DEBUG [org.jboss.mx.metadata.xb.ModelMBeanConstructorInfoContainer] addChild, {urn:jboss-test:xmbean:2.0}description,The default no-arg constructor 2007-08-28 20:02:49,968 DEBUG [org.jboss.mx.metadata.xb.ModelMBeanAttributeInfoContainer] addChild, access,read-write 2007-08-28 20:02:49,968 DEBUG [org.jboss.mx.metadata.xb.ModelMBeanAttributeInfoContainer] addChild, {urn:jboss-test:xmbean:2.0}description,The root JNDI name of the context the bindings are to be added under 2007-08-28 20:02:49,968 DEBUG [org.jboss.mx.metadata.xb.ModelMBeanAttributeInfoContainer] addChild, {urn:jboss-test:xmbean:2.0}name,RootName 2007-08-28 20:02:49,968 DEBUG [org.jboss.mx.metadata.xb.ModelMBeanAttributeInfoContainer] addChild, {urn:jboss-test:xmbean:2.0}type,java.lang.String 2007-08-28 20:02:49,968 DEBUG [org.jboss.mx.metadata.xb.ModelMBeanAttributeInfoContainer] addChild, access,read-write 2007-08-28 20:02:49,968 DEBUG [org.jboss.mx.metadata.xb.ModelMBeanAttributeInfoContainer] addChild, {urn:jboss-test:xmbean:2.0}description,The JNDI bindings to add under the RootName 2007-08-28 20:02:49,968 DEBUG [org.jboss.mx.metadata.xb.ModelMBeanAttributeInfoContainer] addChild, {urn:jboss-test:xmbean:2.0}name,Bindings 2007-08-28 20:02:49,968 DEBUG [org.jboss.mx.metadata.xb.ModelMBeanAttributeInfoContainer] addChild, {urn:jboss-test:xmbean:2.0}type,org.jboss.naming.JNDIBindings 2007-08-28 20:02:49,968 DEBUG [org.jboss.mx.metadata.xb.ModelMBeanOperationInfoContainer] addChild, impact,ACTION_INFO 2007-08-28 20:02:49,968 DEBUG [org.jboss.mx.metadata.xb.ModelMBeanOperationInfoContainer] addChild, {urn:jboss-test:xmbean:2.0}description,The start lifecycle operation 2007-08-28 20:02:49,968 DEBUG [org.jboss.mx.metadata.xb.ModelMBeanOperationInfoContainer] addChild, {urn:jboss-test:xmbean:2.0}name,start 2007-08-28 20:02:49,968 DEBUG [org.jboss.mx.metadata.xb.ModelMBeanOperationInfoContainer] addChild, {urn:jboss-test:xmbean:2.0}return-type,void 2007-08-28 20:02:49,968 DEBUG [org.jboss.mx.metadata.xb.ModelMBeanOperationInfoContainer] addChild, impact,ACTION_INFO 2007-08-28 20:02:49,968 DEBUG [org.jboss.mx.metadata.xb.ModelMBeanOperationInfoContainer] addChild, {urn:jboss-test:xmbean:2.0}description,The stop lifecycle operation 2007-08-28 20:02:49,968 DEBUG [org.jboss.mx.metadata.xb.ModelMBeanOperationInfoContainer] addChild, {urn:jboss-test:xmbean:2.0}name,stop 2007-08-28 20:02:49,984 DEBUG [org.jboss.mx.metadata.xb.ModelMBeanOperationInfoContainer] addChild, {urn:jboss-test:xmbean:2.0}return-type,void 2007-08-28 20:02:49,984 DEBUG [org.jboss.mx.metadata.xb.ModelMBeanNotificationInfoContainer] addChild, {urn:jboss-test:xmbean:2.0}description,The bind event notification 2007-08-28 20:02:49,984 DEBUG [org.jboss.mx.metadata.xb.ModelMBeanNotificationInfoContainer] addChild, {urn:jboss-test:xmbean:2.0}name,bindEvent 2007-08-28 20:02:50,203 DEBUG [org.jboss.test.xml.mbeanserver.XMBean2UnitTestCase] testJavaBeanSchemaInitializerInterceptor took 750ms 2007-08-28 20:02:50,203 DEBUG [org.jboss.test.xml.mbeanserver.XMBean2UnitTestCase] ==== Stopping testJavaBeanSchemaInitializerInterceptor ==== 2007-08-28 20:02:50,203 DEBUG [org.jboss.test.xml.mbeanserver.XMBean2UnitTestCase] ==== tornDown org.jboss.test.xml.mbeanserver.XMBean2UnitTestCase ==== ... -- 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

18 years

2
7
0 / 0

[JBoss JIRA] Updated: (JBAS-2235) Server Controller Tasks: Throw error if normal shutdown fails

by Dimitris Andreadis (JIRA)

[ http://jira.jboss.com/jira/browse/JBAS-2235?page=all ] Dimitris Andreadis updated JBAS-2235: ------------------------------------- Fix Version/s: JBossAS-5.0.0.CR1 (was: JBossAS-5.0.0.Beta3) > Server Controller Tasks: Throw error if normal shutdown fails > ------------------------------------------------------------- > > Key: JBAS-2235 > URL: http://jira.jboss.com/jira/browse/JBAS-2235 > Project: JBoss Application Server > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Test Suite > Environment: jboss-4.0 tip > Reporter: Ryan Campbell > Assigned To: Martin Vecera > Fix For: JBossAS-5.0.0.CR1 > > Time Spent: 2 hours > Remaining Estimate: 0 minutes > > Currently, when a server fails to respond to a shutdown request, the process is killed and the tests continue. > There should be an error thrown if the server fails to shutdown within the timeout period. -- 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

18 years, 1 month

1
0
0 / 0

[JBoss JIRA] Created: (JBAS-4856) Fix web service issues related to the new metadata model

by Thomas Diesler (JIRA)

Fix web service issues related to the new metadata model -------------------------------------------------------- Key: JBAS-4856 URL: http://jira.jboss.com/jira/browse/JBAS-4856 Project: JBoss Application Server Issue Type: Task Security Level: Public (Everyone can see) Reporter: Thomas Diesler Assigned To: Thomas Diesler Fix For: JBossAS-5.0.0.Beta3 -- 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

18 years, 1 month

1
3
0 / 0

[JBoss JIRA] Resolved: (JBXB-66) XOPMarshaller needs to include the xmime:contentType attribute

by Heiko Braun (JIRA)

[ http://jira.jboss.com/jira/browse/JBXB-66?page=all ] Heiko Braun resolved JBXB-66. ----------------------------- Resolution: Done > XOPMarshaller needs to include the xmime:contentType attribute > -------------------------------------------------------------- > > Key: JBXB-66 > URL: http://jira.jboss.com/jira/browse/JBXB-66 > Project: JBoss XML Binding (JBossXB) > Issue Type: Bug > Reporter: Heiko Braun > Assigned To: Heiko Braun > > It's currently in the branch CR5_4.0.4GA and should be ported to HEAD -- 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

18 years, 1 month

1
0
0 / 0

[JBoss JIRA] Closed: (JBAS-3378) Application Policy (Authentication + Authorization Info) Extendable

by Anil Saldhana (JIRA)

[ http://jira.jboss.com/jira/browse/JBAS-3378?page=all ] Anil Saldhana closed JBAS-3378. ------------------------------- Resolution: Won't Fix This feature is available in JBoss5 going forward. > Application Policy (Authentication + Authorization Info) Extendable > ------------------------------------------------------------------- > > Key: JBAS-3378 > URL: http://jira.jboss.com/jira/browse/JBAS-3378 > Project: JBoss Application Server > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Security > Affects Versions: JBossAS-4.0.4.GA > Reporter: Anil Saldhana > Assigned To: Anil Saldhana > Fix For: JBossAS-4.2.3.GA > > > <policy> > <application-policy name="xyz" extends "abc"> > <authentication> > ... > </authentication> > </application-policy> > </policy> > A configuration that can derive from a different application policy for authentication (and or authorization) information is useful to reduce redundant definition of login modules in various security domain definitions. -- 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

18 years, 1 month

1
0
0 / 0

[JBoss JIRA] Created: (JBAS-5036) Local home create() implementation returns wrong type

by Arto Huusko (JIRA)

Local home create() implementation returns wrong type ----------------------------------------------------- Key: JBAS-5036 URL: http://jira.jboss.com/jira/browse/JBAS-5036 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Components: EJB3 Affects Versions: JBossAS-4.2.1.GA Reporter: Arto Huusko Assigned To: Carlo de Wolf Local home (and presumably remote, too) implementation for EJB 3 sessions creates an object that is an instance of the local *business* interface of the EJB 3 session, and returns that. This is contrary to EJB 3 specification, which says that local home create methods must return an instance of the local interface of the EJB 3 session (as in: not local business interface). The type of the local interface is apparently deduced from the return type of the create method in the local home interface (there is no annotation for it). For beans that follow the specification, this causes a class cast exception when create() is called: the local home interface is specified to return an instance of local interface, but the implementation JBoss supplies creates a instance of local business interface (I presume so, because changing local home to return that works), and then we end up with class cast exception. There is no workaround other than going against specification in code: define local home interface to return instance of local business interface. This simple session, which as far as I can see is exactly according to EJB 3 spec, illustrates the problem, and does not work on JBoss 4.2.1.GA: -- @javax.ejb.Stateless(name="Stateless") @javax.ejb.LocalHome(StatelessHome.class) @javax.ejb.Local({StatelessLocal.class}) public class StatelessBean implements StatelessLocal { public void ejbCreate() {} } -- public interface StatelessLocal {} -- public interface StatelessHome extends javax.ejb.EJBLocalHome { public StatelessLocal21 create() throws javax.ejb.CreateException;} -- public interface StatelessLocal21 extends javax.ejb.EJBLocalObject, StatelessLocal {} -- When home is looked up, and create is called, the result is: java.lang.ClassCastException: $Proxy271 cannot be cast to StatelessLocal21 -- 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

18 years, 1 month

3
7
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 December 2007