I have applied Tim's fix locally and now the QL tests are passing on my
Windows machine.
If someone can send me instructions on how to run the devtests on V3, I
can run them and commit Tim's fix for you.
Regards,
Dies
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