[GLASSFISH-8436] Need QL or SQE Tests for start|stop domain Created: 22/May/09  Updated: 06/Mar/12

Status: Open
Project: glassfish
Component/s: sqe-test
Affects Version/s: V3
Fix Version/s: not determined

Type: Improvement Priority: Blocker
Reporter: Byron Nevins Assignee: mzh777
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 8,436

 Description   

See #8387

The regression in that bug was from V2->V3. The bug sat undetected for a year.
What that bug says is:

  • If the domain is already running then 'asadmin start-domain' should return
    zero (success)
  • If the domain is NOT running then 'asadmin stop-domain' should return zero
    (success).

Before the fix both of these situations returned in hard errors with non-zero
getting returned.

===============================================================

A QL test should be added – or some other frequently run automated test to
detect it if it regresses again.

I tried to add a QL test but it is very complicated to add a test in there –
(ant maven TestNG are all firing at the same time and talking to each other) not
to mention dangerous since so many developers depend on it.

For the test all you have to do is run asadmin start-domain twice in a row.
Both times a zero (success) should be returned. Exact same story for stop-domain.



 Comments   
Comment by Byron Nevins [ 23/May/09 ]

Defect -> Enhancement

Comment by Byron Nevins [ 27/May/09 ]

Changed back to defect. Read on...

-------------------------------------------------------------------

In the process of filing Issue 8455 I noticed the following Issue.
Because of 8455 my environment was now in the state where it was impossible to
ever start the domain again.

QL tries to start the domain. It prints a message saying it could not be
started. And then QL gamely presses on anyways! But every successive test is,
of course, going to fail now.

The domain not starting is a catastrophic error and QL tests ought to instantly
come to a screeching halt. Any more tests are just a waste of time, no possible
good can come from it.

It is very simple to fix this – just add the "fail-on-error=true" to the
start-domain ant command.

Comment by Byron Nevins [ 13/Jul/09 ]

Changing to P1.

My domain would not start because I added a nutty jvm option. I forgot about
it. So in my environment the domain will not start.

QL knew this IMMEDIATELY. But instead of telling me "domain won't start" and
stopping, it continues for a half hour wasting time running tests that can't
possibly pass.

Finally I get an Ant error message that has nothing whatsoever to do with the
real error.

ONE line of code will fix this problem.

Comment by kumara [ 01/Sep/09 ]

Moving to sqe-test as there is no subcomponent for quicklook tests.

Comment by mzh777 [ 08/Sep/09 ]

Change the type to Enhancement.

I changed the adminCLI tests to detect the asadmin return type (0 or 1) since
then. Tried to call asadmin start/stop domain from the test but it causes QL
hangs on windows (other platforms are fine). Had email communications with Bill
and Kedar and didn't find a way to go through. Put the issue in the list of QL
enhancement.

Comment by Tom Mueller [ 06/Mar/12 ]

Bulk update to change fix version to "not determined" for all issues still open but with a fix version for a released version.





[GLASSFISH-16717] LB tests compilation error on AIX due to com.sun.net.ssl.HostnameVerifier dependency Created: 24/May/11  Updated: 04/Jan/12

Status: Open
Project: glassfish
Component/s: test
Affects Version/s: 3.1.1_b06
Fix Version/s: None

Type: Bug Priority: Critical
Reporter: mzh777 Assignee: mzh777
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

AIX 6.1, IBM JDK 1.6.0


Tags: 3_1_1-scrubbed

 Description   

The SQE HA LB tests have dependency on JDK package com.sun.net.ssl.HostnameVerifier that doesn't exist on IBM JDK. Compilcation error on IBM JDK for LB tests:

compile-common:
[javac] Compiling 130 source files to /export/home/ming/gf-ha-qe/build
[javac] /export/home/ming/gf-ha-qe/functional/lb/src/com/sun/dft/glassfish/lb/RR/http/MultipleFailoverHttpOnly.java:24: package com.sun.net.ssl does not exist
[javac] import com.sun.net.ssl.HostnameVerifier;
[javac] ^
[javac] /export/home/ming/gf-ha-qe/functional/lb/src/com/sun/dft/glassfish/lb/RR/http/OnlyHttpsListeners.java:21: package com.sun.net.ssl does not exist
[javac] import com.sun.net.ssl.HostnameVerifier;
[javac] ^
[javac] /export/home/ming/gf-ha-qe/functional/lb/src/com/sun/dft/glassfish/lb/RR/https_routing_off/BasicHttps.java:23: package com.sun.net.ssl does not exist
[javac] import com.sun.net.ssl.HostnameVerifier;
[javac] ^
[javac] /export/home/ming/gf-ha-qe/functional/lb/src/com/sun/dft/glassfish/lb/RR/https_routing_off/FailoverHttpHttpHttpsSingleSession.java:24: package com.sun.net.ssl does not exist
[javac] import com.sun.net.ssl.HostnameVerifier;
[javac] ^

java version "1.6.0"
Java(TM) SE Runtime Environment (build pap3260sr9fp1-20110208_03(SR9 FP1))



 Comments   
Comment by Alex Pineda [ 24/May/11 ]

Need help to find the solution to this issue

Comment by Alex Pineda [ 24/May/11 ]

Changing the category to "other" as we, QA, needs help with this issue.

Comment by scatari [ 24/May/11 ]

This is a test issue, consider using javax.net.ssl.HostnameVerifier instead of Sun specific implementation. The alternative is to bundle Sun Implementation in a special jar and use it in the classpath. Assigning back to the test Engineer.





[GLASSFISH-13368] Fix the deprecated syntax in specifying the method checkpoint Created: 10/Sep/10  Updated: 02/Dec/11

Status: Open
Project: glassfish
Component/s: sqe-test
Affects Version/s: 4.0
Fix Version/s: None

Type: Bug Priority: Major
Reporter: mzh777 Assignee: mzh777
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: Linux


Issuezilla Id: 13,368
Tags: 3_1-exclude

 Description   

<checkpointed-methods> is deprecated and needs to be changed to use
<checkpoint-at-end-of-method>

All methods inside <checkpoint-at-end-of-method> need to use new element format
to specify parameters or over-riding.

The corresponding issue in GF3.1 is 13305.






[GLASSFISH-18684] [Regression] Ran into EJB Container initialization error with IIOPFailoverDynamicICAccess test Created: 03/May/12  Updated: 01/Jul/12

Status: In Progress
Project: glassfish
Component/s: sqe-test
Affects Version/s: 4.0_b34
Fix Version/s: None

Type: Bug Priority: Major
Reporter: mzh777 Assignee: mzh777
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

OEL 5
JDK 1.6.0_24-b50


Attachments: Zip Archive IIOPFailoverDynamicICAccess.zip    
Tags: 3x_regression

 Description   

Test com.sun.dft.glassfish.iiop.dynamiccluster.failover.instanceadd.InitialContext.IIOPFailoverDynamicICAccess generates following exceptions:

[#|2012-05-01T20:46:37.266+0000|SEVERE|44.0|javax.enterprise.system.tools.deployment.org.glassfish.deployment.common|_ThreadID=10;_ThreadName=Thread-2;|Exception while invoking class org.glassfish.ejb.startup.EjbDeployer load method
java.lang.RuntimeException: EJB Container initialization error
at org.glassfish.ejb.startup.EjbApplication.loadContainers(EjbApplication.java:240)
at org.glassfish.ejb.startup.EjbDeployer.load(EjbDeployer.java:294)
at org.glassfish.ejb.startup.EjbDeployer.load(EjbDeployer.java:102)
at org.glassfish.internal.data.ModuleInfo.load(ModuleInfo.java:186)
at org.glassfish.internal.data.ApplicationInfo.load(ApplicationInfo.java:264)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:479)
at com.sun.enterprise.v3.server.ApplicationLoaderService.processApplication(ApplicationLoaderService.java:388)
at com.sun.enterprise.v3.server.ApplicationLoaderService.postConstruct(ApplicationLoaderService.java:224)
at com.sun.hk2.component.AbstractCreatorImpl.inject(AbstractCreatorImpl.java:132)
at com.sun.hk2.component.ConstructorCreator.initialize(ConstructorCreator.java:117)
at com.sun.hk2.component.AbstractCreatorImpl.get(AbstractCreatorImpl.java:84)
at com.sun.hk2.component.SingletonInhabitant.get(SingletonInhabitant.java:67)
at com.sun.hk2.component.EventPublishingInhabitant.get(EventPublishingInhabitant.java:141)
at com.sun.hk2.component.AbstractInhabitantImpl.get(AbstractInhabitantImpl.java:135)
at com.sun.enterprise.v3.server.StartupRunLevelBridge.activate(StartupRunLevelBridge.java:93)
at com.sun.enterprise.v3.server.RunLevelBridge.postConstruct(RunLevelBridge.java:110)
at com.sun.enterprise.v3.server.StartupRunLevelBridge.postConstruct(StartupRunLevelBridge.java:65)
at com.sun.hk2.component.AbstractCreatorImpl.inject(AbstractCreatorImpl.java:132)
at com.sun.hk2.component.ConstructorCreator.initialize(ConstructorCreator.java:117)
at com.sun.hk2.component.AbstractCreatorImpl.get(AbstractCreatorImpl.java:84)
at com.sun.hk2.component.SingletonInhabitant.get(SingletonInhabitant.java:67)
at com.sun.hk2.component.EventPublishingInhabitant.get(EventPublishingInhabitant.java:141)
at com.sun.hk2.component.EventPublishingInhabitant.get(EventPublishingInhabitant.java:141)
at com.sun.hk2.component.RunLevelInhabitant.get(RunLevelInhabitant.java:110)
at com.sun.hk2.component.AbstractInhabitantImpl.get(AbstractInhabitantImpl.java:135)
at com.sun.enterprise.v3.server.AppServerStartup$StartupInhabitantActivator.activate(AppServerStartup.java:526)
at org.jvnet.hk2.component.internal.runlevel.DefaultRunLevelService$Worker.activateRunLevel(DefaultRunLevelService.java:1106)
at org.jvnet.hk2.component.internal.runlevel.DefaultRunLevelService$Worker.upActiveRecorder(DefaultRunLevelService.java:1060)
at org.jvnet.hk2.component.internal.runlevel.DefaultRunLevelService$Worker.run(DefaultRunLevelService.java:1026)
at org.jvnet.hk2.component.internal.runlevel.DefaultRunLevelService$SyncProceedToOp.proceedTo(DefaultRunLevelService.java:1256)
at org.jvnet.hk2.component.internal.runlevel.DefaultRunLevelService.proceedTo(DefaultRunLevelService.java:797)
at org.jvnet.hk2.component.internal.runlevel.DefaultRunLevelService.proceedTo(DefaultRunLevelService.java:759)
at com.sun.enterprise.v3.server.AppServerStartup.proceedTo(AppServerStartup.java:360)
at com.sun.enterprise.v3.server.AppServerStartup.run(AppServerStartup.java:254)
at com.sun.enterprise.v3.server.AppServerStartup.doStart(AppServerStartup.java:172)
at com.sun.enterprise.v3.server.AppServerStartup.start(AppServerStartup.java:163)
at com.sun.enterprise.glassfish.bootstrap.GlassFishImpl.start(GlassFishImpl.java:79)
at com.sun.enterprise.glassfish.bootstrap.GlassFishDecorator.start(GlassFishDecorator.java:63)
at com.sun.enterprise.glassfish.bootstrap.osgi.OSGiGlassFishImpl.start(OSGiGlassFishImpl.java:71)
at com.sun.enterprise.glassfish.bootstrap.GlassFishMain$Launcher.launch(GlassFishMain.java:117)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at com.sun.enterprise.glassfish.bootstrap.GlassFishMain.main(GlassFishMain.java:97)
at com.sun.enterprise.glassfish.bootstrap.ASMain.main(ASMain.java:55)
Caused by: java.lang.RuntimeException: Error while binding JNDI name enterprise.lottery_annotation_ejb_stateless.Dice for EJB DiceBean
at com.sun.ejb.containers.BaseContainer.initializeHome(BaseContainer.java:1546)
at com.sun.ejb.containers.StatelessSessionContainer.initializeHome(StatelessSessionContainer.java:206)
at com.sun.ejb.containers.ContainerFactoryImpl.createContainer(ContainerFactoryImpl.java:159)
at org.glassfish.ejb.startup.EjbApplication.loadContainers(EjbApplication.java:228)
... 45 more
Caused by: javax.naming.NameAlreadyBoundException: Use rebind to override
at com.sun.enterprise.naming.impl.TransientContext.doBindOrRebind(TransientContext.java:333)
at com.sun.enterprise.naming.impl.TransientContext.bind(TransientContext.java:268)
at com.sun.enterprise.naming.impl.SerialContextProviderImpl.bind(SerialContextProviderImpl.java:98)
at com.sun.enterprise.naming.impl.LocalSerialContextProviderImpl.bind(LocalSerialContextProviderImpl.java:99)
at com.sun.enterprise.naming.impl.SerialContext.bind(SerialContext.java:675)
at com.sun.enterprise.naming.impl.SerialContext.bind(SerialContext.java:692)
at javax.naming.InitialContext.bind(InitialContext.java:404)
at com.sun.enterprise.naming.impl.GlassfishNamingManagerImpl.publishObject(GlassfishNamingManagerImpl.java:208)
at com.sun.enterprise.naming.impl.GlassfishNamingManagerImpl.publishObject(GlassfishNamingManagerImpl.java:189)
at com.sun.ejb.containers.BaseContainer$JndiInfo.publish(BaseContainer.java:5520)
at com.sun.ejb.containers.BaseContainer.initializeHome(BaseContainer.java:1533)
... 48 more

#]

Test steps in IIOPFailoverDynamicICAccess:
1. Deploy cart.ear to st-cluster (7 instances)
2. Stop st-cluster then delete the last 2 instance.
3. Start st-cluster then add items to cart.
4. Deploy LotteryAnnotation.ear to st-cluster.
5. Create 2 instances and start instances.
6. Access Lottery remote interfaces and play.
7. Check instance logs to see if all remote calls have access to LotteryBean.setName.

Note: To ensure a clean build, b34 had a fresh re-installation and still saw this error.



 Comments   
Comment by mzh777 [ 03/May/12 ]

Attach the logs from DAS and st-cluster. The full testing steps is in ant.output.

Comment by mzh777 [ 03/May/12 ]

The full testing steps is in ant.output of the attached testing logs.
The test apps exceed the issue attachment limit. You can access the test apps cart.ear LotteryAnnotation.ear at /net/asqe-logs/export1/4.0/Results/build34/ha/iiop_rerun/

Comment by mzh777 [ 03/May/12 ]

I skipped step 5 and still saw the exceptions during the 2nd deployment (step 4). But the appclient was able to access Lottery app remotely and the test passed. It seems not an IIOP issue. Reassign the Component to Naming.

Comment by Cheng Fang [ 05/May/12 ]

did the test pass with b33? Is b34 the first build that had this failure?

Comment by Cheng Fang [ 06/May/12 ]

I don't have the file permission to copy the ear files. Ming, can you send them to me or open up the file permission?

So if step 4 failed without even running step 5, does that mean the first time deployment of lottery app failed because the binding for DiceBean already exists? This is strange if this is the first time deployment. Is there another EJB with the same jndi name, or is DiceBean declared twice in lottery app?

Comment by mzh777 [ 06/May/12 ]

Cheng, QE had run on b32 and the test failed too. I have added reading permission to the apps. There is no lottery app deployed on GF. I even tried to re-install new GF and run this test only. Still the 2nd deployment of lottery app had problem.

Comment by Cheng Fang [ 07/May/12 ]

cart.ear (the first deployed ear) contains a library jar (lib/LotteryAnnotation-ejb.jar), which is the same ejb-jar as in the second ear (LotteryAnnotation.ear).

So after car.ear is deployed, the jndi name enterprise.lottery_annotation_ejb_stateless.Dice is bound to DiceBean as declared in its library jar. When the deployment of LotteryAnnotation.ear tries to bind DiceBean to the same jndi name, hence the naming error.

The content of cart.ear:
0 Thu May 03 18:20:42 EDT 2012 META-INF/
102 Thu May 03 18:20:40 EDT 2012 META-INF/MANIFEST.MF
0 Thu May 03 18:20:40 EDT 2012 lib/
30435 Thu May 03 18:20:40 EDT 2012 cart-app-client.jar
2354 Thu May 03 18:20:40 EDT 2012 cart-ejb.jar
6435 Thu May 03 18:20:40 EDT 2012 lib/LotteryAnnotation-ejb.jar
4054 Thu May 03 18:20:40 EDT 2012 lib/callback-service.jar

The content of LotteryAnnotation.ear:
0 Thu May 03 18:20:40 EDT 2012 META-INF/
102 Thu May 03 18:20:38 EDT 2012 META-INF/MANIFEST.MF
13082 Thu May 03 18:20:40 EDT 2012 LotteryAnnotation-app-client.jar
6435 Thu May 03 18:20:40 EDT 2012 LotteryAnnotation-ejb.jar
10663 Thu May 03 18:20:40 EDT 2012 LotteryAnnotation-war.war
629 Thu May 03 18:20:40 EDT 2012 META-INF/application.xml
247 Thu May 03 18:20:40 EDT 2012 META-INF/sun-application.xml

My recommendation is to either remove the lib/LotteryAnnotation-ejb.jar from cart.ear, or skip the step that deploys LotteryAnnotation.ear.

Comment by Cheng Fang [ 07/May/12 ]

assign to deployment to see if any recent changes to ear lib annotation processing.

Comment by Hong Zhang [ 07/May/12 ]

The ear lib annotation processing was enabled in v3 and there is no recent behavior change in this area.

When did the regression start to happen? With a smaller window, we could look at the svn history to see if there are any related check ins.

But in any case, as Cheng commented, this seems to be an expected failure if you try to deploy EJB with same name from different applications. You should repackage the application as Cheng suggested.

Comment by mzh777 [ 07/May/12 ]

The test last passed on GF3.1.2 build 23:
http://javaweb.us.oracle.com/net/asqe-logs/export1/3.1.2/Results/build23/ha/oel6svn2/iiop/com.sun.dft.glassfish.iiop.dynamiccluster.failover.instanceadd.InitialContext.IIOPFailoverDynamicICAccess/

The deployment completed with warnings. There are javax.naming.NameAlreadyBoundException also in the server.log of instance101. Will investigate further by changing the cart.ear app and see if the failure still persists.

Comment by Hong Zhang [ 21/Jun/12 ]

Re-assign to Ming as he will try with the correct packaging to see if it resolves the issue.

Comment by mzh777 [ 01/Jul/12 ]

After commented out the second deployment of LotteryAnnotation.ear, the test passed manually. There are several other tests use the same client so need to find the impact of the changes to the other tests. Will update the bug when the tests are fixed.





[GLASSFISH-7163] QL fails to produce report if $CWD != "QL directory" Created: 10/Feb/09  Updated: 06/Mar/12

Status: Open
Project: glassfish
Component/s: sqe-test
Affects Version/s: V3
Fix Version/s: not determined

Type: Improvement Priority: Minor
Reporter: Sanjeeb Sahoo Assignee: mzh777
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: Sun


Issuezilla Id: 7,163

 Description   

It appears that someone is making an assumption that QL is invoked with current
working directory as <WS>/v3/tests/quicklook, where WS points to the directory
where v3 has been chcked out. When I tried running QL like this:
(cd /tmp; mvn -f <WS>/v3/tests/quicklook/pom.xml test -Dglassfish.home=/foo),
it produced the following error:

quicklook-summary:
[INFO] ------------------------------------------------------------------------
[ERROR] BUILD ERROR
[INFO] ------------------------------------------------------------------------
[INFO] An Ant BuildException has occured: The following error occurred while
executing this line:
/space/ss141213/WS/gf/v3/tests/quicklook/build.xml:74: The following error
occurred while executing this line:
/space/ss141213/WS/gf/v3/tests/quicklook/build.xml:260: Unable to load file:
java.io.FileNotFoundException:
/space/ss141213/WS/gf/v3/tests/quicklook/runtestng.output (No such file or
directory)

As you can see, it is looking for runtestng.output in QL directory, but it has
actually produced them in /tmp.

Please fix it instead of asking developers to cd to QL directory before
executing the tests.



 Comments   
Comment by mzh777 [ 01/Oct/09 ]

Change the issue type to enhancement and lower the priority to P4 for v3
release. Will address the issue during next QL enhancement.

Comment by Tom Mueller [ 06/Mar/12 ]

Bulk update to change fix version to "not determined" for all issues still open but with a fix version for a released version.





[GLASSFISH-8490] Need a QL test for 8438 Created: 08/Jun/09  Updated: 06/Mar/12

Status: Open
Project: glassfish
Component/s: sqe-test
Affects Version/s: V3
Fix Version/s: not determined

Type: Improvement Priority: Minor
Reporter: Byron Nevins Assignee: mzh777
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 8,490

 Description   

See IT 8438 for details.

We wasted a bunch of money on this because there is no test in place. Several
people had to poke around and try to figure out the problem.

Test – very simple

(1) start-domain
(2) create-domain --adminport 4848 domain2 --> EXPECT FAILURE, 4848 IS IN USE
(3) create-domain --adminport 4848 --no-checkports domain2 --> EXPECT SUCCESS,
a warning will be printed out
(4) delete-domain domain2



 Comments   
Comment by mzh777 [ 01/Oct/09 ]

Change the issue type to enhancement and lower the priority to P4 for v3
release. Will address the issue during next QL enhancement.

Comment by Tom Mueller [ 06/Mar/12 ]

Bulk update to change fix version to "not determined" for all issues still open but with a fix version for a released version.





[GLASSFISH-10476] derby.log is kept in domain1/config Created: 21/Oct/09  Updated: 06/Mar/12

Status: Open
Project: glassfish
Component/s: other
Affects Version/s: V3
Fix Version/s: not determined

Type: Bug Priority: Minor
Reporter: Sanjeeb Sahoo Assignee: mzh777
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 10,476

 Description   

I was surprised to see derby.log in domain1/config with following content:
----------------------------------------------------------------
2009-10-21 09:47:07.271 GMT:
Booting Derby version The Apache Software Foundation - Apache Derby - 10.5.3.0

  • (802917): instance a816c00e-0124-767e-1de5-000009898290
    on database directory
    /space/ss141213/WS/gf/v3/publish/glassfishv3/glassfish/domains/domain1/lib/databases/ejbtimer

Database Class Loader started - derby.database.classpath=''

It appears to be getting created during QL run. Do we expect write permission
for config dir?



 Comments   
Comment by dochez [ 28/Oct/09 ]

QL harness issue most likely, P4 though

Comment by Tom Mueller [ 06/Mar/12 ]

Bulk update to change fix version to "not determined" for all issues still open but with a fix version for a released version.





[GLASSFISH-9934] Can not build on JDK7 Created: 01/Oct/09  Updated: 06/Mar/12

Status: Open
Project: glassfish
Component/s: other
Affects Version/s: V3
Fix Version/s: not determined

Type: Bug Priority: Minor
Reporter: Byron Nevins Assignee: mzh777
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 9,934

 Description   

/export/home/bnlocal/gf/v3/deployment/dol/src/main/java/com/sun/enterprise/deployment/RootDeploymentDescriptor.java:307:
index has p rivate access in
RootDeploymentDescriptor
if (extension.index==null) {
^
/export/home/bnlocal/gf/v3/deployment/dol/src/main/java/com/sun/enterprise/deployment/RootDeploymentDescriptor.java:311:
index has p rivate access in
RootDeploymentDescriptor
if (index.equals(extension.index)) {
^
/export/home/bnlocal/gf/v3/deployment/dol/src/main/java/com/sun/enterprise/deployment/RootDeploymentDescriptor.java:327:
index has p rivate access in
RootDeploymentDescriptor
instance.index = index;
^
Note: Some input files use or override a deprecated API.



 Comments   
Comment by janey [ 26/Oct/09 ]

Not a must-fix for v3 release.

Comment by Byron Nevins [ 26/Oct/09 ]

This is a huge pain point for me at least.

I want to use dtrace in GF therefore I must use JDK7. But I have to reset to
JDK6 for every build.

Of course I always forget nd it takes about an hour for me to realize that I
need to switch back and then run the entire build over again.

Comment by Byron Nevins [ 26/Oct/09 ]

Note that V3 runs ok on 7 – it just won't build

Comment by Byron Nevins [ 26/Oct/09 ]

Work-around. Make the enforcer disallow trying to build on 7
This will stop the build fast with a sane error message...

Comment by Byron Nevins [ 26/Oct/09 ]

Enforcer jdk version

Old: [1.6,) 1.6 <= jdk

New: [1.6,1.7) 1.6 <= jdk < 1.7

Comment by janey [ 26/Oct/09 ]

Is the maven enforcer plugin preventing you to compile in JDK 7? The original description looks like a
different issue when building with JDK 7 - "Some input files use or override a deprecated API."

Comment by Byron Nevins [ 26/Oct/09 ]

I fixed the problem in DOL:
New Revision: 33337

Modified:

trunk/v3/deployment/dol/src/main/java/com/sun/enterprise/deployment/RootDeploymentDescriptor.java

Log:
https://glassfish.dev.java.net/issues/show_bug.cgi?id=9934

JDK6 bug. Discovered by trying to build with JDK7

Superclass method is trying to access a private variable of superclass through a
reference to a subclass. This was never allowed in Java.
The compiler in 6 must be confused by the Generics

Fix: Simply upcast the subclass reference. (Suggested by Bill Shannon)

===================================================================

I'm doing another build in JDK7 now...

Comment by Byron Nevins [ 26/Oct/09 ]

Security has some bad Generics constructs. JDK 7 found them.

============================

It took me 15 minutes to painstakingly find this error! It was buried in a sea
of warnings. javac does not print any string you can grep on to find the error.

1 error
135 warnings

=====================================

236
/export/home/bnlocal/gf/v3/security/core/src/main/java/com/sun/enterprise/security/SecurityDeployer.java:327:
name clash: <V
>loadMetaData(Class<V>,DeploymentContext) in SecurityDeployer and
loadMetaData(Class<T>,DeploymentContext) in SimpleDeployer have th
e same erasure, yet neither overrides the other
237 public <V> V loadMetaData(Class<V> type, DeploymentContext context) {
238 ^
239 where V,T are type-variables:
240 V extends Object declared in method
<V>loadMetaData(Class<V>,DeploymentContext)
241 T extends Container declared in class SimpleDeployer

Comment by Byron Nevins [ 26/Oct/09 ]

reassign

Comment by kumarjayanti [ 26/Oct/09 ]

Hong,

The method in Deployer.java is abstract

/**

  • Loads the meta date associated with the application.
    *
  • @parameters type type of metadata that this deployer has declared providing.
    */
    public <V> V loadMetaData(Class<V> type, DeploymentContext context);

and at the same time there is definition of the following method in
SimpleDeployer.java:

/**

  • Loads the meta date associated with the application.
    *
  • @parameters type type of metadata that this deployer has declared providing.
    */
    public T loadMetaData(Class<T> type, DeploymentContext context) { return null; }

As byron points out both the methods have the same erasure. So i am guessing
you really meant to implement the abstract method in SimpleDeployer. Is that
correct. If so can you fix this.

This bug is marked v3_exlude but i presume it is a simple fix.

Let me know.

Comment by kumarjayanti [ 27/Oct/09 ]

reassigning. Once you fix the SimpleDeployer i can remove the overriding method
in SecurityDeployer.

Comment by Byron Nevins [ 27/Oct/09 ]

Yes – please fix now.

I'd like to get to the next, currently unknown, bug that JDK7 uncovers!
Note that this is an error - not a warning.

Also what's up with the 135 warnings? Do you get that in security/core for a
JDK6 build too?

Comment by Hong Zhang [ 27/Oct/09 ]

kumar: I have checked in the changes in SimpleDeployer to make it has the same
signature as Deployer for loadMetaData method.

Comment by Byron Nevins [ 31/Oct/09 ]

Latest JDK7 build failure:

deployment/admin

/export/home/bnlocal/gf/v3/deployment/admin/src/test/java/org/glassfish/deployment/admin/ListComponentsCommandTest.java:210:
name clash: <T>getApplicationConfig(Class<T>) and getApplicationConfig(Class<?>)
have the same erasure
public <T extends ApplicationConfig> T getApplicationConfig(Class<T>
type)

{return null;}

^
where T is a type-variable:
T extends ApplicationConfig declared in method <T>getApplicationConfig(Class<T>)
Note: ListComponentsCommandTest.java uses unchecked or unsafe operations.
Note: Recompile with -Xlint:unchecked for details.

Comment by Hong Zhang [ 02/Nov/09 ]

Byron: I have fixed the latest problem in deployment/admin so I am assigning the
bug back to you for your futher findings with JDK7.

Comment by kumara [ 03/Nov/09 ]

-> P4 This is not visible to end users of GlassFish and therefore fits P4 classification.

Comment by Byron Nevins [ 04/Nov/09 ]

V3 compiles with JDK7 now!

The next issue is that QL fails with 2 errors I think.

To reproduce:

get JDK7 installed and ready
build v3 from scratch
run QL

Comment by Tom Mueller [ 06/Mar/12 ]

Bulk update to change fix version to "not determined" for all issues still open but with a fix version for a released version.





Generated at Mon May 25 04:16:29 UTC 2015 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.