[GLASSFISH-4021] Resouce Injection does not work in HandlerChain due to EJB initialization order (non-deterministic) Created: 21/Jan/08  Updated: 21/Sep/15

Status: Open
Project: glassfish
Component/s: ejb_container, web_services
Affects Version/s: V3
Fix Version/s: 4.1.1

Type: Bug Priority: Critical
Reporter: gfuser9999 Assignee: Lukas Jungmann
Resolution: Unresolved Votes: 5
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 4,021
Tags: 3_1-exclude, 4_0-release-notes, 4_0-release-notes-completed, 4_0-release-notes-drafted

 Description   

--------
Problem
--------
1. Resource injections fails when using HandlerChain that have a
EJB/Resource injected that is an EJB/JNDI. And one gets
"Handler xxxxx instance injection failed : Exception attempting to inject
Resolved Ejb-Ref xxxx/bean@jndi: - > xxxxx]

The issues is that assuming we have 2 EJB and we want to have

  • EJB B exposed as Webservice and handle a HandlerChain handler
    So we have
    @Stateless
    @WebService
    @HandlerChain(file = "handle.xml")
    public void EJBBBean { ... }
  • We do not care above EJB A
  • Note that the handler is
    public class handler implements SOAPHanlder { @EJB EJBBBean bean; .... }
  • Now when one deploy this depending on the ordering
    of initialization of EJB, sometimes
    EJBA, EJBB and this works but if sometimes it is
    EJBB, EJBA then resource injection fails
  • The issues is that the following happens where it seems when
    a EJB is exposed as WebService and have a handler,
    a) The EJB is created and the handler is created
    b) The handler will be injected but then the issue is
    that THERE is IT may be possible that at the time
    the dependency is not met (since EJBA is not loaded or initialized
    nor registered to the JNDI even)

com.sun.enterprise.InjectionException: Exception attempting to inject Resolved
Ejb-Ref org.test.ws.FailInjectionHandler/bean@jndi: - > b5Bean into class
org.test.ws.FailInjectionHandler
at
com.sun.enterprise.util.InjectionManagerImpl._inject(InjectionManagerImpl.java:391)
at
com.sun.enterprise.util.InjectionManagerImpl.inject(InjectionManagerImpl.java:206)
at
com.sun.enterprise.util.InjectionManagerImpl.injectInstance(InjectionManagerImpl.java:100)
at
com.sun.enterprise.webservice.WsUtil.processConfiguredHandlers(WsUtil.java:2529)
at
com.sun.enterprise.webservice.WsUtil.configureJAXWSServiceHandlers(WsUtil.java:2570)
at
com.sun.enterprise.webservice.EjbRuntimeEndpointInfo.prepareInvocation(EjbRuntimeEndpointInfo.java:294)
at
com.sun.enterprise.webservice.EjbRuntimeEndpointInfo.initRuntimeInfo(EjbRuntimeEndpointInfo.java:342)
at
com.sun.enterprise.webservice.WebServiceEjbEndpointRegistry.registerEjbWebServiceEndpoint(WebServiceEjbEndpointRegistry.java:122)
at
com.sun.ejb.containers.StatelessSessionContainer.initializeHome(StatelessSessionContainer.java:329)
at
com.sun.ejb.containers.ContainerFactoryImpl.createContainer(ContainerFactoryImpl.java:345)
at
com.sun.enterprise.server.AbstractLoader.loadEjbs(AbstractLoader.java:550)
at
com.sun.enterprise.server.ApplicationLoader.doLoad(ApplicationLoader.java:188)

  • Now, this problem does not seems to be that the system does not resolve ordering
    Since writing more EJB seems to say that the GF system tends to order the EJB
    module
    However, there seems to be some race or data structure ordering issue since
    that the EJB module loading sequence on every stop/start is different and
    it is possible to get a EJB processing order that does not work.

--------------------
Testcase and details
--------------------
1. Get the attached NB6 ejbdeptest.zip and deploy
This testcase have many a few EJB modules to make this easier to hit this
Deploy ejbdeptest.ear

2. Stop/Start (asadmin stop-domain/start-domain)
and look for the injection failure. (REPEAT until failure is SEEN)
(grep SEVERE)

3. [Unpredictable and repeat (2) until SEVERE happens like below]

[#......|SEVERE|sun-appserver9.1|javax.enterprise.system.container.ejb|_ThreadID=20;_ThreadName=httpSSLWorkerThread-14849-2;_RequestID=3a6b0964-02e0-419f-acc0-49c651e2916b;|Handler
org.test.ws.FailInjectionHandler instance injection failed : Exception
attempting to inject Resolved Ejb-Ref
org.test.ws.FailInjectionHandler/bean@jndi: - > b5Bean into class
org.test.ws.FailInjectionHandler|#]

3. Note some tracing does indicate that Bean processing via getEjbDescriptors()
varies sometimes and below is a failure sequence. (It is unknown
why the behaviour on the EJB processed changes sometimes)

[#.....|INFO|sun-appserver9.1|javax.enterprise.system.co
re.classloading|_ThreadID=10;_ThreadName=main;|[DEBUG] AbstractLoader org.test.s
lsb.e0Bean org.test.slsb.b6Bean org.test.slsb.b3Bean org.test.slsb.b2Bean or
g.test.slsb.b4Bean org.test.slsb.b1Bean org.test.slsb.b5Bean org.test.slsb.b0
Bean org.test.slsb.e1Bean org.test.slsb.zfailBean org.test.slsb.z0Bean org.t
est.slsb.z1Bean org.test.slsb.e2Bean |#]



 Comments   
Comment by Hong Zhang [ 22/Jan/08 ]

Assign to Mahesh for initial investigation. Also addding Bhakti to the Cc.

Attaching CWeng's suggested solutions below:
=============================================
And so i suppose plain common-sense must be used (which would then indicate the
system should be able to tell that a Handler class is used by WebserviceX and
the Handler class need Y, so Y must be initialized by X.

Even if there is no LOAD order, one may presume that creation of ALL EJB should
be done first and then on 2nd part the creation of all Webservices that those
EJB expose is done.
At this point the EJB and Webservice step for a EJB is coupled together....

Comment by Mahesh Kannan [ 14/Feb/08 ]

The problem is that the handlers are created probably way too early.

The Container calls
WebServiceEjbEndpointRegistry.registerEjbWebServiceEndpoint() during container
initialization time which causes the handlers to be instantiated (which inturn
causes injection). We need to delay the instantiation of the handlers till the
dependent EJBs are processed.

One way to do that is to provide two methods:
1. One to register the the EjbService endpoint which WILL NOT call
WsUtil.processConfiguredHandlers()

2. The other method (say createConfiguredHandlers()) can create and call
InjectionManager.injectInstance(handler)

Once the above methods are in place the StatelessContainer can call the second
method from doAfterApplicationDeployed().

I am assigning this to Bhakti to implement the above two methods.

Comment by Bhakti Mehta [ 15/Feb/08 ]

Looking into it

Comment by harpreet [ 09/Apr/08 ]

Based on input from Bhakti, assigning issue to next release

Comment by sanandal [ 11/Jan/09 ]

"Reclassifying as P4 because this issue is not deemed "must fix" for this v2.1
release whose primary release driver is SailFin.
This issue will be scrubbed after this release and will be given the right
priority for the next release."

Comment by ramapulavarthi [ 01/Dec/10 ]

I have n't run any tests but seeing the code in v3.1, we should run into the same problem.
Can't forward port the patches CR6653050 and CR6750245 as the code in v3 is little different from v2.1.
The fix needs to go into EJB container code to change the way we intialize and load the ejb web services.

Comment by Bhakti Mehta [ 08/Dec/10 ]

Reassigning to Rama since he has already looked into this issue . My inclination is to exclude this for this release but will wait for Rama's input

Comment by ramapulavarthi [ 21/Dec/10 ]

This requires changes in EJB Container to change the way EJB ws are loaded and needs coordination with EJB team. Adding V3.1 excludes as this is risky to make this change now.

Comment by Nazrul [ 23/Dec/10 ]

This bug has been around for few releases now. Based on inputs from Bill, I am setting target for 3.2 release with P2 priority so that it gets fixed. If we do not want to fix this bug, please close it.

Comment by 8086 [ 25/Mar/12 ]

We have been waiting for a fix for three years now. As of now, our application needs to be redeployed until it works. This might take anywhere from 1 redeploy to 15 redeploys to get it working.

If you are not fixing it, is there a way to work around it in our code that can remove the pain of innumerous redeploys?

Comment by kumara [ 26/Mar/12 ]

-> Martin Grebac for evaluation.

Comment by Gail Risdal [ 31/May/13 ]

Added the following to the release notes:

Resource Injection does not work in HandlerChain due to EJB initialization order (non-deterministic) (4021)

Description
EJB module deployment may fail when an EJB that is exposed as a web service, and which has a handler, is initialized before an EJB on which it has dependencies. This is caused by the way the EJB container initializes and loads EJB web services.

Workaround
EJB initialization usually happens in alphabetical order. Rename the EJBs so that the EJB exposed as a web service is initialized after the EJB on which it has dependencies.

In the following example, B is initialized first together with handler X, which expects C to be available but it is not, and deployment fails. The workaround is to rename B to D (for example), so lexicographically it follows C, in which case C should be initialized first and be available for injection to X.

EJB module sth:

@Stateless public class C

{...}
@Stateless @WebService @HandlerChain(file = "handlers.xml") public class B {...}

handlers.xml:

<?xml version="1.0" encoding="UTF-8"?>
<jws:handler-chains ...>
<jws:handler-chain>
<jws:handler>
<jws:handler-class>X</jws:handler-class>
</jws:handler>
</jws:handler-chain>
</jws:handler-chains>

Handler:

</jws:handler-chains>
@EJB private C;
...}

Comment by Gail Risdal [ 05/Jun/13 ]

Fixed the example in the release notes (first line in the "Handler" section; release notes document has proper formatting/indentation):

EJB module sth:

@Stateless public class C

{...}
@Stateless @WebService @HandlerChain(file = "handlers.xml") public class B {...}

handlers.xml:

<?xml version="1.0" encoding="UTF-8"?>
<jws:handler-chains ...>
<jws:handler-chain>
<jws:handler>
<jws:handler-class>X</jws:handler-class>
</jws:handler>
</jws:handler-chain>
</jws:handler-chains>

Handler:

public class X implements SOAPHandler<SOAPMessageContext>

{ @EJB private C; ...}




[GLASSFISH-18406] @EJB injection fails but JNDI lookup works in web service class in Glassfish Created: 24/Feb/12  Updated: 21/Sep/15

Status: Open
Project: glassfish
Component/s: web_services
Affects Version/s: 3.1.2_b23
Fix Version/s: 4.1.1

Type: Improvement Priority: Major
Reporter: dwschulze Assignee: Lukas Jungmann
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Glassfish 3.1.2 beta built 2012-02-14, Windows 7 pro 64-bit, JDK 1.6


Attachments: Zip Archive reports.2012.02.24.zip    
Issue Links:
Related
is related to GLASSFISH-2105 EJB Web Service resource injection oc... Resolved
is related to GLASSFISH-2190 Resource injection fails. Resolved
Tags: metro2_2_1-waived

 Description   

I have a @WebService class that injects an @EJB. The EJB is packaged in a .jar file which is in the same .war file as the web service classes. The @EJB injection always fails, but I can do a JNDI lookup on the EJB. I've tried making the EJB and its interface @Remote, but that didn't matter. Injection still fails and JNDI lookup still works.

I'm using a version 3.0 web.xml. There's no ejb deployment descriptor in the ejb.jar file, but that is not suppose to matter in EJB 3.1.

EJB class and interface packaged in a .jar in the .war file:

//@Remote
public interface ReportServiceI {

public String testAlive();
}

@Stateless
//@Remote (ReportServiceI.class)
public class ReportService implements ReportServiceI

{...}

Web Service class:

@WebService(
targetNamespace = "http://www.reps.corp.com/services/reports/ReportService",
portName="ReportPort",
serviceName="ReportService",
endpointInterface="com.corp.reps.reports.ws.server.ReportServiceWSI")

public class ReportServiceWS implements ReportServiceWSI {

public static Logger logger = Logger.getLogger(ReportServiceWS.class);

// These all fail
// @EJB
// @EJB(beanInterface=ReportServiceI.class)
// @EJB(lookup="java:global/repsreports/ReportService")
ReportServiceI reportService;

public String testAlive() {

// this works
try

{ InitialContext context = new InitialContext(); reportService = (ReportServiceI)context.lookup("java:global/repsreports/ReportService"); }

catch (NamingException ex)

{ logger.error(ex); return "InitialContext.lookup() failed."; }

...

}



 Comments   
Comment by Cheng Fang [ 24/Feb/12 ]

If you make ReportServiceWS into EJB by adding @Stateless, does the injection work?

Comment by dwschulze [ 24/Feb/12 ]

Putting @Stateless on ReportServiceWS doesn't make any difference. All 3 forms of @EJB injection fail and the JNDI lookup succeeds.

I also want to avoid making ReportServiceWS a SessionBean for security reasons. The @WebService will be the only publicly visible interface into the system and I'm going to put WS-Security on those.

Comment by Cheng Fang [ 24/Feb/12 ]

Thanks for trying it. Can you attach a test app?

Comment by dwschulze [ 24/Feb/12 ]

I'll have to rename things (scrub proprietary names etc.).

Comment by dwschulze [ 24/Feb/12 ]

With Glassfish 3.1 or 3.1.2 running type mvn install in the top level reports project.

There is a Swing client in the reports.gui project. The main class is ReportsGUI. Run this GUI. Click on the second tab "Message Success Rate". Press the "Test Connectivity" button to verify that @EJB injection works.

The server side code is currently doing JNDI lookup which works. Comment out the init() method and uncomment one of the @EJB annotations to observe failure.

Comment by Cheng Fang [ 25/Feb/12 ]

I was able to reproduce the issue.

Note: need to use mvn 3.x to run the sample (mvn 2.2.1 failed). I also added some debug statement in @PostConstruct and @EJB setter method that can be displayed in server.log right after 'mvn install', without having to run the gui.

From my testing, @EJB injection into WebService class is not happening. That may explain why there is no injection-related errors or warnings.

Could be related to the two very old issues GLASSFISH-2190 and GLASSFISH-2105.

Comment by Cheng Fang [ 25/Feb/12 ]

assign to web services team to evaluate potential regression.

Comment by Bhakti Mehta [ 27/Feb/12 ]

Assigning to Lukas from the webservices team

Comment by Lukas Jungmann [ 28/Jun/12 ]

EJB injection in non-jsr109 deployment, which your app is using (it includes sun-jaxws.xml), is undefined, AFAIK => switching to enhancement

to "get around" this or better - implement your ws correctly - remove "proprietary" sun-jaxws.xml from your webapp as well as all relevant elements from web.xml (listener-class, servlet-class etc), they're not needed if you're deploying your app on glassfish





[GLASSFISH-18244] Web Service calls are not logged on server access log Created: 24/Jan/12  Updated: 08/Feb/13

Status: Open
Project: glassfish
Component/s: web_services
Affects Version/s: 3.1.1
Fix Version/s: future release

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

Issue Links:
Dependency
depends on GLASSFISH-19582 Move AccessLog support on Grizzly lev... Open
Tags: 3_1_2-exclude, metro2_3-exclude

 Description   

If you enable access logging on the HTTP Service, the generated access log only contains data for HTTP calls that are not Web Services calls.
For instance, if you deploy a JAX-WS enabled EJB and a Web application on the same server, the web application accesses will show up on the access log, but the EJB WS accesses will not.



 Comments   
Comment by Joe Di Pol [ 24/Jan/12 ]

Too late to fix in 3.1.2. Excluding.

Comment by Lukas Jungmann [ 24/Jan/13 ]

EJB endpoint is being registered using o.g.api.container.RequestDispatcher.registerEndpoint API. I'd expect that all services bound to underlied host/networklistener (ie accesslogging) become available to context being registered. Or is there some API I can use to send messages to PEAccessLogValve?

Thanks.

note that similar issue is there also for appclients (and logging access to generated JWS app URLs)

Comment by oleksiys [ 24/Jan/13 ]

related to http://java.net/jira/browse/GLASSFISH-19582





[GLASSFISH-20661] web service endpoint is not available for the deployed EJB application Created: 25/Jun/13  Updated: 22/Jul/15

Status: Open
Project: glassfish
Component/s: web_services
Affects Version/s: 4.0_b89_RC5
Fix Version/s: None

Type: Bug Priority: Major
Reporter: xianwu Assignee: Lukas Jungmann
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

OS
Windows 7 Enterprise (Service Pack 1)

JDK
java version "1.7.0_11"
Java(TM) SE Runtime Environment (build 1.7.0_11-b21)
Java HotSpot(TM) 64-Bit Server VM (build 23.6-b04, mixed mode)



 Description   

Reproducible operational steps:
asadmin deploy ws_ejb_ng.jar
Application deployed with name ws_ejb_ng.
Command deploy executed successfully.

Detailed description of the issue:
The deployed EJB application program has the settings below.

1) The WebService annotation and the EJB annotation are included at the same time.
@WebService annotation:
@javax.ws.WebService
@EJB annotation:
@javax.ejb.Stateless
2) The value of < ejb-name > in ejb-jar.xml is different from the value of @Stateless.

The deploy command is successful and no error messages are shown in server.log.
However the web service endpoint is not available.

The testing was under GlassFish v4 b89

If the value of < ejb-name > in ejb-jar.xml matches with the value of @Stateless (see ws_ejb_ok.jar),
then, the web service endpoint is available.

I will include sample applications and loggings late



 Comments   
Comment by xianwu [ 25/Jun/13 ]

Hi Chris

I have uploaded the sample applications and logging files at
https://github.com/xianwum/GLASSFISH-20661

List of Files
ws_ejb_ng.jar (EJB Application whose web service endpoint is not available)
ws_ejb_ng.log (server.log when the ws_ejb_ng.jar is deployed)
ws_ejb_ok.jar (EJB Application whose web service endpoint is available)
ws_ejb_ok.log (server.log when the ws_ejb_ok.jar is deployed)

The only difference between ws_ejb_ng.jar and ws_ejb_ok.jar is <ejb-name> in META-INF\ejb-jar.xml.

In ws_ejb_ok.jar#META-INF\ejb-jar.xml, we have "<ejb-name>HelloEJBa</ejb-name>"
but in ws_ejb_ng.jar#META-INF\ejb-jar.xml, we have "<ejb-name>HelloEJBb</ejb-name>"

In HelloEJB.java, we have

@WebService(endpointInterface="endpoint.Hello")
@Stateless(name = "HelloEJBa")
public class HelloEJB implements Hello {

public String sayHello(String who)

{ return "WebSvcTest-Hello " + who; }

}

Regards, Xianwu

Comment by marina vatkina [ 25/Jun/13 ]

Let's start with web-services

Comment by gregn123 [ 22/Jul/15 ]

This problem still exists in Glassfish 4.1.

I have fully explained the bug and it's cause, provided sample apps that illustrate and reproduce the bug, and provided a proposed patch for Glassfish 4.1 (source patch + corresponding binary) here:

https://github.com/gregn123/GLASSFISH-20661

Please see the README.txt file in the above GitHub repository for more details.





GlassFish services and components to conform with configuration modularity (GLASSFISH-19408)

[GLASSFISH-19414] Web Services related configuration in domain.xml to conform with configuration modularity Created: 06/Dec/12  Updated: 21/Sep/15

Status: Open
Project: glassfish
Component/s: web_services
Affects Version/s: None
Fix Version/s: 4.1.1

Type: Sub-task Priority: Major
Reporter: Masoud Kalali Assignee: Lukas Jungmann
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Different modules/services requires to conform with configuration modularity. This is a parent task for all the issue being filed for this project. More details at the internal wiki page: http://aseng-wiki.us.oracle.com/asengwiki/display/GlassFish/Config+Modularity+One+Pager This ticket is to track this change for web services container/configuration.






[GLASSFISH-11151] servlet-name needs to be FQCN Created: 23/Nov/09  Updated: 06/Mar/12

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

Type: Bug Priority: Minor
Reporter: Bhakti Mehta Assignee: Lukas Jungmann
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: 11,151
Status Whiteboard:

v3_exclude


 Description   

This is to keep track of this issue for 3.1
In WebserviceHandler since currently we are using
webComponent.setName(endpoint.getEndpointName()); this is generating the web.xml
without the FCQN.
As Rama mentioned
"This is making the existing TCK tests which use wrong servlet-name work.
I think the bug should be fixed as
webComponent.setName(endpoint.getEndpointName()); --->
webComponent.setCanonicalName(implClassFullName)"

However we are not going to make that change right now.



 Comments   
Comment by Bhakti Mehta [ 23/Nov/09 ]

Since this is a fix which is going to be targetted for v3.1 and it is risky to
make it right now we are marking as v3_exclude. Filing this bug for tracking purpose

Comment by Bhakti Mehta [ 23/Nov/09 ]

fixed a typo

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.

Comment by Bhakti Mehta [ 06/Mar/12 ]

Lukas, I have lost the context to the bug which made me file this issue and am not sure if this is valid anymore, feel free to close it otherwise.





[GLASSFISH-9949] Fix warning of container implementing Module Created: 02/Oct/09  Updated: 06/Mar/12

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

Type: Bug Priority: Minor
Reporter: Bhakti Mehta Assignee: Lukas Jungmann
Resolution: Unresolved Votes: 7
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: Macintosh


Issue Links:
Duplicate
is duplicated by GLASSFISH-4479 doesn't support class com.sun.xml.ws.... Resolved
Issuezilla Id: 9,949

 Description   

https://jax-ws.dev.java.net/issues/show_bug.cgi?id=802



 Comments   
Comment by Bhakti Mehta [ 20/Oct/09 ]

In v3 when ejb and webservices are deployed WSEndpoint is created at that point
and also JAXWSContainer.
However we do not have the ServletContext at that point and hence the
JAXWSServletModule which extends ServletModule is null.
See JAXWSContainer code in v3 workspace.
This is same as v2 and will fix it once the higher priority ones are done

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-13175] Service level WebServiceFeature annotations configured on a WebService reference are not passed to the JAX-WS Runtime Created: 27/Aug/10  Updated: 18/Jan/12

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

Type: Bug Priority: Minor
Reporter: ramapulavarthi Assignee: Lukas Jungmann
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,175

 Description   

JAX-WS allows web services features to be configured on WebService reference
when the target is a service. Service level WebServiceFeatures configured on
WebServiceReference are not passed to the JAX-WS Runtime.

ex:
@FooFeature
@WebServiceRef
HelloService hello;

There are no service level features that are in use now. So the priority is low.






[GLASSFISH-6445] Need to provide better information when user deploys webservices to v3 without installing metro from UC Created: 06/Oct/08  Updated: 06/Mar/12

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

Type: Bug Priority: Minor
Reporter: Bhakti Mehta Assignee: Lukas Jungmann
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Attachments: Text File diffs.txt    
Issuezilla Id: 6,445
Status Whiteboard:

gfv3-prelude-excluded


 Description   

Currently if a user deploys to v3 without installing metro from UC he will get a
ClassNotFoundException [1]

I would like to provide better error message to the user asking him to install
metro by running UC client

Filing this bug to keep track of this issue and so I can commit the fix

[1]java.lang.ClassNotFoundException: com.sun.xml.ws.transport.http.servlet.WSServle
tContextListener
at org.glassfish.web.loader.WebappClassLoader.loadClass(WebappClassLoade
r.java:1509)
at org.apache.catalina.core.StandardContext.listenerStart(StandardContex
t.java:4574)
at org.apache.catalina.core.StandardContext.start(StandardContext.java:5
311)

Here is the patch which would fix this problem

Index: src/main/java/org/apache/catalina/core/StandardContext.java
===================================================================
— src/main/java/org/apache/catalina/core/StandardContext.java (revision 23226)

+++ src/main/java/org/apache/catalina/core/StandardContext.java (working copy)
@@ -4578,9 +4578,16 @@
results[i]);
// END PWC 1.2 6310695
} catch (Throwable t) {

  • getServletContext().log
  • (sm.getString("standardContext.applicationListener",
  • listeners[i]), t);
    +
    + if (listeners[i].equals("com.sun.xml.ws.transport.http.servlet.
    WSServletContextListener")) { + getServletContext().log(sm.getString("standardContext.missin gmetro"),t) ; + + }

    else

    { + getServletContext().log + (sm.getString("standardContext.applicationListener", + listeners[i]), t); + }

    +
    ok = false;
    }
    }
    Index: src/main/resources/org/apache/catalina/core/LocalStrings.properties
    ===================================================================

      • src/main/resources/org/apache/catalina/core/LocalStrings.properties (revisio
        n 23226)
        +++ src/main/resources/org/apache/catalina/core/LocalStrings.properties (working
        copy)
        @@ -259,3 +259,5 @@
        standardContext.alternateDocBase.missingPathOrUrlPattern=PWC1417: Missing alter
        nate docbase URL pattern or directory location
        standardContext.startManager.error=PWC1418: Error manager.start()
        standardContext.duplicateListener=PWC1419: The listener " {0}

        " is already config
        ured for this context. The duplicate definition has been ignored.
        +standardContext.missingmetro=PWC1420: This is a webservice based application a
        nd for this Metro needs to be installed...\n Pls run updatecenter client located
        in bin folder to install metro
        +



 Comments   
Comment by Bhakti Mehta [ 06/Oct/08 ]

Updated the title to mention that the CNFE occurs when we try to deploy
webservices based app without installing metro

Comment by jluehe [ 06/Oct/08 ]

Created an attachment (id=1936)
luehe diffs

Comment by jluehe [ 06/Oct/08 ]

Hi Bhakti, your diffs would work, but my preference would be to refactor the
code in web-core's StandardContext.java that is responsible for loading and
instantiating listeners, so we can override it in web-glue's WebModule.java
(which is a subclass of StandardContext.java) and log the warning there.

I was thinking of something along the lines of the attached diffs ("luehe diffs").

Let me know if that would work for you.

Comment by jluehe [ 06/Oct/08 ]

Sending
web/war-util/src/main/resources/com/sun/logging/enterprise/system/container/web/LogStrings.properties
Sending
web/web-core/src/main/java/org/apache/catalina/core/StandardContext.java
Sending web/web-glue/src/main/java/com/sun/enterprise/web/WebModule.java
Transmitting file data ...
Committed revision 23238.

Comment by jluehe [ 07/Oct/08 ]

Ported fix to v3_prelude_release branch:

Sending
web/war-util/src/main/resources/com/sun/logging/enterprise/system/container/web/LogStrings.properties
Sending
web/web-core/src/main/java/org/apache/catalina/core/StandardContext.java
Sending web/web-glue/src/main/java/com/sun/enterprise/web/WebModule.java
Transmitting file data ...
Committed revision 23246.

At this morning's v3 engineering meeting, it was agreed that this fix should be
considered temporary only.
Post prelude, a "webservices sniffer" would be responsible for intercepting the
deployment of an application exposing webservices (based on the presence of a
webservices.xml deployment descriptor) and abort the deployment if Metro was not
installed.

Reopening this issue and reassigning it to Bhakti.

Comment by jluehe [ 07/Oct/08 ]

...

Comment by Bhakti Mehta [ 08/Oct/08 ]

Accepting bug and making note this is exclude for v3 prelude

Comment by kumara [ 24/Oct/08 ]

Reclassifying as P4 because these issues are not must fix for prelude release.
This issue will be scrubbed after prelude release and will be given the right
priority for v3 final release.

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-5289] Tester page enabled for services secured with new namespaces Created: 10/Jul/08  Updated: 10/Feb/13

Status: Open
Project: glassfish
Component/s: web_services, web_services_mgmt
Affects Version/s: 9.1peur2
Fix Version/s: not determined

Type: Bug Priority: Minor
Reporter: Marek Potociar Assignee: Lukas Jungmann
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: 5,289

 Description   

This issue is opened as a replacement for wsit issue #922 (
https://wsit.dev.java.net/issues/show_bug.cgi?id=922 ):

If you secure your service with new metro13 namespaces, the Tester page is
enabled for it. It shall be disallowed, same as with metro10 namespaces.



 Comments   
Comment by sanandal [ 11/Jan/09 ]

"Reclassifying as P4 because this issue is not deemed "must fix" for this v2.1
release whose primary release driver is SailFin.
This issue will be scrubbed after this release and will be given the right
priority for the next release."

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-4158] DEA: MARSHAL exception when trying to return List via webservice Created: 12/Feb/08  Updated: 09/Dec/11

Status: Open
Project: glassfish
Component/s: web_services
Affects Version/s: 9.1pe
Fix Version/s: None

Type: Bug Priority: Minor
Reporter: vamsee_krishna Assignee: Lukas Jungmann
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Attachments: Java Archive File EnterpriseApplicationTest-ejb.jar     Zip Archive EnterpriseApplicationTest.zip     Zip Archive screenshots.zip     Text File server.log    
Issuezilla Id: 4,158

 Description   

The issue occurs while deploying EJB and WAR file separately. It seems there is
a issue while returning a LIST in a webservice when remote interface is used.( I
am aware that when deployed EJB and WAR separately, the communication is going
to happen through remote interfaces).

Here is the code where the exception was occurring
/*CustomerFacade.java

public void removeAll(List<Customer> customers)
{
for (Customer customer : customers)

{ em.remove(em.merge(customer)); }

}

I have attached the project,server.log file along with some screen shots.



 Comments   
Comment by vamsee_krishna [ 12/Feb/08 ]

Created an attachment (id=1333)
Project demonstrating the issue

Comment by vamsee_krishna [ 12/Feb/08 ]

Created an attachment (id=1334)
server log file

Comment by vamsee_krishna [ 12/Feb/08 ]

Created an attachment (id=1335)
screenshots showing the DB structure,Deployment Scenario

Comment by vamsee_krishna [ 12/Feb/08 ]

Environment:-
JavaEE,MySQL,Hibenate,Facelets-1.1.12
-----------------------------------------------------
More information:-

When an single object is been sent, it works properly. Issue exists only when a
LIST of objects been sent.

Please refer create and removeAll Methods under CustomersFacade.java for better
understanding.

Comment by Bhakti Mehta [ 12/Feb/08 ]

Looking into it

Comment by Bhakti Mehta [ 12/Feb/08 ]

Assigning to Mahesh for evaluation.

Comment by Mahesh Kannan [ 14/Feb/08 ]

Can the submitter of this bug post the .war and .jar files?

Comment by vamsee_krishna [ 14/Feb/08 ]

Created an attachment (id=1337)
jar file of the application

Comment by vamsee_krishna [ 14/Feb/08 ]

war file can not be uploaded as size is 22.3MB.

Mahesh,
Any other areas you prefer to upload the file.

Comment by vamsee_krishna [ 15/Feb/08 ]

Mahesh,

I have uploaded the war file. Please find the link below
http://www.4shared.com/file/37889021/fec86f2a/EnterpriseApplicationTest-war.html

Comment by harpreet [ 21/Mar/08 ]

marking for 9.2

Comment by sanandal [ 11/Jan/09 ]

"Reclassifying as P4 because this issue is not deemed "must fix" for this v2.1
release whose primary release driver is SailFin.
This issue will be scrubbed after this release and will be given the right
priority for the next release."





[GLASSFISH-1244] <BT6438701>Tester page doesn't work with Sun WebServer 6.1 Loadbalancer Created: 03/Oct/06  Updated: 06/Mar/12

Status: Open
Project: glassfish
Component/s: web_services
Affects Version/s: 9.0pe
Fix Version/s: not determined

Type: Bug Priority: Minor
Reporter: gfbugbridge Assignee: Lukas Jungmann
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: Solaris
Platform: All


Issuezilla Id: 1,244

 Description   

*********READ-ONLY Data from Bugtraq*********************
Description Unable to access to Testser page if it's configured through a loadbalancer. Server busy page appears when access to the Tester pageSTEPS TO REPRODUCE:1. Install AppServers 9PE http://easqelx16.red.iplanet.com:4848 & http://easqelx16.red.iplanet.com:80802. Install WebServer 6.1 Loadblancer http://davis.red.iplanet.com:60603. Configure loadblancer for AppServer 9PE4. Deploy the attached application TestWebJAX-WS205. Launch a browser and access to the application from Loadbalancer http://davis.red.iplanet.com:6060/TestWebJAX-WS20 and http://davis:6060/TestWebJAX-WS20/NewServiceService?wsdlNote: Both url were accessed successfully. Application works with the Loadbalancer6. Access Tester url http://davis:6060/TestWebJAX-WS20/NewServiceService?TesterBUG: Busy Server message appears on the access page Tester page does not work with Sun Webserver Loadbalancer
**********READ-ONLY Data from Bugtraq Ends********
*********READ-ONLY Data from Bugtraq*********************
Justification Priority changed from [] to XXXXXX 2006-06-14 18:38:17 GMT
**********READ-ONLY Data from Bugtraq Ends********
*********READ-ONLY Data from Bugtraq*********************
http://swsblweb1.central.sun.com:8080/CrPrint?id=6438701
**********READ-ONLY Data from Bugtraq Ends********



 Comments   
Comment by gfbugbridge [ 02/Nov/06 ]

*********READ-ONLY Data from Bugtraq*********************
Description Unable to access to Testser page if it's configured through a loadbalancer. Server busy page appears when access to the Tester page
STEPS TO REPRODUCE:
1. Install AppServers 9PE
http://easqelx16.red.iplanet.com:4848 & http://easqelx16.red.iplanet.com:8080
2. Install WebServer 6.1 Loadblancer
http://davis.red.iplanet.com:6060
3. Configure loadblancer for AppServer 9PE
4. Deploy the attached application TestWebJAX-WS20
5. Launch a browser and access to the application from Loadbalancer
http://davis.red.iplanet.com:6060/TestWebJAX-WS20 and
http://davis:6060/TestWebJAX-WS20/NewServiceService?wsdl
Note:
Both url were accessed successfully.
Application works with the Loadbalancer
6. Access Tester url http://davis:6060/TestWebJAX-WS20/NewServiceService?Tester
BUG:
Busy Server message appears on the access page
Tester page does not work with Sun Webserver Loadbalancer

**********READ-ONLY Data from Bugtraq Ends********
*********READ-ONLY Data from Bugtraq*********************
Justification Priority changed from [] to XXXXXX 2006-06-14 18:38:17 GMT

**********READ-ONLY Data from Bugtraq Ends********
*********READ-ONLY Data from Bugtraq*********************
Inside SWAN :http://swsblweb1.central.sun.com:8080/CrPrint?id=6438701
Outside SWAN :http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6438701
**********READ-ONLY Data from Bugtraq Ends********

Comment by vijaysr [ 21/Feb/07 ]

reassigning

Comment by vijaysr [ 21/Feb/07 ]

reassigning

Comment by mikeg [ 25/Feb/07 ]

It looks like the logic used by the tester page assumes that the
WebServiceTesterServlet instance sending the test request and the endpoint
servicing the request are in the same VM. This won't generally be the case if
the test request is sent through the LoadBalancer. The usage of the
LoadBalancer here is an edge case considering the fact that the service can
still be tested by sending the test request directly to the AS hosting the
endpoint. Reducing the priority.

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-2451] JAX-RPC Message handler broken Created: 19/Feb/07  Updated: 07/Mar/13

Status: Open
Project: glassfish
Component/s: web_services
Affects Version/s: 9.0peur1
Fix Version/s: not determined

Type: Bug Priority: Minor
Reporter: sauvage Assignee: Lukas Jungmann
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Attachments: Zip Archive TestWebService.zip    
Issue Links:
Dependency
depends on JAX_RPC-32 JAX-RPC Message handler broken Open
Issuezilla Id: 2,451

 Description   

Hi,

When I set a JAX-RPC message handler to a web service and call it without Sun's
SOAP API I get the following stack trace:
java.lang.ClassCastException: com.sun.xml.messaging.saaj.soap.impl.TextImpl
at
com.sun.xml.rpc.server.StreamingHandler.getOpcodeForRequestMessage(StreamingHandler.java:628)
at com.sun.enterprise.webservice.WsUtil.getInvMethod(WsUtil.java:943)
at
com.sun.enterprise.webservice.ServletPreHandler.handleRequest(ServletPreHandler.java:55)
at com.sun.xml.rpc.client.HandlerChainImpl.handleRequest(HandlerChainImpl.java:86)
at
com.sun.xml.rpc.server.StreamingHandler.callRequestHandlers(StreamingHandler.java:918)
at
com.sun.xml.rpc.server.StreamingHandler.preHandlingHook(StreamingHandler.java:831)
at com.sun.xml.rpc.server.StreamingHandler.handle(StreamingHandler.java:102)
at
com.sun.xml.rpc.server.http.JAXRPCServletDelegate.doPost(JAXRPCServletDelegate.java:443)
at com.sun.enterprise.webservice.JAXRPCServlet.doPost(JAXRPCServlet.java:50)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:767)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:860)
at sun.reflect.GeneratedMethodAccessor71.invoke(Unknown Source)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at org.apache.catalina.security.SecurityUtil$1.run(SecurityUtil.java:249)
at java.security.AccessController.doPrivileged(Native Method)
at javax.security.auth.Subject.doAsPrivileged(Subject.java:517)
at org.apache.catalina.security.SecurityUtil.execute(SecurityUtil.java:282)
at org.apache.catalina.security.SecurityUtil.doAsPrivilege(SecurityUtil.java:165)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:257)
at
org.apache.catalina.core.ApplicationFilterChain.access$000(ApplicationFilterChain.java:55)
at
org.apache.catalina.core.ApplicationFilterChain$1.run(ApplicationFilterChain.java:161)
at java.security.AccessController.doPrivileged(Native Method)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:157)
at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:263)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:551)
at
org.apache.catalina.core.StandardContextValve.invokeInternal(StandardContextValve.java:225)
at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:173)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:551)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:161)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:551)
at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:132)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:551)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:933)
at org.apache.coyote.tomcat5.CoyoteAdapter.service(CoyoteAdapter.java:185)
at
com.sun.enterprise.web.connector.grizzly.ProcessorTask.process(ProcessorTask.java:653)
at
com.sun.enterprise.web.connector.grizzly.ProcessorTask.process(ProcessorTask.java:534)
at
com.sun.enterprise.web.connector.grizzly.ProcessorTask.doTask(ProcessorTask.java:403)
at com.sun.enterprise.web.connector.grizzly.WorkerThread.run(WorkerThread.java:55)

This happens because com.sun.xml.rpc.server.StreamingHandler wrongly assumes the
first child of SOAP Body is an element but it is text in this case.

Regards,

Laurent.



 Comments   
Comment by vijaysr [ 21/Feb/07 ]

Is it possible to give us a test case ?

Comment by sauvage [ 22/Feb/07 ]

Created an attachment (id=756)
test case

Comment by sauvage [ 22/Feb/07 ]

Use TestWebService/test/Hello-soapui-project.xml SOAPUI project to reproduce the
error.

Comment by sauvage [ 22/Feb/07 ]

This bug is duplicate of JAX-RPC GLASSFISH-32 providing a patch.

Comment by vijaysr [ 27/Feb/07 ]

reassign

Comment by mikeg [ 19/Mar/07 ]
      • Issue 2422 has been marked as a duplicate of this issue. ***
Comment by mikeg [ 19/Mar/07 ]

Bug occurs in JAX-RPC codebase only. Need to fix there and re-integrate
JAX-RPC. The bug is caused by a Text node in the SOAPBody of a request message
to a JAX-RPC endpoint that uses handlers. All three conditions are necessary to
reproduce the bug. The Text node here is written by toolkit other than JAX-WS
RI. (soapui. Lowering the priority. Reassigning to JAX-WS Runtime team.

Comment by vivekp [ 28/Oct/09 ]

Assigning to the right owner.

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-21468] NPE in EclipseLink ServerPlatformUtils on first DB access Created: 23/Nov/15  Updated: 25/Nov/15

Status: Open
Project: glassfish
Component/s: entity-persistence
Affects Version/s: 4.1.1
Fix Version/s: None

Type: Bug Priority: Minor
Reporter: anoopgupta Assignee: Lukas Jungmann
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Oracle Linux 6u4 x86_64, Intel Xeon processor



 Description   

With GF 4.1.1 build 1 (by default using EclipseLink 2.6.1.v20150605-31e8258), a Java EE application using persistence.xml connects to the DB fine, yet on first DB access prints an NPE in the server.log with the following trace:

java.lang.NullPointerException
at org.eclipse.persistence.platform.server.ServerPlatformUtils.createServerPlatform(ServerPlatformUtils.java:99)
at org.eclipse.persistence.sessions.factories.SessionManager.init(SessionManager.java:77)
at org.eclipse.persistence.sessions.factories.SessionManager.<clinit>(SessionManager.java:71)
at org.eclipse.persistence.internal.jpa.EntityManagerSetupImpl.addSessionToGlobalSessionManager(EntityManagerSetupImpl.java:907)
at org.eclipse.persistence.internal.jpa.EntityManagerSetupImpl.initSession(EntityManagerSetupImpl.java:2671)
at org.eclipse.persistence.internal.jpa.EntityManagerSetupImpl.deploy(EntityManagerSetupImpl.java:675)
at org.eclipse.persistence.internal.jpa.EntityManagerFactoryDelegate.getAbstractSession(EntityManagerFactoryDelegate.java:205)
at org.eclipse.persistence.internal.jpa.EntityManagerFactoryDelegate.getDatabaseSession(EntityManagerFactoryDelegate.java:183)
at org.eclipse.persistence.internal.jpa.EntityManagerFactoryImpl.getDatabaseSession(EntityManagerFactoryImpl.java:528)
at org.eclipse.persistence.jpa.PersistenceProvider.createContainerEntityManagerFactoryImpl(PersistenceProvider.java:385)
at org.eclipse.persistence.jpa.PersistenceProvider.createContainerEntityManagerFactory(PersistenceProvider.java:313)
at org.glassfish.persistence.jpa.PersistenceUnitLoader.loadPU(PersistenceUnitLoader.java:199)
at org.glassfish.persistence.jpa.PersistenceUnitLoader.<init>(PersistenceUnitLoader.java:107)
at org.glassfish.persistence.jpa.JPADeployer$1.visitPUD(JPADeployer.java:223)
at org.glassfish.persistence.jpa.JPADeployer$PersistenceUnitDescriptorIterator.iteratePUDs(JPADeployer.java:510)
at org.glassfish.persistence.jpa.JPADeployer.createEMFs(JPADeployer.java:230)
at org.glassfish.persistence.jpa.JPADeployer.prepare(JPADeployer.java:168)
at com.sun.enterprise.v3.server.ApplicationLifecycle.prepareModule(ApplicationLifecycle.java:925)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:434)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:219)
at org.glassfish.deployment.admin.DeployCommand.execute(DeployCommand.java:491)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$2$1.run(CommandRunnerImpl.java:539)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$2$1.run(CommandRunnerImpl.java:535)
at java.security.AccessController.doPrivileged(Native Method)
at javax.security.auth.Subject.doAs(Subject.java:360)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$2.execute(CommandRunnerImpl.java:534)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$3.run(CommandRunnerImpl.java:565)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$3.run(CommandRunnerImpl.java:557)
at java.security.AccessController.doPrivileged(Native Method)
at javax.security.auth.Subject.doAs(Subject.java:360)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:556)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:1464)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.access$1300(CommandRunnerImpl.java:109)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1846)
at org.glassfish.deployment.autodeploy.AutoOperation.run(AutoOperation.java:164)
at org.glassfish.deployment.autodeploy.AutoDeployer.deploy(AutoDeployer.java:597)
at org.glassfish.deployment.autodeploy.AutoDeployer.deployAll(AutoDeployer.java:484)
at org.glassfish.deployment.autodeploy.AutoDeployer.run(AutoDeployer.java:412)
at org.glassfish.deployment.autodeploy.AutoDeployer.run(AutoDeployer.java:403)
at org.glassfish.deployment.autodeploy.AutoDeployService$1.run(AutoDeployService.java:233)
at java.util.TimerThread.mainLoop(Timer.java:555)
at java.util.TimerThread.run(Timer.java:505)
]]

[2015-11-22T15:04:47.579-0800] [glassfish 4.1] [INFO] [] [org.eclipse.persistence.session./file:/scratch/anogupta/spec/glassfish4/glassfish/domains/spec2015-1/applications/vehicle/WEB-INF/classes/_vehicle] [tid: _ThreadID=53 _ThreadName=AutoDeployer] [timeMillis: 1448233487579] [levelValue: 800] [[
EclipseLink, version: Eclipse Persistence Services - 2.6.1.v20150605-31e8258]]



 Comments   
Comment by anoopgupta [ 23/Nov/15 ]

The exception is preceded by a warning:
[2015-11-22T15:53:34.897-0800] [glassfish 4.1] [WARNING] [] [org.eclipse.persistence.default] [tid: _ThreadID=56 _ThreadName=AutoDeployer] [timeMillis: 1448236414897] [levelValue: 900] [[

Comment by Lukas Jungmann [ 23/Nov/15 ]

exception itself should be harmless, if not or if you want to get rid of it, try to add

<property name="eclipselink.target-server" value="Glassfish"/>

to persistence.xml

Comment by anoopgupta [ 23/Nov/15 ]

The exception does seem harmless. However, I did try the target-server, but still get the NullPointerException. I verified that the deployed war has the updated persistence.xml as follows::

<?xml version="1.0" encoding="UTF-8"?>
<persistence version="2.1"
   xmlns="http://xmlns.jcp.org/xml/ns/persistence" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
   xsi:schemaLocation="
        http://xmlns.jcp.org/xml/ns/persistence
        http://xmlns.jcp.org/xml/ns/persistence/persistence_2_1.xsd">
   <persistence-unit name="vehicle">
      <provider>org.eclipse.persistence.jpa.PersistenceProvider</provider>
      <jta-data-source>jdbc/SPECjVehicleDS</jta-data-source>
      <class>org.spec.jent.common.vehicle.entity.VehicleDescription</class>
       <exclude-unlisted-classes>true</exclude-unlisted-classes>
       <properties>
         <property name="eclipselink.target-server" value="Glassfish"/>
         <property name="javax.persistence.schema-generation.database.action" value="create"/>
      </properties>
   </persistence-unit>
</persistence>
Comment by Lukas Jungmann [ 25/Nov/15 ]

fixed this within https://bugs.eclipse.org/bugs/show_bug.cgi?id=482894
will be fixed in GF with the next EL integration





Generated at Sat Feb 13 09:39:27 UTC 2016 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.