Location of the seam-exception-handler module
by Jason Porter
I put this up on my github account, and will be developing from there.
It's built via gradle, but for those of you that don't have gradle
you can use gradlew.
If you'd like to install it into your maven repo issue gradlew (or
gradlew.bat) install and it'll put it into
~/.m2/repository/org/jboss/seam/exception-handling/seam-exception-handling/
That's all there is to it atm. I'm missing a demo, and some doc
stuff, but it's functional (or at least it is according to the tests
:) ).
--
Jason Porter
http://lightguard-jp.blogspot.com
http://twitter.com/lightguardjp
Software Engineer
Open Source Advocate
PGP key id: 926CCFF5
PGP key available at: keyserver.net, pgp.mit.edu
16 years
Agenda Meeting today
by Pete Muir
* Review current status of all modules (quick overview of what we have, any blocking issues, future work needed for Seam 3.0)
* Work out a plan to help those along that are lagging
Reminder, meeting starts at 10:00 eastern :-)
16 years
Transactions and persistence
by Stuart Douglas
As some of you may know I've started looking at the transactions and persistence module. To start with I am just going to port what we had in seam 2, and we can work form there. I have already ported the UserTransaction wrapper stuff and the transaction interceptor. Alternate UserTransaction wrappers can be specified in seam XML (e.g. if you want to use HibernateTransaction).
I have changed the default to use EJB synchronisations (<transaction:ejb-transaction/> from seam 2), you will need to manually install SeSynchronisations in a non EJB environment. I will look at making the extension smart enough to detect this in most cases, so it will just work either way.
I think that in a normal EE6 setup this module should not require a single line of XML, configuration should only be required if you are in a non-EE environment.
I that the SMPC should be configured with an annotation on a producer field, something like:
@Produces
@ManagedPersistenceContext
@PersistenceContext
@ConversationScoped
EntityManager entityManager;
I don't think we should override the behaviour of every resource producer field by default, and xml configuration should also be supported.
Questions:
Do we want to allow @TransactionAttribute to be used on managed beans (as well as @Transactional)?
I think we should do this. Also there was talk of changing the names used in the seam provided annotation, is that still on the cards (personally I am very much against this)?
Are we still going to provide seam equivalents of the EE API's (e.g. @ApplicationException etc)?
I'm guessing yes.
Seam 2 allowed you to use seam-jndi.properties to specify JNDI properties
Are we going to do something like this? If so where at.
Are we going to support REQUIRES_NEW for managed beans?
I really want this. It will probably only be availible in a JTA environment though, and will probably require XML configuration in some cases.
Are we going to stop the ManagedPersistenceContext from propagating across the transaction boundary for REQUIRES_NEW transactions?
I think that in this situation:
@Stateless
public class MyEJB
{
@Inject EntityManager entityManager;
@TransactionAttribute(TransactionAttributeType.REQUIRES_NEW)
public void doStuff()
{
entityManager.createQuery(...);
...
}
}
we should inject a new EM rather than one that is enlisted in the outside transaction. We could also provide a TransactionScoped em, but that does not solve the problem in the following situation:
@Stateless
public class MyEJB
{
@Inject HelperBean helper;
@TransactionAttribute(TransactionAttributeType.REQUIRES_NEW)
public void doStuff()
{
helper.doStuff()
}
}
public class HelperBean {
@Inject EntityManager entityManager;
public void doStuff() {};
}
I think that we should maintain a stack of EM's in the Managed Persistence Context, and push a new one when we cross a transaction boundary, so all em calls after than point are invoked on a new EM. This is a real problem, and there are heaps of posts about this in the seam 2 forum.
Where do seam managed transactions belong?
Probably the faces module.
Do we want to support multiple RESOURCE_LOCAL transactions?
There have been quite a few posts on the forum about this, but I don't know if it really makes sense. You would need some way of telling the transaction interceptor which UT it is supposed to use. Seam managed transaction would probably have to work on both transactions, wether they are needed or not.
Does all this sound ok? If so I will write this stuff up on the module page and start implementing.
Stuart
16 years
Repositories temporarily down
by Pete Muir
All,
Sonatype have just migrated the snapshot repo to a new URL (the old URLs will be around for a couple of weeks still). I am working on updating the builds and website, but until I'm done deploying snapshots won't work.
Pete
16 years
Moving the regular project meeting to 10:00 Eastern
by Pete Muir
All,
We need to move the IRC meeting to 10:00 Eastern this week, and we will move to that timeslot permanently, as a meeting starting at :45 is unusual ;-) We'll also increase the time slot to 1h, although we normally keep the meeting to 30 - 45m in duration. Location remains the same - #seam-dev on irc.freenode.net.
Pete
16 years
trunk cleanup
by Dan Allen
As I mentioned in the last IRC meeting, there is some cleanup that needs to
be done on trunk. The directories currently getting attention are fine. It's
the cruft that sits around them that needs to go. It's making it really
difficult for newcomers to understand what the heck to checkout. I'll also
put together a brief README.txt that simply explains the purpose of each
root-level directory.
I'd like to nuke the following directories from the Seam repo, which I don't
believe are currently being used.
http://anonsvn.jboss.org/repos/seam/trunk/ (each component has it's own
trunk in Seam 3, so this trunk is erroneous; all Seam 2 stuff is under a
branch)
http://anonsvn.jboss.org/repos/seam/seam-gen/ (the real encore is in
/sandbox)
I would like to consolidate /build and /dist under a single folder. They are
both build/packaging related and I think they should be seen as a single
top-level unit. They are this way in Weld.
http://anonsvn.jboss.org/repos/weld/build/trunk/
I'll do the cleanup tomorrow unless I get feedback otherwise.
-Dan
--
Dan Allen
Senior Software Engineer, Red Hat | Author of Seam in Action
Registered Linux User #231597
http://mojavelinux.com
http://mojavelinux.com/seaminaction
http://www.google.com/profiles/dan.j.allen
16 years
Seam JMS Module Page Updates
by Jordan Ganoff
Dan,
I've updated the module page's Design Notes section[1] to reflect the change
requests from Pete's module review and our discussions during the July 1
meeting in #seam-dev. My next task will be to fix the usage of Arquillian
and JBoss AS 6 so that the tests pass again in Hudson. Once the build is
back on track it the planned implementation can begin.
[1]: http://www.seamframework.org/Seam3/JMSModuleOverview#H-DesignNotes
--
Jordan Ganoff
16 years
AnnotationLiterals in weld-extensions
by Stuart Douglas
Does anyone have any objection to adding a complete set of AnnotationLiterals for all CDI annotations into weld-extensions?
Stuart
16 years
Persistence/Transaction module
by Shane Bryzak
Hey guys,
Does anyone know what the current status is of the
persistence/transaction module? Specifically the transaction part of it
- is it in a state where it can actually be used, and if so, what's
required? I've got a number of things stuck in development at the
moment because they require transaction support.
Shane
16 years
