I believe the targets container annotation and a custom arquillian.xml to
essentially have the same deployment multiple times will be what I need to
do this.
- John
On Tue, Jul 12, 2011 at 8:27 AM, Ken Finnigan <ken(a)kenfinnigan.me> wrote:
On Tue, Jul 12, 2011 at 12:40 AM, Jason Porter
<lightguard.jp(a)gmail.com>wrote:
> Looks like there was some discussion in IRC about this (
>
http://transcripts.jboss.org/channel/irc.freenode.org/%23seam-dev/2011/%2...
> ).
>
> There was some chat between John and myself last night. John, when you
have a moment, can you email the list with some more details of the specific
testing use cases you have as we discussed?
> I think we can figure this one out using some Arquillian injections. If
> you look at
https://docs.jboss.org/author/display/ARQ/Resource+injection You
> can see that we can get Arquillian to inject some information about what
> it's doing (granted the docs would be much more useful with an example and
> some of the types of things you can inject. To get some info about take a
> look at
>
https://github.com/arquillian/arquillian-core/blob/master/test/api/src/ma....
> I bet we could probably get it to inject
>
https://github.com/arquillian/arquillian-core/blob/master/container/test-...
would be very helpful (I'm hoping it'll inject it into the deployment
> static method. We'll have to ask Aslak about that) in customizing the
> deployment.
>
>
I think this would solve John's issue of specifying slightly different
configured JMS Lookup factories for each environment.
> Another possibility is to use the multiple containers idea (
>
https://docs.jboss.org/author/display/ARQ/Multiple+Containers) and run
> the same test under different containers with their own deployment. This way
> you could have a utility method create a base archive for your test then
> just augment with things that need to be different.
>
>
I'd looked at this before but thought it only applied to multiple
containers of the same type (ie. the container that was added to the Maven
classpath determined the type of container Arquillian would use), but it
looks like the docs have been updated to show you can specify dependencies
for containers that I presume don't need to be identical.
Whether this supports not defining an Arquillian container in Maven and
then specifying it in container config as a dependency would be a question
for Aslak.
There may be multiple routes we can go with this. I think the best idea
> would be get Aslak in the Seam Community meeting and let's talk to him about
> this and see what he recommends.
>
>
> On Mon, Jul 11, 2011 at 18:06, John D. Ament <john.d.ament(a)gmail.com>wrote:
>
>> Because Ken wrote..
>>
>>
>> "I believe this should be possible by having base tests that define what
>> the test does (in terms of the Seam JMS classes) and then separate tests
>> that extend the base to add the specific libraries for that scenario"
>>
>> Right now there are 22 test classes covering 73 test cases. I do want to
>> multiply this out, hoping that I can do 22 test classes supporting 280+ test
>> cases.
>>
>>
>> On Mon, Jul 11, 2011 at 12:57 PM, Jason Porter
<lightguard.jp(a)gmail.com>wrote:
>>
>>> No sure why you would need to create all the extra classes. Why are you
>>> thinking you need to do that?
>>>
>>> Sent from my iPhone
>>>
>>> On Jul 11, 2011, at 10:45, "John D. Ament"
<john.d.ament(a)gmail.com>
>>> wrote:
>>>
>>> I guess at a high level, yes it would be. However, I was trying to
>>> avoid creating 60 additional classes to support the idea. Essentially there
>>> would be
>>>
>>> testsuite
>>> se-owb-activemq
>>> se-weld-openmq
>>> se-weld-hornetq
>>>
>>>
>>>
>>> John
>>>
>>> On Mon, Jul 11, 2011 at 10:41 AM, Ken Finnigan <
<ken(a)kenfinnigan.me>
>>> ken(a)kenfinnigan.me> wrote:
>>>
>>>> Yes it is a new structure for a Seam module for container testing.
>>>>
>>>> Do you mean that you would want to run the three below scenarios, for
>>>> all tests, against whichever containers you define (ie. AS7, SE, etc)?
I
>>>> believe this should be possible by having base tests that define what
the
>>>> test does (in terms of the Seam JMS classes) and then separate tests
that
>>>> extend the base to add the specific libraries for that scenario, ie OWB
+
>>>> Apache ActiveMQ, which can then be further specialized for any specific
>>>> container configuration that is required.
>>>>
>>>> So I would see you needing something like:
>>>>
>>>> \testsuite
>>>> \internals
>>>> \base (holds the base test cases, with the extended versions
>>>> for each scenario of CDI/JMS provider combos)
>>>> \jboss (profile for as7, with test case extended from the base
>>>> that holds specific container config)
>>>> \tomcat (profile plus test extended with container specific
>>>> config.
>>>>
>>>> You can then have as many container modules as you want.
>>>>
>>>> Does that make sense?
>>>>
>>>> Over the next day or two I'll be completing the migration of i18n to
>>>> option 3 so that it can be used as a base for other modules.
>>>>
>>>> Ken
>>>>
>>>>
>>>>
>>>> On Sun, Jul 10, 2011 at 1:35 PM, John D. Ament
<<john.d.ament(a)gmail.com>
>>>> john.d.ament(a)gmail.com> wrote:
>>>>
>>>>> So what exactly is this? Is this a new structure to support
testing?
>>>>>
>>>>> Here's something I'm interested in. I want to be able to
test seam
>>>>> JMS in an SE type of environment, potentially with starting the JMS
server
>>>>> in the same VM or a separate VM. Part of this requires special
modules in
>>>>> Seam JMS that connect to remote JMS providers, some of this requires
special
>>>>> testing scenarios. Ideally, I would want to run the full test suite
>>>>> repeatedly for each matching pair. For example:
>>>>>
>>>>> Seam JMS + OWB + Apache ActiveMQ
>>>>> Seam JMS + Weld + Hornetq
>>>>> Seam JMS + Weld + OpenMQ
>>>>>
>>>>> Is this approach attainable through this setup?
>>>>>
>>>>> John
>>>>>
>>>>> On Fri, Jul 8, 2011 at 12:11 PM, Jason Porter
<<http://lightguard.jp>
>>>>> lightguard.jp@ <
http://gmail.com>gmail.com> wrote:
>>>>>
>>>>>> I'm liking #3
>>>>>>
>>>>>> Sent from my iPhone
>>>>>>
>>>>>> On Jul 8, 2011, at 9:28, Ken Finnigan <
<ken(a)kenfinnigan.me>
>>>>>> ken(a)kenfinnigan.me> wrote:
>>>>>>
>>>>>> I've been doing some further thinking around this over the
last
>>>>>> couple of days and have come up with 3 possible structures (there
are
>>>>>> undoubtedly more but that is as far as my brain got!):
>>>>>>
>>>>>> 1) The original idea below. ie.
>>>>>> \testsuite
>>>>>> \api
>>>>>> \internals
>>>>>> \smoke
>>>>>>
>>>>>> This setup requires each container, and version there of, to be
a
>>>>>> separate profile. Container specific tests can be excluded with
surefire.
>>>>>>
>>>>>> This does get quite messy quickly if there are lots of
containers,
>>>>>> and lots of container specific tests that need to be written (ie.
lots of
>>>>>> exclusions in profiles for tests you don't want to run)
>>>>>>
>>>>>> 2) More along the lines of Seam Persistence. ie.
>>>>>> \testsuite
>>>>>> \base
>>>>>> \jboss
>>>>>> \weld-embedded
>>>>>> \jetty
>>>>>>
>>>>>> Each version of a container will have their own profile within a
>>>>>> container module.
>>>>>>
>>>>>> This nicely breaks down the containers, but makes it difficult
to
>>>>>> know what pieces of a module (ie. API, internals, etc) are being
tested on
>>>>>> each container.
>>>>>>
>>>>>> 3) A hybrid approach ie.
>>>>>> \testsuite
>>>>>> \base or common
>>>>>> \internals
>>>>>> \base
>>>>>> \jboss
>>>>>> \jetty
>>>>>>
>>>>>> We could either go with a base/common module at the root of
>>>>>> testsuite, which would hold utilities for artifact creation and
all common
>>>>>> tests or base tests for all modules, and/or a base/common for
each submodule
>>>>>> (ie. api, internals). Could take either approach, but a single
base/common
>>>>>> at the testsuite root may make it simpler.
>>>>>>
>>>>>> Each container module would then have a profile for each
version,
>>>>>> with the version of a container that you want to test as part of
builds set
>>>>>> to be active by default.
>>>>>>
>>>>>>
>>>>>> I'm personally leaning towards 3 as it gives us a breakdown
of types
>>>>>> of testing, api, internals, smoke, cluster, etc while also
providing a
>>>>>> breakdown of container specific test requirements.
>>>>>>
>>>>>> Note: All pure unit tests that do not require a container would
still
>>>>>> remain in the appropriate module, ie. api or impl, of the
project.
>>>>>>
>>>>>> Any other options anyone can think of, or tweaks to any of the
above
>>>>>> options?
>>>>>>
>>>>>> What does everyone think?
>>>>>>
>>>>>> Ken
>>>>>>
>>>>>>
>>>>>> On Wed, Jul 6, 2011 at 1:43 PM, Jason Porter
<<http://lightguard.jp><http://lightguard.jp>
>>>>>> lightguard.jp@ <
http://gmail.com>
<
http://gmail.com>gmail.com>wrote:
>>>>>>
>>>>>>> Adding the rest of the list as I think we're nearing the
point we
>>>>>>> want some more feedback.
>>>>>>>
>>>>>>> On Wed, Jul 6, 2011 at 10:35, Ken Finnigan <
<ken@kenfinnigan.me><ken(a)kenfinnigan.me>
>>>>>>> ken(a)kenfinnigan.me> wrote:
>>>>>>>
>>>>>>>> Nasty, read the irc log, not nice at all on AS7 part!
>>>>>>>>
>>>>>>>> At the moment I have a structure similar to persistence,
but more
>>>>>>>> following AS7. ie:
>>>>>>>>
>>>>>>>> \module_parent
>>>>>>>> \api
>>>>>>>> \impl
>>>>>>>> \testsuite
>>>>>>>> \api
>>>>>>>> \benchmark
>>>>>>>> \clustering
>>>>>>>> \internals
>>>>>>>> \smoke
>>>>>>>> \stress
>>>>>>>>
>>>>>>>
>>>>>>> I like the ideas, but I think the structure should be along
the
>>>>>>> lines of the containers (perhaps in addition to, if we're
going to test
>>>>>>> things like clustering and perf).
>>>>>>>
>>>>>>>
>>>>>>>> Idea being that pure unit tests (ie. no container) remain
within
>>>>>>>> either api/impl modules, then any container testing falls
within the
>>>>>>>> testsuite somewhere. Default test only runs api,
internals and smoke,
>>>>>>>> others are picked up by a profile.
>>>>>>>>
>>>>>>>
>>>>>>> Having the different containers be different test modules
also gets
>>>>>>> us away from having to rely on a profile (so you could run
each set of tests
>>>>>>> in one go instead of multiple invocations or lots of
profiles).
>>>>>>>
>>>>>>>
>>>>>>>> At present most of these folders are just ideas about the
kinds of
>>>>>>>> tests we could do (along the AS7 lines), but they seemed
appropriate.
>>>>>>>> Existing i18n module tests are now in internals for
testing the
>>>>>>>> implementation. I see smoke as being more comprehensive
tests covering
>>>>>>>> combined use of features in the module, and quite
possibly integration with
>>>>>>>> other modules too.
>>>>>>>>
>>>>>>>
>>>>>>> I do kind of like the idea of all the tests being inside the
test
>>>>>>> suite, but I'm also okay with basic unit tests living in
api and impl. I
>>>>>>> think we probably need to do some lifecycle tweaking and have
those tests
>>>>>>> under the testsuite run under the integration phase like
Solder.
>>>>>>>
>>>>>>>
>>>>>>>> Which container is run is then all down to profile. Not
sure
>>>>>>>> whether to continue with embedded weld being the default
container that is
>>>>>>>> run when no profile is specified, or to force a profile
to be specified for
>>>>>>>> any container testing.
>>>>>>>>
>>>>>>>> Also had another thought today as to whether the poms for
the test
>>>>>>>> modules should define dependencies, or whether dependent
libraries should be
>>>>>>>> added directly to deployment artifact as library to
prevent unintended
>>>>>>>> libraries from appearing on test classpath.
>>>>>>>>
>>>>>>>
>>>>>>> If we go with test modules instead of profiles this becomes a
non
>>>>>>> issue as they'd just be test deps for the module.
>>>>>>>
>>>>>>> Thoughts?
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On Wed, Jul 6, 2011 at 11:35 AM, Jason Porter
<<http://lightguard.jp><http://lightguard.jp>
>>>>>>>> lightguard.jp@ <
http://gmail.com>
<
http://gmail.com>gmail.com>wrote:
>>>>>>>>
>>>>>>>>> Very cool. I got stuff working for catch last night
too, but there
>>>>>>>>> is a problem if you're testing deployment errors.
It's actually an AS7 and
>>>>>>>>> Arquillian issue. I've opened JIRA tickets about
both. I think what we'll
>>>>>>>>> want to do is set up testing similar to what Stuart
has done in Persistence
>>>>>>>>> with multiple modules. We'll eventually want to
test in (probably) embedded
>>>>>>>>> weld (it's runs quickly, could probably be like a
smoke test), JBoss AS7,
>>>>>>>>> AS6, GF 3.1, Resin and an OWB container or embedded
OWB. Not all of those
>>>>>>>>> containers work right now but then we really could
say we know it all works
>>>>>>>>> on each CDI impl.
>>>>>>>>>
>>>>>>>>> Sent from my iPhone
>>>>>>>>>
>>>>>>>>> On Jul 6, 2011, at 7:44, Ken Finnigan <
<ken@kenfinnigan.me><ken(a)kenfinnigan.me>
>>>>>>>>> ken(a)kenfinnigan.me> wrote:
>>>>>>>>>
>>>>>>>>> I actually "stole" some day job time to try
at work as I thought
>>>>>>>>> the problem might be caused by the local build of as7
I had in my repo, but
>>>>>>>>> that wasn't it.
>>>>>>>>>
>>>>>>>>> Figured out the problem I was having with the aether
class not
>>>>>>>>> being found was caused by the arquillian junit
container dependency being
>>>>>>>>> specified in a parent pom, and then the managed
container being specified in
>>>>>>>>> the pom running the tests, which meant Maven decided
the versions of the
>>>>>>>>> jars in the pom running the tests should take
precedence.
>>>>>>>>>
>>>>>>>>> Adding the junit container dependency to the pom
running the tests
>>>>>>>>> fixed that problem.
>>>>>>>>>
>>>>>>>>> Should be able to finish up the test setup some time
tonight to
>>>>>>>>> then forward to the mailing list for review.
>>>>>>>>>
>>>>>>>>> Ken
>>>>>>>>>
>>>>>>>>> On Tue, Jul 5, 2011 at 11:13 PM, Jason Porter
<<http://lightguard.jp><http://lightguard.jp><http://lightguard.jp>
>>>>>>>>> lightguard.jp@ <
http://gmail.com>
<
http://gmail.com><http://gmail.com>
>>>>>>>>> gmail.com> wrote:
>>>>>>>>>
>>>>>>>>>> Sure, you let me know a time. I'm working on
getting Catch up to
>>>>>>>>>> date as well. BTW, Arquillian 1.0.0.Final will be
out tomorrow, not sure
>>>>>>>>>> about container support though.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On Tue, Jul 5, 2011 at 20:22, Ken Finnigan
<<ken@kenfinnigan.me><ken@kenfinnigan.me><ken(a)kenfinnigan.me>
>>>>>>>>>> ken(a)kenfinnigan.me> wrote:
>>>>>>>>>>
>>>>>>>>>>> Jason,
>>>>>>>>>>>
>>>>>>>>>>> If you have some time tomorrow it would be
appreciated if you
>>>>>>>>>>> could take a look at the new testsuite setup
on i18n. Here's the branch:
>>>>>>>>>>> git://
<
http://github.com/kenfinnigan/international.git><http://github.com/...
>>>>>>>>>>>
github.com/kenfinnigan/international.git
>>>>>>>>>>>
>>>>>>>>>>> I thought I was making progress but now I
seem to have managed
>>>>>>>>>>> to move backwards! For some reason I keep
getting a NoClassDef errors on
>>>>>>>>>>> aether classes. It appears that the classes
are brought in correctly from
>>>>>>>>>>> the arquillian junit container (from
shrinkwrap beta 3), but then the jboss
>>>>>>>>>>> as managed container brings in an older
version of shrinkwrap that doesn't
>>>>>>>>>>> include aether.
>>>>>>>>>>>
>>>>>>>>>>> I'm sure it's a simple fix, as
I've mirrored it off confbuzz,
>>>>>>>>>>> servlet and rest, as well as jbossas, that
all run as7 arquillian tests, but
>>>>>>>>>>> can't see the wood for the trees tonight.
Will be looking at it again
>>>>>>>>>>> tomorrow evening, but if you can spot an easy
fix that would be great!
>>>>>>>>>>>
>>>>>>>>>>> Thanks
>>>>>>>>>>> Ken
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On Tue, Jul 5, 2011 at 1:39 PM, Jason Porter
<<http://lightguard.jp><http://lightguard.jp><http://lightguard.jp>
>>>>>>>>>>> lightguard.jp@ <
http://gmail.com>
<
http://gmail.com><http://gmail.com>
>>>>>>>>>>> gmail.com> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> Okay, great. Let me or Dan know if you
need some help.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> On Tue, Jul 5, 2011 at 11:37, Ken
Finnigan
<<ken@kenfinnigan.me><ken@kenfinnigan.me><ken(a)kenfinnigan.me>
>>>>>>>>>>>> ken(a)kenfinnigan.me> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> Pretty good.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Have the basic structure for the
module in terms of what needs
>>>>>>>>>>>>> to go where.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Currently going through and getting
the existing i18n tests
>>>>>>>>>>>>> working in AS7, which is proving more
of a challenge than I expected!
>>>>>>>>>>>>>
>>>>>>>>>>>>> Of all the tests that pass in
weld-ee-embedded, about a third
>>>>>>>>>>>>> actually pass in AS7! Most of it, I
think, is down to differing classpaths,
>>>>>>>>>>>>> but should be in a position to push
the feature branch to my fork of i18n in
>>>>>>>>>>>>> a couple of days.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Once I've pushed it to my fork I
was going to send an email to
>>>>>>>>>>>>> everyone on seam-dev to get their
thoughts on the layout/setup for testing.
>>>>>>>>>>>>>
>>>>>>>>>>>>> btw, you don't need to worry
about cc'ing my sorstech email in
>>>>>>>>>>>>> the future as I don't use that
much anymore.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Ken
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> On Tue, Jul 5, 2011 at 1:20 PM, Jason
Porter
<<http://lightguard.jp><http://lightguard.jp><http://lightguard.jp>
>>>>>>>>>>>>> lightguard.jp@
<
http://gmail.com> <
http://gmail.com><http://gmail.com>
>>>>>>>>>>>>> gmail.com> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> How goes things with i18n and the
new Arquillian?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> --
>>>>>>>>>>>>>> Jason Porter
>>>>>>>>>>>>>>
<
http://lightguard-jp.blogspot.com><http://lightguard-jp.blogspot.co...
>>>>>>>>>>>>>>
http://lightguard-jp.blogspot.com
>>>>>>>>>>>>>>
<
http://twitter.com/lightguardjp><http://twitter.com/lightguardjp>...
>>>>>>>>>>>>>>
http://twitter.com/lightguardjp
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Software Engineer
>>>>>>>>>>>>>> Open Source Advocate
>>>>>>>>>>>>>> Author of Seam Catch - Next
Generation Java Exception
>>>>>>>>>>>>>> Handling
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> PGP key id: 926CCFF5
>>>>>>>>>>>>>> PGP key available at:
<
http://keyserver.net><http://keyserver.net><http://keyserver....
>>>>>>>>>>>>>>
keyserver.net,
<
http://pgp.mit.edu> <
http://pgp.mit.edu><http://pgp.mit.edu>
>>>>>>>>>>>>>>
pgp.mit.edu
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> --
>>>>>>>>>>>> Jason Porter
>>>>>>>>>>>>
<
http://lightguard-jp.blogspot.com><http://lightguard-jp.blogspot.co...
>>>>>>>>>>>>
http://lightguard-jp.blogspot.com
>>>>>>>>>>>>
<
http://twitter.com/lightguardjp><http://twitter.com/lightguardjp>...
>>>>>>>>>>>>
http://twitter.com/lightguardjp
>>>>>>>>>>>>
>>>>>>>>>>>> Software Engineer
>>>>>>>>>>>> Open Source Advocate
>>>>>>>>>>>> Author of Seam Catch - Next Generation
Java Exception Handling
>>>>>>>>>>>>
>>>>>>>>>>>> PGP key id: 926CCFF5
>>>>>>>>>>>> PGP key available at:
<
http://keyserver.net><http://keyserver.net><http://keyserver....
>>>>>>>>>>>>
keyserver.net, <
http://pgp.mit.edu>
<
http://pgp.mit.edu><http://pgp.mit.edu>
>>>>>>>>>>>>
pgp.mit.edu
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> Jason Porter
>>>>>>>>>>
<
http://lightguard-jp.blogspot.com><http://lightguard-jp.blogspot.co...
>>>>>>>>>>
http://lightguard-jp.blogspot.com
>>>>>>>>>>
<
http://twitter.com/lightguardjp><http://twitter.com/lightguardjp>...
>>>>>>>>>>
http://twitter.com/lightguardjp
>>>>>>>>>>
>>>>>>>>>> Software Engineer
>>>>>>>>>> Open Source Advocate
>>>>>>>>>> Author of Seam Catch - Next Generation Java
Exception Handling
>>>>>>>>>>
>>>>>>>>>> PGP key id: 926CCFF5
>>>>>>>>>> PGP key available at:
<
http://keyserver.net><http://keyserver.net><http://keyserver....
>>>>>>>>>>
keyserver.net, <
http://pgp.mit.edu>
<
http://pgp.mit.edu><http://pgp.mit.edu>
>>>>>>>>>>
pgp.mit.edu
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Jason Porter
>>>>>>>
<
http://lightguard-jp.blogspot.com><http://lightguard-jp.blogspot.co...
>>>>>>>
http://lightguard-jp.blogspot.com
>>>>>>>
<
http://twitter.com/lightguardjp><http://twitter.com/lightguardjp>
>>>>>>>
http://twitter.com/lightguardjp
>>>>>>>
>>>>>>> Software Engineer
>>>>>>> Open Source Advocate
>>>>>>> Author of Seam Catch - Next Generation Java Exception
Handling
>>>>>>>
>>>>>>> PGP key id: 926CCFF5
>>>>>>> PGP key available at: <
http://keyserver.net>
<
http://keyserver.net>
>>>>>>>
keyserver.net, <
http://pgp.mit.edu>
<
http://pgp.mit.edu>pgp.mit.edu
>>>>>>>
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> seam-dev mailing list
>>>>>> <seam-dev@lists.jboss.org>seam-dev(a)lists.jboss.org
>>>>>> <
https://lists.jboss.org/mailman/listinfo/seam-dev>
>>>>>>
https://lists.jboss.org/mailman/listinfo/seam-dev
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
>
> --
> Jason Porter
>
http://lightguard-jp.blogspot.com
>
http://twitter.com/lightguardjp
>
> Software Engineer
> Open Source Advocate
> Author of Seam Catch - Next Generation Java Exception Handling
>
> PGP key id: 926CCFF5
> PGP key available at:
keyserver.net,
pgp.mit.edu
>
Ken