[JBoss JIRA] (JBRULES-3388) KnowledgeAgent custom classloader not working for PKG resources
by Herman Post (JIRA)
Herman Post created JBRULES-3388:
------------------------------------
Summary: KnowledgeAgent custom classloader not working for PKG resources
Key: JBRULES-3388
URL: https://issues.jboss.org/browse/JBRULES-3388
Project: Drools
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: drools-core
Affects Versions: 5.3.1.Final
Environment: Windows 7, Java7-5, JBoss AS7.1
Reporter: Herman Post
Assignee: Mark Proctor
I believe there may be a bug when trying to use a custom class loader with the KnowledgeAgent and the KnowledgeBuilderConfiguration, and when the ChangeSet is a PKG resource.
I have been trying to get the knowledge-agent-classloader sample from the new Drools Cookbook to work with a PKG resource. The sample works fine for a DRL resource, but when I convert it to use my fact jar, and a PKG resource containing my rules, which I downloaded from Guvnor, it throws a ClassNotFoundException for my fact model. If I put my fact model in the classpath, the error goes away and my rules can be added to the KnowledgeAgent and run correctly. Following is the code from the sample that I have converted, and I have attached a zip file with a complete project demonstrating the problem. Also, I can get my rules and fact model to work if I use a DRL ChangeSet.knowledge-agent-classloader.zip
URL modelJarURL = getClass().getResource("Patient-1.0.jar");
URLClassLoader customURLClassloader = new URLClassLoader(new URL[] {modelJarURL });
KnowledgeBuilderConfiguration kbuilderConfig = KnowledgeBuilderFactory.newKnowledgeBuilderConfiguration(null,
customURLClassloader);
KnowledgeBaseConfiguration kbaseConfig = KnowledgeBaseFactory.newKnowledgeBaseConfiguration(null, customURLClassloader);
KnowledgeBase kbase = KnowledgeBaseFactory.newKnowledgeBase(kbaseConfig);
KnowledgeAgentConfiguration aconf = KnowledgeAgentFactory.newKnowledgeAgentConfiguration();
KnowledgeAgent kagent = KnowledgeAgentFactory.newKnowledgeAgent("test", kbase, aconf, kbuilderConfig);
// kagent.applyChangeSet(new ClassPathResource("change-set.xml", getClass())); // this goes with model.jar
// kagent.applyChangeSet(new ClassPathResource("drl-change-set.xml", getClass())); // this goes with Patient.jar
kagent.applyChangeSet(new ClassPathResource("pkg-change-set.xml", getClass())); // this goes with Patient.jar
return kagent.getKnowledgeBase();
Following is the stack trace from the error:
java.lang.NullPointerException
at org.drools.impl.KnowledgeBaseImpl.addKnowledgePackages(KnowledgeBaseImpl.java:148)
at org.drools.agent.impl.KnowledgeAgentImpl.addResourcesToKnowledgeBase(KnowledgeAgentImpl.java:1016)
at org.drools.agent.impl.KnowledgeAgentImpl.rebuildResources(KnowledgeAgentImpl.java:785)
at org.drools.agent.impl.KnowledgeAgentImpl.buildKnowledgeBase(KnowledgeAgentImpl.java:657)
at org.drools.agent.impl.KnowledgeAgentImpl.applyChangeSet(KnowledgeAgentImpl.java:190)
at org.drools.agent.impl.KnowledgeAgentImpl.applyChangeSet(KnowledgeAgentImpl.java:169)
at drools.cookbook.chapter02.KnowledgeAgentClassloaderTest.createKnowledgeBase(KnowledgeAgentClassloaderTest.java:59)
at drools.cookbook.chapter02.KnowledgeAgentClassloaderTest.customClassloaderTest(KnowledgeAgentClassloaderTest.java:30)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at org.junit.internal.runners.TestMethod.invoke(TestMethod.java:59)
at org.junit.internal.runners.MethodRoadie.runTestMethod(MethodRoadie.java:98)
at org.junit.internal.runners.MethodRoadie$2.run(MethodRoadie.java:79)
at org.junit.internal.runners.MethodRoadie.runBeforesThenTestThenAfters(MethodRoadie.java:87)
at org.junit.internal.runners.MethodRoadie.runTest(MethodRoadie.java:77)
at org.junit.internal.runners.MethodRoadie.run(MethodRoadie.java:42)
at org.junit.internal.runners.JUnit4ClassRunner.invokeTestMethod(JUnit4ClassRunner.java:88)
at org.junit.internal.runners.JUnit4ClassRunner.runMethods(JUnit4ClassRunner.java:51)
at org.junit.internal.runners.JUnit4ClassRunner$1.run(JUnit4ClassRunner.java:44)
at org.junit.internal.runners.ClassRoadie.runUnprotected(ClassRoadie.java:27)
at org.junit.internal.runners.ClassRoadie.runProtected(ClassRoadie.java:37)
at org.junit.internal.runners.JUnit4ClassRunner.run(JUnit4ClassRunner.java:42)
at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:50)
at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:467)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:683)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:390)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:197)
I have been having the exact same problem when trying to use a custom class loader with just a KnowldegeBuilder and no KnowledgeAgent.
--
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
13 years, 5 months
[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
13 years, 5 months
[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
13 years, 5 months
[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
13 years, 5 months