[JBoss Microcontainer Development] New message: "Re: Security problems with org.jboss.test:jboss-test 1.1.5.GA"
by Flavia Rainone
User development,
A new message was posted in the thread "Security problems with org.jboss.test:jboss-test 1.1.5.GA":
http://community.jboss.org/message/530617#530617
Author : Flavia Rainone
Profile : http://community.jboss.org/people/flavia.rainone@jboss.com
Message:
--------------------------------------------------------------
> mailto:adrian@jboss.org wrote:
>
> Looks like a bug to me, but I don't see any recent changes in the code that would cause the problem?
>
> The SecurityManager shouldn't be installed until it runs AbstractTestDelegate.setUp()
> The error above is happening in the constructor of the delegate.
>
> Its only after that happens that you can do:
>
> delegate.enableSecurity = true;
>
> Most likely, there is a security manager still around from a previous test?
You're right!
Taking a better look, I found this:
public class AOPTestDelegate extends AbstractTestDelegate
{
public void tearDown() throws Exception
{
>>> //TODO Figure out cause of security exception when making this call
>>> // super.tearDown();
String deployedByClassLoader = (String)systemProps.get(EclipseTestTransformer.CLASSLOADER_DEPLOYED_XML);
if (deployedByClassLoader != null)
{
URL url = Thread.currentThread().getContextClassLoader().getResource(deployedByClassLoader);
AspectXmlLoader.undeployXML(url);
}
}
}
AbstractTestDelegate.setUpSecurity defines a SecurityManager, and AbstractTestDelegate.tearDownSecurity should set the SecurityManager as null. This is not happening, because AbstractTestDelegate.tearDown is overwritten and the call to super.tearDown is commented out.
Uncomenting this call took me to:
Testcase: testBasic took 1.531 sec
Caused an ERROR
access denied (java.lang.RuntimePermission setSecurityManager)
java.security.AccessControlException: access denied (java.lang.RuntimePermission setSecurityManager)
at java.security.AccessControlContext.checkPermission(AccessControlContext.java:323)
at java.security.AccessController.checkPermission(AccessController.java:546)
at java.lang.SecurityManager.checkPermission(SecurityManager.java:532)
at java.lang.System.setSecurityManager0(System.java:272)
at java.lang.System.setSecurityManager(System.java:263)
at org.jboss.test.AbstractTestDelegate.tearDownSecurity(AbstractTestDelegate.java:195)
at org.jboss.test.AbstractTestDelegate.tearDown(AbstractTestDelegate.java:142)
at org.jboss.test.aop.AOPTestDelegate.tearDown(AOPTestDelegate.java:66)
at org.jboss.test.AbstractTestSetup.tearDown(AbstractTestSetup.java:73)
at org.jboss.test.AbstractTestCaseWithSetup.tearDown(AbstractTestCaseWithSetup.java:112)
>From that, I'm assuming that I should define a security policy that allow AbstractTestDelegate to call setSecurityManager. Is that correct?
--------------------------------------------------------------
To reply to this message visit the message page: http://community.jboss.org/message/530617#530617
16 years, 1 month
[JBoss Portal] New message: "How to set a request attribute in processEvent"
by antoine seilles
User development,
A new message was posted in the thread "How to set a request attribute in processEvent":
http://community.jboss.org/message/530616#530616
Author : antoine seilles
Profile : http://community.jboss.org/people/natoine
Message:
--------------------------------------------------------------
My problem :
I got an event, i process it with processEvent and i would like to set an attribute to the end of this process.
How can i do it?
public void processEvent(EventRequest request, EventResponse response)
{
Event event = request.getEvent();
if(event.getName().equals("selection"))
{
Selection _selection = (Selection) event.getValue();
//doesn't work
request.getPortletSession().setAttribute("new_selection", _selection);
//doesn't work
this.getPortletContext().setAttribute("new_selection", _selection);
//doesn't work
request.setAttribute("new_selection", _selection);
}
}
--------------------------------------------------------------
To reply to this message visit the message page: http://community.jboss.org/message/530616#530616
16 years, 1 month
[jBPM] New message: "Re: jBPM 4.3 and business rules/Drools integration"
by Ronald van Kuijk
User development,
A new message was posted in the thread "jBPM 4.3 and business rules/Drools integration":
http://community.jboss.org/message/530611#530611
Author : Ronald van Kuijk
Profile : http://community.jboss.org/people/kukeltje
Message:
--------------------------------------------------------------
1) Yes, it is a hard dependency, but it is also a tradeoff between a simple way of managing a set of resources vs a full blown governance system with version management, deployment management etc. So unless the latter becomes available, I think the current way is what is there which I think is sufficient for a lot if not most usecases. Ofcourse, we are always open to contributions, even small ones that take away the some of the limitations without making everything to complex.
2) No idea... there is nothing in jira, and some of the 'choices' were not realy choices in the sense that limitations were put in place deliberately. Again, in many cases it is sufficient for now.
3) Some discussion about this can be found in the developer forum. The developer of the rules integration has the opinion that it currently is sufficient to just fire all rules and have less granularity. This compared to the number 1 and 2 I agree with you.
--------------------------------------------------------------
To reply to this message visit the message page: http://community.jboss.org/message/530611#530611
16 years, 1 month
[jBPM] New message: "jBPM 4.3 and business rules/Drools integration"
by Patricia B
User development,
A new message was posted in the thread "jBPM 4.3 and business rules/Drools integration":
http://community.jboss.org/message/530592#530592
Author : Patricia B
Profile : http://community.jboss.org/people/patriciab
Message:
--------------------------------------------------------------
Hi all,
I implemented a couple of use cases for checking the integration of Drools rule within a jBPM workflow definition. It is a great step forward in having business rules integrated with jBPM activies, and allow the end user to specify the business rules to be invoked, but I ran into a few limitations, and I have a few questions about that.
1) jBPM expects to find the business rule deployed on the same deployment package with the process definition that is using that rule. IMHO this creates a pretty hard dependency between the rule files and the process definitions files, dependency that does not feel natural, as the process definitions changes and rule changes are not following the same pattern. On the real use case I can see business rules changing more frequent than the process definitions, and I also can see the same business rule being used by more than one process definition. And the process definitions that use the same business rule can be deployed on different deployment packages, on real life.
But having the constraint that the business rule and process definition that is using it to be on the same deployment package, pretty much imposes that all process definitions and all business rules for an application be deployed on the same deployment package, and every time when a process definition is modified to redeploy the whole package, not just the updated process definition.
I wonder if in the future releases, there is any alternative to this hard dependency between the business rule files and the process definition files being on the same deployment package. I wonder if it would make more sense to allow injection of the KnowledgeRule service into the jBPM RuleDeployer, and that service will know to return the correct KnowledgeBase based on the rule package and/or rule name, and/or rule file. This KnowledgeRule service will take care of loading the business rules from a custom location, and not from the jBPM deployment.
2) jBPM expects that all rule files are extension ".drl". This seems very limiting as Drools engine also has the decision table rules as excel files, or csv files, and also business rules using the designer with ".brl" file extension.
Is any plan for future releases to include the other rule files extensions besides the ".drl" one?
3) jBPM rule activity allows to specify the facts for a rule, and all rules deployed with the same process definition are fired.
I wonder if there is any plan for future releases to allow for a more granular rule state configuration, when a user can specify either the rule name, or the rule package, besides the rule facts. I can see on large applications business rules using the same facts, but actually having different functionality, and being able to specify the rule name or package, will fire the expected rule only.
I wonder if anybody else tried the jBPM Drools integration and whether it found out the same limitations as me. Any feedback is useful.
Thanks.
--------------------------------------------------------------
To reply to this message visit the message page: http://community.jboss.org/message/530592#530592
16 years, 1 month