[1.3 CVS]Tomcat users getting the shaft?

[dsmith1]

First of let me thank the Seam team for their hard work and effort creating an excellent application framework.

Now to the meat, this maybe my misguided misconception but the latest changes for 1.3 HEAD are very dishearten to me.

I?ve been following Seam since 1.0. When it was first announced that Seam would support an EE1.4 environment, including Tomcat I finally took the plunge and we began creating our first application in Seam.

Although it appeared to be overkill to use micro-container, just to get JTA and JNDI support in Tomcat it was easy to live with. Just adding a jar to WEB-INF/lib and the adding jndi.properties to your classpath is all it took.

Following Seam?s CVS, I see that micro-container has been replaced with JBoss Embedded Beta 2. Which requires you to MODIFY the Tomcat base install and modify the conf/server.xml? Possibly affecting other applications already installed on the server.

Essentially you have to install ?JBoss AS? to get setAutoCommit(false), commit(), rollback(), and to lookup an 2 Objects (EMF/UT). I my eyes this is definite overkill.

According to http://www.jboss.com/index.html?module=bb&op=viewtopic&t=110887
1.3 ALPHA included ?extension point for integration with non-JTA transaction environments.? I can find documentation on this anywhere.

I assume he is referring to the new Transaction component http://jira.jboss.com/jira/browse/JBSEAM-1144

According to http://jira.jboss.org/jira/browse/JBSEAM-992#action_12365465 the ?extension? points still not complete.

Which so much of Seam not depending on an EE environment, With the exception of JMS I just do see why the JTA / JNDI dependencies are mandatory.

Since MC has been dropped could you please revisit these issues?

[gavin.king]

I will have a longer response to this post later.

For now: I really did not want to do this, but I just committed some code to let you use Hibernate or JPA tx management instead of JTA. Just do this:

<transaction:hibernate-transaction session="#{mySession}"/>

<transaction:entity-manager-transaction session="#{myEntityManager}"/>

Please test this out for me, since I did it especially for you, and I need to release 1.3 in a couple of days. Thanks.

[bill.burke]

PLEASE ARGUE WITH ME! I want to get this right....

Essentially you have to install ?JBoss AS? to get setAutoCommit(false), commit(), rollback(), and to lookup an 2 Objects (EMF/UT). I my eyes this is definite overkill.

* This is a perception vs. reality problem. Something is overkill if it affects your productivity or the performance of your system. I don't see either being the case here.

* BTW, What do you think the previous incarnation of Seam was bootstrapping? It was pretty much bootstrapping the same exact services.

* Microcontainer is no more overkill than a bean factory like Spring. IMO, it would be overkill for Seam to implement a unit of work pattern and connection pooling. Why not use something that is mature and already works and scales with you automatically as your application grows? If it adds minimal overhead to your boot time, what is the big deal about adding one line of configuration to server.xml?

* Add connection pooling to one of the things you're using.

* You can modify embedded container to only bootstrap JTA, JNDI, and connection pooling.

* While you only want the JTA, JNDI, and connection pooling support. Other users might want JMS, EJB3, JMS, JCA, Security, and/or remoting support. You can easily fine tune embedded container to not use one of these subsystems.

http://wiki.jboss.org/wiki/Wiki.jsp?page=EmbeddedOptimizations

* MC has an "On Demand" feature. Right now components in JBoss 5 are in transition from the old kernel, but soon we hope to have components like JMS only loaded when they are used. That way you won't have to modify the embedded (or AS) distribution and the kernel will only bootstrap subsystems you actually use.

* Right now, the EMbedded container gives you a consistent way to package and configure JBoss components between JBoss AS, Java SE environments, Tomcat standalone, and unit tests. This basically allows us to reuse all JBoss documentation written on how to use and configure these deployments. It makes it easier for us (non-Seam developers) to maintain the components you're using (no duplicate deployment layer). It makes it easier for us to add new component types that are usable between all these different environments (like ESB, Drools, jbpm, etc...).

* 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?

[dsmith1]

The hardship comes in having to modify the tomcat install. With MC you only had to a jar in your WEB-INF/lib.

* While you only want the JTA, JNDI, and connection pooling support. Other users might want JMS, EJB3, JMS, JCA, Security, and/or remoting support. You can easily fine tune embedded container to not use one of these subsystems.

I agree with you on this. If I did want all of those services, why wouldn't I install a full EE server? No to mention you can not cluster Embedded JBoss

[dsmith1]

Please test this out for me, since I did it especially for you, and I need to release 1.3 in a couple of days. Thanks.

Thank you Gavin, for working on this.

Using

<transaction:entity-transaction entityManager="#{myEntityManager}"/>

There is a circular dependency between EntityManager and EntityTransaction so I get one big nasty stack trace

ManagedPersistenceContext
----
 @Unwrap
 public EntityManager getEntityManager() throws NamingException, SystemException
 {
 if (entityManager==null) initEntityManager();

 //join the transaction
 if ( !synchronizationRegistered && !Lifecycle.isDestroying() && Transaction.instance().isActive() )

and

EntityTransaction
------
 @Unwrap
 @Override
 public UserTransaction getTransaction() throws NamingException
 {
 EntityManager em = entityManager.getValue();

<Snip repeating stacktrace>
 at org.jboss.seam.persistence.ManagedPersistenceContext.getEntityManager(ManagedPersistenceContext.java:110)
 at sun.reflect.GeneratedMethodAccessor58.invoke(Unknown Source)
 at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
 at java.lang.reflect.Method.invoke(Method.java:597)
 at org.jboss.seam.util.Reflections.invoke(Reflections.java:21)
 at org.jboss.seam.util.Reflections.invokeAndWrap(Reflections.java:124)
 at org.jboss.seam.Component.callComponentMethod(Component.java:1978)
 at org.jboss.seam.Component.unwrap(Component.java:2004)
 at org.jboss.seam.Component.getInstance(Component.java:1791)
 at org.jboss.seam.Component.getInstance(Component.java:1744)
 at org.jboss.seam.Component.getInstance(Component.java:1738)
 at org.jboss.seam.el.SeamELResolver.getValue(SeamELResolver.java:59)
 at javax.el.CompositeELResolver.getValue(CompositeELResolver.java:135)
 at com.sun.faces.el.FacesCompositeELResolver.getValue(FacesCompositeELResolver.java:64)
 at org.jboss.el.parser.AstIdentifier.getValue(AstIdentifier.java:44)
 at org.jboss.el.ValueExpressionImpl.getValue(ValueExpressionImpl.java:186)
 at org.jboss.seam.core.Expressions$1.getValue(Expressions.java:115)
 at org.jboss.seam.transaction.EntityTransaction.getTransaction(EntityTransaction.java:35)
 at sun.reflect.GeneratedMethodAccessor57.invoke(Unknown Source)
 at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
 at java.lang.reflect.Method.invoke(Method.java:597)
 at org.jboss.seam.util.Reflections.invoke(Reflections.java:21)
 at org.jboss.seam.util.Reflections.invokeAndWrap(Reflections.java:124)
 at org.jboss.seam.Component.callComponentMethod(Component.java:1978)
 at org.jboss.seam.Component.unwrap(Component.java:2004)
 at org.jboss.seam.Component.getInstance(Component.java:1791)
 at org.jboss.seam.Component.getInstance(Component.java:1756)
 at org.jboss.seam.Component.getInstance(Component.java:1733)
 at org.jboss.seam.Component.getInstance(Component.java:1728)
 at org.jboss.seam.transaction.Transaction.instance(Transaction.java:58)
 at org.jboss.seam.persistence.ManagedPersistenceContext.getEntityManager(ManagedPersistenceContext.java:110)
 at sun.reflect.GeneratedMethodAccessor58.invoke(Unknown Source)
 at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
 at java.lang.reflect.Method.invoke(Method.java:597)
 at org.jboss.seam.util.Reflections.invoke(Reflections.java:21)
 at org.jboss.seam.util.Reflections.invokeAndWrap(Reflections.java:124)
 at org.jboss.seam.Component.callComponentMethod(Component.java:1978)
 at org.jboss.seam.Component.unwrap(Component.java:2004)
 at org.jboss.seam.Component.getInstance(Component.java:1791)

[gavin.king]

Hehe, yeah, thats obvious :-)

Let me have another try :)

[gavin.king]

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...)

[gavin.king]

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.

[dsmith1]

Thanks once again for doing this.

Believe it or not I'm in the boat of just installing a full EE environment, but some decisions (made by less than informed people ^^) you just can't go against.

Thanks

[wesleyhales]

FWIW - I think the EEJB/war bootstrap was good because you could run jetty and easily build/test. But, like Gavin said, I wouldn't have been able to take it to production without removing jars and config code.

I *finally* got my tomcat impl up and running with embedded (don't laugh), and I gotta say that 2 lines of config code and a few jars is nothing to gripe about for local development. I am just deploying a context to tomcat via maven/cargo and everything works like a charm. The only thing missing now is a scan interval for picking up changes.

[wesleyhales]

One more thing - Should there be a copy of the embedded Jboss files in Seam? Will seam have it's own version of Jboss Embedded? If no, I think a readme in the Seam dist would suffice...

[dsmith1]

"wesleyhales" wrote:

I *finally* got my tomcat impl up and running with embedded (don't laugh), and I gotta say that 2 lines of config code and a few jars is nothing to gripe about for local development. I am just deploying a context to tomcat via maven/cargo and everything works like a charm. The only thing missing now is a scan interval for picking up changes.

Yes, this isn't difficult to install.

But take it from this prospective, when you already have a Tomcat environment up in production and sysadmins that are "trained" and support it. Try asking them to install some jars to tomcat libs and modify server.xml on ever instance... This isn't even taking into account they will have to change their upgrade process. Just imagine "You want me to do what?, for just one application."

Then you might be thinking ok, hmm maybe you could get them to install JBoss AS. Nope. Imagine again: "You want us to learn some new AS, for just one application@$#%"

[wesleyhales]

Definitely - I totally agree and know that would be near impossible to do... But this is a recent struggle on the Jboss side to have deployable apps that don't need to be modified for dev and prod (of course you could write a custom script if you maintained your own version of RC9) but that would be hackery and unjustifiable.
However, it would be cool for Jboss to maintain the same concept of bootstrapping in a war (like RC9) that would wrap the embedded EJB code base.

I'm fortunate in my situation having Jboss in prod, but I see where you are coming from. But, I don't think there is any way to get around boostrapping at a container level.

[bill.burke]

I agree with you on this. If I did want all of those services, why wouldn't I install a full EE server?

The whole idea is to sneak by the "lightweight" litmus test. We (JBoss) knows these components are lightweight, ala cartable, fast to boot and performant, but we have to fight this "lightweight" propaganda.

But, didn't you answer this yourself? Specifically:

Then you might be thinking ok, hmm maybe you could get them to install JBoss AS. Nope. Imagine again: "You want us to learn some new AS, for just one application@$#%"

Now this is good feedback.

But take it from this prospective, when you already have a Tomcat environment up in production and sysadmins that are "trained" and support it. Try asking them to install some jars to tomcat libs and modify server.xml on ever instance... This isn't even taking into account they will have to change their upgrade process. Just imagine "You want me to do what?, for just one application."

This is good feedback as well. Thanks.