"org.fusesource.scalate.TemplateException: loader constraint violation" when using SBTs embedded Jetty and scalatra/scalate - scala

I started getting this error yesterday when using the embedded 'jetty-run' task in SBT. I reverted my code to a previous version and it's still happening.
Note that I packaged up the application and deployed it in an actual jetty instance and I don't get the error. I started getting this error after adding some dependencies to my project (may or may not be related), but have since removed them.
I tried 'clean' 'clean-lib' and 'clean-cache' as well as cleaning out my ~/.m2/repository, ~/.ivy2/cache and project/boot directories.
Anybody have any other ideas?
The line that is blowing up is:
templateEngine.layout(uri, Map("flash" -> flash))
More of the stack trace is below:
org.fusesource.scalate.TemplateException: loader constraint violation: when resolving method "scala.tools.nsc.Settings.(Lscala/Function1;)V" the class loader (instance of sbt/jetty/LazyJettyRun7$SbtWebAppLoader$1) of the current class, org/fusesource/scalate/support/ScalaCompiler, and the class loader (instance of java/net/URLClassLoader) for resolved class, scala/tools/nsc/Settings, have different Class objects for the type scala/Function1 used in the signature
at org.fusesource.scalate.TemplateEngine.compileAndLoad(TemplateEngine.scala:775)
at org.fusesource.scalate.TemplateEngine.compileAndLoadEntry(TemplateEngine.scala:637)
at org.fusesource.scalate.TemplateEngine.liftedTree1$1(TemplateEngine.scala:368)
at org.fusesource.scalate.TemplateEngine.load(TemplateEngine.scala:362)
at org.fusesource.scalate.TemplateEngine.load(TemplateEngine.scala:420)
at org.fusesource.scalate.TemplateEngine.layout(TemplateEngine.scala:521)
at com.ford.testbuilder.web.AppDefaults$class.com$ford$testbuilder$web$AppDefaults$$render(SharedTraits.scala:79)
at com.ford.testbuilder.web.AppDefaults$$anonfun$6.apply(SharedTraits.scala:52)
at org.scalatra.ScalatraKernel$$anonfun$handle$1$$anonfun$apply$mcV$sp$1$$anonfun$apply$mcV$sp$2$$anonfun$6.apply(ScalatraKernel.scala:133)
at org.scalatra.ScalatraKernel$$anonfun$handle$1$$anonfun$apply$mcV$sp$1$$anonfun$apply$mcV$sp$2$$anonfun$6.apply(ScalatraKernel.scala:133)
at scala.collection.LinearSeqOptimized$class.foreach(LinearSeqOptimized.scala:61)
at scala.collection.immutable.List.foreach(List.scala:45)
at scala.collection.generic.TraversableForwarder$class.foreach(TraversableForwarder.scala:44)
at scala.collection.mutable.ListBuffer.foreach(ListBuffer.scala:42)
at org.scalatra.ScalatraKernel$$anonfun$handle$1$$anonfun$apply$mcV$sp$1$$anonfun$apply$mcV$sp$2.apply$mcV$sp(ScalatraKernel.scala:133)
at org.scalatra.ScalatraKernel$$anonfun$handle$1$$anonfun$apply$mcV$sp$1$$anonfun$apply$mcV$sp$2.apply(ScalatraKernel.scala:121)
at org.scalatra.ScalatraKernel$$anonfun$handle$1$$anonfun$apply$mcV$sp$1$$anonfun$apply$mcV$sp$2.apply(ScalatraKernel.scala:121)
at scala.util.DynamicVariable.withValue(DynamicVariable.scala:71)
at org.scalatra.ScalatraKernel$$anonfun$handle$1$$anonfun$apply$mcV$sp$1.apply$mcV$sp(ScalatraKernel.scala:121)
at org.scalatra.ScalatraKernel$$anonfun$handle$1$$anonfun$apply$mcV$sp$1.apply(ScalatraKernel.scala:121)
at org.scalatra.ScalatraKernel$$anonfun$handle$1$$anonfun$apply$mcV$sp$1.apply(ScalatraKernel.scala:121)
at scala.util.DynamicVariable.withValue(DynamicVariable.scala:71)
at org.scalatra.ScalatraKernel$$anonfun$handle$1.apply$mcV$sp(ScalatraKernel.scala:120)
at org.scalatra.ScalatraKernel$$anonfun$handle$1.apply(ScalatraKernel.scala:120)
at org.scalatra.ScalatraKernel$$anonfun$handle$1.apply(ScalatraKernel.scala:120)
at scala.util.DynamicVariable.withValue(DynamicVariable.scala:71)
at org.scalatra.ScalatraKernel$class.handle(ScalatraKernel.scala:119)
at com.ford.testbuilder.web.LoginServlet.org$scalatra$CookieSupport$$super$handle(LoginServlet.scala:10)
at org.scalatra.CookieSupport$$anonfun$handle$1$$anonfun$apply$mcV$sp$1.apply$mcV$sp(CookieSupport.scala:102)
at org.scalatra.CookieSupport$$anonfun$handle$1$$anonfun$apply$mcV$sp$1.apply(CookieSupport.scala:102)
at org.scalatra.CookieSupport$$anonfun$handle$1$$anonfun$apply$mcV$sp$1.apply(CookieSupport.scala:102)
at scala.util.DynamicVariable.withValue(DynamicVariable.scala:71)
at org.scalatra.CookieSupport$$anonfun$handle$1.apply$mcV$sp(CookieSupport.scala:101)
at org.scalatra.CookieSupport$$anonfun$handle$1.apply(CookieSupport.scala:101)
at org.scalatra.CookieSupport$$anonfun$handle$1.apply(CookieSupport.scala:101)
at scala.util.DynamicVariable.withValue(DynamicVariable.scala:71)
at org.scalatra.CookieSupport$class.handle(CookieSupport.scala:100)
at com.ford.testbuilder.web.LoginServlet.org$scalatra$FlashMapSupport$$super$handle(LoginServlet.scala:10)
at org.scalatra.FlashMapSupport$$anonfun$handle$1.apply$mcV$sp(flashMap.scala:101)
at org.scalatra.FlashMapSupport$$anonfun$handle$1.apply(flashMap.scala:100)
at org.scalatra.FlashMapSupport$$anonfun$handle$1.apply(flashMap.scala:100)
at scala.util.DynamicVariable.withValue(DynamicVariable.scala:71)
at org.scalatra.FlashMapSupport$class.handle(flashMap.scala:100)

I figured this out after trying a fresh checkout on someone else's machine (which was working fine) and comparing the classpaths. I found that I had both the scala-library-2.8.1.jar as well as the scala-library.jar in my classpath.
This was caused by the following line in my project file:
override def filterScalaJars = false
Wasted the better part of a day on this :(

Related

Quarkus native build Random/SplittableRandom exception with Vert.x Redis Client

I am doing a native build of my Quarkus app and am hitting the UnsupportedFeatureException: Detected an instance of Random/SplittableRandom on a few Vertx Redis Client classes.
I am building using the docker container method:
./mvnw package -Dnative -Dquarkus.native.container-build=true
I have fixed some of the exceptions by including in the pom.xml:
<quarkus.native.additional-build-args>
--initialize-at-run-time=io.vertx.redis.client.impl.RedisSentinelClient
</quarkus.native.additional-build-args>
but am stuck on this one:
Fatal error: com.oracle.graal.pointsto.util.AnalysisError$ParsingError: Error encountered while parsing
io.vertx.redis.client.impl.RedisClusterConnection.send(io.vertx.redis.client.Request)
Parsing context:
at io.vertx.redis.client.impl.RedisClusterConnection.send(RedisClusterConnection.java:117)
at io.vertx.redis.client.impl.BaseRedisClient.lambda$send$1(BaseRedisClient.java:45)
at io.vertx.redis.client.impl.BaseRedisClient$$Lambda$1711/0x00000007c1ea57e8.apply(Unknown Source)
I have tried adding
--initialize-at-run-time=io.vertx.redis.client.impl.RedisSentinelClient\,io.vertx.redis.client.impl.RedisClusterConnection
--initialize-at-run-time=io.vertx.redis.client.impl.RedisSentinelClient\,io.vertx.redis.client.impl.BaseRedisClient
and even
--initialize-at-run-time=io.vertx.redis.client.impl.RedisSentinelClient\,io.vertx.redis.client.impl.RedisReplicationConnection.send(io.vertx.redis.client.Request)
but the error persists.
I am fairly new to Java and very new to native building / GraalVM etc
Can anyone shed any light on what class I should add, please?
Thanks,
Murray
I believe we can propose a change to vert.x redis client to avoid the split random use. The randomness is there mostly to share the load across nodes. It is not used for any security related features. For this reason, a proposal to either round-robin would probably make more sense as a solution to this issue.
Ok, this seems to fix it:
EDIT: No it doesn't. See below.
<quarkus.native.additional-build-args>
--initialize-at-run-time=io.vertx.redis.client.impl.RedisSentinelClient\,io.vertx.redis.client.impl.RedisReplicationConnection
</quarkus.native.additional-build-args>
The full profiles section in the pom.xml looks like this, for anyone else new to all this.
<profiles>
<profile>
<id>native</id>
<activation>
<property>
<name>native</name>
</property>
</activation>
<properties>
<skipITs>false</skipITs>
<quarkus.package.type>native</quarkus.package.type>
<quarkus.native.additional-build-args>
--initialize-at-run-time=io.vertx.redis.client.impl.RedisSentinelClient\,io.vertx.redis.client.impl.RedisReplicationConnection
</quarkus.native.additional-build-args>
</properties>
</profile>
</profiles>
I have different errors now, so still not building, but at least this seems to fix that specific issue.
EDIT: The problem persists...
If I build with the pom as described above, ie:
<quarkus.native.additional-build-args>
--initialize-at-run-time=io.vertx.redis.client.impl.RedisSentinelClient\,io.vertx.redis.client.impl.RedisReplicationConnection
</quarkus.native.additional-build-args>
I now get:
Error: Classes that should be initialized at run time got initialized during image building:
io.vertx.redis.client.impl.RedisReplicationConnection
the class was requested to be initialized at run time
(from command line with 'io.vertx.redis.client.impl.RedisReplicationConnection').
So, I guess that is not the right class afterall.
If I remove that class from the list I revert to the Random exception.
(Showing more detail)
[1/7] Initializing... (3.7s # 0.10GB)
Version info: 'GraalVM 22.3.1.0-Final Java 17 Mandrel Distribution'
Java version info: '17.0.6+10'
C compiler: gcc (linux, x86_64, 11.3.0)
Garbage collector: Serial GC
4 user-specific feature(s)
- io.quarkus.runner.Feature: Auto-generated class by Quarkus from the existing extensions
- io.quarkus.runtime.graal.DisableLoggingFeature: Disables INFO logging during the analysis phase for the [org.jboss.threads] categories
- io.quarkus.runtime.graal.ResourcesFeature: Register each line in META-INF/quarkus-native-resources.txt as a resource on Substrate VM
- io.quarkus.websockets.client.runtime.DisableLoggingFeature: Disables INFO logging during the analysis phase for the [io.undertow.websockets] categories
[2/7] Performing analysis... [*] (14.1s # 3.37GB)
12,032 (89.58%) of 13,432 classes reachable
17,778 (59.65%) of 29,803 fields reachable
61,621 (57.16%) of 107,809 methods reachable
541 classes, 150 fields, and 2,655 methods registered for reflection
Fatal error: com.oracle.graal.pointsto.util.AnalysisError$ParsingError: Error encountered while parsing io.vertx.redis.client.impl.RedisReplicationConnection.send(io.vertx.redis.client.Request)
Parsing context:
at io.vertx.redis.client.impl.RedisReplicationConnection.send(RedisReplicationConnection.java:111)
at io.vertx.redis.client.RedisConnection.send(RedisConnection.java:83)
at io.vertx.redis.client.impl.RedisReplicationClient.getNodes(RedisReplicationClient.java:183)
at io.vertx.redis.client.impl.RedisReplicationClient.lambda$connect$4(RedisReplicationClient.java:126)
at io.vertx.redis.client.impl.RedisReplicationClient$$Lambda$2203/0x00000007c1630f60.handle(Unknown Source)
at io.vertx.core.impl.future.FutureImpl$1.onSuccess(FutureImpl.java:91)
{etc}
I am beginning to think I have an error / issue in my code where I am using the Vert.x Redis Client. I am trying to narrow it down by trial and error.
Any other suggestions are most welcome.

How can i solve java.lang.IllegalStateException: Illegal access:?

I am using Eclipse to develope a webapp. Everything was working fine, but sometimes when I tried to publist->start my server, I received the following error:
Oct 03, 2019 6:52:55 PM org.apache.catalina.loader.WebappClassLoaderBase checkStateForResourceLoading
INFO: Illegal access: this web application instance has been stopped already. Could not load []. The following stack trace is thrown for debugging purposes as well as to attempt to terminate the thread which caused the illegal access.
java.lang.IllegalStateException: Illegal access: this web application instance has been stopped already. Could not load []. The following stack trace is thrown for debugging purposes as well as to attempt to terminate the thread which caused the illegal access.
at org.apache.catalina.loader.WebappClassLoaderBase.checkStateForResourceLoading(WebappClassLoaderBase.java:1383)
at org.apache.catalina.loader.WebappClassLoaderBase.getResource(WebappClassLoaderBase.java:1036)
at com.mysql.cj.jdbc.AbandonedConnectionCleanupThread.checkThreadContextClassLoader(AbandonedConnectionCleanupThread.java:117)
at com.mysql.cj.jdbc.AbandonedConnectionCleanupThread.run(AbandonedConnectionCleanupThread.java:84)
at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
at java.base/java.lang.Thread.run(Thread.java:834)
For the first few times, I just restarted the server, and it was working fine, but now even a restart doesent solve the problem. I read about it online, and some sources mentioned that it might be a thread management issue, but I couldn't get further than that. Can anybody please provide some info? Thanks.
The mysql driver is trying to clean-up on web application shutdown which is good. Unfortunately it is trying to load additional classes to perform this clean-up and - since the web application is shutting down - class loading is no longer available. Ideally, the driver would load all the classes it needed to clean-up when it firsts loads - that would avoid this issue.
If you can figure out which classes it is trying to load - a check of the driver source code should show you which - then you should be able to load them yourself on application start in, for example, a ServletContextListener.
If you created any Entity class and forgot to give ID to any specific column then also this problem occurs. So assign #ID to any column and run again. your issue will resolve.

typesafe activator ui not launching

play.api.Application$$anon$1: Execution exception[[IllegalArgumentException: req
uirement failed: Source file 'C:\Users\shriv_000\.activator\1.3.6\templates\inde
x.db_e25b80033130c08.tmp' is a directory.]]
at play.api.Application$class.handleError(Application.scala:296) ~[play_
2.11-2.3.9.jar:2.3.9]
at play.api.DefaultApplication.handleError(Application.scala:402) [play_
2.11-2.3.9.jar:2.3.9]
at play.core.server.netty.PlayDefaultUpstreamHandler$$anonfun$14$$anonfu
n$apply$1.applyOrElse(PlayDefaultUpstreamHandler.scala:205) [play_2.11-2.3.9.jar
:2.3.9]
at play.core.server.netty.PlayDefaultUpstreamHandler$$anonfun$14$$anonfu
n$apply$1.applyOrElse(PlayDefaultUpstreamHandler.scala:202) [play_2.11-2.3.9.jar
:2.3.9]
at scala.runtime.AbstractPartialFunction.apply(AbstractPartialFunction.s
cala:36) [scala-library.jar:0.13.8]
Caused by: java.lang.IllegalArgumentException: requirement failed: Source file '
C:\Users\shriv_000\.activator\1.3.6\templates\index.db_e25b80033130c08.tmp' is a
directory.
at scala.Predef$.require(Predef.scala:219) ~[scala-library.jar:0.13.8]
at sbt.IO$.copyFile(IO.scala:584) ~[client-all-2-11-0.3.5.jar:0.3.5]
at sbt.IO$.move(IO.scala:786) ~[client-all-2-11-0.3.5.jar:0.3.5]
at activator.package$RichIO$.createViaTemporary$extension(package.scala:
30) ~[activator-templates-cache-1.0-a0afb008ea619bf9d87dc010156cddffa8a6f880.jar
:1.3.6]
at activator.templates.repository.UriRemoteTemplateRepository$$anonfun$r
esolveIndexTo$1.apply(UriRemoteTemplateRepository.scala:228) ~[activator-templat
es-cache-1.0-a0afb008ea619bf9d87dc010156cddffa8a6f880.jar:1.0-a0afb008ea619bf9d8
7dc010156cddffa8a6f880]
[info] application - onStop received closing down the app
I am at activator 1.3.6
I have seen TypeSafe Activator installation error and it might be different then my problem. I have been able to create and launch a play project.
The solution provided there did not work for me.
I see this problem frequently.
I found a workaround. Try to execute activator as an administrator.

D2FS within workflow method

I´m trying to use D2FS services within a workflow method, but im getting the following error:
Caused by: com.sun.xml.bind.v2.runtime.IllegalAnnotationsException: 2 counts of IllegalAnnotationExceptions
Two classes have the same XML type name "address". Use #XmlType.name and #XmlType.namespace to assign different names to them.
this problem is related to the following location:
at com.sun.xml.ws.developer.MemberSubmissionEndpointReference$Address
at public com.sun.xml.ws.developer.MemberSubmissionEndpointReference$Address com.sun.xml.ws.developer.MemberSubmissionEndpointReference.addr
at com.sun.xml.ws.developer.MemberSubmissionEndpointReference
this problem is related to the following location:
at javax.xml.ws.wsaddressing.W3CEndpointReference$Address
at private javax.xml.ws.wsaddressing.W3CEndpointReference$Address javax.xml.ws.wsaddressing.W3CEndpointReference.address
at javax.xml.ws.wsaddressing.W3CEndpointReference
Two classes have the same XML type name "elements". Use #XmlType.name and #XmlType.namespace to assign different names to them.
this problem is related to the following location:
at com.sun.xml.ws.developer.MemberSubmissionEndpointReference$Elements
at public com.sun.xml.ws.developer.MemberSubmissionEndpointReference$Elements com.sun.xml.ws.developer.MemberSubmissionEndpointReference.referenceProperties
at com.sun.xml.ws.developer.MemberSubmissionEndpointReference
this problem is related to the following location:
at javax.xml.ws.wsaddressing.W3CEndpointReference$Elements
at private javax.xml.ws.wsaddressing.W3CEndpointReference$Elements javax.xml.ws.wsaddressing.W3CEndpointReference.referenceParameters
at javax.xml.ws.wsaddressing.W3CEndpointReference
I tried to update the jaxws-rt libraries and started getting the new error:
java.lang.LinkageError: ClassException: attempting to castjar:file:/C:/Documentum/jboss4.3.0/server/DctmServer_MethodServer/deploy/bpm.ear/APP-INF/lib/jaxws-api.jar!/javax/xml/ws/spi/Provider.classtojar:file:/C:/Documentum/jboss4.3.0/jdk/jre/lib/rt.jar!/javax/xml/ws/spi/Provider.class
at javax.xml.ws.spi.Provider.provider(Provider.java:94)
at javax.xml.ws.Service.<init>(Service.java:56)
at com.emc.d2fs.schemas.models.ModelPortService.<init>(ModelPortService.java:46)
at com.emc.cgd.methodsWorkflow.DispatchExtStorageUpdateData.doTask(DispatchExtStorageUpdateData.java:45)
at com.documentum.bpm.rtutil.WorkflowMethod.execute(WorkflowMethod.java:214)
at com.documentum.bpm.rtutil.AbstractWorkflowMethod.executeMethod(AbstractWorkflowMethod.java:27)
at com.documentum.bpm.rtutil.GenericWorkflowMethod.execute(GenericWorkflowMethod.java:124)
at com.documentum.bpm.rtutil.GenericWorkflowMethod.execute(GenericWorkflowMethod.java:65)
at com.documentum.mthdservlet.DfMethodRunner.runIt(Unknown Source)
at com.documentum.mthdservlet.AMethodRunner.runAndReturnStatus(Unknown Source)
Any idea how to solve it?
Im using:
JBoss 4.3
JAX-WS Implementation 2.2
Thanks
On tomcat I had to add following jars to the tomcat lib:
jaxws-api.jar
jaxws-rt.jar
stax-ex.jar
streambuffer.jar
Perhaps this will resolver the problem on jBoss as well.

using an EJB 3.1 bean through a remote java stand-alone application

I have been trying to use Java EE 6 to create an Application Server based app which is to receive Job objects from a GWT Web Application and those Jobs would be pulled from a Java stand-alone application. I have been thinking that the EJB model would provide me with easy way to do remoting because my client app should be able to run on a different machine.
I am using Glassfish 3.1 and Netbeans 7.0.1 as my IDE, I have also used eclipse Java EE to reproduce same problem.
I have been facing the next difficulties:
It was not easy to find out about InitialContext, is it the only way to use the remoting? shouldn't I be able to use #EJB/#Inject for some automatic code injection from my stand alone app using some configuration file?
I have discovered some how (not found directly in documentation) that for the InitialContext mechanism to work I need to add to my Libraries: gf-client-module.jar and weld-osgi-bundle.jar
I have been receiving the next error:
Exception in thread "main" javax.ejb.EJBException: java.rmi.MarshalException: CORBA MARSHAL 1330446343 No; nested exception is:
org.omg.CORBA.MARSHAL: FINE: IOP00810007: Underflow in BufferManagerReadStream after last fragment in message vmcid: OMG minor code: 7 completed: No
at ContentCreator._JobDispatcherRemote_Wrapper.getSimpleJobForProcessing(ContentCreator/_JobDispatcherRemote_Wrapper.java)
at javaapplication1.JavaApplication1.main(JavaApplication1.java:35)
Caused by: java.rmi.MarshalException: CORBA MARSHAL 1330446343 No; nested exception is:
org.omg.CORBA.MARSHAL: FINE: IOP00810007: Underflow in BufferManagerReadStream after last fragment in message vmcid: OMG minor code: 7 completed: No
at com.sun.corba.ee.impl.javax.rmi.CORBA.Util.mapSystemException(Util.java:267)
at com.sun.corba.ee.impl.presentation.rmi.StubInvocationHandlerImpl.privateInvoke(StubInvocationHandlerImpl.java:213)
at com.sun.corba.ee.impl.presentation.rmi.StubInvocationHandlerImpl.invoke(StubInvocationHandlerImpl.java:152)
at com.sun.corba.ee.impl.presentation.rmi.codegen.CodegenStubBase.invoke(CodegenStubBase.java:227)
at ContentCreator.__JobDispatcherRemote_Remote_DynamicStub.getSimpleJobForProcessing(ContentCreator/__JobDispatcherRemote_Remote_DynamicStub.java)
... 2 more
Caused by: org.omg.CORBA.MARSHAL: FINE: IOP00810007: Underflow in BufferManagerReadStream after last fragment in message vmcid: OMG minor code: 7 completed: No
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at java.lang.reflect.Constructor.newInstance(Constructor.java:525)
at com.sun.corba.ee.spi.orbutil.logex.corba.CorbaExtension.makeException(CorbaExtension.java:248)
at com.sun.corba.ee.spi.orbutil.logex.corba.CorbaExtension.makeException(CorbaExtension.java:95)
at com.sun.corba.ee.spi.orbutil.logex.WrapperGenerator.handleFullLogging(WrapperGenerator.java:387)
at com.sun.corba.ee.spi.orbutil.logex.WrapperGenerator.access$400(WrapperGenerator.java:107)
at com.sun.corba.ee.spi.orbutil.logex.WrapperGenerator$2.invoke(WrapperGenerator.java:511)
at com.sun.corba.ee.spi.orbutil.proxy.CompositeInvocationHandlerImpl.invoke(CompositeInvocationHandlerImpl.java:99)
at $Proxy24.endOfStream(Unknown Source)
at com.sun.corba.ee.impl.encoding.BufferManagerReadStream.underflow(BufferManagerReadStream.java:128)
at com.sun.corba.ee.impl.encoding.CDRInputStream_1_1.grow(CDRInputStream_1_1.java:113)
at com.sun.corba.ee.impl.encoding.CDRInputStream_1_2.alignAndCheck(CDRInputStream_1_2.java:126)
at com.sun.corba.ee.impl.encoding.CDRInputStream_1_0.read_long(CDRInputStream_1_0.java:496)
at com.sun.corba.ee.impl.encoding.CDRInputStream_1_0.readValueTag(CDRInputStream_1_0.java:1810)
at com.sun.corba.ee.impl.encoding.CDRInputStream_1_0.read_value(CDRInputStream_1_0.java:1040)
at com.sun.corba.ee.impl.encoding.CDRInputObject.read_value(CDRInputObject.java:531)
at com.sun.corba.ee.impl.presentation.rmi.DynamicMethodMarshallerImpl$14.read(DynamicMethodMarshallerImpl.java:384)
at com.sun.corba.ee.impl.presentation.rmi.DynamicMethodMarshallerImpl.readResult(DynamicMethodMarshallerImpl.java:483)
at com.sun.corba.ee.impl.presentation.rmi.StubInvocationHandlerImpl.privateInvoke(StubInvocationHandlerImpl.java:203)
... 5 more
I have been facing problems with using Java EE 6 remotely in my scenario and have found little help for those problems any assistance would be greatly appreciated.
In my case i have the same stack message "Underflow in BufferManagerReadStream after last fragment in message vmcid: OMG minor code: 7"
In my project i had a nested object which not implements the Serializable interface. Implementing the Inteface solved my problem.
Did you take care that the class of the object that you pass as argument while rmi-invoking the method getSimpleJobForProcessing implements the interface java.io.Serializable?
This was one reason, why I had such exceptions, too.
The #EJB annotation is processed and interpreted by a Java EE compliant container, so as far as I know there is no simple way to do this from a Java application that doesn't run in a container.
However, if you are running from a Glassfish container, you might be able to get rid of the JNDI lookup.
You can try the following:
#EJB(name = "RemoteService")
private StatusService remoteService;
and then in your sun-web.xml:
<ejb-ref>
<ejb-ref-name>RemoteService</ejb-ref-name>
<jndi-name>java:comp/env/com//RemoteService</jndi-name>
</ejb-ref>
With the exception, I cannot help.