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
-- Ed
On 3/12/2019 11:21 AM, Lance Andersen
wrote:
Lance, I'm using the last stable build from https://jenkins.eclipse.org/jakartaee-tck/job/jakartaeetck-nightly-build/lastStableBuild/ vs.
out local build/workspace as suggested just to rule out
any odd config issue in build etc. That has not made a
difference.
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?
From: Lance Andersen <lance.andersen@xxxxxxxxxx>
To: jakartaee-tck developer discussions
<jakartaee-tck-dev@xxxxxxxxxxx>
Cc: Scott Highbarger <shighbar@xxxxxxxxxx>
Date: 03/11/2019 12:57 PM
Subject: Re: [jakartaee-tck-dev] Jakarta TCK
issues with runclient
Hi Scott
Are you running out of a
workspace or a built release from your workspace?
On Mar 11, 2019, at 2:39 PM, Alwin Joseph <alwin.joseph@xxxxxxxxxx>
wrote:
Hi Scott,
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,
From: Anand Francis Joseph Augustine <anand.francis.joseph.augustin@xxxxxxxxxx>
To: jakartaee-tck developer
discussions <jakartaee-tck-dev@xxxxxxxxxxx>
Date: 03/01/2019 08:11 AM
Subject: Re: [jakartaee-tck-dev] Jakarta
TCK issues with runclient
Sent by: jakartaee-tck-dev-bounces@xxxxxxxxxxx
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 of report.dir and work.dirin
ts.jte file is wrong or if the paths do not exist.
Otherwise it can be due to missing or corrupt testsuite.jtt/testsuite.jtd files. 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?
>> The run.cts custom 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 runs enable.jaspicbefore
calling runclient. These instructions are part of
the user guide. If you use run.cts target, 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.
Regards
Anand
From: Scott
Highbarger <shighbar@xxxxxxxxxx>
Sent: Friday,
March 1, 2019 12:20 AM
To: jakartaee-tck-dev@xxxxxxxxxxx
Subject: [jakartaee-tck-dev]
Jakarta TCK issues with runclient
Good morning
all,
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
<graphics2.jpeg>
_______________________________________________
jakartaee-tck-dev mailing list
jakartaee-tck-dev@xxxxxxxxxxx
To change your delivery options, retrieve your
password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/jakartaee-tck-dev
_______________________________________________
jakartaee-tck-dev mailing list
jakartaee-tck-dev@xxxxxxxxxxx
To change your delivery options, retrieve your
password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/jakartaee-tck-dev
_______________________________________________
jakartaee-tck-dev mailing list
jakartaee-tck-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password,
or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/jakartaee-tck-dev
<1B382346.gif>
Lance Andersen| Principal Member of Technical Staff |
+1.781.442.2037
Oracle Java 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
_______________________________________________
jakartaee-tck-dev mailing list
jakartaee-tck-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/jakartaee-tck-dev
|