October 2012 - jboss-jira - Jboss List Archives

[JBoss JIRA] (AS7-5319) useless jboss-ejb-policy and jboss-web-policy security domains in default config files

by Marcel Å ebek (JIRA)

Marcel Å ebek created AS7-5319: ---------------------------------- Summary: useless jboss-ejb-policy and jboss-web-policy security domains in default config files Key: AS7-5319 URL: https://issues.jboss.org/browse/AS7-5319 Project: Application Server 7 Issue Type: Bug Components: Security Reporter: Marcel Å ebek Assignee: Anil Saldhana Distribution configuration files contain jboss-{ejb,web}-policy security domains. It seems to me that they are not used anywhere, and as such they only cause confusion to people who configure authorization. -- 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, 7 months

3
2
0 / 0

[JBoss JIRA] (AS7-5552) Web console's CLI response marshelling is rounding the long values into integer values

by Ramesh Reddy (JIRA)

Ramesh Reddy created AS7-5552: --------------------------------- Summary: Web console's CLI response marshelling is rounding the long values into integer values Key: AS7-5552 URL: https://issues.jboss.org/browse/AS7-5552 Project: Application Server 7 Issue Type: Bug Components: Console Affects Versions: 7.1.1.Final Reporter: Ramesh Reddy Assignee: Heiko Braun When CLI request made through web console, when response model node has "long" values such as "date" values, they are being truncated into "int" values, thus invalidating them. Ex: teiid runtime has few places we have date returned through cli calls, those are being invalidated. -- 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, 7 months

3
7
0 / 0

[JBoss JIRA] (JBRULES-3664) BeliefSystem Should keep each logically asserted object

by Mark Proctor (JIRA)

Mark Proctor created JBRULES-3664: ------------------------------------- Summary: BeliefSystem Should keep each logically asserted object Key: JBRULES-3664 URL: https://issues.jboss.org/browse/JBRULES-3664 Project: Drools Issue Type: Feature Request Security Level: Public (Everyone can see) Reporter: Mark Proctor Assignee: Mark Proctor -- 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, 7 months

1
4
0 / 0

[JBoss JIRA] (AS7-5311) Deployment of multiple .rar's with ironjacamar.xml

by Jesper Pedersen (JIRA)

Jesper Pedersen created AS7-5311: ------------------------------------ Summary: Deployment of multiple .rar's with ironjacamar.xml Key: AS7-5311 URL: https://issues.jboss.org/browse/AS7-5311 Project: Application Server 7 Issue Type: Bug Components: JCA Affects Versions: 7.1.2.Final (EAP) Reporter: Jesper Pedersen Assignee: Stefano Maestri Priority: Critical Fix For: 7.1.3.Final (EAP), 7.2.0.Alpha1 Deploying an .ear with multiple .rar's, which all have an ironjacamar.xml file results in {noformat} 11:17:24,899 ERROR [org.jboss.msc.service] (MSC service thread 1-14) MSC000002: Invocation of listener "org.jboss.as.connector.deployers.ra.processors.ParsedRaDeploymentProcessor$1@16c5f7e" failed: java.lang.IllegalArgumentException: JBAS014809: Ein Knoten ist bereits registriert unter '(deployment => *)(subdeployment => *)(subsystem => resource-adapters)(ironjacamar => ironjacamar)' at org.jboss.as.controller.registry.ConcreteResourceRegistration.registerSubModel(ConcreteResourceRegistration.java:108) [jboss-as-controller-7.1.2.Final-redhat-1.jar:7.1.2.Final-redhat-1] at org.jboss.as.controller.registry.AbstractResourceRegistration.registerSubModel(AbstractResourceRegistration.java:68) [jboss-as-controller-7.1.2.Final-redhat-1.jar:7.1.2.Final-redhat-1] at org.jboss.as.connector.subsystems.resourceadapters.IronJacamarRegistrator.invoke(IronJacamarRegistrator.java:33) [jboss-as-connector-7.1.2.Final-redhat-1.jar:7.1.2.Final-redhat-1] at org.jboss.as.connector.deployers.ra.processors.ParsedRaDeploymentProcessor$1.registerIronjacamar(ParsedRaDeploymentProcessor.java:158) [jboss-as-connector-7.1.2.Final-redhat-1.jar:7.1.2.Final-redhat-1] at org.jboss.as.connector.deployers.ra.processors.AbstractResourceAdapterDeploymentServiceListener.transition(AbstractResourceAdapterDeploymentServiceListener.java:131) [jboss-as-connector-7.1.2.Final-redhat-1.jar:7.1.2.Final-redhat-1] at org.jboss.msc.service.ServiceControllerImpl.invokeListener(ServiceControllerImpl.java:1416) [jboss-msc-1.0.2.GA-redhat-1.jar:1.0.2.GA-redhat-1] at org.jboss.msc.service.ServiceControllerImpl.access$2700(ServiceControllerImpl.java:49) [jboss-msc-1.0.2.GA-redhat-1.jar:1.0.2.GA-redhat-1] at org.jboss.msc.service.ServiceControllerImpl$ListenerTask.run(ServiceControllerImpl.java:1954) [jboss-msc-1.0.2.GA-redhat-1.jar:1.0.2.GA-redhat-1] at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [rt.jar:1.6.0_31] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [rt.jar:1.6.0_31] at java.lang.Thread.run(Thread.java:662) [rt.jar:1.6.0_31] {noformat} -- 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, 7 months

3
3
0 / 0

[JBoss JIRA] (AS7-5858) JBOSS 7.1.1.Final hangs on z/OS with new JDK maintenance

by Bob Bennett (JIRA)

Bob Bennett created AS7-5858: -------------------------------- Summary: JBOSS 7.1.1.Final hangs on z/OS with new JDK maintenance Key: AS7-5858 URL: https://issues.jboss.org/browse/AS7-5858 Project: Application Server 7 Issue Type: Bug Components: Server Affects Versions: 7.1.1.Final Environment: operating system - z/OS version 1.13 JDK version info: java version "1.7.0" Java(TM) SE Runtime Environment (build pmz6470sr2-20120901_01(SR2)) IBM J9 VM (build 2.6, JRE 1.7.0 z/OS s390x-64 20120809_118929 (JIT enabled, AOT enabled) J9VM - R26_Java726_SR2_20120809_0948_B118929 JIT - r11.b01_20120808_24925 GC - R26_Java726_SR2_20120809_0948_B118929 J9CL - 20120809_118929) JCL - 20120831_02 based on Oracle 7u3-b05 Reporter: Bob Bennett Assignee: Jason Greene When I install the jboss-as-7.1.1.Final on a z/OS system with the newest JDK, and start the standalone server, it gets stuck and never completes initialization. It also does not respond to kill, and requires kill -9 to terminate. I have javacore from the hang. I opened an issue with IBM support, and here is their response: Hi Bob, Have you contacted JBoss support for this issue? >From my review of the javacore, every application-related thread is waiting on some kind of internal state monitoring code. The most prominent cause of waiting appears to be a CountdownLatch used in: org/jboss/as/controller/ParallelBootOperationStepHandler $ParallelBootTransactionControl.operationPrepared A quick search found this possibly related JBoss bug which was introduced because of incompatibilities with Java 7 (although it would appear to have been fixed before your current build, but I'm not certain how.) https://issues.jboss.org/browse/AS7-2940?_sscc=t The CountdownLatch is one of the Concurrency classes, and is very simplistic in that it allows an application to direct threads to wait until some certain number of actions have occured. The application code (JBoss in this case) would need to explain how many countdowns are required and which piece of code decrements the counter as needed. There's not much to say from a JVM perspective other than the threads are all waiting for an application-level event (a call to the "countDown()" method 'N' times where 'N' is how many JBoss initialized the CountDownLatch to originally.) If the JBoss team believes there is a specific thread not processing for one reason or another, we could look at that from a JVM perspective to see why. Unfortunately we'd need the JBoss team to explain which thread they think should be executing and why. A system dump of the problem (taken using signal 3, or from the operator console) would potentially allow for the internal state variables associated here to be read out... but that won't really be of any use if we don't know what JBoss expects them to be. Regards, Java Defect Support Please let me know if you need more info, either from myself or IBM JDK support. -- 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, 7 months

5
17
0 / 0

[JBoss JIRA] (JBRULES-3470) publish org.drools.updatesite-*-assembly.zip contents to download.jboss.org so it can be used by end-users and linked from JBoss Central

by Nick Boldt (JIRA)

Nick Boldt created JBRULES-3470: ----------------------------------- Summary: publish org.drools.updatesite-*-assembly.zip contents to download.jboss.org so it can be used by end-users and linked from JBoss Central Key: JBRULES-3470 URL: https://issues.jboss.org/browse/JBRULES-3470 Project: Drools Issue Type: Feature Request Security Level: Public (Everyone can see) Components: drools-eclipse Affects Versions: 5.4.0.CR1, 5.3.1.Final Reporter: Nick Boldt Assignee: Mark Proctor Currently the only ways to get drools/jbpm 5 plugins installed into Eclipse are to: a) download the org.drools.updatesite-*-assembly.zip zip from Nexus, or b) unpack the droolsjbpm-tools-distribution-*.zip linked from http://www.jboss.org/drools/downloads, or c) use the nightly staging site for JBT SOA Tooling http://download.jboss.org/jbosstools/updates/nightly/soa-tooling/trunk/ d) use the nightly staging site for JBDS SOA Tooling http://www.qa.jboss.com/binaries/RHDS/builds/staging/devstudio-5.0_trunk.... Since the JBT site (c) is going away, and (a) and (b) are a relative pain in the butt, we need a new unpacked site, eg., under here: http://download.jboss.org/drools/updates/ or http://download.jboss.org/drools/releases/ -- 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, 7 months

2
20
0 / 0

[JBoss JIRA] (AS7-3681) JBoss crashes when run with AspectJ java agent

by Jack Lund (JIRA)

Jack Lund created AS7-3681: ------------------------------ Summary: JBoss crashes when run with AspectJ java agent Key: AS7-3681 URL: https://issues.jboss.org/browse/AS7-3681 Project: Application Server 7 Issue Type: Bug Components: Server Affects Versions: 7.1.0.CR1b, 7.0.2.Final Environment: OS X 10.7.2, Ubuntu 11.10 Reporter: Jack Lund Assignee: Jason Greene Priority: Blocker When trying to start JBoss with the AspectJ java agent (-javaagent:/path/aspectjweaver.jar) to enable load-time weaving, JBoss crashes with the following stack trace in the logs: ========================================================================= JBoss Bootstrap Environment JBOSS_HOME: /home/jack/jboss-as-7.1.0.CR1b JAVA: java JAVA_OPTS: -server -javaagent:/home/jack/aspectjweaver.jar -Xms64m -Xmx512m -XX:MaxPermSize=256m -Djava.net.preferIPv4Stack=true -Dorg.jboss.resolver.warning=true -Dsun.rmi.dgc.client.gcInterval=3600000 -Dsun.rmi.dgc.server.gcInterval=3600000 -Djboss.modules.system.pkgs=org.jboss.byteman -Djava.awt.headless=true ========================================================================= WARNING: Failed to load the specified logmodule org.jboss.logmanager:main Exception in thread "main" java.lang.ExceptionInInitializerError at org.jboss.as.server.Main.main(Main.java:92) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:616) at org.jboss.modules.Module.run(Module.java:248) at org.jboss.modules.Main.main(Main.java:313) Caused by: java.lang.IllegalStateException: The LogManager was not properly installed (you must set the "java.util.logging.manager" system property to "org.jboss.logmanager.LogManager") at org.jboss.logmanager.Logger.getLogger(Logger.java:60) at org.jboss.logmanager.log4j.BridgeRepositorySelector.<clinit>(BridgeRepositorySelector.java:42) ... 7 more -- 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, 7 months

9
14
0 / 0

[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, 7 months

2
12
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, 7 months

4
4
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, 7 months

5
6
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira October 2012