PLEASE ARGUE WITH ME! I want to get this right.... anonymous wrote : 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? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4057044#4057044 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4057044 _______________________________________________ jboss-user mailing list [email protected] https://lists.jboss.org/mailman/listinfo/jboss-user
