[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
| 
Re: [jakartaee-tck-dev] Unable to access jarfile in test run
 | 
On 6/17/20 1:15 PM, Scott Marlow wrote:
On 6/17/20 12:36 PM, Scott Marlow wrote:
On 6/17/20 12:21 PM, Scott Marlow wrote:
https://github.com/eclipse-ee4j/jakartaee-tck/issues/339 is the issue 
for this bug.
Let me know if someone is planning to work on fixing this.  I'll look 
at it in a few hours if not (will assign to myself).  Please comment 
on the issue or assign to yourself if you work on it.
I'll work on this now. :)
I'm testing locally and on 
https://ci.eclipse.org/jakartaee-tck/job/jakartaee-tck/job/master/706/console.
Scott
Scott
On 6/17/20 12:16 PM, Scott Marlow wrote:
On 6/17/20 9:43 AM, Gurkan Erdogdu wrote:
Hi
I noticed that there is a ts_dep in path.
there is no such ts_dep directory in the dist/ folder. Who is 
adding ts_dep?
Good catch.
I'm looking for ts_dep in output from:
git diff --no-ext-diff --unified=0 8.0.2 HEAD --no-ext-diff > 
allchanges.diff  (see 
https://gist.github.com/scottmarlow/67a84984df5d449560d6691f1c7b2b22 
for partial output related to #1 below).
Some references of note:
1. 
src/com/sun/ts/lib/implementation/sun/javaee/glassfish/AutoDeployment.java 
removed getClientClassPath() which was hard coded to return empty 
string since ./jakartaeetck/bin/xml/impl/glassfish/s1as.xml handles 
passing generated jar with EJB stubs to the Appclient Main class. 
Still, there could of been a side effect of calling the 
getClientClassPath() that I missed when removing this method (as 
part of dropped Jakarta Deployment).
Here is a side effect that was deleted, creating the ts_dep folder:
"
-    File ctsDeployDir = new File(sTSDeploymentDir);
-
-    // we should only be calling this method with archives that 
contain an
-    // appclient
-
-    if (!ctsDeployDir.exists()) {
-      if (!ctsDeployDir.mkdir()) {
2. 
src/com/sun/ts/lib/implementation/sun/javaee/SunRIDeployment2.java 
was removed, it also had a getClientClassPath() method that used 
Jakarta Deployment calls to determine the return the jar with eJB 
stubs, but was hard coded to return empty string also.  There could 
of been a side effect of calling the getClientClassPath() that I 
missed when removing this class that was mostly depending on Jakarta 
deployment (as part of dropped Jakarta Deployment).
I propose that we add back in the side effects from #1, like 
creating the ts_dep folder.
I'll create an issue for this.
Scott
Regards.
Gurkan
On Wed, Jun 17, 2020 at 2:35 PM Alwin Joseph 
<alwin.joseph@xxxxxxxxxx <mailto:alwin.joseph@xxxxxxxxxx>> wrote:
    Hi,
    We are getting errors similar to below during several of the 
test runs.
        [runcts] OUT => [javatest.batch] Error: Unable to access 
jarfile 
/root/jakartaeetck/bin/xml/../../dist/com/sun/ts/tests/samples/ejb/ee/simpleHello/ts_dep/ejb_sam_HelloClient.jar 
        [runcts] OUT => [javatest.batch] Failed. unexpected exit 
code: exit code 1
    The logs with this error are in [1] for sample test runs , [2] for
    jacc.
    [1]
https://ci.eclipse.org/jakartaee-tck/blue/rest/organizations/jenkins/pipelines/jakartaee-tck/branches/master/runs/704/nodes/34/steps/49/log/?start=0 
    [2]
https://ci.eclipse.org/jakartaee-tck/blue/rest/organizations/jenkins/pipelines/jakartaee-tck/branches/master/runs/703/nodes/134/steps/782/log/?start=0 
    Thanks & Regards,
    Alwin Joseph
    _______________________________________________
    jakartaee-tck-dev mailing list
    jakartaee-tck-dev@xxxxxxxxxxx 
<mailto:jakartaee-tck-dev@xxxxxxxxxxx>
    To unsubscribe from this list, visit
    https://www.eclipse.org/mailman/listinfo/jakartaee-tck-dev
--
Gurkan Erdogdu
http://gurkanerdogdu.blogspot.com
_______________________________________________
jakartaee-tck-dev mailing list
jakartaee-tck-dev@xxxxxxxxxxx
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/jakartaee-tck-dev