Re: [action] pom.xml review request -- was Re: QL failure.

From: Byron Nevins <Byron.Nevins_at_Sun.COM>
Date: Thu, 21 May 2009 23:30:49 -0700

Confirmed. The bug is fixed. I checked in the changes.

How tested:

Full checkout & build from scratch
QL - 1 error 2 skips
change the one file
build
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@fast.au.fujitsu.com>
Date: Wednesday, May 20, 2009 6:39 pm
Subject: Re: QL failure.
To: dev@glassfish.dev.java.net, jr158900@dev.java.net, tjquinn@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@glassfish.dev.java.net
For additional commands, e-mail: dev-help@glassfish.dev.java.net


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@glassfish.dev.java.net
For additional commands, e-mail: dev-help@glassfish.dev.java.net


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@glassfish.dev.java.net
For additional commands, e-mail: dev-help@glassfish.dev.java.net