[GLASSFISH-21334] JDK 9 - quicklook tests are broken Created: 19/Mar/15  Updated: 02/Apr/15

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

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

ALL


Tags: javaee_ri_fix, jdk9-int

 Description   

I am getting the following exception when I am running the quicklook test in JDK9

Failed to execute goal org.apache.maven.plugins:maven-antrun-plugin:1.7:run (default-test) on project quicklook: Execution default-test of goal org.apache.maven.plugins:maven-antrun-plugin:1.7:run failed: Plugin org.apache.maven.plugins:maven-antrun-plugin:1.7 or one of its dependencies could not be resolved: Could not find artifact com.sun:tools-jar:jar:1 at specified path /usr/lib/jvm/jdk1.9.0/../lib/tools.jar

In the pom.xml of quicklook project we have the following plugin

<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-antrun-plugin</artifactId>
<version>1.7</version>

maven-antrun-plugin internally uses tools.jar which is removed in JDK 9 as part of JEPS220.



 Comments   
Comment by Arindam Bandyopadhyay [ 19/Mar/15 ]

The related maven issue is https://jira.codehaus.org/browse/MNG-5732





[GLASSFISH-20446] transaction/ee/dblogs/mdb does not test auto-recovery for local jms Created: 30/Apr/13  Updated: 19/Sep/14

Status: Open
Project: glassfish
Component/s: test
Affects Version/s: 4.0_b86_RC2
Fix Version/s: 4.1

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


 Description   

setup-local always uses delegated=true






[GLASSFISH-20855] move and mavenize major developer tests from glassfish v2 repository to trunk/appserver/tests Created: 15/Oct/13  Updated: 15/Apr/14

Status: Open
Project: glassfish
Component/s: build_system, test
Affects Version/s: 4.0
Fix Version/s: future release

Type: Improvement Priority: Major
Reporter: Romain Grécourt Assignee: Romain Grécourt
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: 2 weeks
Time Spent: Not Specified
Original Estimate: 2 weeks
Environment:

any


Tags: devtest, glassfish, maven, test

 Description   
  • Current developer test suite are documented here: https://wikis.oracle.com/display/glassfish/DeveloperTestDashboard
  • Those test suites are owned by particular developer, they are responsible for monitoring the test results.
  • They can take some time to run, hence they are not required for every checkin but depending on the changes (owner will likely request it)

The codeline comes from GlassFish 2.x, the test codebase is still located in the v2 svn repository: https://svn.java.net/svn/glassfish~v2/trunk/appserv-tests/devtests/

Those tests suite are still developed, and are used to test the current GlassFish codeline.

  • They are using the infrastructure that is provided by the old workspace
  • It is based on ant and is sometime platform dependent (i.e, can't work on windows).
  • It requires shell environment configuration to run (PATH and environment variables used by the tests)

This improvement is about mavenizing some of those devtests with as few changes as possible, in order to provide the following:

  • No change in the source code
  • Only maven / jdk required, everything else is downloaded and configured on the fly via maven
  • A pom.xml wrapping the tests scenario (e.g. with profiles)
  • Test workspace nested under appserver/tests, in order to be tagged be each release

Some things nice to have:

  • Windows / UNIX profiles to help sorting the suite that supports windows or not.
  • Generation of standard junit/testng report for easier CI
  • Test coverage infra (with cobertura)

Here are the in-scope test suites:

  • deployment
  • ejb
  • security
  • admin
  • webtier

Eventually, some documentation should be written under appserver/tests to guide developers.






[GLASSFISH-19947] Some EJB devtests do not follow Interceptors spec for LC method signatures Created: 19/Mar/13  Updated: 19/Mar/13

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

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


 Description   

The Interceptors 1.2 (EE 7) has relaxed the LC method signature rules as follows:

Lifecycle callback interceptor methods defined on an interceptor class must have one of the following signatures:

void <METHOD>(InvocationContext)
Object <METHOD>(InvocationContext) throws Exception

Note: A lifecycle callback interceptor method must not throw application exceptions, but it may be declared to throw checked exceptions including the java.lang.Exception if the same interceptor method interposes on business or timeout methods in addition to lifecycle events. If a lifecycle callback interceptor method returns a value, it is ignored by the container.

Lifecycle callback interceptor methods defined on a target class have the following signature:

void <METHOD>()






[GLASSFISH-19851] Nucleus admin dev tests do not do a proper cleanup. Created: 13/Mar/13  Updated: 13/Mar/13

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

Type: Bug Priority: Critical
Reporter: Marek Potociar Assignee: Justin Lee
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: jersey, test-framework

 Description   

GF nucleus admin dev tests run before GF nucleus QL tests cause false negatives because GF nucleus admin dev tests do not clean-up GF test instance properly. This leads to observable false negatives behaviour on the same cleanly checked out sources, for example:

  1. run GF nucleus quick look - PASS
  2. run GF nucleus admin dev tests - PASS
  3. run GF nucleus quick look again - FAIL

Or:

  1. run GF nucleus admin dev tests - PASS
  2. run GF nucleus admin dev tests - FAIL

This issue complicates pre-integration testing required by Jersey and has cost us a lot of wasted effort on Jersey side.

From what we observed, a possible problem with admin dev tests AFAIK is that they leave a few GF instances running which may lead to port conflicts in the subsequently run test suites.






[GLASSFISH-13548] Allocate exception for servlet Simple com.sun.enterprise.container.common.spi.util.InjectionException Created: 20/Sep/10  Updated: 06/Mar/12

Status: Open
Project: glassfish
Component/s: test
Affects Version/s: 3.1
Fix Version/s: not determined

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

Operating System: All
Platform: Linux


Attachments: File SampleService.ear     Text File server.log     Text File server.log    
Issuezilla Id: 13,548
Tags: 3_1-exclude, test_issue

 Description   

Once I deploy this webservice transaction test application and access the
webservice, I get the below exception:

Steps to reproduce:
===================

1)Create connection pool using
asadmin --echo=true create-jdbc-connection-pool --datasourceclassname
org.apache.derby.jdbc.ClientXADataSource --restype javax.sql.XADataSource –
property
portNumber=1527:serverName=localhost:User=APP:Password=APP:databaseName=sample
derby_netPool

2)Create jdbc resource using
asadmin create-jdbc-resource --connectionpoolid derby_netPool --enabled=true
jdbc/JavaProgrammingLibrary

3)Deploy the attached application and access it from browser :
http://localhost:8080/SampleService-war/SimpleService?wsdl

Exception:
==========
[#|2010-09-
20T17:27:33.698+0530|INFO|glassfish3.1|javax.enterprise.system.tools.admin.org.g
lassfish.deployment.admin|_ThreadID=15;_ThreadName=Thread-1;|SampleService was
successfully deployed in 25,969 milliseconds.|#]

[#|2010-09-
20T17:27:36.247+0530|INFO|glassfish3.1|javax.enterprise.system.container.web.com
.sun.enterprise.web|_ThreadID=15;_ThreadName=Thread-1;|PWC1412: WebModule[null]
ServletContext.log():PWC1409: Marking servlet Simple as unavailable|#]

[#|2010-09-
20T17:27:36.247+0530|INFO|glassfish3.1|javax.enterprise.system.container.web.com
.sun.enterprise.web|_ThreadID=126;_ThreadName=http-thread-pool-
10080(1);|PWC1412: WebModule[null] ServletContext.log():PWC1409: Marking servlet
Simple as unavailable|#]

[#|2010-09-
20T17:27:36.247+0530|INFO|glassfish3.1|javax.enterprise.system.container.web.com
.sun.enterprise.web|_ThreadID=126;_ThreadName=http-thread-pool-
10080(1);|PWC1412: WebModule[null] ServletContext.log():PWC1409: Marking servlet
Simple as unavailable|#]

[#|2010-09-
20T17:27:36.250+0530|WARNING|glassfish3.1|javax.enterprise.system.container.web.
com.sun.enterprise.web|_ThreadID=15;_ThreadName=Thread-
1;|StandardWrapperValve[Simple]: PWC1382: Allocate exception for servlet Simple
com.sun.enterprise.container.common.spi.util.InjectionException: Error creating
managed object for class org.glassfish.webservices.JAXWSServlet
at
com.sun.enterprise.container.common.impl.util.InjectionManagerImpl.createManaged
Object(InjectionManagerImpl.java:317)
at
com.sun.enterprise.web.WebContainer.createServletInstance(WebContainer.java:690)
at
com.sun.enterprise.web.WebModule.createServletInstance(WebModule.java:1945)
at
org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.java:1251)
at
org.apache.catalina.core.StandardWrapper.allocate(StandardWrapper.java:1058)
at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:1
89)
at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:1
75)
at
org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:655)
at
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:595)
at com.sun.enterprise.web.WebPipeline.invoke(WebPipeline.java:98)
at
com.sun.enterprise.web.PESessionLockingStandardPipeline.invoke(PESessionLockingS
tandardPipeline.java:91)
at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:162)
at
org.apache.catalina.connector.CoyoteAdapter.doService(CoyoteAdapter.java:326)
at
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:227)
at
com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java
:228)
at
com.sun.grizzly.http.ProcessorTask.invokeAdapter(ProcessorTask.java:824)
at com.sun.grizzly.http.ProcessorTask.doProcess(ProcessorTask.java:721)
at com.sun.grizzly.http.ProcessorTask.process(ProcessorTask.java:1014)
at
com.sun.grizzly.http.DefaultProtocolFilter.execute(DefaultProtocolFilter.java:22
0)
at
com.sun.grizzly.DefaultProtocolChain.executeProtocolFilter(DefaultProtocolChain.
java:135)
at
com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:102)
at
com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:88)
at
com.sun.grizzly.http.HttpProtocolChain.execute(HttpProtocolChain.java:76)
at
com.sun.grizzly.ProtocolChainContextTask.doCall(ProtocolChainContextTask.java:53
)
at
com.sun.grizzly.SelectionKeyContextTask.call(SelectionKeyContextTask.java:57)
at com.sun.grizzly.ContextTask.run(ContextTask.java:69)
at
com.sun.grizzly.util.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:53
0)
at
com.sun.grizzly.util.AbstractThreadPool$Worker.run(AbstractThreadPool.java:511)
at java.lang.Thread.run(Thread.java:619)
Caused by: com.sun.enterprise.container.common.spi.util.InjectionException: No
descriptor registered for current invocation :
com.sun.enterprise.web.WebComponentInvocation@14b746c8
at
com.sun.enterprise.container.common.impl.util.InjectionManagerImpl.injectInstanc
e(InjectionManagerImpl.java:148)
at
com.sun.enterprise.container.common.impl.util.InjectionManagerImpl.injectInstanc
e(InjectionManagerImpl.java:132)
at
com.sun.enterprise.container.common.impl.util.InjectionManagerImpl.createManaged
Object(InjectionManagerImpl.java:311)
... 28 more

#]

[#|2010-09-
20T17:27:36.250+0530|WARNING|glassfish3.1|javax.enterprise.system.container.web.
com.sun.enterprise.web|_ThreadID=126;_ThreadName=http-thread-pool-
10080(1);|StandardWrapperValve[Simple]: PWC1382: Allocate exception for servlet
Simple
com.sun.enterprise.container.common.spi.util.InjectionException: Error creating
managed object for class org.glassfish.webservices.JAXWSServlet
at
com.sun.enterprise.container.common.impl.util.InjectionManagerImpl.createManaged
Object(InjectionManagerImpl.java:317)
at
com.sun.enterprise.web.WebContainer.createServletInstance(WebContainer.java:690)
at
com.sun.enterprise.web.WebModule.createServletInstance(WebModule.java:1945)
at
org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.java:1251)
at
org.apache.catalina.core.StandardWrapper.allocate(StandardWrapper.java:1058)
at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:1
89)
at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:1
75)
at
org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:655)
at
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:595)
at com.sun.enterprise.web.WebPipeline.invoke(WebPipeline.java:98)
at
com.sun.enterprise.web.PESessionLockingStandardPipeline.invoke(PESessionLockingS
tandardPipeline.java:91)
at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:162)
at
org.apache.catalina.connector.CoyoteAdapter.doService(CoyoteAdapter.java:326)
at
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:227)
at
com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java
:228)
at
com.sun.grizzly.http.ProcessorTask.invokeAdapter(ProcessorTask.java:824)
at com.sun.grizzly.http.ProcessorTask.doProcess(ProcessorTask.java:721)
at com.sun.grizzly.http.ProcessorTask.process(ProcessorTask.java:1014)
at
com.sun.grizzly.http.DefaultProtocolFilter.execute(DefaultProtocolFilter.java:22
0)
at
com.sun.grizzly.DefaultProtocolChain.executeProtocolFilter(DefaultProtocolChain.
java:135)
at
com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:102)
at
com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:88)
at
com.sun.grizzly.http.HttpProtocolChain.execute(HttpProtocolChain.java:76)
at
com.sun.grizzly.ProtocolChainContextTask.doCall(ProtocolChainContextTask.java:53
)
at
com.sun.grizzly.SelectionKeyContextTask.call(SelectionKeyContextTask.java:57)
at com.sun.grizzly.ContextTask.run(ContextTask.java:69)
at
com.sun.grizzly.util.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:53
0)
at
com.sun.grizzly.util.AbstractThreadPool$Worker.run(AbstractThreadPool.java:511)
at java.lang.Thread.run(Thread.java:619)
Caused by: com.sun.enterprise.container.common.spi.util.InjectionException: No
descriptor registered for current invocation :
com.sun.enterprise.web.WebComponentInvocation@14b746c8
at
com.sun.enterprise.container.common.impl.util.InjectionManagerImpl.injectInstanc
e(InjectionManagerImpl.java:148)
at
com.sun.enterprise.container.common.impl.util.InjectionManagerImpl.injectInstanc
e(InjectionManagerImpl.java:132)
at
com.sun.enterprise.container.common.impl.util.InjectionManagerImpl.createManaged
Object(InjectionManagerImpl.java:311)
... 28 more

#]

[#|2010-09-
20T17:27:36.250+0530|WARNING|glassfish3.1|javax.enterprise.system.container.web.
com.sun.enterprise.web|_ThreadID=126;_ThreadName=http-thread-pool-
10080(1);|StandardWrapperValve[Simple]: PWC1382: Allocate exception for servlet
Simple
com.sun.enterprise.container.common.spi.util.InjectionException: Error creating
managed object for class org.glassfish.webservices.JAXWSServlet
at
com.sun.enterprise.container.common.impl.util.InjectionManagerImpl.createManaged
Object(InjectionManagerImpl.java:317)
at
com.sun.enterprise.web.WebContainer.createServletInstance(WebContainer.java:690)
at
com.sun.enterprise.web.WebModule.createServletInstance(WebModule.java:1945)
at
org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.java:1251)
at
org.apache.catalina.core.StandardWrapper.allocate(StandardWrapper.java:1058)
at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:1
89)
at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:1
75)
at
org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:655)
at
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:595)
at com.sun.enterprise.web.WebPipeline.invoke(WebPipeline.java:98)
at
com.sun.enterprise.web.PESessionLockingStandardPipeline.invoke(PESessionLockingS
tandardPipeline.java:91)
at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:162)
at
org.apache.catalina.connector.CoyoteAdapter.doService(CoyoteAdapter.java:326)
at
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:227)
at
com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java
:228)
at
com.sun.grizzly.http.ProcessorTask.invokeAdapter(ProcessorTask.java:824)
at com.sun.grizzly.http.ProcessorTask.doProcess(ProcessorTask.java:721)
at com.sun.grizzly.http.ProcessorTask.process(ProcessorTask.java:1014)
at
com.sun.grizzly.http.DefaultProtocolFilter.execute(DefaultProtocolFilter.java:22
0)
at
com.sun.grizzly.DefaultProtocolChain.executeProtocolFilter(DefaultProtocolChain.
java:135)
at
com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:102)
at
com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:88)
at
com.sun.grizzly.http.HttpProtocolChain.execute(HttpProtocolChain.java:76)
at
com.sun.grizzly.ProtocolChainContextTask.doCall(ProtocolChainContextTask.java:53
)
at
com.sun.grizzly.SelectionKeyContextTask.call(SelectionKeyContextTask.java:57)
at com.sun.grizzly.ContextTask.run(ContextTask.java:69)
at
com.sun.grizzly.util.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:53
0)
at
com.sun.grizzly.util.AbstractThreadPool$Worker.run(AbstractThreadPool.java:511)
at java.lang.Thread.run(Thread.java:619)
Caused by: com.sun.enterprise.container.common.spi.util.InjectionException: No
descriptor registered for current invocation :
com.sun.enterprise.web.WebComponentInvocation@14b746c8
at
com.sun.enterprise.container.common.impl.util.InjectionManagerImpl.injectInstanc
e(InjectionManagerImpl.java:148)
at
com.sun.enterprise.container.common.impl.util.InjectionManagerImpl.injectInstanc
e(InjectionManagerImpl.java:132)
at
com.sun.enterprise.container.common.impl.util.InjectionManagerImpl.createManaged
Object(InjectionManagerImpl.java:311)
... 28 more

#]


 Comments   
Comment by Sreekanth [ 20/Sep/10 ]

Created an attachment (id=4923)
Ear file

Comment by Bhakti Mehta [ 11/Oct/10 ]
      • Issue 13549 has been marked as a duplicate of this issue. ***
Comment by Bhakti Mehta [ 30/Nov/10 ]

Rama, please can you look into this issue with WSServletContextListener This is the stacktrace I am seeing with yesterday's build
asadmin deploy ~/gfbugs/13458/SampleService.ear
org.glassfish.api.admin.CommandException: remote failure: Error occurred during deployment: Exception while loading the app : java.lang.IllegalStateException: ContainerBase.addChild: start: org.apache.catalina.LifecycleException: java.lang.IllegalArgumentException: javax.servlet.ServletException: com.sun.enterprise.container.common.spi.util.InjectionException: Error creating managed object for class org.glassfish.webservices.WSServletContextListener. Please see server.log for more details.
Command deploy failed.

Btw I tried these steps
asadmin --echo=true create-jdbc-connection-pool --datasourceclassname org.apache.derby.jdbc.ClientXADataSource --restype javax.sql.XADataSource --property portNumber=1527:serverName=localhost:User=APP:Password=APP:databaseName=sample derby_netPool

asadmin create-jdbc-resource --connectionpoolid derby_netPool --enabled=true jdbc/JavaProgrammingLibrary

asadmin deploy ~/gfbugs/13458/SampleService.ear

Comment by ramapulavarthi [ 15/Dec/10 ]

I tried with latest V3.1 standalone built from my local workspace and I could not reproduce the problem. The ear file deployed fine for me. Are you seeing problem when deploying to a cluster? Please confirm the issue with latest Galssfish V3.1 nightly/promoted build.

Comment by ramapulavarthi [ 15/Dec/10 ]

Please confirm the issue with latest build of v3.1.

Comment by Sreekanth [ 20/Dec/10 ]

I am still seeing this issue with the latest build of metro and glassfish 3.1 .I am not using clustered environment.But I have 2 domains running on that server.

Please find the attached server log.

Comment by Sreekanth [ 20/Dec/10 ]

Server file.

Comment by Sreekanth [ 20/Dec/10 ]

Assigning back to Rama.

Comment by ramapulavarthi [ 20/Dec/10 ]

Sreekanth, Can you reproduce it on a default glassfish installation that has single (default) domain?

Comment by Sreekanth [ 21/Dec/10 ]

Yes.It is reproducible on default setup as well.

Comment by Sreekanth [ 21/Dec/10 ]

log file when run with default glassfish installation

Comment by ramapulavarthi [ 22/Dec/10 ]

Finally I have managed to deploy the ear with some modifications.
(1) There are additional resources required by the application. They can be created by doing
asadmin create-jms-resource --restype javax.jms.Queue --enabled=true --property Name=PhysicalQueue jms/Queue
asadmin create-jms-resource --restype javax.jms.ConnectionFactory jms/ConnectionFactory

These steps are gathered from wstx sample in https://wsit-docs.dev.java.net/releases/1.2/wsittutorial.zip

(2) The contents of the ear file are
META-INF/
META-INF/MANIFEST.MF
jar/
lib/
META-INF/application.xml
META-INF/sun-application.xml
SampleService-ejb.jar
SampleService-war.war
lib/SampleService-ejb.jar ---> is not needed and should be removed.

(3) In this application, the META-INF/MANIFEST.MF in SampleService-war.war has Class-Path: SampleService-ejb.jar which is discovered by the EJB Deployer twice as it exists in root ear as well as the classpath of the war.

There seems to be a bug in Gllassfish deployment, when an ejb is shared by the web application like this, the EJB annotations (in this case ws) are processed twice. Some observations about the problem can also be found at a Users's blog http://www.shareyourwork.org/roller/ralphsjavablog/entry/jee6_and_packaging_an_ear.

To workaround this, remove the Class-Path entry in SampleService-war.war META-INF/MANIFEST.MF. Also, this ejb is not used by the Servlet at all and seems to have been introduced for no useful reason. I could deploy fine with the above modifications.

With this evaluation, I think this is a non-blocker for Metro in v3.1. Deployment issue in v3.1 has to be pursued as a separate issue in GF.

Comment by ramapulavarthi [ 23/Dec/10 ]

Assigning back to sqe and adding 3_1-exclude so that sqe can continue to track it for fixing the test case.

The EAR should be fixed to not share the EJB components. May be the Deployer could be intelligent to detect this and warn the users on deployment, but it is tricky to implement with the possibility of different components packaged in the same module in JavaEE 6. The discussion on topic can be followed at http://java.net/projects/glassfish/lists/dev/archive/2010-12/message/200

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-14687] [regression] javax.xml.ws.WebServiceException while deploying a 109 web service Created: 15/Nov/10  Updated: 17/Feb/12

Status: Reopened
Project: glassfish
Component/s: test
Affects Version/s: 3.1
Fix Version/s: None

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

Operating System: All
Platform: Linux


Attachments: Java Archive File 14687-src.jar     File jaxws-wsamss11.war     File jaxws-wsamss12.war     Text File server.log    
Issuezilla Id: 14,687
Tags: 3_1-exclude, 3_1_2-exclude, metro2_2-waived

 Description   

While deploying the attached applications on 3.1 build 29 get the following
exception. This used to work fine with GF 3.0.1.

[#|2010-11-15T18:57:38.336+0530|WARNING|glassfish3.1|javax.enterprise.webservices.org.glassfish.webservices|_ThreadID=14;_ThreadName=Thread-1;|Deployment
failed
javax.xml.ws.WebServiceException: WSDL
jndi:/server/jaxws-wsamss11/WEB-INF/wsdl/wsaTestService.wsdl has the following
services [

{http://example.org/wsaTestService}

wsaTestService] but not . Maybe you
forgot to specify a serviceName and/or targetNamespace in
@WebService/@WebServiceProvider?
at
com.sun.xml.ws.server.EndpointFactory.verifyPrimaryWSDL(EndpointFactory.java:481)
at com.sun.xml.ws.server.EndpointFactory.createEndpoint(EndpointFactory.java:159)
at com.sun.xml.ws.api.server.WSEndpoint.create(WSEndpoint.java:513)
at com.sun.xml.ws.api.server.WSEndpoint.create(WSEndpoint.java:568)
at
org.glassfish.webservices.WSServletContextListener.registerEndpoint(WSServletContextListener.java:260)
at
org.glassfish.webservices.WSServletContextListener.contextInitialized(WSServletContextListener.java:99)
at
org.apache.catalina.core.StandardContext.contextListenerStart(StandardContext.java:4703)
at com.sun.enterprise.web.WebModule.contextListenerStart(WebModule.java:533)
at org.apache.catalina.core.StandardContext.start(StandardContext.java:5323)
at com.sun.enterprise.web.WebModule.start(WebModule.java:497)
at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:917)
at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:901)
at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:697)
at com.sun.enterprise.web.WebContainer.loadWebModule(WebContainer.java:1934)
at com.sun.enterprise.web.WebContainer.loadWebModule(WebContainer.java:1611)
at com.sun.enterprise.web.WebApplication.start(WebApplication.java:100)
at org.glassfish.internal.data.EngineRef.start(EngineRef.java:130)
at org.glassfish.internal.data.ModuleInfo.start(ModuleInfo.java:242)
at org.glassfish.internal.data.ApplicationInfo.start(ApplicationInfo.java:262)
at
com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:438)
at
com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:243)
at org.glassfish.deployment.admin.DeployCommand.execute(DeployCommand.java:351)
at
com.sun.enterprise.v3.admin.CommandRunnerImpl$1.execute(CommandRunnerImpl.java:354)
at
com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:369)
at
com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:1061)
at
com.sun.enterprise.v3.admin.CommandRunnerImpl.access$1200(CommandRunnerImpl.java:95)
at
com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1257)
at
com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1246)
at com.sun.enterprise.v3.admin.AdminAdapter.doCommand(AdminAdapter.java:396)
at com.sun.enterprise.v3.admin.AdminAdapter.service(AdminAdapter.java:216)
at com.sun.grizzly.tcp.http11.GrizzlyAdapter.service(GrizzlyAdapter.java:168)
at com.sun.enterprise.v3.server.HK2Dispatcher.dispath(HK2Dispatcher.java:117)
at
com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:234)
at com.sun.grizzly.http.ProcessorTask.invokeAdapter(ProcessorTask.java:817)
at com.sun.grizzly.http.ProcessorTask.doProcess(ProcessorTask.java:718)
at com.sun.grizzly.http.ProcessorTask.process(ProcessorTask.java:1007)
at
com.sun.grizzly.http.DefaultProtocolFilter.execute(DefaultProtocolFilter.java:225)
at
com.sun.grizzly.DefaultProtocolChain.executeProtocolFilter(DefaultProtocolChain.java:137)
at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:104)
at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:90)
at com.sun.grizzly.http.HttpProtocolChain.execute(HttpProtocolChain.java:79)
at
com.sun.grizzly.ProtocolChainContextTask.doCall(ProtocolChainContextTask.java:54)
at com.sun.grizzly.SelectionKeyContextTask.call(SelectionKeyContextTask.java:59)
at com.sun.grizzly.ContextTask.run(ContextTask.java:71)
at
com.sun.grizzly.util.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:532)
at com.sun.grizzly.util.AbstractThreadPool$Worker.run(AbstractThreadPool.java:513)
at java.lang.Thread.run(Thread.java:619)

#]

[#|2010-11-15T18:57:38.343+0530|SEVERE|glassfish3.1|org.apache.catalina.core.StandardContext|_ThreadID=14;_ThreadName=Thread-1;|PWC1306:
Startup of context /jaxws-wsamss11 failed due to previous errors|#]

[#|2010-11-15T18:57:38.347+0530|SEVERE|glassfish3.1|org.apache.catalina.core.StandardContext|_ThreadID=14;_ThreadName=Thread-1;|PWC1305:
Exception during cleanup after start failed
org.apache.catalina.LifecycleException: PWC2769: Manager has not yet been started
at org.apache.catalina.session.StandardManager.stop(StandardManager.java:872)
at org.apache.catalina.core.StandardContext.stop(StandardContext.java:5527)
at com.sun.enterprise.web.WebModule.stop(WebModule.java:528)
at org.apache.catalina.core.StandardContext.start(StandardContext.java:5341)
at com.sun.enterprise.web.WebModule.start(WebModule.java:497)
at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:917)
at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:901)
at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:697)
at com.sun.enterprise.web.WebContainer.loadWebModule(WebContainer.java:1934)
at com.sun.enterprise.web.WebContainer.loadWebModule(WebContainer.java:1611)
at com.sun.enterprise.web.WebApplication.start(WebApplication.java:100)
at org.glassfish.internal.data.EngineRef.start(EngineRef.java:130)
at org.glassfish.internal.data.ModuleInfo.start(ModuleInfo.java:242)
at org.glassfish.internal.data.ApplicationInfo.start(ApplicationInfo.java:262)
at
com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:438)
at
com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:243)
at org.glassfish.deployment.admin.DeployCommand.execute(DeployCommand.java:351)
at
com.sun.enterprise.v3.admin.CommandRunnerImpl$1.execute(CommandRunnerImpl.java:354)
at
com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:369)
at
com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:1061)
at
com.sun.enterprise.v3.admin.CommandRunnerImpl.access$1200(CommandRunnerImpl.java:95)
at
com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1257)
at
com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1246)
at com.sun.enterprise.v3.admin.AdminAdapter.doCommand(AdminAdapter.java:396)
at com.sun.enterprise.v3.admin.AdminAdapter.service(AdminAdapter.java:216)
at com.sun.grizzly.tcp.http11.GrizzlyAdapter.service(GrizzlyAdapter.java:168)
at com.sun.enterprise.v3.server.HK2Dispatcher.dispath(HK2Dispatcher.java:117)
at
com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:234)
at com.sun.grizzly.http.ProcessorTask.invokeAdapter(ProcessorTask.java:817)
at com.sun.grizzly.http.ProcessorTask.doProcess(ProcessorTask.java:718)
at com.sun.grizzly.http.ProcessorTask.process(ProcessorTask.java:1007)
at
com.sun.grizzly.http.DefaultProtocolFilter.execute(DefaultProtocolFilter.java:225)
at
com.sun.grizzly.DefaultProtocolChain.executeProtocolFilter(DefaultProtocolChain.java:137)
at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:104)
at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:90)
at com.sun.grizzly.http.HttpProtocolChain.execute(HttpProtocolChain.java:79)
at
com.sun.grizzly.ProtocolChainContextTask.doCall(ProtocolChainContextTask.java:54)
at com.sun.grizzly.SelectionKeyContextTask.call(SelectionKeyContextTask.java:59)
at com.sun.grizzly.ContextTask.run(ContextTask.java:71)
at
com.sun.grizzly.util.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:532)
at com.sun.grizzly.util.AbstractThreadPool$Worker.run(AbstractThreadPool.java:513)
at java.lang.Thread.run(Thread.java:619)

#]


 Comments   
Comment by sonymanuel [ 15/Nov/10 ]

Created an attachment (id=5464)
webservice app

Comment by sonymanuel [ 15/Nov/10 ]

Created an attachment (id=5465)
app2

Comment by sonymanuel [ 15/Nov/10 ]

Created an attachment (id=5466)
server log

Comment by Bhakti Mehta [ 20/Nov/10 ]

Is this only happening in specific cases. I do not see cts failures related to
this. Requesting Rama to look into this

Comment by jitu [ 08/Dec/10 ]

Can you attach the source code. Want to see primarily @WebService, @WebServiceProvider annotations.
WEB-INF/classes/wsa/msinterop/s11/server/NonAnonymousProvider.class
WEB-INF/classes/wsa/msinterop/s11/server/WsaTestImpl.class
WEB-INF/classes/wsa/msinterop/s11/server/WsaTestPortType.class
WEB-INF/classes/wsa/msinterop/s11/server/WsaTestService.class

Comment by sonymanuel [ 08/Dec/10 ]

Attaching requested src.

Comment by jitu [ 09/Dec/10 ]

@WebServiceProvider(wsdlLocation="WEB-INF/wsdl/wsaTestService.wsdl")
@ServiceMode(value = Service.Mode.MESSAGE)
public class NonAnonymousProvider implements Provider<SOAPMessage> {
}

In the above class, WSDL is specified, but not serviceName, portName, and targetNamespace elements. Otherwise, runtime cannot find a correponding port in WSDL. I would be really surprised, if this really worked any time.

Also, I don't see any use in specifying wsdlLocation in this case. Correct the test.

Comment by jitu [ 09/Dec/10 ]

Test case is invalid.

Comment by sonymanuel [ 21/Dec/10 ]

I tried deploying the app on GF 3.0.1 and it works fine. See logs below.

[#|2010-12-21T22:53:24.424+0530|INFO|glassfish3.0.1|javax.enterprise.webservices.org.glassfish.webservices|_ThreadID=26;_ThreadName=Thread-1;|WS00018: Webservice Endpoint deployed
WsaTestImpl listening at address at http://localhost:10128/jaxws-wsamss11/wsaTestService|#]

[#|2010-12-21T22:53:24.425+0530|INFO|glassfish3.0.1|javax.enterprise.webservices.org.glassfish.webservices|_ThreadID=26;_ThreadName=Thread-1;|WS00018: Webservice Endpoint deployed
wsa.msinterop.s11.server.NonAnonymousProvider listening at address at http://localhost:10128/jaxws-wsamss11/NonAnonymousProviderService|#]

[#|2010-12-21T22:53:24.475+0530|INFO|glassfish3.0.1|javax.enterprise.system.container.web.com.sun.enterprise.web|_ThreadID=26;_ThreadName=Thread-1;|Loading application jaxws-wsamss11 at /jaxws-wsamss11|#]

[#|2010-12-21T22:53:24.475+0530|INFO|glassfish3.0.1|javax.enterprise.system.container.web.com.sun.enterprise.web|_ThreadID=26;_ThreadName=http-thread-pool-10096-(1);|Loading application jaxws-wsamss11 at /jaxws-wsamss11|#]

[#|2010-12-21T22:53:24.475+0530|INFO|glassfish3.0.1|javax.enterprise.system.container.web.com.sun.enterprise.web|_ThreadID=26;_ThreadName=http-thread-pool-10096-(1);|Loading application jaxws-wsamss11 at /jaxws-wsamss11|#]

[#|2010-12-21T22:53:24.486+0530|INFO|glassfish3.0.1|javax.enterprise.system.tools.admin.org.glassfish.deployment.admin|_ThreadID=26;_ThreadName=Thread-1;|jaxws-wsamss11 was successfully deployed in 229 milliseconds.|#]

I checked the CVS history for this test case. This particular test was written by Arun and checked in by Deepak (I think) on 2007/03/09. There has been no change to the test or config file since. Since it deployed fine on GF 3.0.1, I assume it worked on all prior GF/Metro releases till 2007/03/09

Reopening the issue as it is a regression and ~450 jax-wsa interop test cases are blocked because of this deployment issue.

The sources are available
tango/qe-tests/jax-wsa/interop-109/src/wsamss11

If its a test case please let me know exactly what to fix since I am fairly new to this.

With the 20th Dec nightly build I am seeing a NPE.

[#|2010-12-21T22:46:24.266+0530|SEVERE|glassfish3.1|javax.enterprise.system.core.com.sun.enterprise.v3.server|_ThreadID=15;_ThreadName=Thread-1;|The log message is null.
java.lang.RuntimeException
at org.glassfish.webservices.WebServicesDeployer.prepare(WebServicesDeployer.java:192)
at com.sun.enterprise.v3.server.ApplicationLifecycle.prepareModule(ApplicationLifecycle.java:870)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:410)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:240)
at org.glassfish.deployment.admin.DeployCommand.execute(DeployCommand.java:370)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$1.execute(CommandRunnerImpl.java:354)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:369)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:1080)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.access$1200(CommandRunnerImpl.java:95)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1260)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1248)
at com.sun.enterprise.v3.admin.AdminAdapter.doCommand(AdminAdapter.java:453)
at com.sun.enterprise.v3.admin.AdminAdapter.service(AdminAdapter.java:220)
at com.sun.grizzly.tcp.http11.GrizzlyAdapter.service(GrizzlyAdapter.java:168)
at com.sun.enterprise.v3.server.HK2Dispatcher.dispath(HK2Dispatcher.java:117)
at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:234)
at com.sun.grizzly.http.ProcessorTask.invokeAdapter(ProcessorTask.java:817)
at com.sun.grizzly.http.ProcessorTask.doProcess(ProcessorTask.java:718)
at com.sun.grizzly.http.ProcessorTask.process(ProcessorTask.java:1007)
at com.sun.grizzly.http.DefaultProtocolFilter.execute(DefaultProtocolFilter.java:225)
at com.sun.grizzly.DefaultProtocolChain.executeProtocolFilter(DefaultProtocolChain.java:137)
at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:104)
at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:90)
at com.sun.grizzly.http.HttpProtocolChain.execute(HttpProtocolChain.java:79)
at com.sun.grizzly.ProtocolChainContextTask.doCall(ProtocolChainContextTask.java:54)
at com.sun.grizzly.SelectionKeyContextTask.call(SelectionKeyContextTask.java:59)
at com.sun.grizzly.ContextTask.run(ContextTask.java:71)
at com.sun.grizzly.util.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:532)
at com.sun.grizzly.util.AbstractThreadPool$Worker.run(AbstractThreadPool.java:513)
at java.lang.Thread.run(Thread.java:619)
Caused by: java.lang.NullPointerException
at org.glassfish.webservices.WebServicesDeployer.doWebServiceDeployment(WebServicesDeployer.java:719)
at org.glassfish.webservices.WebServicesDeployer.doWebServicesDeployment(WebServicesDeployer.java:650)
at org.glassfish.webservices.WebServicesDeployer.prepare(WebServicesDeployer.java:183)
... 29 more

#]
Comment by ramapulavarthi [ 23/Dec/10 ]

We should definitely fix the NPE.

Regarding the original issue, as Jitu mentioned test case need to be fixed to specify serviceName and portName and targetNameSpace in @WebServiceProvider matching those attributes in the packaged wsdl. In V2 we might be creating the web service endpoint lazily giving a false sense of deployment success. If you try to access the endpoint, then you would see if the web service was created successfully. Check the logs by accessing http://localhost:10128/jaxws-wsamss11/NonAnonymousProviderService in a browser after deploying on V2 or V3.0.1. Though the testcase is not modified, it is possible that the the test case has not been ever verified to make sure that the non-anonymous endpoint receives messages.

Comment by ramapulavarthi [ 23/Dec/10 ]

Removing the 3_1-regression keyword as it is not real regression. Adding 3_1-exclude so that sqe can continue to track for fixing the test case.

As earlier evaluated, in V3.1 we are creating web service endpoints on deployment unlike in previous versions where endpoints are lazily created. This is done as fix for https://glassfish.dev.java.net/issues/show_bug.cgi?id=14061. This is one way good that it finds the serious runtime errors during deployment itself. The sqe test case should be corrected and the exception in the log is clear on what is missing. Here is the excerpt from v3.1 log.

Caused by: java.lang.RuntimeException: Servlet web service endpoint '' failure
at org.glassfish.webservices.WSServletContextListener.contextInitialized(WSServletContextListener.java:104)
at org.apache.catalina.core.StandardContext.contextListenerStart(StandardContext.java:4683)
at com.sun.enterprise.web.WebModule.contextListenerStart(WebModule.java:531)
at org.apache.catalina.core.StandardContext.start(StandardContext.java:5303)
... 38 more
Caused by: javax.xml.ws.WebServiceException: WSDL jndi:/server/jaxws-wsamss11/WEB-INF/wsdl/wsaTestService.wsdl has the following services [

{http://example.org/wsaTestService}

wsaTestService] but not . Maybe you forgot to specify a serviceName and/or targetNamespace in @WebService/@WebServiceProvider?
at com.sun.xml.ws.server.EndpointFactory.verifyPrimaryWSDL(EndpointFactory.java:481)
at com.sun.xml.ws.server.EndpointFactory.createEndpoint(EndpointFactory.java:159)
at com.sun.xml.ws.api.server.WSEndpoint.create(WSEndpoint.java:513)
at com.sun.xml.ws.api.server.WSEndpoint.create(WSEndpoint.java:568)
at org.glassfish.webservices.WSServletContextListener.registerEndpoint(WSServletContextListener.java:260)
at org.glassfish.webservices.WSServletContextListener.contextInitialized(WSServletContextListener.java:99)
... 41 more

#]
Comment by ramapulavarthi [ 23/Dec/10 ]

sqe should fix the testcase

Comment by sonymanuel [ 03/Jan/11 ]

Assigning to Anand for checking the testcase.

Comment by Martin Grebac [ 09/Dec/11 ]

Sreekanth, is this one still valid?

Comment by Sreekanth [ 17/Feb/12 ]

This is still an issue with the latest promoted build of glassfish 3.1.2.Will try to fix as suggested by Jitu and Rama





[GLASSFISH-16507] Servlet 2.3 test case compile error with JDK7 - missing package com.sun.image.codec.jpeg Created: 30/Apr/11  Updated: 28/Jan/12

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

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

System running RHEL 5 with JDK7 build136 acquired at http://jre.us.oracle.com/java/re/jdk/7/promoted/ea/b136/bundles/ and Glassfish 3.1.1 build3


Tags: 3_1-next, 3_1_1-scrubbed

 Description   

When compiling our Servlet 2.3 test cases, it fails due error: package com.sun.image.codec.jpeg does not exist

In researching through Google, found several references that in OpenJDK this package has been removed and in the Java Advance Imaging Home page (http://java.sun.com/products/java-media/jai/iio.html), under the JPEG section, it mentions that some of the classes are unofficially implemented in the com.sun.image.codec.jpeg package.

What is not clear is what is the story with JDK7 and whether this is a JDK or an implementation issue that needs to be solved in our test case, thus, the reason for the bug report. We hope to get clarity on this point and perhaps instructions on how to replace these classes with a supported type in JDK7.

To see the problem, please follow the following example, but please adjust the glassfish3, jdk, ant location and your id in CVSROOT

% setenv CVSROOT :pserver:cvsguest@sunsw.us.oracle.com:/m/jws
% setenv SPS_HOME /space/test1/ws/appserver-sqe
% setenv S1AS_HOME /space/test1/glassfish3/glassfish
% setenv JAVA_HOME /space/test1/tool/jdk1.7.0-b136
% setenv ANT_HOME /space/test1/tool/apache-ant-1.7.1
% setenv PATH $JAVA_HOME/bin:$ANT_HOME/bin:$S1AS_HOME/bin:$PATH

To check out test source

% cvs co appserver-sqe/bootstrap.xml
% cd appserver-sqe
% ant -f bootstrap.xml co-core

To run the test
% ant start-domain
% ant startDerby
% ant v3g-core-all
% ant v3g-tomcat-all

After the test fishines (or aborts), run the following to stop the server
% ant stopDerby
% ant stop-domain

The complete compile error is:
[javac] Compiling 18 source files to /export/hudson/workspace/alex-core-jdk7/appserver-sqe/build/pe/amd64_wolfrun.us.oracle.com_Linux/tomcat-servlets/classes/com/sun/s1aspesqe/product_test/servlet2_3/WEB-INF/classes
[javac] /export/hudson/workspace/alex-core-jdk7/appserver-sqe/pe/tomcat/servlet/product_test
/servlet2_3/src/filters/FilterImage.java:72: error: package com.sun.image.codec.jpeg does not ex
ist [javac] import com.sun.image.codec.jpeg.JPEGImageEncoder; [javac] ^
[javac] /export/hudson/workspace/alex-core-jdk7/appserver-sqe/pe/tomcat/servlet/product_test
/servlet2_3/src/filters/FilterWEG.java:73: error: package com.sun.image.codec.jpeg does not exis
t [javac] import com.sun.image.codec.jpeg.JPEGImageEncoder; [javac] ^
[javac] /export/hudson/workspace/alex-core-jdk7/appserver-sqe/pe/tomcat/servlet/product_test
/servlet2_3/src/filters/FilterWRES.java:72: error: package com.sun.image.codec.jpeg does not exi
st [javac] import com.sun.image.codec.jpeg.JPEGImageEncoder;
[javac] ^ [javac] /export/hudson/workspace/alex-core-jdk7/appserver-sqe/pe/tomcat/servlet/product_test
/servlet2_3/src/filters/ResponseWrapperNR.java:72: error: package com.sun.image.codec.jpeg does
not exist
[javac] import com.sun.image.codec.jpeg.JPEGImageEncoder;
[javac] ^ [javac] /export/hudson/workspace/alex-core-jdk7/appserver-sqe/pe/tomcat/servlet/product_test/servlet2_3/src/filters/FilterImage.java:144: error: cannot find symbol
[javac] JPEGImageEncoder encoder=com.sun.image.codec.jpeg.JPEGCodec.createJPEGEncoder(imageStream);
[javac] ^
[javac] symbol: class JPEGImageEncoder
[javac] location: class FilterImage
[javac] /export/hudson/workspace/alex-core-jdk7/appserver-sqe/pe/tomcat/servlet/product_test
/servlet2_3/src/filters/FilterImage.java:144: error: package com.sun.image.codec.jpeg does not e
xist
[javac] JPEGImageEncoder encoder=com.sun.image.codec.jpeg.JPEGCodec.createJPEGEncoder(imageStream);
[javac] ^ [javac] Note: Some input files use unchecked or unsafe operations.
[javac] Note: Recompile with -Xlint:unchecked for details. [javac] 6 errors

BUILD FAILED



 Comments   
Comment by Shing Wai Chan [ 02/May/11 ]

According to the error message above, the test case java file, appserver-sqe/pe/tomcat/servlet/product_test/servlet2_3/src/filters/FilterImage.java, refers to the com.sun.image.codec.jpeg.JPEGCodec.

This is a test case class, not in the server code.

Comment by Alex Pineda [ 28/Oct/11 ]

Assigning Tomcat test issue to module owner.

Comment by sb110099 [ 23/Jan/12 ]

This issue is only seen on Windows 7 with jdk7u2.
Need further investigation to modify these tests with equivalent packages in jdk7.
For now , commenting out these tests for Win7 and jdk7 runs.

Thanks,
Sudipa

Comment by sb110099 [ 28/Jan/12 ]

The bug indicating removal of this package (com.sun.image.codec.jpeg) from JDK 7 is found as:
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6527962

Have adjusted the tests with "import javax.imageio." instead of com.sun.image.codec. .

Sudipa





[GLASSFISH-18120] SQL exception when attempting to ping-connection-pool: No suitable driver Created: 05/Jan/12  Updated: 18/Jan/12

Status: Open
Project: glassfish
Component/s: test
Affects Version/s: 3.1.2_b16
Fix Version/s: None

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

AIX system running GF 3.1.2 build16 (ogs-3.1.2-b16-aix.sh). Problem is seen on AIX6.1 and AIX7.1. JDK1.6.0 SR9 P1. Issue is specific to AIX as no issue is seen on Solaris/Linux systems.


Attachments: Text File server.log    

 Description   

Test case is part SQE AdminCLI single instance test suite. The scenario is based on deploying to test apps, creating a connection pool, listing the connection pool and lastly "pinging" the connection pool. The failure occurs while trying to "ping" the connection pool. The error message in the server.log shows:

WARNING glassfish3.1.2 javax.enterprise.resource.resourceadapter.com.sun.enterprise.connectors.service _ThreadID=7;_ThreadName=Thread-7; RAR8054: Exception while creating an unpooled [test] connection for pool [ testderbypool ], SQLException: No suitable driver #]

and the command fails and returns the following error.
remote failure: Ping Connection Pool failed for testderbypool.
SQLException: No suitable driver Please check the server.log for more details.
Command ping-connection-pool failed.

This problem is only seen on AIX systems. The test case works on Linux/Unix systems. Perhaps a "driver bundling" or path issue?

To exact commands executed by the test case are
o asadmin deploy --user admin --passwordfile $TEST_HOME/pe/admincli/config/runtime/pepassword.txt --host aixas11.us.oracle.com --port 4848 $TEST_HOME/common/admincli/apps/rar/cciblackbox-tx.rar

o asadmin deploy --user admin --passwordfile $TEST_HOME/pe/admincli/config/runtime/pepassword.txt --host aixas11.us.oracle.com --port 4848 $TEST_HOME/common/admincli/apps/cci-embedded/assemble/connector-embedded-cciApp.ear

Application deployed with name connector-embedded-cciApp.
Command deploy executed successfully.

o asadmin create-connector-connection-pool --user admin --passwordfile $TEST_HOME/pe/admincli/config/runtime/pepassword.txt --host aixas11.us.oracle.com --port 4848 --steadypoolsize 8 --maxpool
size 32 --maxwait 60000 --poolresize 2 --idletimeout 300 --failconnection=true --raname connector-embedded-cciApp#cciblackbox-tx --connectiondefinition javax.resource.cci.ConnectionFactory --property ConnectionURL=jdbc\\:derby\\:\\//localhost\\:1527/sun-appserv-samples\;create\\=true\;:user=APP:password=APP testderbypool

Connector connection pool testderbypool created.

o asadmin list-connector-connection-pools --user admin --passwordfile $TEST_HOME/pe/admincli/config/runtime/pepassword.txt --host aixas11.us.oracle.com --port 4848

Command list-connector-connection-pools executed successfully.

o asadmin ping-connection-pool --user admin --passwordfile $TEST_HOME/pe/admincli/config/runtime/pepassword.txt --host aixas11.us.oracle.com --port 4848 --terse=false testderbypool

remote failure: Ping Connection Pool failed for testderbypool.
SQLException: No suitable driver Please check the server.log for more details.
Command ping-connection-pool failed.



 Comments   
Comment by Alex Pineda [ 05/Jan/12 ]

Adding server.log file to hopefully help diagnose the problem.

Comment by scatari [ 05/Jan/12 ]

Could be a packaging issue or the recent upgrade to a few components or class loader changes on AIX causing this? Assigning to Bhakti for further evaluation.

Comment by Bhakti Mehta [ 05/Jan/12 ]

Alex couple of questions.
Was this test run with earlier builds of 3.1.2 or is it the first time you noticed this?
I am just trying to isolate if there were previous builds which had this test working then we can look for changes which may have caused this error.

I have also pinged Jagadish and Jane and looking more into it.

I assume this worked with 3.1.1 right?

Regards,
Bhakti

Comment by Alex Pineda [ 05/Jan/12 ]

As mentioned, the test pass on the other platforms (Solaris, Linux). In terms of AIX, I saw the failures in build14 and build15, but I thought it was system (AIX7.1 or environment)isue as no other tests fail because of a missing driver (which is what the error implies). Build14 is the first time I ran the tests on AIX. These tests passed in GF3.1.1 with AIX 6.1. This week, I was able to reproduce the problem on both AIX 7.1 and AIX 6.1 with JDK6 and JDK7.

Comment by Bhakti Mehta [ 05/Jan/12 ]

I looked at this issue http://java.net/jira/browse/GLASSFISH-16524 and tried adding the following
<jvm-options>-Djava.ext.dirs=$

{com.sun.aas.javaRoot}/lib/ext
${path.separator}${com.sun.aas.javaRoot}

/jre/lib/ext
$

{path.separator}${com.sun.aas.installRoot}/../javadb/lib
${path.separator}

$

{com.sun.aas.instanceRoot}

/lib/ext</jvm-options>
to domain.xml and restarted and tried the ping-connection-pool but it did not work for me on the aixas11 machine. Requesting Jagadish for more input.

Comment by Bhakti Mehta [ 05/Jan/12 ]

I have made the following changes and the test now works for me

[hudson@aixas11:~/workspace/alex-admincli/glassfish3/glassfish/bin] $ !584
asadmin --user admin --passwordfile /export/hudson/workspace/alex-admincli/appserver-sqe/pe/admincli/config/runtime/pepassword.txt --host aixas11.us.oracle.com --port 4848 ping-connection-pool
Enter the value for the pool_name operand> testderbypool
Command ping-connection-pool executed successfully.

I have copied derby jars to the following location
~/workspace/alex-admincli/glassfish3/glassfish/domains/domain1/lib/ext] $ ls
derbyclient.jar ojdbc6.jar

Added the jvm options in domain.xml
<jvm-options>-Djava.ext.dirs=$

{com.sun.aas.javaRoot}/lib/ext
${path.separator}${com.sun.aas.javaRoot}

/jre/lib/ext
$

{path.separator}${com.sun.aas.installRoot}/../javadb/lib
${path.separator}

$

{com.sun.aas.instanceRoot}

/lib/ext</jvm-options>

I will ask Alex to try this and modify the tests to take care of these settings and maybe reassign to him

Comment by Alex Pineda [ 06/Jan/12 ]

The test is part of an automated suite and thus, it can not not prompt for input. Also, we need to understand why the problem is happening and not change the test. Re-assigning it back to Bhakti.

Comment by Bhakti Mehta [ 06/Jan/12 ]

FYI just to clarify you do not need to prompt for input. I had forgotten to add the pool-name to the command and hence it promoted me for the pool_name.
Your normal test command should work with these changes which I made.
I have sent a follow up email to Jagadish asking how to handle this fix for aix platform whether will this be documented or will we do something special in our installation to copy these jars and add the jvm options?

Comment by Jagadish [ 12/Jan/12 ]

I have tried both 3.1.2 and 3.1.1 GlassFish builds in AIX. The test-case fails. This is the same as issue GLASSFISH-16524
As indicated before in the issue : http://java.net/jira/browse/GLASSFISH-16524
the test-case needs to be fixed in any of the ways :

  • suffix/prefix "$ {com.sun.aas.installRoot}

    /../javadb/lib" to "-Djava.ext.dirs" jvm-option in domain.xml

  • Do Class.forName for the DerbyDriver being used.
    Any of the above two will make the DerbyDriver registered in the runtime so that DriverManager.getConnection() will work.
Comment by Bhakti Mehta [ 18/Jan/12 ]

Assigning to Alex based on email exchanges with Jagadish and Alex





[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-17007] typo in quicklook/wsit/JaxwsFromWsdl/metadata/web.xml Created: 10/Jul/11  Updated: 02/Dec/11

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

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


 Description   

From server.log:

[#|2011-07-10T09:54:28.359-0400|WARNING|glassfish3.1.1|javax.enterprise.system.tools.deployment.org.glassfish.deployment.common|_ThreadID=18;_ThreadName=Thread-2;|DPL8007: Unsupported deployment descriptors element mlns value http://java.sun.com/xml/ns/j2ee|#]

quicklook/wsit/JaxwsFromWsdl/metadata/web.xml has the wrong attr name (shoule be xmlns?):

<web-app version="2.4" mlns="http://java.sun.com/xml/ns/j2ee">
<display-name>JaxwsFromWsdl</display-name>
<description>JaxwsFromWsdl</description>



 Comments   
Comment by Justin Lee [ 01/Aug/11 ]

Not sure why this is assigned to me. I don't know anything about it.

Comment by Justin Lee [ 01/Aug/11 ]

You made the last change to this. Do you know what should happen here or know who does?

Comment by Cheng Fang [ 01/Aug/11 ]

I chose owner automatic, and happens to be you.





[GLASSFISH-13898] ear files checked in into src tree Created: 08/Oct/10  Updated: 18/May/11

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

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

Operating System: All
Platform: Macintosh


Issuezilla Id: 13,898
Tags: 3_1-exclude, 3_1-next

 Description   

admingui/devtests/src/test/resources/ejb-timer-sessiontimerApp.ear
admingui/devtests/src/test/resources/ejb-ejb30-hello-sessionApp.ear

there is also a .war file



 Comments   
Comment by Nazrul [ 11/Nov/10 ]

Changing target milestone from 3.1_ms08 to not determined

Comment by Nazrul [ 29/Nov/10 ]

Getting help from Siraj. We may consider moving the console test src code outside the main workspace (faster build time for everyone).

Comment by Jason Lee [ 07/Dec/10 ]

For what it's worth, the only effect these tests have on anyone is the time it takes to check them out initially. They are not part of the build, but must be compiled and run separately.

Comment by Anissa Lam [ 08/Dec/10 ]

Markthis as 3.1-exclude.
This won't make it to MS7.
If we have the resource and get approval after MS7, we may reconsider this.





[GLASSFISH-12179] BaseDevTest to run org.glassfish.ant.embedded.tasks.AdminTask in embedded mode Created: 08/Jun/10  Updated: 10/Dec/10

Status: Open
Project: glassfish
Component/s: test
Affects Version/s: 3.1
Fix Version/s: future release

Type: Improvement Priority: Major
Reporter: Amy Roh Assignee: Justin Lee
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: Macintosh


Issuezilla Id: 12,179

 Description   

Embedded mode uses embedded targets to run embedded ant tasks (defined in
devtests/embedded/common.xml). since BaseDevTest doesn't use ant tasks from
common.xml, the embedded commands cannot be found. BaseDevTest needs to be
modified to use org.glassfish.ant.embedded.tasks.AdminTask when running in
embedded mode.

<taskdef name="glassfish-embedded-admin"
classname="org.glassfish.ant.embedded.tasks.AdminTask"
classpath="$

{env.GF_HOME}/ant-tasks/target/ant-tasks.jar:${env.GF_HOME}

/extras/embedded/all/target/glassfish-embedded-all.jar:$

{env.S1AS_HOME}

/modules/ant.j






Generated at Sat Jul 04 10:16:46 UTC 2015 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.