January 2008 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JBAS-3925) Unification of transports to Remoting 2.2.0

by Scott M Stark (JIRA)

Unification of transports to Remoting 2.2.0 ------------------------------------------- Key: JBAS-3925 URL: http://jira.jboss.com/jira/browse/JBAS-3925 Project: JBoss Application Server Issue Type: Task Security Level: Public (Everyone can see) Components: Clustering, EJB2, EJB3, JB5-Messaging, Naming, Remoting Affects Versions: JBossAS-5.0.0.Beta1 Reporter: Scott M Stark Assigned To: Brian Stansberry Fix For: JBossAS-5.0.0.Beta2 We need to drop the legacy transports and align on remoting implementations based on the 2.2.0 release of remoting. This task is a container for the subtasks needed to accomplish this. -- 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

15 years, 9 months

3
6
0 / 0

[JBoss JIRA] Created: (JBRULES-1434) Drools Spring

by Mark Proctor (JIRA)

Drools Spring ------------- Key: JBRULES-1434 URL: http://jira.jboss.com/jira/browse/JBRULES-1434 Project: JBoss Drools Issue Type: Feature Request Security Level: Public (Everyone can see) Components: All Reporter: Mark Proctor Fix For: FUTURE -- 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

15 years, 9 months

4
7
0 / 0

[JBoss JIRA] Created: (JBRULES-1398) Document constraint weighting in the solver manual

by Geoffrey De Smet (JIRA)

Document constraint weighting in the solver manual -------------------------------------------------- Key: JBRULES-1398 URL: http://jira.jboss.com/jira/browse/JBRULES-1398 Project: JBoss Drools Issue Type: Task Security Level: Public (Everyone can see) Components: Solver Reporter: Geoffrey De Smet Assigned To: Geoffrey De Smet Priority: Optional use examination examples? -- 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

15 years, 10 months

1
2
0 / 0

[JBoss JIRA] Created: (JBJMX-109) loaderRepositoryClass="..." seems to be useless

by David Schlotfeldt (JIRA)

loaderRepositoryClass="..." seems to be useless ----------------------------------------------- Key: JBJMX-109 URL: http://jira.jboss.com/jira/browse/JBJMX-109 Project: JBoss JMX Issue Type: Feature Request Affects Versions: JBossAS-4.0.0 Reporter: David Schlotfeldt This isn't exactly an error, and maybe we just aren't suppose to use it, but DTD and documentation says we can specify an implementation of org.jboss.mx.loading.LoaderRepository to use in many xml files, such as jboss-app.xml, with the loaderRepositoryClass attribute. Well even though you can -- you can't. You can't because a number of classes including UnifiedClassLoader cast objects directly to UnifiedLoaderRepository3 instead of LoaderRepository. Which means your implementations actually need to extend UnifiedLoaderRepository3. Also HeirarchicalLoaderRepository3 is not flexible. You would think it would be possible to create a hierarchy of LoaderRepositorys but you can't. This is because it expects its parent to be a UnifiedLoaderRepository3 -- okay fine, whatever. So you should at least be able a HeirarchicalLoaderRepository3 object as a parent to another HeirarchicalLoaderRepository3 object since UnifiedLoaderRepository3 extends UnifiedLoaderRepository3. You can't . Why? Well because I am PRETTY SURE that HeirarchicalLoaderRepository3.getPackageClassLoaders(..) returns a Set of PkgClassLoader objects while UnifiedLoaderRepository3 .getPackageClassLoaders(..) (the method it overrides!) returns a Set of RepositoryClassLoader objects. When HeirarchicalLoaderRepository3 calls getPackageClassLoaders(...) on its parent repository it casts items to RepositoryClassLoader , since that is what UnifiedLoaderRepository3 returns. This means if you make HeirarchicalLoaderRepository3 have a parent of type HeirarchicalLoaderRepository3 you will get a ClassCastException since.. well.. a PkgClassLoader isn't a RepositoryClassLoader class. LoadMgr3 is actually programmed to expect the Set returned by getPackageClassLoaders(...) to be both RepositoryClassLoader and PkgClassLoader objects probably because of this. I COMPLETELY understand how code gets messy through time but this code should really be cleaned up -- especially if we are allowing users to specify a LoaderRepository implementation. As it stands the loaderRepositoryClass attribute SEEMS to be useless to specify your own implementation. -- 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

15 years, 10 months

3
2
0 / 0

[JBoss JIRA] Created: (JASSIST-39) failure to compile an instance method which invokes a static method in a different class and both methods have the same return type, name and argument types

by twieger (JIRA)

failure to compile an instance method which invokes a static method in a different class and both methods have the same return type, name and argument types ------------------------------------------------------------------------------------------------------------------------------------------------------------ Key: JASSIST-39 URL: http://jira.jboss.com/jira/browse/JASSIST-39 Project: Javassist Issue Type: Bug Reporter: twieger Assigned To: Shigeru Chiba The testcase below demonstrates the problem. The first invocation of CtNewMethod#make works, the second one fails. It looks like the problem is related with MemberResolver#lookupMethod. The check to enable the creation of a recursively called method is not precise enough. It actually succeeds, although the current method is an instance method, and the method which shall be invoked is a static method. ========================================== package experimental; import javassist.CannotCompileException; import javassist.ClassPool; import javassist.CtClass; import javassist.CtNewMethod; import org.testng.annotations.Test; public class TestJavaAssist { @Test public void testJavaAssist() throws CannotCompileException { ClassPool classPool = new ClassPool(); classPool.appendSystemPath(); CtClass ctClass = classPool.makeClass("Test"); CtNewMethod.make("public String foox(){return experimental.TestJavaAssist.foo();}", ctClass); CtNewMethod.make("public String foo(){return experimental.TestJavaAssist.foo();}", ctClass); } public static final String foo() { return "foo"; } } -- 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

15 years, 10 months

2
1
0 / 0

[JBoss JIRA] Created: (JBAS-3927) Update naming service to using remoting based proxy

by Scott M Stark (JIRA)

Update naming service to using remoting based proxy --------------------------------------------------- Key: JBAS-3927 URL: http://jira.jboss.com/jira/browse/JBAS-3927 Project: JBoss Application Server Issue Type: Sub-task Security Level: Public (Everyone can see) Components: Naming, Remoting Reporter: Scott M Stark Assigned To: Scott M Stark The integration of the NamingService with the legacy detached invoker needs to be factored out and replaced with a remoting based proxy. -- 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

15 years, 10 months

3
4
0 / 0

[JBoss JIRA] Created: (JBPORTAL-1793) Isolate management code in a management sub module for the identity module

by Julien Viet (JIRA)

Isolate management code in a management sub module for the identity module -------------------------------------------------------------------------- Key: JBPORTAL-1793 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1793 Project: JBoss Portal Issue Type: Task Security Level: Public (Everyone can see) Components: Portal Identity Affects Versions: Identity-1.0 Reporter: Julien Viet Assigned To: Boleslaw Dawidowicz Fix For: Identity-1.1 -- 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

15 years, 10 months

2
1
0 / 0

[JBoss JIRA] Created: (JBPORTAL-1685) Maven migration

by Julien Viet (JIRA)

Maven migration --------------- Key: JBPORTAL-1685 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1685 Project: JBoss Portal Issue Type: Task Security Level: Public (Everyone can see) Reporter: Julien Viet Assigned To: Wesley Hales Fix For: 2.8 Final -- 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

15 years, 10 months

3
2
0 / 0

[JBoss JIRA] Created: (JBPORTAL-1707) New UserModule/RoleModule finders

by Andrew Oliver (JIRA)

New UserModule/RoleModule finders --------------------------------- Key: JBPORTAL-1707 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1707 Project: JBoss Portal Issue Type: Feature Request Security Level: Public (Everyone can see) Components: Portal Security Affects Versions: 2.6.1 Final Reporter: Andrew Oliver Assigned To: Julien Viet While working with clients using the portal API some efficiency issues with regards to finders have become apparent: It is presently possible to find users having a role by calling MembershipModule.getUsers(role). However it is not possible to get a list of users with a set of roles, a list of users who do NOT have a role or set of roles. (there are ways in both HQL and LDAP to construct each type of query). I suggest something similar to hibernate conditions. MembershipModule.getUsers().addCondition( Condition.and( Condition.not(roleSet), Condition.with(roleSet) ) ) this would result in roughly: from Users where roles in (:roleSet) and roles not in (:roleSet2) and something like (& (|(role=roleName)(role=roleName) ) (&(!role=roleName)(!role=roleName) ) ) in LDAP the attribute name can be based on the type. As it stands you have to do something like: try { Role roleApproved = rolemodule.findRoleByName("approved"); Role roleUsers = rolemodule.findRoleByName("User"); //todo create transient wrapper set. Set users = membership.getUsers(roleUsers); dirtyStinkyHackToGetAroundPortalAPIBugACO(users); System.err.println("Total number of users with User Role : " + users.size() ); Set temp = new HashSet(); temp = dirtyStinkyHackToGetAroundPortalAPIBugACO(users); //because the hibernate set doesn't have removeall users = temp; Set usersApproved = membership.getUsers(roleApproved); System.err.println("number of users with approved role: "+usersApproved.size()); users.removeAll(usersApproved); System.err.println("Total number of users with User Role and NO approved role : " + users.size() ); Map profiles = profiles(users); response.setRenderParameter("op", "new"); request.getPortletSession().setAttribute("users", users); request.getPortletSession().setAttribute("profiles", profiles); } catch (IdentityException e) { //todo type this and catch it up higher to make a //smarter error message throw new RuntimeException(e); } private Map profiles(Set users) throws IdentityException { Iterator i = users.iterator(); Map retval = new HashMap(); while(i.hasNext()) { User user = (User) i.next(); retval.put(user, profileModule.getProperties(user)); } return retval; } private Set dirtyStinkyHackToGetAroundPortalAPIBugACO(Set users) { Iterator i = users.iterator(); Set retval = new HashSet(); while(i.hasNext()) { User u = (User)i.next(); u.getUserName(); retval.add(u); } return retval; } Just to get the list of users who DONT have the "approved" role. For our immediate needs: UserModule.getUsersWithout(role) would work...until next time. -Andy -- 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

15 years, 10 months

3
3
0 / 0

[JBoss JIRA] Created: (JBPORTAL-1708) Identity APIs should invalidate cache on update/change of role membership

by Andrew Oliver (JIRA)

Identity APIs should invalidate cache on update/change of role membership ------------------------------------------------------------------------- Key: JBPORTAL-1708 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1708 Project: JBoss Portal Issue Type: Bug Security Level: Public (Everyone can see) Components: Portal Identity Affects Versions: 2.6.1 Final Reporter: Andrew Oliver Consider this code: String username = request.getParameter("username"); User user= usermodule.findUserByUserName(username); System.err.println("user was equal to "+(user == null ? "null" : user.getUserName())); Role role = rolemodule.findRoleByName("approved"); Set users = new HashSet(); users.add(user); membership.assignUsers(role, users); And this code: Role roleApproved = rolemodule.findRoleByName("approved"); Set usersApproved = membership.getUsers(roleApproved); With the default Hibernate settings for identity in server\default\deploy\jboss-portal.sar\conf\hibernate\user\hibernate.cfg.xml: <property name="cache.use_second_level_cache">true</property> <property name="cache.use_query_cache">true</property> The second bit of code doesn't see changes by the first bit of code until the portal is restarted (it seems). Switching these to false solves the problem. It is likely that this is due to the HibernateMembershipModuleImpl and the <set name="roles" table="jbp_role_membership" lazy="false" inverse="false" cascade="none" sort="unsorted"> <cache usage="read-write"/> <key column="jbp_uid"/> <many-to-many class="org.jboss.portal.identity.db.HibernateRoleImpl" column="jbp_rid" outer-join="true"/> </set> which specifies a cached collection and in http://viewvc.jboss.org/cgi-bin/viewvc.cgi/portal/branches/JBoss_Portal_B... public void assignRoles(User user, Set roles) throws IdentityException { //throw new UnsupportedOperationException("Not yet implemented"); if (!(user instanceof HibernateUserImpl)) { throw new IllegalArgumentException("User is not a HibernateUserImpl user"); } // We make a defensive copy with unwrapped maps and update with a new set Set copy = new HashSet(); for (Iterator i = roles.iterator(); i.hasNext();) { Object o = i.next(); if (o instanceof HibernateRoleImpl) { copy.add(o); } else { throw new IllegalArgumentException("Only HibernateRoleImpl roles can be accepted"); } } // Assign new roles HibernateUserImpl ui = (HibernateUserImpl)user; ui.setRoles(copy); } The defensive copy which avoids the hibernate collection probably prevents triggering of the cache invalidation logic in the many-many relationship (not 100% sure that this is how hibernate works for collection caching but it seems logical). The hibernate membership module's usage of hibernate is a bit odd and probably needs review anyhow. -- 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

15 years, 10 months

3
6
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 January 2008