JAX-WS context listener initializing failed in JBOSS - servlets

I'm getting below error when trying to deploy a JAX-WS web service in JBOSS 4.0.3. I'm using JAX-WS RI runtime libraries. I'm not using JBOSS-WS the JBOSS specific JAX-WS.
18:31:21,125 INFO [STDOUT] Feb 20, 2015 6:31:21 PM com.sun.xml.ws.transport.http.servlet.WSServletContextListener contextInitialized
INFO: WSSERVLET12: JAX-WS context listener initializing
18:31:21,203 INFO [STDOUT] Feb 20, 2015 6:31:21 PM com.sun.xml.ws.transport.http.servlet.WSServletContextListener parseAdaptersAndCreateDelegate
SEVERE: WSSERVLET11: failed to parse runtime descriptor:
java.lang.AbstractMethodError: javax.xml.transform.TransformerFactory.setFeature(Ljava/lang/String;Z)V
java.lang.AbstractMethodError: javax.xml.transform.TransformerFactory.setFeature(Ljava/lang/String;Z)V
at com.sun.xml.ws.util.xml.XmlUtil.newTransformerFactory(XmlUtil.java:392)
at com.sun.xml.ws.util.xml.XmlUtil.newTransformerFactory(XmlUtil.java:400)
at com.sun.xml.ws.util.xml.XmlUtil.<clinit>(XmlUtil.java:233)
at com.sun.xml.ws.api.streaming.XMLStreamReaderFactory.getXMLInputFactory(XMLStreamReaderFactory.java:127)
at com.sun.xml.ws.api.streaming.XMLStreamReaderFactory.<clinit>(XMLStreamReaderFactory.java:89)
at com.sun.xml.ws.transport.http.DeploymentDescriptorParser.parse(DeploymentDescriptorParser.java:176)
at com.sun.xml.ws.transport.http.servlet.WSServletContextListener.parseAdaptersAndCreateDelegate(WSServletContextListener.java:131)
at com.sun.xml.ws.transport.http.servlet.WSServletContextListener.contextInitialized(WSServletContextListener.java:152)
at org.apache.catalina.core.StandardContext.listenerStart(StandardContext.java:3669)
at org.apache.catalina.core.StandardContext.start(StandardContext.java:4104)
at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:759)
at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:739)
at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:524)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)...
In the web.xml I've put the listener for the class: com.sun.xml.ws.transport.http.servlet.WSServletContextListener

The class javax.xml.transform.TransformerFactory is abstract, and you need an Implementation of that class somewhere in your classpath. The exception java.lang.AbstractMethodError: javax.xml.transform.TransformerFactory.setFeature(Ljava/lang/String;Z) often indicates a version conflict in your dependencies, because the implementation you use was build against a different version of the interface.
To solve it you must use a matching implementation. TransformerFactory-implementations are contained withing XML parsers like Xalan or Xerces. You can tell Java to use a certain parser implementation by setting the appropriate system properties:
Properties p = System.getProperties();
p.setProperty("javax.xml.transform.TransformerFactory", "com.sun.org.apache.xalan.internal.xsltc.trax.TransformerFactoryImpl");
p.setProperty("javax.xml.parsers.DocumentBuilderFactory", "com.sun.org.apache.xerces.internal.jaxp.DocumentBuilderFactoryImpl");
p.setProperty("javax.xml.parsers.SAXParserFactory", "com.sun.org.apache.xerces.internal.jaxp.SAXParserFactoryImpl");
System.setProperties(p);
Executing this during initialization of your application will set the default parser implementation to the internal Xalan parser of the JRE. To use other parsers, include their dependencies and put the Implementations classes' names in the setProperties methods.

Related

Eclipselink Lazy loading fails when upgrade to Jersey2 for Weblogic 12c migration from WL11g

We are working to migrate an Java 7 - EJB(Remote implementation) application from Weblogic 11G to Weblogic 12C. As part of the migration we have upgraded to Jersey2(2.26) from Jersey1(1.17.1). Though Jersey1 is backward compatible we have upgraded for long run purpose.
The beans have been injected as EJBs and with its Remote implementations. In one of the Service layer method, child object is accessed from the parent entity that is retrieved from DAO layer(Entity is retrieved with EntityManager and JTA PersistenceUnit defined along with all the entities listed in persistence.xml). While trying to access that we are getting below error.
Caused By: Exception [EclipseLink-7242] (Eclipse Persistence Services - 2.6.7.v20190604-418f1a1c56): org.eclipse.persistence.exceptions.ValidationException Exception Description: An attempt was made to traverse a relationship using indirection that had a null Session. This often occurs when an entity with an uninstantiated LAZY relationship is serialized and that relationship is traversed after serialization. To avoid this issue, instantiate the LAZY relationship prior to serialization.
Eclipselink will create a temporary-read session for indirection/LAZY access out side of sessions as far as I know.
Why it is not working in 12c while it was working in 11g.
We haven't changed the Eclipselink version. It is still in 2.4.2 in pom.xml. (However as the 12c ships with Eclipselink 2.6.7 by default it is being used. I've read the documentation for Eclipselink 2.4.2 and 2.6.7) Not much of a change in terms of LAZY/EAGER Fetch and weaving.)
I have read that Weaving is enabled by default in JavaEE. So ideally the above error shouldn't have occurred.
To troubleshoot it further, I've simply made standalone main method class with direct DB connectivity with same eclipselink 2.6.7. I'm trying to access the child the same way after I've closed the EntityManager and EntityManagerFactory. That time it is working. Why it is not working in 12c alone? What am I missing here?
P.s.: I have upgraded javaee-api from 6.0 yo 7.0 as well. Just sharing. Also the packaging is changed to 'jar' from 'ejb' to make it compatible with 12c/Jersey2.
Update 1: Posting full trace to know if there are any internal serialization happened(as per Chris comment). P.s.: Updated my package name as com.foo.bar.foobar.
javax.ejb.EJBException: EJB Exception: ; nested exception is:
Exception [EclipseLink-7242] (Eclipse Persistence Services - 2.6.7.v20190604-418f1a1c56): org.eclipse.persistence.exceptions.ValidationException
Exception Description: An attempt was made to traverse a relationship using indirection that had a null Session. This often occurs when an entity with an uninstantiated LAZY relationship is serialized and that relationship is traversed after serialization. To avoid this issue, instantiate the LAZY relationship prior to serialization.
at weblogic.ejb.container.internal.RemoteBusinessIntfProxy.unwrapRemoteException(RemoteBusinessIntfProxy.java:130)
at weblogic.ejb.container.internal.RemoteBusinessIntfProxy.invoke(RemoteBusinessIntfProxy.java:102)
at com.sun.proxy.$Proxy307.getMember(Unknown Source)
at com.foo.bar.foobar.service.rest.InboxServlet.getMember(InboxServlet.java:374)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at org.glassfish.jersey.server.model.internal.ResourceMethodInvocationHandlerFactory$1.invoke(ResourceMethodInvocationHandlerFactory.java:81)
at org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher$1.run(AbstractJavaResourceMethodDispatcher.java:144)
at org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher.invoke(AbstractJavaResourceMethodDispatcher.java:161)
at org.glassfish.jersey.server.model.internal.JavaResourceMethodDispatcherProvider$TypeOutInvoker.doDispatch(JavaResourceMethodDispatcherProvider.java:205)
at org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher.dispatch(AbstractJavaResourceMethodDispatcher.java:99)
at org.glassfish.jersey.server.model.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:389)
at org.glassfish.jersey.server.model.ResourceMethodInvoker.apply(ResourceMethodInvoker.java:347)
at org.glassfish.jersey.server.model.ResourceMethodInvoker.apply(ResourceMethodInvoker.java:102)
at org.glassfish.jersey.server.ServerRuntime$2.run(ServerRuntime.java:326)
at org.glassfish.jersey.internal.Errors$1.call(Errors.java:271)
at org.glassfish.jersey.internal.Errors$1.call(Errors.java:267)
at org.glassfish.jersey.internal.Errors.process(Errors.java:315)
at org.glassfish.jersey.internal.Errors.process(Errors.java:297)
at org.glassfish.jersey.internal.Errors.process(Errors.java:267)
at org.glassfish.jersey.process.internal.RequestScope.runInScope(RequestScope.java:317)
at org.glassfish.jersey.server.ServerRuntime.process(ServerRuntime.java:305)
at org.glassfish.jersey.server.ApplicationHandler.handle(ApplicationHandler.java:1154)
at org.glassfish.jersey.servlet.WebComponent.serviceImpl(WebComponent.java:473)
at org.glassfish.jersey.servlet.WebComponent.service(WebComponent.java:427)
at org.glassfish.jersey.servlet.ServletContainer.service(ServletContainer.java:388)
at org.glassfish.jersey.servlet.ServletContainer.service(ServletContainer.java:341)
at org.glassfish.jersey.servlet.ServletContainer.service(ServletContainer.java:228)
at weblogic.servlet.internal.StubSecurityHelper$ServletServiceAction.run(StubSecurityHelper.java:295)
at weblogic.servlet.internal.StubSecurityHelper$ServletServiceAction.run(StubSecurityHelper.java:260)
at weblogic.servlet.internal.StubSecurityHelper.invokeServlet(StubSecurityHelper.java:137)
at weblogic.servlet.internal.ServletStubImpl.execute(ServletStubImpl.java:353)
at weblogic.servlet.internal.TailFilter.doFilter(TailFilter.java:25)
at weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:78)
at com.foo.bar.foobar.service.rest.InboxServletHandler.doFilter(InboxServletHandler.java:50)
at weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:78)
at weblogic.servlet.internal.WebAppServletContext$ServletInvocationAction.wrapRun(WebAppServletContext.java:3797)
at weblogic.servlet.internal.WebAppServletContext$ServletInvocationAction.run(WebAppServletContext.java:3763)
at weblogic.security.acl.internal.AuthenticatedSubject.doAs(AuthenticatedSubject.java:344)
at weblogic.security.service.SecurityManager.runAsForUserCode(SecurityManager.java:197)
at weblogic.servlet.provider.WlsSecurityProvider.runAsForUserCode(WlsSecurityProvider.java:203)
at weblogic.servlet.provider.WlsSubjectHandle.run(WlsSubjectHandle.java:71)
at weblogic.servlet.internal.WebAppServletContext.doSecuredExecute(WebAppServletContext.java:2451)
at weblogic.servlet.internal.WebAppServletContext.securedExecute(WebAppServletContext.java:2299)
at weblogic.servlet.internal.WebAppServletContext.execute(WebAppServletContext.java:2277)
at weblogic.servlet.internal.ServletRequestImpl.runInternal(ServletRequestImpl.java:1720)
at weblogic.servlet.internal.ServletRequestImpl.run(ServletRequestImpl.java:1680)
at weblogic.servlet.provider.ContainerSupportProviderImpl$WlsRequestExecutor.run(ContainerSupportProviderImpl.java:272)
at weblogic.invocation.ComponentInvocationContextManager._runAs(ComponentInvocationContextManager.java:352)
at weblogic.invocation.ComponentInvocationContextManager.runAs(ComponentInvocationContextManager.java:337)
at weblogic.work.LivePartitionUtility.doRunWorkUnderContext(LivePartitionUtility.java:57)
at weblogic.work.PartitionUtility.runWorkUnderContext(PartitionUtility.java:41)
at weblogic.work.SelfTuningWorkManagerImpl.runWorkUnderContext(SelfTuningWorkManagerImpl.java:655)
at weblogic.work.ExecuteThread.execute(ExecuteThread.java:420)
at weblogic.work.ExecuteThread.run(ExecuteThread.java:360)
Caused By: Exception [EclipseLink-7242] (Eclipse Persistence Services - 2.6.7.v20190604-418f1a1c56): org.eclipse.persistence.exceptions.ValidationException
Exception Description: An attempt was made to traverse a relationship using indirection that had a null Session. This often occurs when an entity with an uninstantiated LAZY relationship is serialized and that relationship is traversed after serialization. To avoid this issue, instantiate the LAZY relationship prior to serialization.
at org.eclipse.persistence.exceptions.ValidationException.instantiatingValueholderWithNullSession(ValidationException.java:1024)
at org.eclipse.persistence.internal.indirection.UnitOfWorkValueHolder.instantiate(UnitOfWorkValueHolder.java:232)
at org.eclipse.persistence.internal.indirection.DatabaseValueHolder.getValue(DatabaseValueHolder.java:89)
at com.foo.bar.foobar.entity.Provider._persistence_get_address(Provider.java)
at com.foo.bar.foobar.entity.Provider.getAddress(Provider.java:193)
at com.foo.bar.foobar.InboxBusiness.updateMemberAddress(InboxBusiness.java:1535)
at com.foo.bar.foobar.InboxBusiness.updateMember(InboxBusiness.java:641)
at com.foo.bar.foobar.InboxBusiness.getMember(InboxBusiness.java:403)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at com.bea.core.repackaged.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:333)
at com.bea.core.repackaged.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:190)
at com.bea.core.repackaged.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:157)
at com.oracle.pitchfork.intercept.MethodInvocationInvocationContext.proceed(MethodInvocationInvocationContext.java:101)
at com.oracle.pitchfork.intercept.JeeInterceptorInterceptor.invoke(JeeInterceptorInterceptor.java:101)
at com.bea.core.repackaged.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:179)
at com.oracle.pitchfork.intercept.MethodInvocationInvocationContext.proceed(MethodInvocationInvocationContext.java:101)
at org.jboss.weld.ejb.AbstractEJBRequestScopeActivationInterceptor.aroundInvoke(AbstractEJBRequestScopeActivationInterceptor.java:73)
at org.jboss.weld.ejb.SessionBeanInterceptor.aroundInvoke(SessionBeanInterceptor.java:52)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at com.oracle.pitchfork.intercept.JeeInterceptorInterceptor.invoke(JeeInterceptorInterceptor.java:94)
at com.bea.core.repackaged.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:179)
at com.bea.core.repackaged.springframework.aop.support.DelegatingIntroductionInterceptor.doProceed(DelegatingIntroductionInterceptor.java:133)
at com.bea.core.repackaged.springframework.aop.support.DelegatingIntroductionInterceptor.invoke(DelegatingIntroductionInterceptor.java:121)
at com.bea.core.repackaged.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:179)
at com.bea.core.repackaged.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:213)
at com.sun.proxy.$Proxy367.getMember(Unknown Source)
at com.foo.bar.foobar.InboxBusinessRemote_lbjxju_InboxBusinessRemoteImpl.__WL_invoke(Unknown Source)
at weblogic.ejb.container.internal.SessionRemoteMethodInvoker.invokeInternal(SessionRemoteMethodInvoker.java:54)
at weblogic.ejb.container.internal.SessionRemoteMethodInvoker.invoke(SessionRemoteMethodInvoker.java:21)
at com.foo.bar.foobar.InboxBusinessRemote_lbjxju_InboxBusinessRemoteImpl.getMember(Unknown Source)
at com.foo.bar.foobar.InboxBusinessRemote_lbjxju_InboxBusinessRemoteImpl_CBV.getMember(Unknown Source)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at weblogic.ejb.container.internal.RemoteBusinessIntfProxy.invoke(RemoteBusinessIntfProxy.java:89)
at com.sun.proxy.$Proxy307.getMember(Unknown Source)
at com.foo.bar.foobar.service.rest.InboxServlet.getMember(InboxServlet.java:374)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at org.glassfish.jersey.server.model.internal.ResourceMethodInvocationHandlerFactory$1.invoke(ResourceMethodInvocationHandlerFactory.java:81)
at org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher$1.run(AbstractJavaResourceMethodDispatcher.java:144)
at org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher.invoke(AbstractJavaResourceMethodDispatcher.java:161)
at org.glassfish.jersey.server.model.internal.JavaResourceMethodDispatcherProvider$TypeOutInvoker.doDispatch(JavaResourceMethodDispatcherProvider.java:205)
at org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher.dispatch(AbstractJavaResourceMethodDispatcher.java:99)
at org.glassfish.jersey.server.model.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:389)
at org.glassfish.jersey.server.model.ResourceMethodInvoker.apply(ResourceMethodInvoker.java:347)
at org.glassfish.jersey.server.model.ResourceMethodInvoker.apply(ResourceMethodInvoker.java:102)
at org.glassfish.jersey.server.ServerRuntime$2.run(ServerRuntime.java:326)
at org.glassfish.jersey.internal.Errors$1.call(Errors.java:271)
at org.glassfish.jersey.internal.Errors$1.call(Errors.java:267)
at org.glassfish.jersey.internal.Errors.process(Errors.java:315)
at org.glassfish.jersey.internal.Errors.process(Errors.java:297)
at org.glassfish.jersey.internal.Errors.process(Errors.java:267)
at org.glassfish.jersey.process.internal.RequestScope.runInScope(RequestScope.java:317)
at org.glassfish.jersey.server.ServerRuntime.process(ServerRuntime.java:305)
at org.glassfish.jersey.server.ApplicationHandler.handle(ApplicationHandler.java:1154)
at org.glassfish.jersey.servlet.WebComponent.serviceImpl(WebComponent.java:473)
at org.glassfish.jersey.servlet.WebComponent.service(WebComponent.java:427)
at org.glassfish.jersey.servlet.ServletContainer.service(ServletContainer.java:388)
at org.glassfish.jersey.servlet.ServletContainer.service(ServletContainer.java:341)
at org.glassfish.jersey.servlet.ServletContainer.service(ServletContainer.java:228)
at weblogic.servlet.internal.StubSecurityHelper$ServletServiceAction.run(StubSecurityHelper.java:295)
at weblogic.servlet.internal.StubSecurityHelper$ServletServiceAction.run(StubSecurityHelper.java:260)
at weblogic.servlet.internal.StubSecurityHelper.invokeServlet(StubSecurityHelper.java:137)
at weblogic.servlet.internal.ServletStubImpl.execute(ServletStubImpl.java:353)
at weblogic.servlet.internal.TailFilter.doFilter(TailFilter.java:25)
at weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:78)
at com.foo.bar.foobar.service.rest.InboxServletHandler.doFilter(InboxServletHandler.java:50)
at weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:78)
at weblogic.servlet.internal.WebAppServletContext$ServletInvocationAction.wrapRun(WebAppServletContext.java:3797)
at weblogic.servlet.internal.WebAppServletContext$ServletInvocationAction.run(WebAppServletContext.java:3763)
at weblogic.security.acl.internal.AuthenticatedSubject.doAs(AuthenticatedSubject.java:344)
at weblogic.security.service.SecurityManager.runAsForUserCode(SecurityManager.java:197)
at weblogic.servlet.provider.WlsSecurityProvider.runAsForUserCode(WlsSecurityProvider.java:203)
at weblogic.servlet.provider.WlsSubjectHandle.run(WlsSubjectHandle.java:71)
at weblogic.servlet.internal.WebAppServletContext.doSecuredExecute(WebAppServletContext.java:2451)
at weblogic.servlet.internal.WebAppServletContext.securedExecute(WebAppServletContext.java:2299)
at weblogic.servlet.internal.WebAppServletContext.execute(WebAppServletContext.java:2277)
at weblogic.servlet.internal.ServletRequestImpl.runInternal(ServletRequestImpl.java:1720)
at weblogic.servlet.internal.ServletRequestImpl.run(ServletRequestImpl.java:1680)
at weblogic.servlet.provider.ContainerSupportProviderImpl$WlsRequestExecutor.run(ContainerSupportProviderImpl.java:272)
at weblogic.invocation.ComponentInvocationContextManager._runAs(ComponentInvocationContextManager.java:352)
at weblogic.invocation.ComponentInvocationContextManager.runAs(ComponentInvocationContextManager.java:337)
at weblogic.work.LivePartitionUtility.doRunWorkUnderContext(LivePartitionUtility.java:57)
at weblogic.work.PartitionUtility.runWorkUnderContext(PartitionUtility.java:41)
at weblogic.work.SelfTuningWorkManagerImpl.runWorkUnderContext(SelfTuningWorkManagerImpl.java:655)
at weblogic.work.ExecuteThread.execute(ExecuteThread.java:420)
at weblogic.work.ExecuteThread.run(ExecuteThread.java:360)
>
From the docs, EJB's remote interface to access the data serializes the in/out parameters, which nulls out all the instrumentation EclipseLink needs to fetch a lazy relationship. This might have worked previously if your access points were local, as I believe some containers don't always serialize the data to/from remote EJBs if they are within the same app, but should not have been expected to work.
You will need to use a local interface if it is local, or prefetch the data before returning it.

NiFi v1.7.1 : java.lang.reflect.InvocationTargetException:null Error for custom processor

I have created a Custom processor to use AWS Encryption SDK as a separate processor in NiFi version 1.7.1
I have implemented Abstract class with required Properties and createClient functions and processor main class with getSupportedPropertyDescriptors, onTrigger funtions.
But when I am trying to run the processor it gives below error:-
2018-08-15 23:15:39,732 ERROR [Timer-Driven Process Thread-5] o.a.n.p.a.encryption.EncryptorProcessor EncryptorProcessor[id=3eaf70a8-0165-1000-a4d1-6cfa42125382] Failed to properly initialize Processor. If still scheduled to run, NiFi will attempt to initialize and run the Processor again after the 'Administrative Yield Duration' has elapsed. Failure is due to java.lang.reflect.InvocationTargetException: java.lang.reflect.InvocationTargetException
java.lang.reflect.InvocationTargetException: null
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at org.apache.nifi.util.ReflectionUtils.invokeMethodsWithAnnotations(ReflectionUtils.java:142)
at org.apache.nifi.util.ReflectionUtils.invokeMethodsWithAnnotations(ReflectionUtils.java:130)
at org.apache.nifi.util.ReflectionUtils.invokeMethodsWithAnnotations(ReflectionUtils.java:75)
at org.apache.nifi.util.ReflectionUtils.invokeMethodsWithAnnotation(ReflectionUtils.java:52)
at org.apache.nifi.controller.StandardProcessorNode.lambda$initiateStart$4(StandardProcessorNode.java:1499)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180)
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)
Caused by: java.lang.NullPointerException: null
at org.apache.nifi.processors.aws.AbstractAWSProcessor.createConfiguration(AbstractAWSProcessor.java:221)
at org.apache.nifi.processors.aws.AbstractAWSProcessor.onScheduled(AbstractAWSProcessor.java:268)
at org.apache.nifi.processors.aws.AbstractAWSCredentialsProviderProcessor.onScheduled(AbstractAWSCredentialsProviderProcessor.java:65)
... 15 common frames omitted
Versions:-
AWS Encryption SDK version - 1.3.1
Nifi Version - 1.7.1
Bouncy castle dependency version - 1.59
CodeBase outline:
AbstractProcessor:
Has necessary properties declaration
Client creation overloaded functions
ProcessorClass:
init function
onTrigger function with actual Encryptiop SDK Code.
Any help would be appreciated!

Jboss Datagrid server leveldb cache lock - Resource temporarily unavailable

I am running 2 instances of Jboss Datagrid server in RHEL in distributed mode. I am using leveldb cache store as my level 2 cache. Both of these instance should use the same leveldb cache store path and should write the key/value to this path.
/shared/usr/local/leveldb.
here is my configuration
(There is a softlink created inside the data directory so that the leveldb path is pointed to the same shared directory in both servers).
I am getting the following error on the second instance (first instance is comping up without any issues). I am using shared="true" in the configuration which should allow both datagrid servers to access the same cache store.
2016-12-05 13:15:19,077 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-5) MSC000001: Failed to start service jboss.datagrid-infinispan.clustered.mycache: org.jboss.msc.service.StartException in service jboss.datagrid-infinispan.clustered.mycache: Failed to start service
at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1904)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
Caused by: org.infinispan.commons.CacheException: Unable to invoke method public void org.infinispan.persistence.manager.PersistenceManagerImpl.start() on object of type PersistenceManagerImpl
at org.infinispan.commons.util.ReflectionUtil.invokeAccessibly(ReflectionUtil.java:172)
at org.infinispan.factories.AbstractComponentRegistry$PrioritizedMethod.invoke(AbstractComponentRegistry.java:864)
at org.infinispan.factories.AbstractComponentRegistry.invokeStartMethods(AbstractComponentRegistry.java:633)
at org.infinispan.factories.AbstractComponentRegistry.internalStart(AbstractComponentRegistry.java:622)
at org.infinispan.factories.AbstractComponentRegistry.start(AbstractComponentRegistry.java:547)
at org.infinispan.factories.ComponentRegistry.start(ComponentRegistry.java:238)
at org.infinispan.cache.impl.CacheImpl.start(CacheImpl.java:877)
at org.infinispan.manager.DefaultCacheManager.wireAndStartCache(DefaultCacheManager.java:637)
at org.infinispan.manager.DefaultCacheManager.createCache(DefaultCacheManager.java:587)
at org.infinispan.manager.DefaultCacheManager.getCache(DefaultCacheManager.java:452)
at org.infinispan.manager.impl.AbstractDelegatingEmbeddedCacheManager.getCache(AbstractDelegatingEmbeddedCacheManager.java:133)
at org.infinispan.server.infinispan.SecurityActions$5.run(SecurityActions.java:130)
at org.infinispan.server.infinispan.SecurityActions$5.run(SecurityActions.java:127)
at org.infinispan.security.Security.doPrivileged(Security.java:76)
at org.infinispan.server.infinispan.SecurityActions.doPrivileged(SecurityActions.java:63)
at org.infinispan.server.infinispan.SecurityActions.startCache(SecurityActions.java:135)
at org.jboss.as.clustering.infinispan.subsystem.CacheService.start(CacheService.java:86)
at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948)
at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881)
... 3 more
Caused by: org.infinispan.commons.CacheException: Unable to start cache loaders
at org.infinispan.persistence.manager.PersistenceManagerImpl.start(PersistenceManagerImpl.java:174)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at org.infinispan.commons.util.ReflectionUtil.invokeAccessibly(ReflectionUtil.java:168)
... 21 more
Caused by: org.infinispan.commons.CacheConfigurationException: Unable to open database
at org.infinispan.persistence.leveldb.LevelDBStore.start(LevelDBStore.java:108)
at org.infinispan.persistence.manager.PersistenceManagerImpl.start(PersistenceManagerImpl.java:141)
... 26 more
Caused by: org.fusesource.leveldbjni.internal.NativeDB$DBException: IO error: lock /shared/usr/local/leveldb/data/mycache/LOCK: Resource temporarily unavailable
at org.fusesource.leveldbjni.internal.NativeDB.checkStatus(NativeDB.java:200)
at org.fusesource.leveldbjni.internal.NativeDB.open(NativeDB.java:218)
at org.fusesource.leveldbjni.JniDBFactory.open(JniDBFactory.java:168)
at org.infinispan.persistence.leveldb.LevelDBStore.openDatabase(LevelDBStore.java:153)
at org.infinispan.persistence.leveldb.LevelDBStore.start(LevelDBStore.java:104)
... 27 more
The LevelDB cache store cannot be shared, because LevelDB itself is not meant to be shared. I've created an issue to ensure that such mistakes can be prevented during configuration validation: https://issues.jboss.org/browse/ISPN-7286

Failed to load jxbrowser in plain OSGi enviroment

I've been using jxbrpowser 6.2 with a trial license. Trying to load it in OSGi enviroment generates the following error:
Exception in thread "JavaFX Application Thread" java.lang.ExceptionInInitializerError
at com.teamdev.jxbrowser.chromium.internal.ipc.IPC.getDefault(Unknown Source)
at com.teamdev.jxbrowser.chromium.BrowserContext.<init>(Unknown Source)
(...)
at com.sun.glass.ui.win.WinApplication$$Lambda$39/30523883.run(Unknown Source)
at java.lang.Thread.run(Thread.java:745)
Caused by: com.teamdev.jxbrowser.chromium.internal.ChromiumExtractorException: Failed to extract chromium binaries into C:\Users\Vladimir\AppData\Local\Temp\jxbrowser-chromium-43.0.2357.52.6.2
at com.teamdev.jxbrowser.chromium.internal.ChromiumExtractor.extract(Unknown Source)
at com.teamdev.jxbrowser.chromium.internal.ipc.IPC.<init>(Unknown Source)
at com.teamdev.jxbrowser.chromium.internal.ipc.IPC.create(Unknown Source)
at com.teamdev.jxbrowser.chromium.internal.ipc.IPC$a.<clinit>(Unknown Source)
... 15 more
Caused by: java.lang.IllegalArgumentException: The /chromium-windows.zip resource cannot be found in JAR files.
at com.teamdev.jxbrowser.chromium.internal.ZIPExtractor.extract(Unknown Source)
at com.teamdev.jxbrowser.chromium.internal.e.run(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
... 19 more
I can successfully load jxbrowser in the non-OSGi environment, as well as in OSGi environment when resources are already extracted.
Is there any way to make jxbrowser successfully extracts the resources from the jar?
It is looking like you don't have a correct OSGI bundle for JxBrowser. As far as I know jxbrowser supports OSGI bundle distribution, you can simply install it into your OSGI container.
Alternatively you can create your own bundle with which is only exports JxBrowser public API, but contains JxBrowser libraries you need. You can automate it with Felix bundle plugin for example http://felix.apache.org/documentation/subprojects/apache-felix-maven-bundle-plugin-bnd.html
In order to make such a bundle working you will need to initialize an temporary browser instance (just create a browser component) inside bundle activator. So that chromium binaries will be extracted when bundle is installed in your OSGi container.

Spring MVC + Dandelion Datables Exception starting filter dandelionFilter

In my Spring MVC application I have used Dandelion Datatables 0.10.1, due to some performance issues I have decided to upgrade the version to 1.0.1 following the official migration guide from:
http://dandelion.github.io/components/datatables/1.0.0/docs/from-0.10.x-to-1.x.html
I have included all the required Maven dependencies, configured the web.xml accordingly to use also the Servlet 3.0 version but when I try to run the appplication I get the following exception during the dandelionFilter loading. Any help is appreciated.
Jul 20, 2015 7:23:08 PM org.apache.catalina.core.StandardContext filterStart
SEVERE: Exception starting filter dandelionFilter
java.lang.NoSuchFieldError: STRICT_DUPLICATE_DETECTION
at com.github.dandelion.core.web.handler.debug.AbstractDebugPage.<clinit>(AbstractDebugPage.java:71)
at com.github.dandelion.core.web.handler.debug.StandardDebugMenu.getPages(StandardDebugMenu.java:45)
at com.github.dandelion.core.Context.initDebugMenus(Context.java:574)
at com.github.dandelion.core.Context.init(Context.java:156)
at com.github.dandelion.core.Context.<init>(Context.java:127)
at com.github.dandelion.core.web.DandelionFilter.init(DandelionFilter.java:96)
at org.apache.catalina.core.ApplicationFilterConfig.initFilter(ApplicationFilterConfig.java:281)
at org.apache.catalina.core.ApplicationFilterConfig.getFilter(ApplicationFilterConfig.java:262)
at org.apache.catalina.core.ApplicationFilterConfig.<init>(ApplicationFilterConfig.java:107)
at org.apache.catalina.core.StandardContext.filterStart(StandardContext.java:4775)
at org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5452)
at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150)
at org.apache.catalina.core.ContainerBase$StartChild.call(ContainerBase.java:1559)
at org.apache.catalina.core.ContainerBase$StartChild.call(ContainerBase.java:1549)
at java.util.concurrent.FutureTask.run(FutureTask.java:262)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:745)
The strict duplication detection feature was added in Jackson-Core 2.3. See http://fasterxml.github.io/jackson-core/javadoc/2.3.0/com/fasterxml/jackson/core/JsonParser.Feature.html#STRICT_DUPLICATE_DETECTION
If possible, you should update this dependency to v2.3.x minimum.

Resources