November 2012 - jboss-jira - Jboss List Archives

[JBoss JIRA] (JASSIST-176) I get a NPE in TypeData

by John Bainbridge (JIRA)

John Bainbridge created JASSIST-176: --------------------------------------- Summary: I get a NPE in TypeData Key: JASSIST-176 URL: https://issues.jboss.org/browse/JASSIST-176 Project: Javassist Issue Type: Bug Affects Versions: 3.17.0-GA Environment: Java 7 Reporter: John Bainbridge Assignee: Shigeru Chiba This kills my JVM. I'm looking at trying to make simple test case. It appears to be releated to JASSIST-175 caused by: java.lang.NullPointerException at javassist.bytecode.stackmap.TypeData.commonSuperClassEx(TypeData.java:400) at javassist.bytecode.stackmap.TypeData$TypeVar.fixTypes2(TypeData.java:342) at javassist.bytecode.stackmap.TypeData$TypeVar.fixTypes(TypeData.java:325) at javassist.bytecode.stackmap.TypeData$TypeVar.dfs(TypeData.java:270) at javassist.bytecode.stackmap.MapMaker.fixTypes(MapMaker.java:301) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:151) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:100) at javassist.bytecode.MethodInfo.rebuildStackMap(MethodInfo.java:423) at javassist.bytecode.MethodInfo.rebuildStackMapIf6(MethodInfo.java:405) at javassist.expr.ExprEditor.doit(ExprEditor.java:113) at javassist.CtClassType.instrument(CtClassType.java:1398) at org.powermock.core.transformers.impl.MainMockTransformer.transform(MainMockTransformer.java:75) at org.powermock.core.classloader.MockClassLoader.loadMockClass(MockClassLoader.java:203) ... 27 more -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 10 months

2
12
0 / 0

[JBoss JIRA] (AS7-5899) UCS-2 CodeSet Interop Issue

by Nick Cross (JIRA)

[ https://issues.jboss.org/browse/AS7-5899?page=com.atlassian.jira.plugin.s... ] Nick Cross commented on AS7-5899: --------------------------------- Fixed upstream in github > UCS-2 CodeSet Interop Issue > --------------------------- > > Key: AS7-5899 > URL: https://issues.jboss.org/browse/AS7-5899 > Project: Application Server 7 > Issue Type: Bug > Components: IIOP > Affects Versions: 7.1.2.Final (EAP) > Reporter: Brad Maxwell > Assignee: Nick Cross > Labels: jacorb > Fix For: Open To Community > > > Interoperability issue when client in JBoss EAP 6 calls IBM WebSphere. The client in JBoss EAP 6 sends "foo" but the server side IBM WebSphere receives "?foo" -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 10 months

1
0
0 / 0

[JBoss JIRA] (AS7-2152) WSDL URL should be anchor

by Richard Opalka (Created) (JIRA)

WSDL URL should be anchor ------------------------- Key: AS7-2152 URL: https://issues.jboss.org/browse/AS7-2152 Project: Application Server 7 Issue Type: Enhancement Components: Console Reporter: Richard Opalka Assignee: Heiko Braun Fix For: 7.1.0.Beta1 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 10 months

4
4
0 / 0

[JBoss JIRA] (AS7-5908) Provide the ability configure endpoint configs in the console

by Heiko Braun (JIRA)

Heiko Braun created AS7-5908: -------------------------------- Summary: Provide the ability configure endpoint configs in the console Key: AS7-5908 URL: https://issues.jboss.org/browse/AS7-5908 Project: Application Server 7 Issue Type: Feature Request Components: Console Reporter: Heiko Braun Assignee: Heiko Braun Fix For: 7.2.0.CR1 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 10 months

1
0
0 / 0

[JBoss JIRA] (SECURITY-659) WebJASPIAuthenticator ignores GroupPrincipalCallback but requires PasswordValidationCallback

by arjan tijms (JIRA)

arjan tijms created SECURITY-659: ------------------------------------ Summary: WebJASPIAuthenticator ignores GroupPrincipalCallback but requires PasswordValidationCallback Key: SECURITY-659 URL: https://issues.jboss.org/browse/SECURITY-659 Project: PicketBox (JBoss Security and Identity Management) Issue Type: Bug Security Level: Public (Everyone can see) Components: PicketBox Affects Versions: PicketBox_v4_0_7 Reporter: arjan tijms Assignee: Anil Saldhana In JBoss AS 7.1.1, if a user provided {{ServerAuthModule}} provides a {{GroupPrincipalCallback}}, then this is ignored by {{WebJASPIAuthenticator}}. The provided handler copies the {{GroupPrincipalCallback}}, but the authenticator then does nothing with it. Simulteanously, if the {{ServerAuthModule}} does not provide a {{PasswordValidationCallback}} to the handler, then this will result in a null pointer exception in the authenticator. Regarding the ignored {{GroupPrincipalCallback}}, the problem seems to be in the following code: {code:title=WebJASPIAuthenticator#authenticate} // ... if (result) { PasswordValidationCallback pvc = cbh.getPasswordValidationCallback(); CallerPrincipalCallback cpc = cbh.getCallerPrincipalCallback(); // get the client principal from the callback. Principal clientPrincipal = cpc.getPrincipal(); if (clientPrincipal == null) { clientPrincipal = new SimplePrincipal(cpc.getName()); } // if the client principal is not a jboss generic principal, we need to build one before registering. if (!(clientPrincipal instanceof JBossGenericPrincipal)) clientPrincipal = this.buildJBossPrincipal(clientSubject, clientPrincipal); {code} {{buildJBossPrincipal()}} looks at the "Roles" group in the Subject, but this hasn't been set by either the handler or other code based on what the GroupPrincipalCallback contains. I wonder if changing this into the following would be more correct: {code:title=WebJASPIAuthenticator#authenticate} // ... if (result) { PasswordValidationCallback pvc = cbh.getPasswordValidationCallback(); CallerPrincipalCallback cpc = cbh.getCallerPrincipalCallback(); GroupPrincipalCallback gpc = cbh.getGroupPrincipalCallback(); // ADDED // get the client principal from the callback. Principal clientPrincipal = cpc.getPrincipal(); if (clientPrincipal == null) { clientPrincipal = new SimplePrincipal(cpc.getName()); } // if the client principal is not a jboss generic principal, we need to build one before registering. if (!(clientPrincipal instanceof JBossGenericPrincipal)) clientPrincipal = this.buildJBossPrincipal(clientSubject, clientPrincipal, gpc); // ADDED gpc PARAMETER {code} With {{buildJBossPrincipal()}} implemented as: {code:title=WebJASPIAuthenticator#buildJBossPrincipal} protected Principal buildJBossPrincipal(Subject subject, Principal principal, GroupPrincipalCallback groupPrincipalCallback) { List<String> roles = new ArrayList<String>(); // look for roles in the subject first. for (Principal p : subject.getPrincipals()) { if (p instanceof Group && p.getName().equals("Roles")) { Enumeration<? extends Principal> members = ((Group) p).members(); while (members.hasMoreElements()) roles.add(members.nextElement().getName()); } } // START ADDED if (groupPrincipalCallback != null && groupPrincipalCallback.getGroups() != null) { for (String group : groupPrincipalCallback.getGroups()) { roles.add(group); } } // END ADDED // if the subject didn't contain any roles, look for the roles declared in the deployment descriptor. JBossWebRealm realm = (JBossWebRealm) this.getContainer().getRealm(); Set<String> descriptorRoles = realm.getPrincipalVersusRolesMap().get(principal.getName()); if (roles.isEmpty() && descriptorRoles != null) roles.addAll(descriptorRoles); // build and return the JBossGenericPrincipal. return new JBossGenericPrincipal(realm, principal.getName(), null, roles, principal, null, null, null, subject); } {code} As for the PasswordValidationCallback, WebJASPIAuthenticator now contains the following code in {{authenticate()}}: {code:title=WebJASPIAuthenticator#authenticate} this.register(request, response, clientPrincipal, authMethod, pvc.getUsername(), new String(pvc.getPassword())); {code} The {{register()}} method considers both username and password as optional, but because there's no null check on {{pvc}}, the above line will throw a NPE in case no PasswordValidationCallback is provided. This could perhaps be changed into something like the following: {code:title=WebJASPIAuthenticator#authenticate} this.register(request, response, clientPrincipal, authMethod, pvc != null ? pvc.getUsername() : null, pvc != null ? new String(pvc.getPassword()) : null); {code} -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 10 months

5
6
0 / 0

[JBoss JIRA] (AS7-5907) Assign an unique NodeID automatically

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/AS7-5907?page=com.atlassian.jira.plugin.s... ] Tom Jenkinson edited comment on AS7-5907 at 11/8/12 10:01 AM: -------------------------------------------------------------- This was deferred in JBTM, but I think it might be something AS7 would like to provide for usability aspects. Generally: assuming the user does not define the node-identifier themselves, use Cleberts algorithm to persistently store a unique node-identifier. Note the node-identifier must be unique for any server that talks to another server or shares an object store, it may be that UUID is not considered to be guaranteed to be unique enough. was (Author: tomjenkinson): This was deferred in JBTM, but I think it might be something AS7 would like to provide for usability aspects. Generally: assuming the user does not define the node-identifier themselves, use Cleberts algorithm to persistently store a unique node-identifier. Note the node-identifier must be unique for any server that talks to another server or shares an object store, it may be that UUID is not considered unique enough. > Assign an unique NodeID automatically > ------------------------------------- > > Key: AS7-5907 > URL: https://issues.jboss.org/browse/AS7-5907 > Project: Application Server 7 > Issue Type: Feature Request > Reporter: Clebert Suconic > Assignee: Stefano Maestri > > It shouldn't be needed to assign the node-id manually IMO. > You could store the node-id on a file and recover it for subsequent starts. > On hornetQ for instance, we look for the nodeID on a file, if the file doesn't exist we assign a UUID and write to the file. > In our previous experience UUID would be a best fit to assign the nodes since that was the only way we could guarantee unique IDs between the nodes. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 10 months

1
0
0 / 0

[JBoss JIRA] (AS7-5907) Assign an unique NodeID automatically

by Clebert Suconic (JIRA)

[ https://issues.jboss.org/browse/AS7-5907?page=com.atlassian.jira.plugin.s... ] Clebert Suconic commented on AS7-5907: -------------------------------------- This would save us a lot of hassle with users not setting the proper NodeID when in cluster. > Assign an unique NodeID automatically > ------------------------------------- > > Key: AS7-5907 > URL: https://issues.jboss.org/browse/AS7-5907 > Project: Application Server 7 > Issue Type: Feature Request > Reporter: Clebert Suconic > Assignee: Stefano Maestri > > It shouldn't be needed to assign the node-id manually IMO. > You could store the node-id on a file and recover it for subsequent starts. > On hornetQ for instance, we look for the nodeID on a file, if the file doesn't exist we assign a UUID and write to the file. > In our previous experience UUID would be a best fit to assign the nodes since that was the only way we could guarantee unique IDs between the nodes. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 10 months

1
0
0 / 0

[JBoss JIRA] (AS7-5907) Assign an unique NodeID automatically

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/AS7-5907?page=com.atlassian.jira.plugin.s... ] Tom Jenkinson commented on AS7-5907: ------------------------------------ This was deferred in JBTM, but I think it might be something AS7 would like to provide for usability aspects. Generally: assuming the user does not define the node-identifier themselves, use Cleberts algorithm to persistently store a unique node-identifier. Note the node-identifier must be unique for any server that talks to another server or shares an object store, it may be that UUID is not considered unique enough. > Assign an unique NodeID automatically > ------------------------------------- > > Key: AS7-5907 > URL: https://issues.jboss.org/browse/AS7-5907 > Project: Application Server 7 > Issue Type: Feature Request > Reporter: Clebert Suconic > Assignee: Stefano Maestri > > It shouldn't be needed to assign the node-id manually IMO. > You could store the node-id on a file and recover it for subsequent starts. > On hornetQ for instance, we look for the nodeID on a file, if the file doesn't exist we assign a UUID and write to the file. > In our previous experience UUID would be a best fit to assign the nodes since that was the only way we could guarantee unique IDs between the nodes. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 10 months

1
0
0 / 0

[JBoss JIRA] (AS7-5907) Assign an unique NodeID automatically

by Clebert Suconic (JIRA)

[ https://issues.jboss.org/browse/AS7-5907?page=com.atlassian.jira.plugin.s... ] Clebert Suconic commented on AS7-5907: -------------------------------------- I chat I had with Tom Jenkinson: clebert: tomjenkinson: but now you have compatibility issues to deal [08:56am] clebert: tomjenkinson: what if you start a new version... [08:56am] clebert: you didn't have the data there.. then you will add it [08:56am] clebert: tomjenkinson: you would have to only set the UUID if there is no data folder.. no Objects pending at all [08:57am] clebert: tomjenkinson: well.. you can easily do a check on.. if (objects.counts() == 0) and ID=default, ID = new UUID, store it on the folder and recover on restart > Assign an unique NodeID automatically > ------------------------------------- > > Key: AS7-5907 > URL: https://issues.jboss.org/browse/AS7-5907 > Project: Application Server 7 > Issue Type: Feature Request > Reporter: Clebert Suconic > Assignee: Stefano Maestri > > It shouldn't be needed to assign the node-id manually IMO. > You could store the node-id on a file and recover it for subsequent starts. > On hornetQ for instance, we look for the nodeID on a file, if the file doesn't exist we assign a UUID and write to the file. > In our previous experience UUID would be a best fit to assign the nodes since that was the only way we could guarantee unique IDs between the nodes. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 10 months

1
0
0 / 0

[JBoss JIRA] (AS7-5907) Assign an unique NodeID automatically

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/AS7-5907?page=com.atlassian.jira.plugin.s... ] Tom Jenkinson moved JBTM-1157 to AS7-5907: ------------------------------------------ Project: Application Server 7 (was: JBoss Transaction Manager) Key: AS7-5907 (was: JBTM-1157) Security: (was: Public) > Assign an unique NodeID automatically > ------------------------------------- > > Key: AS7-5907 > URL: https://issues.jboss.org/browse/AS7-5907 > Project: Application Server 7 > Issue Type: Feature Request > Reporter: Clebert Suconic > Assignee: Tom Jenkinson > > It shouldn't be needed to assign the node-id manually IMO. > You could store the node-id on a file and recover it for subsequent starts. > On hornetQ for instance, we look for the nodeID on a file, if the file doesn't exist we assign a UUID and write to the file. > In our previous experience UUID would be a best fit to assign the nodes since that was the only way we could guarantee unique IDs between the nodes. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 10 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira November 2012