Also in my opinion is correct to rollback process logs but what if in one of the rolled back nodes jbpm sends an email to an operator or a customer or, in general, triggers some operation in external systems?
We can't say that in this case the code has never happened,
in other words,
code has never happened for jbpm but it did happened for some external systems (or even worse people).
There could be situations where syncronization between jbpm and external world would be lost so i think that what Camunda did is a must even because using an ESB gives not only asyncronicity but protocol/transport failover as well.
Camunda, could you explain better how did you designed that special service that collects log data where internal jbpm error occurs?
did you store that logs in the same table as other logs or in a separate location?
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4213810#4213810
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4213810
We've just migrated our app to JBoss 5 (from 4) and have one last annoyance to resolve. We have an EJB client that uses JNDILoginInitialContextFactory to supply string-based user/password combination. On the server, our custom JAAS login module authenticates, and sets our custom Principal to the group "CallerPrincipal" according to spec. EJBs then see this custom principal in the EJBContext just fine.
With JBoss 5, this no longer works. As I understand, with JBoss 5 we have to perform a SecurityClient login now, and obtain the InitialContext with a NamingContextFactory instead.
| SecurityClient client = SecurityClientFactory.getSecurityClient();
| client.setSimple("jdoe", "theduke");
| Properties p = new Properties();
| p.put(Context.INITIAL_CONTEXT_FACTORY, "org.jnp.interfaces.NamingContextFactory");
| p.put(Context.PROVIDER_URL, "jnp://localhost");
| p.put(Context.URL_PKG_PREFIXES, "org.jboss.naming:org.jnp.interfaces");
| InitialContext initialContext = new InitialContext(p);
Upon doing so, authentication succeeds, but the EJBContext seems to only get populated with a SimplePrincipal. I narrowed it down a bit and found that the EJBContext is populated with the principal as it is supplied to the SecurityClient. If I set a test custom principal on the SecurityClient
client.setSimple(new CustomPrincipal("jdoe"), "theduke");
it is propagated to the EJBContext, but this is not a solution, our actual custom principal (User object) is not yet available to the client and cannot be retrieved pre-login.
So how is one supposed to establish a custom callerPrincipal via LoginModule in JBoss 5 now?
Thanks in advance.
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4213808#4213808
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4213808
The company I work for is looking to purchase a vendor application that runs on JBoss 4.2.2.
We would like to install the new application on our existing server, which has Windows 2003 SP2 and IIS 6.0. The web applications that run from this server were built using .NET 2.0.
The JBoss application does NOT have to integrate with IIS or the .NET applications in any way. The two will remain completely separate.
Can anyone offer any advice as to how easy or difficult this might be? Are there any major problems with either JBoss or IIS that would prevent us from running the two systems in parallel without 'infecting' each other?
Thanks in advance for any advice you have.
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4213806#4213806
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4213806