Hi Tim,
Thanks for fixing this during your vacation. This explains why it only
fails when it's built on Windows. The changes in pom.xml look fine.
I don't have a Windows system to test this.
Nandini and Byron - can you verify that this fixes the QL failure.
Thanks,
Jane
Tim Quinn wrote:
> Everyone,
>
> Hint:
>
> Whenever you see a missing separator or an expected character replaced
> with a special character, suspect something with backslashes. For
> example, the tab character Dies mentioned combined with the missing
> "t" from the beginning of "transaction" immediately after that means
> that a backslash has found its way into the string. The resulting
> "\t" is interpreted as the tab character. In other places where the
> backslash does not precede a legitimate special character (such as
> "\g") the following character - without the backslash - is just passed
> to the output which is why it looks as if the string was generated
> with no separators.
>
> Cause:
>
> The appclient/client/acc-standalone/pom.xml uses the dependency
> plug-in's build-classpath goal
>
> http://maven.apache.org/plugins/maven-dependency-plugin/build-classpath-mojo.html
>
> to generate a file that contains the class path computed from the
> maven dependencies.
>
> This goal is intended to create a string formatted for use in a
> -classpath option or CLASSPATH env. variable assignment. We are using
> it instead to create a string for use in a manifest's Class-Path,
> which has different separator and path-separator needs. The default
> behavior is to use platform-specific file separator and path separator
> characters. This, of course, is not what we want.
>
> When I wrote this part of the pom.xml I failed to tell the plug-in to
> always use the forward-slash file separator.
>
> Fix:
>
> Change the appclient/client/acc-standalone/pom.xml (full file
> attached) as follows:
>
> @@ -114,6 +114,7 @@
> <outputFile>${classpath.file}</outputFile>
> <outputFilterFile>true</outputFilterFile>
> <pathSeparator>:</pathSeparator>
> + <fileSeparator>/</fileSeparator>
> <prefix>../modules</prefix>
> <stripVersion>true</stripVersion>
> </configuration>
>
> With this fix in my local workspace on Mac OS X the ejb and deployment
> devtests passed.
>
>
> I do not have the time right now (mid-vacation) to prepare a Windows
> environment to try it there, which is of course necessary. Could
> someone else do so and, assuming the pom change is approved,
>
> - run the ejb devtests,
> - run the deployment devtests,
> - run the QL tests,
>
> and assuming those pass go ahead and check in the pom.xml change on my
> behalf?
>
> This change should take care of the problem.
>
>
> - Tim
>
> Snjezana Sevo-Zenzerovic wrote:
>> 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
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
>> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>>
>>
>
> ------------------------------------------------------------------------
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net