[JBoss Seam] - Re: [1.3 CVS]Tomcat users getting the shaft?
by gavin.kingï¼ jboss.com
anonymous wrote : Seam configuration could have been made simple by writing to the jboss deployment framework. All the gobbledegook in web.xml and tagging ejb jar files with a seam.properties file would have been unneeded. Sure, you would have to use that extra metadata if you wanted to run in WLS or Websphere, but don't you think we should be making things easier in environments where it is possible?
You keep saying this Bill, but it just doesn't seem correct.
I don't see how a JBoss deployer could possibly reduce the web.xml gobbledegook, a typical web.xml in 1.3 on AS 4.2 looks like:
<web-app>
|
| <listener>
| <listener-class>org.jboss.seam.servlet.SeamListener</listener-class>
| </listener>
|
| <filter>
| <filter-name>Seam Filter</filter-name>
| <filter-class>org.jboss.seam.web.SeamFilter</filter-class>
| </filter>
|
| <filter-mapping>
| <filter-name>Seam Filter</filter-name>
| <url-pattern>/*</url-pattern>
| </filter-mapping>
|
| <servlet>
| <servlet-name>Faces Servlet</servlet-name>
| <servlet-class>javax.faces.webapp.FacesServlet</servlet-class>
| <load-on-startup>1</load-on-startup>
| </servlet>
|
| <servlet-mapping>
| <servlet-name>Faces Servlet</servlet-name>
| <url-pattern>*.seam</url-pattern>
| </servlet-mapping>
|
| </web-app>
I'm not sure which bit of that you find offensive, nor do I really see how using a deployer would help.
Oh, and in 1.3, you don't need faces-config at all unless you are using facelets.
As for the seam.properties file: BFD! It's an empty file. Who cares? I would rather require it in all environments than have to document which environments it is required in and which it is not, and make Seam applications more unportable.
The only other bit of required metadata is ejb-jar.xml, which yes, we could eliminate using a deployer, but again, it would reduce portability for little obvious gain in simplicity. It looks exactly the same in every Seam application, and you simply never have to open it or think about it.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4057108#4057108
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4057108
18Â years, 10Â months
[JBoss Seam] - Re: [1.3 CVS]Tomcat users getting the shaft?
by gavin.kingï¼ jboss.com
OK, I had time to sit down and do this properly and actually test it this time. Its now working fine. What this means is that Seam now no longer needs a JTA or JNDI implementation to run (though you will still need the jta api jar in your classpath). Instead, Seam can delegate to EntityTransaction or Hibernate Transaction via an adaptor that implements UserTransaction.
So, the question is, is this a good thing to do? Is it better to run Seam in Tomcat with just the Hibernate jars, and resource-local transaction management, or is it better to go to the effort of installing JBoss Embedded on Tomcat?
Well, if you go the resource-local route you are totally on your own when it comes to:
* connection pooling (last time I checked, Tomcats connection pool was still a PoS and not usable in production)
* JMS
* Mail
* REQUIRES_NEW or NOT_SUPPORTED transaction propagation
* transactions across multiple datasources
* Enterprise-level security
* WebServices
Now, to me these features are kind of non-optional. I simply can't imagine building an application that doesn't need to send and receive email, for example.
Sure, you can certainly find solutions to each of these problems and integrate them into the environment yourself, but it seems to me that this is a fucking lot more work than editing two files in Tomcat's conf/ directory and copying some jars across!
But, you object, before you used to be able to deploy everything in the WAR and not have to futz with Tomcat configuration at all. Well, yes, thats true, and when Bill explained this redesign to me, I knew immediately that there would be lots of complaints about that. But its not like the old way was perfect, not by a long shot. Sure, you didn't have to "reconfigure" Tomcat, but what you did have to do was add additional configuration in components.xml, and add additional jars in your WAR, which made it impossible to create a WAR that deployed on both Tomcat and JBoss (or GlassFish/WLS/WAS). Oh, and you probably didnt see the awful crap code I had to write to workaround the problem of two JNDI trees in Tomcat deployments (I will never understand the reasoning behind a read-only JNDI implementation - it makes about as much sense as a read-only JPA implementation).
Did I make a mistake by removing the MC-only support? I dunno, but my feeling is that there are a lot more people currently using Embeddable EJB3 than plain Microcontainer, and I really wanted to narrow the choice-space of deployment options. We need one or two well-documented options for deploying Seam, not 3 or 4 subtly different permutations of similar things!
Nevertheless its a huge problem for me that people can't now deploy the Seam examples to Tomcat just by typing "ant deploy.tomcat" in the directory. And so I will probably end up using my new resource-local transactions for the Tomcat examples in future releases of 1.3.
OTOH I don't really consider it a good or useful feature for people building serious applications. Unfortunately, one of the things I know about the tech industry is that there are some things you simply can't change people's opinion of, no matter how strong your arguments and evidence. This whole quasi-religious "lightweight" nonsense is one of those things. It used to refer to a meaningful distinction between technologies like Hibernate/Pico/Spring/etc versus the screwed-up IBM-and-Oracle-designed programming models in J2EE. Now it's degenerated to a general vacuous point of FUD directed at anything which depends upon more than 3 jars, or happens to implement standards instead of reinventing boring, well-understood things like transaction management in a proprietary way. The idea that Tomcat=lightweight but JBoss/GlassFish=heavy is simply absurd. JBoss is easier to develop/debug on and easier to deploy into production. And it's a strict superset of Tomcat, that can run Tomcat applications with no code changes.
But, you have to sometimes give people what they think they want, even when it makes little sense. We'll have more success trying to lead people gradually to EE5 by letting them adopt a little piece at a time, as they feel comfortable with it, than we will by telling them to ditch the thing they feel safe and comfortable with.
(Aside: "POJO" is another one that's got totally out-of-hand: I like to believe that I wrote one of the "first" POJO frameworks, certainly people point to the success of Hibernate as validation of the concept. But what I was looking for was just a simpler, more practical programming model, that emphasized the business problem. Now you got guys on TSS arguing that ORM is fundamentally broken because objects need id attributes and hence aren't POJOs. WTF! An identifier attribute is making you unproductive? Your users are complaining that your objects aren't POJO enough? This is not a software development problem, this is pure religion. Man, these guys crack me up...)
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4057107#4057107
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4057107
18Â years, 10Â months
[JBoss jBPM] - Re: Timers get cancelled in TimerServiceBean.ejbTimeout even
by justin.zhou
jbpm.cfg.xml
<jbpm-context>
| <service name="persistence" factory="org.jbpm.persistence.jta.JtaDbPersistenceServiceFactory" >
| <field name="sessionFactoryJndiName">
| <string value="java:/WorkflowSessionFactory" />
| </field>
| <field name="isCurrentSessionEnabled"><true /></field>
| <field name="isTransactionEnabled"><false /></field>
| </service>
| <service name="message" factory="org.jbpm.msg.jms.JmsMessageServiceFactoryImpl" />
| <service name="scheduler" factory="org.jbpm.scheduler.ejbtimer.EjbSchedulerServiceFactory" />
| <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>
hibernate.cfg.xml
<session-factory name="java:/WorkflowSessionFactory">
|
| <!-- hibernate dialect -->
| <property name="hibernate.dialect">org.hibernate.dialect.Oracle9Dialect</property>
|
| <!-- JDBC connection properties (begin) ===
| <property name="hibernate.connection.driver_class">org.hsqldb.jdbcDriver</property>
| <property name="hibernate.connection.url">jdbc:hsqldb:mem:jbpm</property>
| <property name="hibernate.connection.username">sa</property>
| <property name="hibernate.connection.password"></property>
| ==== JDBC connection properties (end) -->
|
| <property name="hibernate.cache.provider_class">org.hibernate.cache.EhCacheProvider</property>
|
| <!-- DataSource properties (begin) -->
| <property name="hibernate.connection.datasource">java:/XAJbpmDS</property>
| <!-- DataSource properties (end) -->
|
| <!-- JTA transaction properties (begin)
| <property name="hibernate.transaction.factory_class">org.hibernate.transaction.JTATransactionFactory</property>
| <property name="hibernate.transaction.manager_lookup_class">org.hibernate.transaction.JBossTransactionManagerLookup</property>
| <property name="jta.UserTransaction">UserTransaction</property>
| === JTA transaction properties (end) -->
|
| <!-- CMT transaction properties (begin) -->
| <property name="hibernate.transaction.factory_class">org.hibernate.transaction.CMTTransactionFactory</property>
| <property name="hibernate.transaction.manager_lookup_class">org.hibernate.transaction.JBossTransactionManagerLookup</property>
| <!-- CMT transaction properties (end) -->
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4057101#4057101
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4057101
18Â years, 10Â months
[JBoss jBPM] - Timers get cancelled in TimerServiceBean.ejbTimeout even Run
by justin.zhou
Hi,
In a processdef, one fork leads to several states, each state has a timer attached. The idea is to do concurrent async executions through the TimerServiceBean. However, get exceptions, when those states changing to join node.
anonymous wrote : Caused by: org.jbpm.graph.def.DelegationException: Row was updated or deleted by another transaction (or u
| nsaved-value mapping was incorrect): [org.jbpm.graph.exe.Token#177]
| at org.jbpm.graph.def.GraphElement.raiseException(GraphElement.java:367)
| at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
| at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
| at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
| at java.lang.reflect.Method.invoke(Method.java:585)
| at org.hibernate.proxy.pojo.javassist.JavassistLazyInitializer.invoke(JavassistLazyInitializer.jav
| a:173)
| at org.jbpm.graph.def.ProcessDefinition_$$_javassist_98.raiseException(ProcessDefinition_$$_javass
| ist_98.java)
| at org.jbpm.graph.def.GraphElement.raiseException(GraphElement.java:358)
| at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
| at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
| at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
| at java.lang.reflect.Method.invoke(Method.java:585)
| at org.hibernate.proxy.pojo.javassist.JavassistLazyInitializer.invoke(JavassistLazyInitializer.jav
| a:173)
| at org.jbpm.graph.node.State_$$_javassist_89.raiseException(State_$$_javassist_89.java)
| at org.jbpm.job.Timer.execute(Timer.java:66)
| at org.jbpm.scheduler.ejbtimer.ExecuteTimerCommand.execute(ExecuteTimerCommand.java:23)
| at org.jbpm.ejb.impl.CommandServiceBean.execute(CommandServiceBean.java:90)
| ... 42 more
|
This is acceptable if things can rollback. However when this happens, timers still been cancelled, so the actions will never been retried and the process sitting dead:
anonymous wrote : 2007-06-23 02:05:15,627 996227 DEBUG [org.jbpm.svc.Services] (EJB-Timer-7[target=jboss.j2ee:jndiName=local
| /TimerServiceBean@11364891,service=EJB]:) closing service 'persistence': org.jbpm.persistence.jta.JtaDbPer
| sistenceService@698193
| 2007-06-23 02:05:15,627 996227 DEBUG [org.jbpm.persistence.db.DbPersistenceService] (EJB-Timer-7[target=jb
| oss.j2ee:jndiName=local/TimerServiceBean@11364891,service=EJB]:) committing hibernate transaction
| 2007-06-23 02:05:15,628 996228 DEBUG [org.hibernate.transaction.CMTTransaction] (EJB-Timer-7[target=jboss.
| j2ee:jndiName=local/TimerServiceBean@11364891,service=EJB]:) commit
| 2007-06-23 02:05:15,628 996228 DEBUG [org.jbpm.svc.Services] (EJB-Timer-7[target=jboss.j2ee:jndiName=local
| /TimerServiceBean@11364891,service=EJB]:) closing service 'scheduler': org.jbpm.scheduler.ejbtimer.EjbSche
| dulerService@b9ec0e
| 2007-06-23 02:05:15,628 996228 DEBUG [org.jbpm.scheduler.ejbtimer.EjbSchedulerService] (EJB-Timer-7[target
| =jboss.j2ee:jndiName=local/TimerServiceBean@11364891,service=EJB]:) removing the timer service session bea
| n
| 2007-06-23 02:05:15,631 996231 DEBUG [org.jbpm.svc.Services] (EJB-Timer-8[target=jboss.j2ee:jndiName=local
| /TimerServiceBean@11364891,service=EJB]:) closing service 'tx': org.jbpm.tx.TxService@38be48
| 2007-06-23 02:05:15,632 996232 ERROR [org.jboss.ejb.plugins.LogInterceptor] (EJB-Timer-8[target=jboss.j2ee
| :jndiName=local/TimerServiceBean@11364891,service=EJB]:) TransactionRolledbackLocalException in method: pu
| blic abstract java.lang.Object org.jbpm.command.CommandService.execute(org.jbpm.command.Command), causedBy
| :
| org.jbpm.JbpmException: couldn't execute org.jbpm.scheduler.ejbtimer.ExecuteTimerCommand@2d0914
| at org.jbpm.ejb.impl.CommandServiceBean.execute(CommandServiceBean.java:92)
| at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
| at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
| at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
| at java.lang.reflect.Method.invoke(Method.java:585)
| at org.jboss.invocation.Invocation.performCall(Invocation.java:359)
| at org.jboss.ejb.StatelessSessionContainer$ContainerInterceptor.invoke(StatelessSessionContainer.j
| ava:237)
| at org.jboss.resource.connectionmanager.CachedConnectionInterceptor.invoke(CachedConnectionInterce
| ptor.java:158)
| at org.jboss.ejb.plugins.StatelessSessionInstanceInterceptor.invoke(StatelessSessionInstanceInterc
| eptor.java:169)
| at org.jboss.ejb.plugins.CallValidationInterceptor.invoke(CallValidationInterceptor.java:63)
| at org.jboss.ejb.plugins.AbstractTxInterceptor.invokeNext(AbstractTxInterceptor.java:121)
|
Should Timer.cancel() rollback facing a RuntimeException in JTA transactions? I tried both JTA and CMP for hibernate, no luck. Did I miss something?
Justin
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4057100#4057100
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4057100
18Â years, 10Â months
[JBoss jBPM] - Why my condtion doesn't get evaluated?
by sparklehorse
I have this snippet process definition
| <decision name="CheckState">
| <transition name="tr2" to="node2">
| <condition>#{JBpmService.status=='DELETED'}</condition>
| </transition>
| <transition name="tr3" to="node3">
| <condition>#{JBpmService.status=='READY'}</condition>
| </transition>
| <transition name="tr0" to="node0">
| <condition>#{JBpmService.status=='UNDEF'}</condition>
| </transition>
| <transition name="tr1" to="node1">
| <condition>#{JBpmService.status=='NOT_LOGGED'}</condition>
| </transition>
| </decision>
|
I've set in contextinstance the object JBpmService in an action prior to the decision ( which has a status property ) with this code
| ContextInstance contextInstance = processInstance.getContextInstance();
| contextInstance.setVariable("JBpmService",jbpms);
| processInstance.signal();
|
What 's wrong?
I get always the first (default) transition.
Is there a simple way to debug this?
I've tried to change the expression in several ways with always the same result: default transition taken. for example
| <condition>#{contextInstance.variables['JBpmService'].status=='READY'}</condition>
| or
| <condition>#{contextInstance.variables.JBpmService.status=='READY'}</condition>
|
i've tried also to set a simple String var status to simplify : always default transition
| <condition>#{status=='READY'}</condition>
| or
| <condition>#{contextInstance.variables.status=='READY'}</condition>
|
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4057098#4057098
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4057098
18Â years, 10Â months