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 <[email protected]> wrote: > On Tue, Jul 12, 2011 at 12:40 AM, Jason Porter <[email protected]>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 <[email protected]>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 >>> <[email protected]>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" <[email protected]> >>>> 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 < <[email protected]> >>>> [email protected]> 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 <<[email protected]> >>>>> [email protected]> 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 < <[email protected]> >>>>>>> [email protected]> 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 < >>>>>>>> <[email protected]><[email protected]> >>>>>>>> [email protected]> 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 < >>>>>>>>>> <[email protected]><[email protected]> >>>>>>>>>> [email protected]> 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 >>>>>>>>>>> <<[email protected]><[email protected]><[email protected]> >>>>>>>>>>> [email protected]> 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 >>>>>>>>>>>>> <<[email protected]><[email protected]><[email protected]> >>>>>>>>>>>>> [email protected]> 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 >>>>>>> <[email protected]>[email protected] >>>>>>> <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 >
_______________________________________________ seam-dev mailing list [email protected] https://lists.jboss.org/mailman/listinfo/seam-dev
