UnsupportedOperationException when setting a model attribute [message #1795991] |
Wed, 03 October 2018 11:12  |
Eclipse User |
|
|
|
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 #1796066 is a reply to message #1796064] |
Thu, 04 October 2018 11:53  |
Eclipse User |
|
|
|
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...
|
|
|
Powered by
FUDForum. Page generated in 0.27833 seconds