[seam-dev] declarative transactions for jms and jcr

[John D. Ament]

Dan,

Generally speaking you are correct.  I agree that transaction APIs should be
moved outside of persistence to allow other modules to use them without
needing to use persistence.  I have already opened (and mostly coded)
SEAMPERSIST-35 which separates the SeamManaged annotation from persistence.
The annotation was already moved to solder by Stuart in SOLDER-77.  I hope
that SEAMPERSIST-35 can be integrated with Final so that the API calls are
clear up front.  So I guess what else needs to come out and what does the
timeframe look like for post Seam 3.0.0 for a supplemental release? I was
targetting May for JCR.  To echo George's point, I've seen a few forum posts
about JTA dependencies in Seam Persistence, when running it in a tomcat
environment.  Is it possible for us to do this, while possibly degrading
softly when it's not around?

John

On Fri, Mar 11, 2011 at 8:39 PM, Dan Allen <dan.j.allen at gmail.com> wrote:

> I'd also add that we are using transactions in the Faces module to provide
> managed transactions integrated into the JSF lifecycle. So again, we see the
> transaction support used as a top-level feature.
>
> -Dan
>
>
> On Fri, Mar 11, 2011 at 20:33, Dan Allen <dan.j.allen at gmail.com> wrote:
>
>> On Fri, Mar 11, 2011 at 20:15, George Gastaldi <gegastaldi at gmail.com>wrote:
>>
>>> Nice, I agree that it is the right way to go. I was almost suggesting
>>> separating that on a separate module also.
>>>
>>> However it must be considered that JTA would not always be used (when
>>> running on tomcat for example). How would this module handle these scenarios
>>> ? Would it depend on persistence module itself ?
>>>
>>
>> The Seam transaction API is an abstraction over JTA. It provides the same
>> interface, but can accommodate a different providers underneath.
>>
>> For instance, you should be able to adapt it to any single resource
>> transaction (recognizing that you lose multiple resource enlistment)
>> (similar to what spring does:
>> http://www.infoq.com/articles/spring-modules-jcr). The module could even
>> go a step further and provide simplified transaction configuration for JTA
>> in a standalone environment. I think there is a lot of interesting avenues
>> to explore, which is why having it in a separate module makes a ton of
>> sense. The floor is open for discussion.
>>
>> -Dan
>>
>> --
>> Dan Allen
>> Principal Software Engineer, Red Hat | Author of Seam in Action
>> Registered Linux User #231597
>>
>> http://www.google.com/profiles/dan.j.allen#about
>> http://mojavelinux.com
>> http://mojavelinux.com/seaminaction
>>
>>
>
>
> --
> Dan Allen
> Principal Software Engineer, Red Hat | Author of Seam in Action
> Registered Linux User #231597
>
> http://www.google.com/profiles/dan.j.allen#about
> http://mojavelinux.com
> http://mojavelinux.com/seaminaction
>
>
> _______________________________________________
> seam-dev mailing list
> seam-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/seam-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/seam-dev/attachments/20110311/91bf70da/attachment.html