UnsupportedOperationException when setting a model attribute [message #1795991] |
Wed, 03 October 2018 15:12 |
|
Hi all,
we have a JEE (Note: non-OSGi, just a plain Java env) application which is using an EMF model.
Inside the deployed war, under the WEB-INF/lib folder, we have (for the EMF part):
* org.eclipse.emf.ecore_2.12.0.v20160420-0247.jar
* org.eclipse.emf.common_2.12.0.v20160420-0247.jar
The exact same war is working successfully when deployed on Tomcat 7 (on Java 7), while when deployed on WebSphere 8.5 (on Java 7) it fails when trying to set an EMF attribute of the model (see stacktrace below).
Any hit?
Thank you very much in advance.
Vincenzo
[18/07/18 16.39.36:024 CEST] 00000070 SystemOut O 18 lug 2018 16:39:36 -ERROR -it.Bper.WebApp.QAVServ.QavServBStore:199>
java.lang.UnsupportedOperationException
at org.eclipse.emf.ecore.impl.MinimalEObjectImpl.eBasicAdapters(MinimalEObjectImpl.java:295)
at org.eclipse.emf.common.notify.impl.BasicNotifierImpl.eNotificationRequired(BasicNotifierImpl.java:244)
at qav.impl.SchedaClienteImpl.setNdg(SchedaClienteImpl.java:489)
at it.rcpvision.bper.qav.application.business.ServiceUtils.buildVirtualCompositesForBStore(ServiceUtils.java:1723)
at it.rcpvision.bper.qav.application.business.ServiceUtils.salvaQuestMultirapBStore(ServiceUtils.java:1656)
at it.Bper.WebApp.QAVServ.QavServBStore.processRequest(QavServBStore.java:123)
at it.Bper.WebApp.QAVServ.QavServBStore.doPost(QavServBStore.java:53)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:595)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:668)
at com.ibm.ws.webcontainer.servlet.ServletWrapper.service(ServletWrapper.java:1227)
at com.ibm.ws.webcontainer.servlet.ServletWrapper.handleRequest(ServletWrapper.java:776)
at com.ibm.ws.webcontainer.servlet.ServletWrapper.handleRequest(ServletWrapper.java:458)
at com.ibm.ws.webcontainer.servlet.ServletWrapperImpl.handleRequest(ServletWrapperImpl.java:178)
at com.ibm.ws.webcontainer.filter.WebAppFilterManager.invokeFilters(WebAppFilterManager.java:1032)
at com.ibm.ws.webcontainer.servlet.CacheServletWrapper.handleRequest(CacheServletWrapper.java:87)
at com.ibm.ws.webcontainer.WebContainer.handleRequest(WebContainer.java:909)
at com.ibm.ws.webcontainer.WSWebContainer.handleRequest(WSWebContainer.java:1662)
at com.ibm.ws.webcontainer.channel.WCChannelLink.ready(WCChannelLink.java:200)
at com.ibm.ws.http.channel.inbound.impl.HttpInboundLink.handleDiscrimination(HttpInboundLink.java:459)
at com.ibm.ws.http.channel.inbound.impl.HttpInboundLink.handleNewRequest(HttpInboundLink.java:526)
at com.ibm.ws.http.channel.inbound.impl.HttpInboundLink.processRequest(HttpInboundLink.java:312)
at com.ibm.ws.http.channel.inbound.impl.HttpInboundLink.ready(HttpInboundLink.java:283)
at com.ibm.ws.tcp.channel.impl.NewConnectionInitialReadCallback.sendToDiscriminators(NewConnectionInitialReadCallback.java:214)
at com.ibm.ws.tcp.channel.impl.NewConnectionInitialReadCallback.complete(NewConnectionInitialReadCallback.java:113)
at com.ibm.ws.tcp.channel.impl.AioReadCompletionListener.futureCompleted(AioReadCompletionListener.java:175)
at com.ibm.io.async.AbstractAsyncFuture.invokeCallback(AbstractAsyncFuture.java:217)
at com.ibm.io.async.AsyncChannelFuture.fireCompletionActions(AsyncChannelFuture.java:161)
at com.ibm.io.async.AsyncFuture.completed(AsyncFuture.java:138)
at com.ibm.io.async.ResultHandler.complete(ResultHandler.java:204)
at com.ibm.io.async.ResultHandler.runEventProcessingLoop(ResultHandler.java:775)
at com.ibm.io.async.ResultHandler$2.run(ResultHandler.java:905)
at com.ibm.ws.util.ThreadPool$Worker.run(ThreadPool.java:1862)
|
|
|
|
Re: UnsupportedOperationException when setting a model attribute [message #1796059 is a reply to message #1796009] |
Thu, 04 October 2018 15:09 |
|
Hi Ed,
thank you!
Your suspect explains many things, including the fact that a remote debugging on WebSphere Application Server (WAS) shows breakpoints hitting nowhere or in blank lines of our EMF source code! :(
So, I can think about a couple of possible solutions:
1) Finding a way to force WAS to ignore its own EMF runtime and use the one included into the deployed war. Any idea on how to do this?
2) On this same WAS we have a RAP application (so, non JEE, but OSGi/Equinox) using successfully EMF and many other EMF technologies. This application can expose a Servlet through the RAP Extension Point "org.eclipse.equinox.http.registry.servlets"
The question is: will such a Servlet (started from an OSGi infrastructure) use the correct EMF runtime (which is correctly used by RAP).
I'll let you know..
|
|
|
Re: UnsupportedOperationException when setting a model attribute [message #1796064 is a reply to message #1796059] |
Thu, 04 October 2018 15:41 |
|
Hi,
I can confirm that solution 2) is working!
Now I have a Servlet running on WAS and working successfully with the correct EMF runtime.
It seems that RAP and its backing OSGi/Equinox runtime is running isolated from the underlying application server libraries (whereas a standard JEE webapp doesn't).
Anyway if someone has a clue for solving the problem in a JEE env, let us know.
Thank you
Vincenzo
|
|
|
Re: UnsupportedOperationException when setting a model attribute [message #1796066 is a reply to message #1796064] |
Thu, 04 October 2018 15:53 |
Ed Merks Messages: 33218 Registered: July 2009 |
Senior Member |
|
|
It's been many years since I was at IBM, so my recollection of how this was handled is very foggy. I had to do some cruel and unusual things in EMF for those folks, e.g., org.eclipse.emf.ecore.impl.EPackageRegistryImpl.Delegator to have a package registry that delegates to a package registry of some other class loader to isolate packages registered in the container from that of the server runtime (or something to that effect). So unfortunately I have no clue how one would solve such a problem. But it seems a general problem, i.e., your jars/libraries should take precedence over any jars the server might be using. Likely there is some magical setting or configuration for this, but I don't know. :-(
I assume that RAP is always well behaved. I know the Eclipse Source guys in Munich make much use of this and I've not heard of any problems from them related to this...
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
Powered by
FUDForum. Page generated in 0.25964 seconds