<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On 11/07/2011, at 5:53 PM, Mark Struberg wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div>Hi Emmanuel!<br><br>My point is: Some features of seam-persistence are more a seam-hibernate (as upgrade path from Seam2 this makes perfect sense I guess) than a general JPA thingy. They only work with Hibernate and cannot be generalized to other JPA providers! And even if you use Hibernate, then there are a few restrictions which should get added to the documentation. I'll try to sum up:<br><br>If you use a scope bigger than @RequestScoped on the EnitityManagerProducer then:<br><br>* This only works with Hibernate and FlushMode.MANUAL. No other JPA provider will do since the EntityManager impls are usually _not_ Serializable.<br></div></blockquote><div><br></div><div>This will still work fine as long as the container does not actually try and actually serialize the session. Not everyone uses HA clustering.</div><br><blockquote type="cite"><div><br>* The problem is that most queries will be performed inside a @Transactional bracelet thus they might have an open transaction. In this case there is no temp-transaction which could be rollbacked. Thus the 'baby non auto-flush' doesn't work out I fear.<br></div></blockquote><blockquote type="cite"><div><font class="Apple-style-span" color="#000000"><br></font>* Also in JPA managed entities must not get accessed from multiple threads in parallel. All scopes longer than @RequestScoped are subject of being hit by parallel AJAX calls or requests from multiple windows. It's only a matter of load to get this situation. I was easily able to reproduce such scenarios with JMeter [1] with 50 parallel threads.<br></div></blockquote><div><br></div><div>From the conversion scope bit of the spec: "The container ensures that a long-running conversation may be associated with at most one request at a time, by blocking or rejecting concurrent requests." If you were seeing behaviour to the contrary then this is a bug.</div><blockquote type="cite"><div><br>* EntityManager#lock must not get used.<br></div></blockquote><blockquote type="cite"><div><br>* native Queries might return wrong results.<br><br>* non-trivial Queries might return wrong results.<br></div></blockquote><div><br></div><div>This is the expected behaviour when using a MANUAL flush mode. </div><br><blockquote type="cite"><div><br>* no select for update allowed.<br><br></div></blockquote><blockquote type="cite"><div><font class="Apple-style-span" color="#000000"><br></font>But I agree completely with you that a Serializable EntityManager would be a BIG benefit. I frankly fear this is only possible by dropping all the pessimistic locking stuff and not doing so much things automatically. There is a JPA-like project called eBean [2] which does exactly that. But it's not a JPA provider exactly because of that... <br></div></blockquote><div><br></div><div>I don't see how it is possible to serialize an EntityManager that is enlisted in a transaction anyway, and as the locks only last till the end of the transaction I don't see how Serialization affects locking. </div><br><blockquote type="cite"><div><br>Imo the easiest way to cope with that situation is to emulate the transactional stuff of EJB with an extended EntityManager. Opening the transaction once the outer @Transactional gets entered, and committing/rollback + closing the EntityManager as soon as you leave the outermost @Transactional method. This will detach all entities immediately, so they can be transfered, used, whatever... One just needs to em.merge them to get them stored later. <br><br></div></blockquote><div><br></div><div>Not really sure what you mean here, arn't you just describing something similar to a standard transaction scoped em?</div><div><br></div><div>Stuart</div><br><blockquote type="cite"><div>I'm not sure about Hibernate, but OpenJPA and Eclipselink both store _loaded and _dirty bitfields in detached entities and this info will also get serialized along the line.<br><br>LieGrue,<br>strub<br><br>[1] <a href="http://jakarta.apache.org/jmeter/">http://jakarta.apache.org/jmeter/</a><br>[2] <a href="http://www.avaje.org/">http://www.avaje.org/</a><br><br>--- On Mon, 7/11/11, Emmanuel Bernard <<a href="mailto:emmanuel@hibernate.org">emmanuel@hibernate.org</a>> wrote:<br><br><blockquote type="cite">From: Emmanuel Bernard <<a href="mailto:emmanuel@hibernate.org">emmanuel@hibernate.org</a>><br></blockquote><blockquote type="cite">Subject: Re: [seam-dev] [seam-persistence] ManagedPersistenceContextExtension<br></blockquote><blockquote type="cite">To: "Mark Struberg" <<a href="mailto:struberg@yahoo.de">struberg@yahoo.de</a>><br></blockquote><blockquote type="cite">Cc: "John D. Ament" <<a href="mailto:john.d.ament@gmail.com">john.d.ament@gmail.com</a>>, "<a href="mailto:seam-dev@lists.jboss.org">seam-dev@lists.jboss.org</a>" <<a href="mailto:seam-dev@lists.jboss.org">seam-dev@lists.jboss.org</a>><br></blockquote><blockquote type="cite">Date: Monday, July 11, 2011, 12:08 AM<br></blockquote><blockquote type="cite">Hibernate has the notion of<br></blockquote><blockquote type="cite">FlushMode.MANUAL to prevent operations from being pushed to<br></blockquote><blockquote type="cite">the DB even upon queries. JPA has a baby version of that<br></blockquote><blockquote type="cite">with extended persistence contexts behaving outside<br></blockquote><blockquote type="cite">transactions. <br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">Yes some methods like lock are not allowed when the em is<br></blockquote><blockquote type="cite">expected to be passivated. But that's not a reason to<br></blockquote><blockquote type="cite">disable a useful feature (passivation) altogether. <br></blockquote><blockquote type="cite">Passivation is sometimes not possible but that far from<br></blockquote><blockquote type="cite">your statement "This is never _never_ NEVER true. The<br></blockquote><blockquote type="cite">EntityManager is not Serializable!". <br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">Emmanuel<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">PS: There are more efficient ways to passivate an<br></blockquote><blockquote type="cite">entityManager than serializing it with some help from the<br></blockquote><blockquote type="cite">persistence provider. I don't remember if we ever finished<br></blockquote><blockquote type="cite">this work. <br></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">On 11 juil. 2011, at 01:44, Mark Struberg <<a href="mailto:struberg@yahoo.de">struberg@yahoo.de</a>><br></blockquote><blockquote type="cite">wrote:<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite"><blockquote type="cite">There are a few problems which can happen:<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">a.) EmtityManager#lock(java.lang.Object o,<br></blockquote></blockquote><blockquote type="cite">javax.persistence.LockModeType lockModeType); and others<br></blockquote><blockquote type="cite">with LockType#PESSIMISTIC_*<br></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">b.) Consider you have an Entity dirty or a fresh one<br></blockquote></blockquote><blockquote type="cite">created with em.persist(). And now you do a non-trivial<br></blockquote><blockquote type="cite">query. In order to guarantee that this new/modified entity<br></blockquote><blockquote type="cite">gets evaluated properly, JPA _explicitly_ allows the<br></blockquote><blockquote type="cite">EntityManager to write those values into the database.<br></blockquote><blockquote type="cite">Voila, you have your open transaction! Not too many people<br></blockquote><blockquote type="cite">are aware of that but yes, querying from the database can<br></blockquote><blockquote type="cite">lead to a SQL INSERT or SQL UPDATE into the database! Of<br></blockquote><blockquote type="cite">course, you better _not_ commit those changes immediately<br></blockquote><blockquote type="cite">;)<br></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">LieGrue,<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">strub<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">--- On Sun, 7/10/11, John D. Ament <<a href="mailto:john.d.ament@gmail.com">john.d.ament@gmail.com</a>><br></blockquote></blockquote><blockquote type="cite">wrote:<br></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">From: John D. Ament <<a href="mailto:john.d.ament@gmail.com">john.d.ament@gmail.com</a>><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">Subject: Re: [seam-dev] [seam-persistence]<br></blockquote></blockquote><blockquote type="cite">ManagedPersistenceContextExtension<br></blockquote><blockquote type="cite"><blockquote type="cite">To: "Mark Struberg" <<a href="mailto:struberg@yahoo.de">struberg@yahoo.de</a>><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">Cc: "Stuart Douglas" <<a href="mailto:stuart.w.douglas@gmail.com">stuart.w.douglas@gmail.com</a>>,<br></blockquote></blockquote><blockquote type="cite"><a href="mailto:seam-dev@lists.jboss.org">seam-dev@lists.jboss.org</a><br></blockquote><blockquote type="cite"><blockquote type="cite">Date: Sunday, July 10, 2011, 11:29 PM<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">But is the select for update done inside the<br></blockquote></blockquote><blockquote type="cite">entitymanager object or a query instance? I don't<br></blockquote><blockquote type="cite">think EntityManager.find(Class,Id) does any type of hold on<br></blockquote><blockquote type="cite">the object found.<br></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">John<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">On Sun, Jul 10, 2011 at 7:15 PM, Mark Struberg <<a href="mailto:struberg@yahoo.de">struberg@yahoo.de</a>><br></blockquote></blockquote><blockquote type="cite">wrote:<br></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">Stu, whenever you do a "select for update" or any<br></blockquote></blockquote><blockquote type="cite">manual locking, you will end up with an EntityManager which<br></blockquote><blockquote type="cite">cannot be transfered to another node. Even if hibernate<br></blockquote><blockquote type="cite">marks it's EntityManager Serializable, it just isn't if I<br></blockquote><blockquote type="cite">didn't miss something!<br></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">LieGrue,<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">strub<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">--- On Sun, 7/10/11, Stuart Douglas <<a href="mailto:stuart.w.douglas@gmail.com">stuart.w.douglas@gmail.com</a>><br></blockquote></blockquote><blockquote type="cite">wrote:<br></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">From: Stuart Douglas <<a href="mailto:stuart.w.douglas@gmail.com">stuart.w.douglas@gmail.com</a>><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">Subject: Re: [seam-dev] [seam-persistence]<br></blockquote></blockquote></blockquote><blockquote type="cite">ManagedPersistenceContextExtension<br></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">To: "Mark Struberg" <<a href="mailto:struberg@yahoo.de">struberg@yahoo.de</a>><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">Cc: <a href="mailto:seam-dev@lists.jboss.org">seam-dev@lists.jboss.org</a><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">Date: Sunday, July 10, 2011, 11:07 PM<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">On 11/07/2011, at 4:07 AM, Mark Struberg wrote:<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">Hi folks!<br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">While reviewing an OWB bug report, 2 questions<br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite">came<br></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">up:<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">a.) EnvironmentUtils#isEEEnvironment() relies<br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite">on the<br></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">absence of 'javax.ejb.Stateless' to decide if a<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">PersitenceUnit gets injected or if you need to do<br></blockquote></blockquote></blockquote><blockquote type="cite">it<br></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">yourself. I think this is an unrelieable<br></blockquote></blockquote></blockquote><blockquote type="cite">assumption. E.g.<br></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">there are a few Extensions which emulate Stateless<br></blockquote></blockquote></blockquote><blockquote type="cite">Session<br></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">beans via a CDI Extension by morphing them into<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">@ApplicationScoped.<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">This is not ideal, but I don't think there is<br></blockquote></blockquote></blockquote><blockquote type="cite">really any<br></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">portable way to detect if the environment is an<br></blockquote></blockquote></blockquote><blockquote type="cite">EE<br></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">environment or not. I was originally planning to<br></blockquote></blockquote></blockquote><blockquote type="cite">add a<br></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">method for configuring this, but it appears I did<br></blockquote></blockquote></blockquote><blockquote type="cite">not get<br></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">around to it.<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">b.) in<br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote></blockquote><blockquote type="cite">ManagedPersistenceContextExtension#registerManagedPersistenceContext<br></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">you register the bean for the EntityManager as<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">passivationCapable. This is never _never_ NEVER<br></blockquote></blockquote></blockquote><blockquote type="cite">true. The<br></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">EntityManager is not Serializable! There is imo no<br></blockquote></blockquote></blockquote><blockquote type="cite">way to<br></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">have an EntityManager in a bean scoped other than<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">@RequestScoped or shorter (e.g.<br></blockquote></blockquote></blockquote><blockquote type="cite">@TransactionalScoped). Any<br></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">other trick is not working in a portable way. This<br></blockquote></blockquote></blockquote><blockquote type="cite">is mainly<br></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">caused by JPA still supporting pessimistic locking<br></blockquote></blockquote></blockquote><blockquote type="cite">(_real_<br></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">locks in the database) as first class citizens.<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">Without this it is not possible to have a<br></blockquote></blockquote></blockquote><blockquote type="cite">conversation<br></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">scoped entity manager. The hibernate EntityManager<br></blockquote></blockquote></blockquote><blockquote type="cite">is in<br></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">fact Serializable. Locks should not be a problem<br></blockquote></blockquote></blockquote><blockquote type="cite">as long as<br></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">you do not attempt to serialise the EM in the<br></blockquote></blockquote></blockquote><blockquote type="cite">middle of a<br></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">transaction.<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">Stuart<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">But I'd be happy if anyone could enlighten me<br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite">and tell<br></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">us how it works ;)<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">LieGrue,<br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">strub<br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite">_______________________________________________<br></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">seam-dev mailing list<br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><a href="mailto:seam-dev@lists.jboss.org">seam-dev@lists.jboss.org</a><br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><a href="https://lists.jboss.org/mailman/listinfo/seam-dev">https://lists.jboss.org/mailman/listinfo/seam-dev</a><br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">_______________________________________________<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">seam-dev mailing list<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><a href="mailto:seam-dev@lists.jboss.org">seam-dev@lists.jboss.org</a><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><a href="https://lists.jboss.org/mailman/listinfo/seam-dev">https://lists.jboss.org/mailman/listinfo/seam-dev</a><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">_______________________________________________<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">seam-dev mailing list<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><a href="mailto:seam-dev@lists.jboss.org">seam-dev@lists.jboss.org</a><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><a href="https://lists.jboss.org/mailman/listinfo/seam-dev">https://lists.jboss.org/mailman/listinfo/seam-dev</a><br></blockquote></blockquote><blockquote type="cite"><br></blockquote><br>_______________________________________________<br>seam-dev mailing list<br><a href="mailto:seam-dev@lists.jboss.org">seam-dev@lists.jboss.org</a><br>https://lists.jboss.org/mailman/listinfo/seam-dev<br></div></blockquote></div><br></body></html>