|
Scott,
Great to hear you have found a work-around and I'm glad Lance was
able to give you the details that led you in a profitable
direction.
Please file an issue. We'll follow up. [If you happen to find and
fix the problem, you can also submit a PR ;-).]
-- Ed
On 3/12/2019 3:05 PM, Scott Highbarger
wrote:
No worries Ed,
Yes, I believe the link you provided is what
we've been using for Glassfish. As for the TCK I'm using the
stable builds vs. Oracle's JavaEE TCK going forward as we
wanted to work with the new Jakarta setup. At this point today
I'm past the blocker we had all week - though I agree with
Lance, I think there is something off in the builds for the
tck since the delieverable.dir problem shows up with runclient
when it should be under the covers which is the follow up on
the issue - but appears we have a work around for now.
Regards,
Scott E. Highbarger
[shighbar@xxxxxxxxxx]
Advisory Software Engineer
WebSphere Application Server CTS
IBM Software Group
(303) 773-5264
 Ed Bratt ---03/12/2019 03:03:04 PM---From: Ed
Bratt <ed.bratt@xxxxxxxxxx> To: jakartaee-tck developer
discussions <jakartaee-tck-dev@xxxxxxxxxxx>, Kevin
Sutter <sut
From: Ed
Bratt <ed.bratt@xxxxxxxxxx>
To: jakartaee-tck
developer discussions <jakartaee-tck-dev@xxxxxxxxxxx>,
Kevin Sutter <sutter@xxxxxxxxxx>
Date: 03/12/2019
03:03 PM
Subject: Re:
[jakartaee-tck-dev] Jakarta TCK issues with runclient
Sent by: jakartaee-tck-dev-bounces@xxxxxxxxxxx
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
----- Original message -----
From: Ed Bratt <ed.bratt@xxxxxxxxxx>
Sent by: jakartaee-tck-dev-bounces@xxxxxxxxxxx
To: jakartaee-tck developer discussions <jakartaee-tck-dev@xxxxxxxxxxx>, Lance Andersen <lance.andersen@xxxxxxxxxx>, Scott Highbarger <shighbar@xxxxxxxxxx>
Cc:
Subject: Re: [jakartaee-tck-dev] Jakarta TCK issues with
runclient
Date: Tue, Mar 12, 2019 2:51 PM
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:
On Mar 12, 2019, at 2:12 PM, Scott
Highbarger <shighbar@xxxxxxxxxx> 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
_______________________________________________
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
_______________________________________________
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
|
