[jBPM Development] New message: "Re: No public metadata API?"
by Sebastian Schneider
JBoss development,
A new message was posted in the thread "No public metadata API?":
http://community.jboss.org/message/524949#524949
Author : Sebastian Schneider
Profile : http://community.jboss.org/people/sebastian.s
Message:
--------------------------------------------------------------
Are you using jBPM 4.3 or jBPM 3.2? In jBPM 4.3 there is the ExecutionService. Using it you can retrieve process instances by their ids:
{code}
ProcessInstance processInstance = executionService.findProcessInstanceById(processInstanceId);
{/code}
Afterwards you can use the following methods to retrieve some of the information you wanted:
{code}
processInstance.findActiveActivityNames();
processInstance.getState();
processInstance.getProcessDefinitionId():
..
{/code}
HTH. If you could be a bit more specific on the data you want to retrieve we would be able to help more. Maybe it's something which is not possible through the API right now but would make sense and thus be useful to others, too. In this case: why not fill a JIRA issue after discussion?
--------------------------------------------------------------
To reply to this message visit the message page: http://community.jboss.org/message/524949#524949
16 years, 1 month
[Tomcat Integration Development] New message: "Re: Deployment of on-demand web applications"
by Brian Stansberry
JBoss development,
A new message was posted in the thread "Deployment of on-demand web applications":
http://community.jboss.org/message/524929#524929
Author : Brian Stansberry
Profile : http://community.jboss.org/people/bstansberry@jboss.com
Message:
--------------------------------------------------------------
JIRA for the basics of this is http://community.jboss.org/thread/147220
AS trunk currently has admin-console, jmx-console and jbossws-console starting this way. For now I left the http-invoker alone, as it's a bit of a different beast from a console.
https://jira.jboss.org/jira/browse/JBAS-7714 is to firm up how to easily enable/disable this behavior. For M2, adding -Djboss.as.deployment.ondemand=false turns it off (i.e. causes the WARs to deploy during normal startup). I think that's OK for M2, which isn't meant to be used in production.
Jaikiran, sorry for the slow reply. I'll think about combining in one file. The advantage of multiple files is the instructions for how to deploy the war normally is simple -- copy the war from common/deploy/ to deploy/ and delete the -activator-jboss-beans.xml. "Delete the file" is easier than "edit the file". But since each activator bean exposes a boolean property to disable the on-demand behavior, I suppose it's even easier to tell people to leave the war where it is and edit the appropriate bean in a single file.
Re: putting all these in one special location and scanning rather than requiring config, that would be quite a bit of effort; it's not just a matter of looking at the name of a deployment archive and figuring everything out. For example, the context path for jbossws-console.war is jbossws, not jbossws-console, so we'd have to find and parse jboss-web.xml to know that.
The admin console uses the ServletContextListener trick you mentioned. Even with that it takes a long time to deploy.
--------------------------------------------------------------
To reply to this message visit the message page: http://community.jboss.org/message/524929#524929
16 years, 1 month
[jBPM Development] New message: "No public metadata API?"
by Bill Burke
JBoss development,
A new message was posted in the thread "No public metadata API?":
http://community.jboss.org/message/524911#524911
Author : Bill Burke
Profile : http://community.jboss.org/people/bill.burke@jboss.com
Message:
--------------------------------------------------------------
I'm prototyping a new REST interface for jbpm for the REST-* effort. One thing I've noticed is that there seems to be no public API to get information about a process definition or instance.
For example, I'd like to be able to know the current state of an execution, and what outgoing transitions are able to be executed. I figured out how to get this information at runtime, but it seems to be an "internal" api (its in a *.internal.* package).
I also wanted to generate an XML document from a ProcessDefinition, but again, all metadata seems to be *very* hidden. I had to really dive into the internals of jbpm to be able to get this information.
Maybe I'm just missing something?
Thanks.
--------------------------------------------------------------
To reply to this message visit the message page: http://community.jboss.org/message/524911#524911
16 years, 1 month
[JBoss Microcontainer Development] New message: "Re: Pluggable dependency resolver"
by Kabir Khan
JBoss development,
A new message was posted in the thread "Pluggable dependency resolver":
http://community.jboss.org/message/524862#524862
Author : Kabir Khan
Profile : http://community.jboss.org/people/kabir.khan@jboss.com
Message:
--------------------------------------------------------------
I mean this:
*public* *void* testPlainLifecycleDependencyWrongOrder() *throws* Throwable
{
plainLifecycleDependencyWrongOrder();
ControllerContext context2 = assertInstall(1, "Name2", ControllerState.+CONFIGURED+);
ControllerContext context1 = assertInstall(0, "Name1");
+assertEquals+(ControllerState.+INSTALLED+, context2.getState());
SimpleBeanWithLifecycle bean1 = (SimpleBeanWithLifecycle) context1.getTarget();
+assertNotNull+(bean1);
SimpleBeanWithLifecycle bean2 = (SimpleBeanWithLifecycle) context2.getTarget();
+assertNotNull+(bean2);
+assertEquals+(1, bean1.createOrder);
+assertEquals+(2, bean2.createOrder);
+assertEquals+(3, bean1.startOrder);
+assertEquals+(4, bean2.startOrder);
}
The new resolver works with
+assertEquals+(1, bean1.createOrder);
+assertEquals+(2, bean1.startOrder);
+assertEquals+(3, bean2.createOrder);
+assertEquals+(4, bean2.startOrder);
The actual hardcoded orders of beans 1 and 2 is an implemetation detail as I see it. The real check is making sure that the initial install of context 2 does not go beyond CONFIGURED and:
bean1.startOrder > bean1.createOrder
bean2.startOrder > bean2.createOrder
bean2.createOrder > bean1.createOrder
bean2.startOrder > bean1.startOrder
I've got an infinite loop in the indexing resolver when I start up AS which I need to fix before I can get any measurements of boot time, although it sounds like we won't gain much from this.
--------------------------------------------------------------
To reply to this message visit the message page: http://community.jboss.org/message/524862#524862
16 years, 1 month
[JBoss Microcontainer Development] New message: "Re: Pluggable dependency resolver"
by Kabir Khan
JBoss development,
A new message was posted in the thread "Pluggable dependency resolver":
http://community.jboss.org/message/524847#524847
Author : Kabir Khan
Profile : http://community.jboss.org/people/kabir.khan@jboss.com
Message:
--------------------------------------------------------------
I have got rid of the recursion, so the benchmark now passes with larger numbers. These are the figures:
**10,000 beans
*wrong order
-Legacy resolver: I gave up and stopped the test after 4 minutes
-Indexing resolver: 4655ms
*correct order
-Legacy resolver: 12937ms
-Indexing resolver: 2553ms
**3,000 beans
*wrong order
-Legacy resolver: 29201ms
-Indexing resolver: 1447ms
*correct order
-Legacy resolver: 2264ms
-Indexing resolver: 1173ms
Note that this is done on plain test controller contexts in the dependency project, so there should be no overhead associated with stuff happening in the ControllerContext actions such as accessing the MDR, instantiating the context etc.
Next, I'll try this revised version in AS to see if it has any influence on boot times.
What I have done breaks a few of the tests in the branch. I think they can be fixed easily, since they take into account the order that things reach the various states. For the record these tests are:
KernelAllTestSuite
All Tests
Kernel Tests
Dependency Tests
org.jboss.test.kernel.dependency.test.PlainLifecycleDependencyTestCase
testPlainLifecycleDependencyWrongOrder(org.jboss.test.kernel.dependency.test.PlainLifecycleDependencyTestCase)
junit.framework.AssertionFailedError: expected:<2> but was:<3>
at junit.framework.Assert.fail(Assert.java:47)
at junit.framework.Assert.failNotEquals(Assert.java:277)
at junit.framework.Assert.assertEquals(Assert.java:64)
at junit.framework.Assert.assertEquals(Assert.java:195)
at junit.framework.Assert.assertEquals(Assert.java:201)
at org.jboss.test.kernel.dependency.test.PlainLifecycleDependencyTestCase.testPlainLifecycleDependencyWrongOrder(PlainLifecycleDependencyTestCase.java:98)
testPlainLifecycleDependencyReinstall(org.jboss.test.kernel.dependency.test.PlainLifecycleDependencyTestCase)
junit.framework.AssertionFailedError: expected:<10> but was:<11>
at junit.framework.Assert.fail(Assert.java:47)
at junit.framework.Assert.failNotEquals(Assert.java:277)
at junit.framework.Assert.assertEquals(Assert.java:64)
at junit.framework.Assert.assertEquals(Assert.java:195)
at junit.framework.Assert.assertEquals(Assert.java:201)
at org.jboss.test.kernel.dependency.test.PlainLifecycleDependencyTestCase.testPlainLifecycleDependencyReinstall(PlainLifecycleDependencyTestCase.java:141)
org.jboss.test.kernel.dependency.test.PlainLifecycleDependencyXMLTestCase
testPlainLifecycleDependencyWrongOrder(org.jboss.test.kernel.dependency.test.PlainLifecycleDependencyXMLTestCase)
junit.framework.AssertionFailedError: expected:<2> but was:<3>
at junit.framework.Assert.fail(Assert.java:47)
at junit.framework.Assert.failNotEquals(Assert.java:277)
at junit.framework.Assert.assertEquals(Assert.java:64)
at junit.framework.Assert.assertEquals(Assert.java:195)
at junit.framework.Assert.assertEquals(Assert.java:201)
at org.jboss.test.kernel.dependency.test.PlainLifecycleDependencyTestCase.testPlainLifecycleDependencyWrongOrder(PlainLifecycleDependencyTestCase.java:98)
testPlainLifecycleDependencyReinstall(org.jboss.test.kernel.dependency.test.PlainLifecycleDependencyXMLTestCase)
junit.framework.AssertionFailedError: expected:<10> but was:<11>
at junit.framework.Assert.fail(Assert.java:47)
at junit.framework.Assert.failNotEquals(Assert.java:277)
at junit.framework.Assert.assertEquals(Assert.java:64)
at junit.framework.Assert.assertEquals(Assert.java:195)
at junit.framework.Assert.assertEquals(Assert.java:201)
at org.jboss.test.kernel.dependency.test.PlainLifecycleDependencyTestCase.testPlainLifecycleDependencyReinstall(PlainLifecycleDependencyTestCase.java:141)
org.jboss.test.kernel.dependency.test.PlainLifecycleDependencyAnnotationTestCase
testPlainLifecycleDependencyWrongOrder(org.jboss.test.kernel.dependency.test.PlainLifecycleDependencyAnnotationTestCase)
junit.framework.AssertionFailedError: expected:<2> but was:<3>
at junit.framework.Assert.fail(Assert.java:47)
at junit.framework.Assert.failNotEquals(Assert.java:277)
at junit.framework.Assert.assertEquals(Assert.java:64)
at junit.framework.Assert.assertEquals(Assert.java:195)
at junit.framework.Assert.assertEquals(Assert.java:201)
at org.jboss.test.kernel.dependency.test.PlainLifecycleDependencyTestCase.testPlainLifecycleDependencyWrongOrder(PlainLifecycleDependencyTestCase.java:98)
testPlainLifecycleDependencyReinstall(org.jboss.test.kernel.dependency.test.PlainLifecycleDependencyAnnotationTestCase)
junit.framework.AssertionFailedError: expected:<10> but was:<11>
at junit.framework.Assert.fail(Assert.java:47)
at junit.framework.Assert.failNotEquals(Assert.java:277)
at junit.framework.Assert.assertEquals(Assert.java:64)
at junit.framework.Assert.assertEquals(Assert.java:195)
at junit.framework.Assert.assertEquals(Assert.java:201)
at org.jboss.test.kernel.dependency.test.PlainLifecycleDependencyTestCase.testPlainLifecycleDependencyReinstall(PlainLifecycleDependencyTestCase.java:141)
--------------------------------------------------------------
To reply to this message visit the message page: http://community.jboss.org/message/524847#524847
16 years, 1 month
[Security Development] Document updated/added: "PicketBox Mapping"
by ANIL SALDHANA
JBoss development,
The document "PicketBox Mapping", was updated Feb 8, 2010
by ANIL SALDHANA.
To view the document, visit:
http://community.jboss.org/docs/DOC-14760#cf
Document:
--------------------------------------------------------------
*PicketBox* (formerly JBoss Security) supports facilities to map a Principal, Role(s) and Attribute(s) in a security process.
Need for mapping
It is important for any security framework to provide facilities to map principal or roles from one form to another.
Examples include:
* The authentication has been performed using X509 Certificates. Now you want to convert the principal from the certificate to a logical name that is meaningful to your application such as display purposes.
* The authentication process derived a set of roles as part of the security domain. But you want to associate a few more roles with the current subject as part of the deployment archive.
Read more below:
*Role Mapping*
The conversion of roles during a particular security event may be important for the following reasons:
* You want to add more roles to the subject than what the authentication process derived.
* You want to replace/remove one or more roles.
--------------------------------------------------------------
16 years, 1 month