Thanks for checking-in the fix.
Byron Nevins wrote:
> Confirmed. The bug is fixed. I checked in the changes.
>
> How tested:
>
> 1. Full checkout & build from scratch
> 2. QL - 1 error 2 skips
> 3. change the one file
> 4. build
> 5. QL - no errors
>
>
> Jane Young wrote:
>> 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
>>
>