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
>
>