Dies,
I think you found the culprit... Unfortunately, Tim, who probably knows what might be going on, is on vacation this week. I know that he had to implement some custom classpath handling to accomodate jar files moved to modules/endorsed directory around the same time so it is possible that this introduced regression.
I can take a closer look at this sometime tommorow if there are no other takers :-)
Thanks,
Snjezana
----- Original Message -----
From: Dies Koper <diesk_at_fast.au.fujitsu.com>
Date: Wednesday, May 20, 2009 6:39 pm
Subject: Re: QL failure.
To: dev_at_glassfish.dev.java.net, jr158900_at_dev.java.net, tjquinn_at_dev.java.net
> Hi Jagadish, Tim,
>
> I think you added things to acc-standalone pom.xml two weeks ago to
> build this classpath.
> I'm not familiar enough with maven to understand what is happening,
> but the "../modules" in this MANIFEST.MF seems to come from this pom.
>
> Could you review r27228 again and try it out on Windows?
>
> Thanks,
> Dies
>
>
> Dies Koper wrote:
> >The stacktrace tells us the problem is on the client side, it doesn't
> even get as far as to connect to the server.
> >
> >Usually, java.naming.factory.initial is taken from a file called
> jndi.properties on the classpath.
> >
> >In GF V3 this file is included in glassfish\lib\jndi-properties.jar
> and glassfish\modules\glassfish-naming.jar.
> >So these need to be included in the test class's classpath.
> >
> >In quicklook\build.xml I the following:
> >
> > <fileset dir="${glassfish.home}/modules">
> > <include name="**/amx*.jar"/>
> > <include name="**/gf-client.jar"/>
> > </fileset>
> >
> >In modules\gf-client.jar (build and packaged on my Windows machine),
> the manifest file specifies the following classpath:
> >
> >Class-Path: ../modulesglassfish-corba-asm.jar ../modulesglassfish-corb
> > a-codegen.jar ../modulesglassfish-corba-csiv2-idl.jar ../modulesglass
> >[...]
> >
> >That doesn't look right to me.
> >
> >Regards,
> >Dies
> >
> >Jane Young wrote:
> >>Is it possible to run this test manually on Windows and check the
> server.log? The stacktrace from QL does not tell me anything.
> >>Sherry/Ming can you send the instructions on executing this test?
> >>Byron/Nandini, can you run this test manually and check server.log?
> >>
> >>Jane
> >>
> >>
> >>Nandini Ektare wrote:
> >>>Snjezana Sevo-Zenzerovic wrote:
> >>>>The difference, as I mentioned earlier, is that your build was
> produced on your Windows system, whereas the one you picked up from
> Hudson was built on either Solaris or Linux...
> >>>>
> >>>>Can we go back from those failed tests and see if there is
> anything that could be platform sensitive at build time?
> >>>For easy reference here is the failed test trace:
> >>>
> >>>[testng] FAILED: helloRemote
> >>>[testng] javax.naming.NoInitialContextException: Need to specify
> class name in environment or system property, or as
> >>>applet parameter, or in an application resource file: java.naming.factory.initial
> >>>[testng] at javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:645)
> >>>[testng] at javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:288)
> >>>[testng] at
> javax.naming.InitialContext.getURLOrDefaultInitCtx(InitialContext.java:325)
>
> >>>[testng] at javax.naming.InitialContext.lookup(InitialContext.java:392)
> >>>[testng] at
> test.ejb.remoteview.RemoteViewTestNG.helloRemote(RemoteViewTestNG.java:18)
>
> >>>[testng] ... Removed 22 stack frames
> >>>[testng] SKIPPED: nonPortableGlobal
> >>>[testng] SKIPPED: portableGlobal
> >>>
> >>>[testng] ===============================================
> >>>[testng] ejb_remoteview
> >>>[testng] Tests run: 3, Failures: 1, Skips: 2
> >>>[testng] ===============================================
> >>>
> >>>>Nandini Ektare wrote:
> >>>>
> >>>>>Sevo-Zenzerovic wrote:
> >>>>>
> >>>>>>Ming, this is passing for me...
> >>>>>>
> >>>>>>Now, sorry to offload this but I do have something rather urgent
> to take care of - could someone who experienced QL failure on their
> Windows system take glassfish.zip file produced by continuous build?
> >>>>>
> >>>>>I ran QL successfully against the continuous build Snjezana had
> referenced
> (http://gf-hudson.sfbay.sun.com/hudson/job/gf-trunk-build-continuous/
> )
> >>>>>That passes without any failures.
> >>>>>
> >>>>>But the zip coming out of the trunk's build has this error. What
> is the difference between the two (if any)?
> >>>>>
> >>>>>Nandini
> >>>>>
> >>>>>>This is still "developer" distribution, but the difference is
> that it is built on Unix as opposed to Windows which may make
> difference when it comes to things such as EOL characters and such...
> >>>>>>
> >>>>>>Ming Zhang wrote:
> >>>>>>
> >>>>>>>Hi Snjezana,
> >>>>>>>
> >>>>>>>Just for the debug purpose, can you/or someone try QL against
> the IPS build on windows also?
> >>>>>>>http://gf-hudson.sfbay/hudson/job/trunk-nightly/lastSuccessfulBuild/artifact/bundles/glassfish-v3-b48-05_20_2009.zip
>
> >>>>>>>So that we are on the same page.
> >>>>>>>
> >>>>>>>Thanks,
> >>>>>>>Ming
> >>>>>>>
> >>>>>>>Snjezana Sevo-Zenzerovic wrote:
> >>>>>>>
> >>>>>>>>Given that the development build now differs from IPS build
> only in the presence of IPS metadata, this is *very* slim possibility....
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>Ming Zhang wrote:
> >>>>>>>>
> >>>>>>>>>But continuous QL job is running on solaris/linux, right? I
> suspect the development build on windows has problem.
> >>>>>>>>>Thanks,
> >>>>>>>>>Ming
> >>>>>>>>>
> >>>>>>>>>Snjezana Sevo-Zenzerovic wrote:
> >>>>>>>>>
> >>>>>>>>>>No, it couldn't because continuous QL job itself is running
> on non-IPS distributions...
> >>>>>>>>>>
> >>>>>>>>>>Ming Zhang wrote:
> >>>>>>>>>>
> >>>>>>>>>>>Byron brought up the failures 2 days ago. I tried to
> reproduce the QL failures with glassfish-v3-b48-05_18_2009.zip on my
> Windows Vista and couldn't see the errors. Today I used
> glassfish-v3-b48-05_20_2009.zip (trunk nightly) and still all QL tests
> passed. Could this be due to IPS vs development build?
> >>>>>>>>>>>
> >>>>>>>>>>>Thanks,
> >>>>>>>>>>>Mings
> >>>>>>>>>>>
> >>>>>>>>>>>Byron Nevins wrote:
> >>>>>>>>>>>
> >>>>>>>>>>>>Yes, I'm not positive but it looks just right.
> >>>>>>>>>>>>
> >>>>>>>>>>>>It was "ejb-something", 1 failure, 2 skips
> >>>>>>>>>>>>over and over again
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>Marina Vatkina wrote:
> >>>>>>>>>>>>
> >>>>>>>>>>>>>Byron,
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>Are these the same failures that you saw?
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>thanks,
> >>>>>>>>>>>>>-marina
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>Nandini Ektare wrote:
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>Thanks Dies.
> >>>>>>>>>>>>>>Jane, even I use windows.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>-Nandini
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>Dies Koper wrote:
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>Hi Nandini, Jane,
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>I've been seeing the same failure during QL for two days.
> >>>>>>>>>>>>>>>That's on Windows.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>Regards,
> >>>>>>>>>>>>>>>Dies
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>Jane Young wrote:
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>Not sure what's going on with your build.
> >>>>>>>>>>>>>>>>I just did a "mvn clean install" on v3 trunk workspace
> and have no problem running QL tests.
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>I'm using a Mac.
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>Nandini Ektare wrote:
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>Jane Young wrote:
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>QL tests are passing on Hudson' v3 trunk continuous
> build.
> >>>>>>>>>>>>>>>>>>http://hudson.glassfish.org/job/gf-trunk-build-continuous/
>
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>Can you compile with "mvn clean install" to make
> sure your build is from a clean target workspace and try running QL again?
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>Hmm...I removed maven repo and did a mvn -U clean
> install. I still get this error.
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>Is there any new additional System property that
> needs to be configured. The error seems to suggest that.
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>Nandini Ektare wrote:
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>With a latest fresh checkout of v3 trunk I see the
> following issue. Is this a known issue ?
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>[testng] FAILED: helloRemote
> >>>>>>>>>>>>>>>>>>>[testng] javax.naming.NoInitialContextException:
> Need to specify class name in environment or system property, or as
> >>>>>>>>>>>>>>>>>>>applet parameter, or in an application resource
> file: java.naming.factory.initial
> >>>>>>>>>>>>>>>>>>>[testng] at
> javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:645)
>
> >>>>>>>>>>>>>>>>>>>[testng] at
> javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:288)
>
> >>>>>>>>>>>>>>>>>>>[testng] at
> javax.naming.InitialContext.getURLOrDefaultInitCtx(InitialContext.java:325)
>
> >>>>>>>>>>>>>>>>>>>[testng] at
> javax.naming.InitialContext.lookup(InitialContext.java:392)
> >>>>>>>>>>>>>>>>>>>[testng] at
> test.ejb.remoteview.RemoteViewTestNG.helloRemote(RemoteViewTestNG.java:18)
>
> >>>>>>>>>>>>>>>>>>>[testng] ... Removed 22 stack frames
> >>>>>>>>>>>>>>>>>>>[testng] SKIPPED: nonPortableGlobal
> >>>>>>>>>>>>>>>>>>>[testng] SKIPPED: portableGlobal
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>[testng] ===============================================
> >>>>>>>>>>>>>>>>>>>[testng] ejb_remoteview
> >>>>>>>>>>>>>>>>>>>[testng] Tests run: 3, Failures: 1, Skips: 2
> >>>>>>>>>>>>>>>>>>>[testng] ===============================================
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>-Nandini
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>