[Microcontainer] - Re: Using VFS to create a symbolic link from WEB-INF/lib
by mwringe
Is there anyupdate on the TLD issue? is is being tracked in jira anywhere?
There are a few ways of getting around it right now, but they are a pain.
- getting the actual location of where the webapp is deployed and copying the file across. Finding the actual file location is a big pain requiring many levels of hacks.
- manipulating the web.xml metadata (easily done with a deployer) to redefine the JspServlet. This will override the JspServlet setting in jboss-web.deployer/web.xml (the shared web.xml file for all webapps). By setting a properly formatted <init-param> for the JspServlet you can make it add any tld from any specified jar with no requirements on it existing in the WEB-INF directory of your webapp.
| <init-param>
| <description>JSTL standard tlds</description>
| <param-name>tagLibJar2</param-name>
| <param-value>../location-to-jar/jar-containing-tld.jar</param-value>
| </init-param>
|
The problem here is that it does change the global JspServlet setting and all webapps will be able to find your tlds. And its probably not the safest operation to be overwriting the JspServlet like this, but it is possible.
It would be a lot easier if this default global web.xml was being handled by deployers and was being exported as an attachment that other deployers could use (like the current MergedJBossWebMetaDataDeployer).
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4227616#4227616
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4227616
15 years, 7 months
[JBoss jBPM] - Re: Design Patterns
by rwallis
1) there is a real persisted wait state (and its set from one minute to 19 days depending on the action taken by the user) but we have been getting stack overflow errors (after running 24/7 for about 2 weeks) and then timers stop working (we have to restart the application server) and this is considered the culprit. Given this, one of our developers doesn't want to use jBPM for batch processing that would require escalation (via a timer) every minute. I however would like to use jBPM because then we could leverage jBPM to create fail/retry logic with nodes and the jBPM console for visibility into the batch processing. (and yes there probably are alternatives to using the same token over in a loop but again thats why this was titled design patterns).
2) In the second part, in its simplest, its a task node to a fork with one transition from the fork going back to the task node and a second transition from the fork going to a different task node. When done manually from the first task node (user signals the transition rather then some external event or a timer) its an easy way to allow for a "Resend" A simple example would be "Supervisory Approval" where tokens comes into a "Processor" task node wHere they transition the token to "Supervisor Approval" but still want the token to remain in their task node in parallel, having the "send for approval" transition go to a fork solves this easily, the token goes back to the "Processor" task node and then also goes to the "Superviosr Approval" task node (with a join at the end of all of this of course). The processor continues to have it as an active task and so does the supervisor, then if the processor has an additional task that needs to be done by the supervisor (but again wants to continue to have the task as well) they simply transition the token to the supervisor task node again. In testing this all works perfectly, and all of the child tokens complete out of the join properly but it does seem that there is a limit to the number of inherited children (like maybe 1000) so if the transitions are manual no problem but if automated with timer then its a problem. The question was asked because there is concern that some "idiot" might want to click the button 1000 times an therefore cause stack overflow to occur, we can put a check in to limit this to something reasonable like 10 times but maybe we shouldn't do this at all...
P.S. sorry about posting initially to the wrong forum.
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4227613#4227613
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4227613
15 years, 7 months
[JBoss jBPM] - Re: nothing persisting?
by ibivibiv
So, now that I know that the JTA persistance is not committing, can anyone give me a hint as to the why? I'll paste my config and a quick example of a MDB that starts a process that never commits to the database.
| <jbpm-configuration>
|
| <jbpm-context>
| <service name="persistence" factory="org.jbpm.persistence.jta.JtaDbPersistenceServiceFactory" />
| <!--<service name="persistence" factory="org.jbpm.persistence.db.DbPersistenceServiceFactory" />-->
| <service name="message" factory="org.jbpm.msg.jms.JmsMessageServiceFactory" />
| <service name="scheduler" factory="org.jbpm.scheduler.ejbtimer.EntitySchedulerServiceFactory" />
| <service name="tx" factory="org.jbpm.tx.TxServiceFactory" />
| <service name="logging" factory="org.jbpm.logging.db.DbLoggingServiceFactory" />
| <service name="authentication" factory="org.jbpm.security.authentication.DefaultAuthenticationServiceFactory" />
| </jbpm-context>
|
| <!-- use the context class loader -->
| <string name="jbpm.classLoader" value="context" />
|
| <!--
| Note, that the default job executor needs to be overwritten with a null value.
| In the enterprise configuration there should be no job executor.
| Async messaging is there bound to jms and scheduling to ejb timers.
| -->
| <null name="jbpm.job.executor" />
|
| </jbpm-configuration>
|
|
| package com.theplanet.jbpm.messagebeans;
|
| import javax.ejb.ActivationConfigProperty;
| import javax.ejb.MessageDriven;
| import javax.ejb.TransactionManagement;
| import javax.ejb.TransactionManagementType;
| import javax.ejb.TransactionAttribute;
| import javax.ejb.TransactionAttributeType;
| import javax.jms.Message;
| import javax.jms.TextMessage;
| import javax.jms.MessageListener;
|
| import org.jbpm.graph.exe.ProcessInstance;
| import org.jbpm.JbpmConfiguration;
| import org.jbpm.JbpmContext;
|
|
| /**
| * Message-Driven Bean implementation class for: ProcessMDB
| *
| */
| @MessageDriven(name = "ProcessMDB", activationConfig = {
| @ActivationConfigProperty(propertyName = "destinationType", propertyValue = "javax.jms.Queue"),
| @ActivationConfigProperty(propertyName = "destination", propertyValue = "queue/ProcessQueue"),
| @ActivationConfigProperty(propertyName = "acknowledgeMode", propertyValue = "Auto-acknowledge") })
| @TransactionManagement(TransactionManagementType.CONTAINER)
| @TransactionAttribute(TransactionAttributeType.REQUIRED)
| public class CopyOfProcessMDB implements MessageListener {
|
| /**
| * Default constructor.
| */
| public CopyOfProcessMDB() {
| // TODO Auto-generated constructor stub
| }
|
| /**
| * @see MessageListener#onMessage(Message)
| */
| public void onMessage(Message message) {
|
| JbpmConfiguration jbpmConfig = JbpmConfiguration.getInstance();
| JbpmContext jbpmContext = jbpmConfig.createJbpmContext();
|
| try {
|
| TextMessage txt = (TextMessage) message;
| ProcessInstance processInstance = jbpmContext
| .newProcessInstanceForUpdate("TestProcess");
|
| processInstance.signal();
| jbpmContext.save(processInstance);
|
| } catch (final Exception exc) {
| try {
| exc.printStackTrace();
|
| // jbpmContext.setRollbackOnly(); old stuff when using bean managed
|
| } catch (final Exception e) {
|
| }
| } finally {
| // jbpmContext.close(); same on bean managed
|
| }
|
| }
|
| }
|
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4227607#4227607
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4227607
15 years, 7 months