[seam-dev] Arquillian update
John D. Ament
john.d.ament at gmail.com
Tue Jul 12 20:03:06 EDT 2011
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 at kenfinnigan.me> wrote:
> On Tue, Jul 12, 2011 at 12:40 AM, Jason Porter <lightguard.jp at gmail.com>wrote:
>
>> Looks like there was some discussion in IRC about this (
>> http://transcripts.jboss.org/channel/irc.freenode.org/%23seam-dev/2011/%23seam-dev.2011-07-12.log.html#t2011-07-12T01:12:19
>> ).
>>
>> 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/main/java/org/jboss/arquillian/test/api/ArquillianResource.java.
>> I bet we could probably get it to inject
>> https://github.com/arquillian/arquillian-core/blob/master/container/test-api/src/main/java/org/jboss/arquillian/container/test/api/TargetsContainer.javawhich 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 at 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 at 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 at 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 at kenfinnigan.me>
>>>> ken at 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 at gmail.com>
>>>>> john.d.ament at 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 at kenfinnigan.me>
>>>>>>> ken at 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 at kenfinnigan.me><ken at kenfinnigan.me>
>>>>>>>> ken at 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 at kenfinnigan.me><ken at kenfinnigan.me>
>>>>>>>>>> ken at 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 at kenfinnigan.me><ken at kenfinnigan.me><ken at kenfinnigan.me>
>>>>>>>>>>> ken at 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/kenfinnigan/international.git><http://github.com/kenfinnigan/international.git>
>>>>>>>>>>>> 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 at kenfinnigan.me><ken at kenfinnigan.me><ken at kenfinnigan.me>
>>>>>>>>>>>>> ken at 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.com><http://lightguard-jp.blogspot.com>
>>>>>>>>>>>>>>> http://lightguard-jp.blogspot.com
>>>>>>>>>>>>>>> <http://twitter.com/lightguardjp><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.net>
>>>>>>>>>>>>>>> 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.com><http://lightguard-jp.blogspot.com>
>>>>>>>>>>>>> http://lightguard-jp.blogspot.com
>>>>>>>>>>>>> <http://twitter.com/lightguardjp><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.net>
>>>>>>>>>>>>> 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.com><http://lightguard-jp.blogspot.com>
>>>>>>>>>>> http://lightguard-jp.blogspot.com
>>>>>>>>>>> <http://twitter.com/lightguardjp><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.net>
>>>>>>>>>>> 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.com>
>>>>>>>> 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 at lists.jboss.org>seam-dev at 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/seam-dev/attachments/20110712/8f87cdf3/attachment-0001.html
More information about the seam-dev
mailing list