geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jarek Gawor <>
Subject Re: [discuss]atinject tck
Date Wed, 11 Aug 2010 16:56:37 GMT

As Lin pointed out the atinject is a bit different. Both JCDI and Bean
Validation TCKs can be run in standalone and in-container mode. For
Geronimo we run them in in-container mode. However, the atinject TCK
seems to only support the standalone mode. So the question is, is it
enough to just run the atinject TCK in standalone mode or do we have
to write some extra code to ensure it runs in in-container mode with


On Wed, Aug 11, 2010 at 12:06 PM, Donald Woods <> wrote:
> It looks like the same general setup as the BVAL tck, in that it uses
> the surefire plugin and a suiteXmlFiles which is either provided in the
> downloaded TCK files or provided locally (which I don't think we can use
> the open web beans overrides unless we have TCK challenges approved by
> Oracle.)
> You should be able to copy the content from
> over into our geronimo/tck/branches/3.0/ area and make a
> atinject-tck-runner project similar to the validator-tck-runner.  Jarek
> already created the required jboss-test-harness-geronimo module to allow
> the JBoss TCK testharness to start/stop a Geronimo server, so the
> biggest part of the effort would be mapping the openwebbeans profile
> from Tomcat over to using Geronimo....
> Since the JBoss provided TCKs use ASL 2.0, take a look at their website,
> which usually describes in pretty good detail how to run the TCKs in
> other app servers.
> -Donald
> On 8/11/10 9:30 AM, Lin Sun wrote:
>> Hi
>> I have been investigating how to run the JSR 330 tck (also called the
>> atinject tck), as this is a requirement for Java EE 6 compliance.
>> I am able to check out the open web bean project and run its atinject
>> tck from the open web bean project checkout dir, using the atinject
>> tck runner provided by open web bean   Basically the atinject tck
>> runner deploys the tck test classes (note it is not an archive) to a
>> stand-alone test container and the atinect tck tests verifies various
>> fields/constructors/methods are injected correctly.   The special part
>> of the atinject tck is that there is no Java EE archive and all tests
>> are written as junit tests.
>> My first thought is we could reuse the atinject tck runner from open
>> web bean project to run the tck, but the concern is that the tests are
>> only deployed to a stand-alone test container instead of the Geronimo
>> server.  So I am not sure if that is valid.
>> My current thoughts are that atinject tck is relatively small and are
>> junit tests thus it is reasonable to run in a stand-alone test
>> container.  The JCDI(JSR 299) tck overlaps some of the atinject tck
>> and should run with the real Application Server like Geronimo.
>> If we also agree with this approach, I think we can just reuse the
>> atinject tck runner in open web bean.   WDYT?
>> Lin
>> ---------- Forwarded message ----------
>> From: Kevan Miller <>
>> Date: Tue, Aug 10, 2010 at 10:43 PM
>> Subject: Re: JCDI and Bean Validation TCKs
>> To:
>> On Jul 21, 2010, at 12:04 AM, Jarek Gawor wrote:
>>> Ok, it sounds like more people prefer to move these tcks into a public
>>> svn location.
>>> So I guess we should create a
>>> repo and move the tcks
>>> over. There should be no problem with moving the following modules
>>> (since it's all Apache licensed stuff):
>>> 1) jboss-test-harness-geronimo - integration code between jboss test
>>> harness & geronimo which is used by #2 and #3
>>> 2) jcdi-testsuite - jcdi tck runner
>>> 3) validator-testsuite - bean validation tck runner
>> All,
>> Please note that the above TCK tests are in our public SVN. Unlike the
>> mainstream Java EE TCK tests, which we are required to keep private,
>> these tests are Apache licensed. We can discuss them openly. This
>> means we have TCK materials in two places (public svn and private
>> svn). I *much* prefer to have our TCK materials in public svn. So,
>> although it complicates some things, IMO, we should err on the side of
>> openness, rather than simplicity...
>> --kevan

View raw message