User-agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.5.3
Yes, my bad. Sorry for the confusion. There is a certified TCK
for Java EE -- that is available by license from Oracle. The
builds for Jakarta EE TCKs aren't "certified," but we can
certainly use them as they trend toward becoming certified, once
Jakarta EE 8 completes. (But I was still confused.)
-- Ed
On 3/12/2019 1:11 PM, Kevin Sutter
wrote:
Ed,
Are we talking about two different things here?
You pointed Scott at the download page for Eclipse Glassfish
5.1. Sure, that's the Java EE 8 compliant version of
Glassfish, but that doesn't help with running the test
buckets. Unless you mean there is a certified version of the
TCK, but I didn't think we had that packaged yet. Scott has
tried building the TCK himself as well as pulling from Maven.
It sounds like Scott might be making some
progress with the latest information from Lance, but that
still doesn't sound like the "final answer"...
---------------------------------------------------
Kevin Sutter
STSM, MicroProfile and Java EE architect
e-mail: sutter@xxxxxxxxxx Twitter: @kwsutter
phone: tl-553-3620 (office), 507-253-3620 (office)
LinkedIn: https://www.linkedin.com/in/kevinwsutter
Scott, it may not make any difference currently, but in
general, I'd recommend you use the build that has was
certified compatible, as opposed to the last successful
build. While we intend that all builds will remain
compatible, the infrastructure isn't reliable enough yet to
assure that always happens and, we don't use CTS results as
a signal to declare success or failure to the Eclipse
GlassFish pipeline builds. If you want to help make that
happen, we'd welcome the contributions. The certified builds
are linked from this page: Eclipse GlassFish
Downloads
I was wondering about the
delieverable.dir based on what was in the Runcts.
Just completed testing that out as Alwin suggested
and it looks like that was the issue as we again
have samples passing on the RI again now using
runclient. ;)
That should not need to be set in a bundle, so seems like
something is amiss. Typically you would set that in a
workspace to the install/<delvierable.dir> you are
currently working with.
Looks like the delievearble.dir is
new?
No, this was introduced into the development process for
the CTS master workspace in 2008 and should not be visible
in a built bundle. The install directory contains the bin
directory for the various technologies. j2ee for example
is for CTS
I don't recall it in the old
javaeetck nor had to set it in the past when using
runclient? Sounds like we might need to make that
a required argument.
Again, this should not need to be set in a bundle, it
sounds like something is off in the build process.
Thanks!
Scott E. Highbarger
[shighbar@xxxxxxxxxx]
Advisory Software Engineer
WebSphere Application Server CTS
IBM Software Group
(303) 773-5264 <1B477311.jpg>
<graycol.gif>Lance Andersen
---03/11/2019 12:57:41 PM---Hi Scott Are you
running out of a workspace or a built release from
your workspace?
Can you try by setting the varibale
-Ddeliverable.dir=j2ee for GF while running
'runclient'.
I will investigate it further by tomorrow if
it does not work.
Regards,
Alwin
On 11/03/19 10:42 PM, Scott Highbarger
wrote:
Hi all, thanks Anand
and Bhat for your earlier responses.
Thanks for the pointer to the TCK
tools/Ant lib classes as well.
I've tried the
suggestions below without luck, we
ran into some other issues which
consumed last week tied to pulling
down a bad GF build, Derby issues
etc. But at this point we are still
hitting a RC 3 issue without little
explanation as to what the root
cause is. The report_dir & work
dir etc. I think are setup but to be
safe we've pulled the pre-built TCK
as suggested as well. In order to
rule out missing config etc. I tried
with GF as well. Pulling the last
stable GF build I'm able to get all
of Samples to pass using the RunCTS
& default setup. But if we
switch this to use runclient I see
the same RC 3 code we see with
OpenLiberty. I've also tried the
-debug option as well as we often
have this enabled on new setups but
there is no additional information
around the actual failure from the
Harness/Java.
I see the extra setup
RunCTS performs but for Samples that
should not be required as the
run_jakartaeetck.sh script already
setups the DB etc. Has anyone else
tried runclient vs. RunCTS against
Glassfish?
Scott E. Highbarger
[shighbar@xxxxxxxxxx]
Advisory Software Engineer
WebSphere Application Server CTS
IBM
Software Group
(303) 773-5264
<graphics2.jpeg>
<graycol.gif>Anand Francis Joseph
Augustine ---03/01/2019 08:11:47
AM---Hi Scott,
Please find below the answers to the
summary questions you had posted
1)Anyone else seen the
harness JVM exiting right away with
RC code 3 and no output/trace on
why? Any suggestions on how to
determine the reason?
>> Are you
using a pre-built
jakartaee TCK bundle
or are you trying to
run it directly by
cloning the github
repository and doing a
clean build and run ?
One common reason for runclient
returning status code 3, could be if
the values ofreport.dirandwork.dirin
ts.jte file is wrong or if the paths
do not exist. Otherwise it can be due
to missing or corrupttestsuite.jtt/testsuite.jtdfiles.
You can run with debug enabled say (ant
-debug runclient) to see the
exact cause of the failure.
2) Why with Glassfish
are we not using runclient interface
which leads to the JTHarness's main
class but instead a custom RunCTS
class to kick off tests? Should we
not perhaps re-architect that and
follow the same code path as other
VIs should use and our documentation
states?
>> Therun.ctscustom
ant target is a convenience ant
target. It takes care of additional
ant targets to be run for specific
suites and sets default values for
properties. Like for JASPIC suite, it
runsenable.jaspicbefore
calling runclient. These instructions
are part of the user guide. If you userun.ctstarget,
it takes care of such things
internally based on the test area we
are running. The source code for
RunCTS ant target is available in the
below link. You can have a look at it
to see what it does. The RunCTS is
available only for the JakartaEE TCK
bundle and cannot be used for
standalone TCKs. https://github.com/eclipse-ee4j/jakartaee-tck-tools/blob/master/tools/ant-ext/src/com/sun/ant/taskdefs/common/RunCTS.java
I don’t see a reason why other VI’s
cannot use it. Though we have not
tested it with VIs other than
GlassFish. You can try it out with
Liberty and see if you face any
issues.
3) I think we should
have the source available for any
classes we have as part of the
project and unless I'm mistaken it
appears we are missing a lot of the
com.sun.ant.taskdefs etc?
>> The source code for these
custom ANT tasks is also donated and
its available in a separate github
repository. https://github.com/eclipse-ee4j/jakartaee-tck-tools
It contains several additional useful
tools used for generating test
coverage, custom ant tasks and other
utility scripts etc.
We've been looking into an issue
we ran into trying to get the
Jakarta TCK working on
OpenLiberty. The documentation
states to use runclient to execute
the tests (in batch mode) but when
doing that we are get RC code 3
from Java from the Harness without
much clue so far as to what we
might be the cause, even with
harness trace enabled.
BUILD
FAILED
/jakarta/javaeetck/bin/xml/ts.nonleafimport.xml:63: The following error
occurred while
executing this
line:
/jakarta/javaeetck/bin/xml/ts.import.xml:90: The following error
occurred while
executing this
line:
/jakarta/javaeetck/bin/build.xml:168: The following error occurred while
executing this
line:
/jakarta/javaeetck/bin/xml/ts.top.import.xml:894: Java returned: 3
I suspect our issue is
config related, but interestingly it
got me comparing our output with a
run against Glassfish/RI, which lead
me to another issue I think should
be brought up.
When the VI is the RI/Glassfish,
instead of kicking the tests off
though runclient per the TCK
documentation it's instead using
it's own Ant target run.cts (from
the implementation specific Ant
script s1as.xml) which ultimately
kicks the tests off via the class
com.sun.ant.taskdefs.common.RunCTS
[see ts.common.props.xml taskdef for
runcts]. I could not find any source
in the proejct for RunCTS class or
any of the com.sun.ant package so
could not follow the path further
for the RI side. What I'm wondering
is why not have the RI's interface
into the TCK match what we are
documenting and suggesting other VIs
use? I.e. runclient instead of the
run.cts/runcts and an glassfish
specific RunCTS? I also think that
the source code for these classes
should be included as part of the
TCK or otherwise available if we are
going to make use of them - but
unless I completely missed something
I can't find source for that class
or any of the others in that
package/area?
Out of curiosity and to compare our
openliberty output to glassfish I
changed the run script to call
runclient on a glassfish setup -
basically trying to run tests
against the RI/GF but using the
method outlined in our Readme and
the guide. When we try this we see
the following error;
+
/jakarta/ri/glassfish5/glassfish/bin/asadmin
--user admin
--passwordfile
/jakarta/admin-password.txt -p 5858 start-domain
Waiting for
domain1 to
start ....
Successfully
started the
domain :
domain1
domain
Location:
/jakarta/ri/glassfish5/glassfish/domains/domain1
Log File:
/jakarta/ri/glassfish5/glassfish/domains/domain1/logs/server.log
Admin Port:
5858
Command
start-domain
executed
successfully.
+ [[ jaxr ==
samples ]]
+ [[
securityapi ==
samples ]]
+ cd
/jakarta/javaeetck//bin
+ echo 'ant
start.auto.deployment.server
>
/tmp/deploy.out
2>&1
& '
ant
start.auto.deployment.server
>
/tmp/deploy.out
2>&1
&
+ cd
/jakarta/jakartaee-tck/src/com/sun/ts/tests/samples
+ ant
runclient
+ ant
start.auto.deployment.server
Buildfile:
/jakarta/jakartaee-tck/src/com/sun/ts/tests/samples/build.xml
[echo] ts.home
=
/jakarta/jakartaee-tck/bin/xml/../..
[mkdir]
Created dir:
/jakarta/jakartaee-tck/classes
[mkdir]
Created dir:
/jakarta/jakartaee-tck/dist
[mkdir]
Created dir:
/jakarta/jakartaee-tck/tmp
[mkdir]
Created dir:
/jakarta/jakartaee-tck/weblib
BUILD FAILED
/jakarta/jakartaee-tck/src/com/sun/ts/tests/samples/build.xml:21: The
following
error occurred
while
executing this
line:
/jakarta/jakartaee-tck/bin/xml/ts.nonleafimport.xml:30: The following
error occurred
while
executing this
line:
/jakarta/jakartaee-tck/bin/xml/ts.import.xml:30: The following error
occurred while
executing this
line:
/jakarta/jakartaee-tck/bin/xml/ts.vehicles.xml:23: The following error
occurred while
executing this
line:
/jakarta/jakartaee-tck/bin/xml/ts.clientjar.xml:23: The following error
occurred while
executing this
line:
/jakarta/jakartaee-tck/bin/xml/ts.common.xml:23: The following error
occurred while
executing this
line:
/jakarta/jakartaee-tck/bin/xml/ts.common.props.xml:240: There is no
deliverabledir
by the name of
samples under
/jakarta/jakartaee-tck/bin/xml/../../install. Please set deliverabledir
in your
environment
It looks like - at
least without some additional
changes you can't run tests against
GF/RI using the method we document
out of the box? We get the above
when trying to run samples, but
since it's looking for the install
directory, which is new in Jakara vs
javaee, it seems to be trying to run
the stand alone TCK for samples
(which there is not one) vs. running
the samples bucket in the main TCK
here.
So in summary;
1) Anyone else seen the
harness JVM exiting right away with
RC code 3 and no output/trace on
why? Any suggestions on how to
determine the reason?
2) Why with Glassfish are we not
using runclient interface which
leads to the JTHarness's main class
but instead a custom RunCTS class to
kick off tests? Should we not
perhaps re-architect that and follow
the same code path as other VIs
should use and our documentation
states?
3) I think we should have the source
available for any classes we have as
part of the project and unless I'm
mistaken it appears we are missing a
lot of the com.sun.ant.taskdefs etc?
Scott E. Highbarger
[shighbar@xxxxxxxxxx]
Advisory Software Engineer
WebSphere Application Server CTS
IBM
Software Group
(303) 773-5264
Lance
Andersen| Principal Member of Technical Staff |
+1.781.442.2037
OracleJava
Engineering
1 Network Drive
Burlington, MA 01803 Lance.Andersen@xxxxxxxxxx
Lance Andersen| Principal
Member of Technical Staff | +1.781.442.2037
Oracle Java
Engineering 1 Network Drive Burlington, MA
01803 Lance.Andersen@xxxxxxxxxx