My project references the following Jar's and I am wondering whether these are the correct Jars for my version of WWildFly Full 10.0.0.Final (WildFly Core 2.0.10.Final).
jboss-servlet-api_3.1_spec-1.0.0.Final.jar
jboss-ejb3-ext-api-2.2.0.Final.jar
jboss-ejb-api_3.2_spec-1.0.0.Final.jar
jboss-jsp-api_2.3_spec-1.0.1.Final.jar
Are these needed for Wildfly or are these the correct ones for WWildFly Full 10.0.0.Final (WildFly Core 2.0.10.Final)?
These version of jar will work with WildFly-10 release without any issue.
Related
in apache nifi 1.10 source code, i can find PutDruidRecord code in
nifi-nar-bundles/nifi-druid-bundle/nifi-druid-processors/src/main/java/org/apache/nifi/processors/druid/PutDruidRecord.java
However, i can't find this processor in nifi 1.10 ui
nifi canvas
Any one can advise?
Out of Apache NiFi's Migration Guidance:
We've removed the following nars from the default convenience binary. These include kite-nar, kafka-0-8-nar, flume-nar, media-nar, druid-controller-service-api-nar, druid-nar, other-graph-services-nar. You can still get them from the various artifact repositories and use them in your flows but we cannot bundle them due to space limitations by default.
I am using api-ldap-client-all-1.0.0-M28.jar as maven dependency in my project. Now api-ldap-client-all-1.0.0-M28.jar internally uses mina-core 2.0.7 version which has 100% CPU usage issues (DIRMINA-988, DIRMINA-1001) which are resolved in latest version(2.0.13) of mina-core. Now I want to update api-ldap-client-all-1.0.0-M28.jar with mina-core 2.0.13. What will be the procedure to do that?
Validation framework which has been rolled up as part of the JEE6 spec (WL12). Both the WL10 and WL12 versions of our application were deployed with the following open source libraries:
JSR-303 / validation-api.jar (version 1.0)
Hibernate Validator (version 4.2.0)
However, the libraries are also bundled with WL 12 (modules directory). Note that the Hibernate Validator version is slightly different.
modules.javax.validation_1.0.0.jar
hibernate.validator_4.1.0.jar
With our WL12 run we are getting below exception:
javax.validation.ValidationException: Unable to get available provider
Attempted Solutions
Our next attempt was to use the WebLogic FilteringClassLoader to prefer the libraries from our application (APP-INF/lib directory) by specifying them in the weblogic-application.xml file (i.e. choose our versions over WebLogic’s). We were already doing this for several other open source libraries in WL10:
<prefer-application-packages>
<package-name>com.google.common.*</package-name>
<package-name>org.apache.commons.lang.*</package-name>
<package-name>org.apache.commons.logging.*</package-name>
<package-name>org.apache.commons.beanutils.*</package-name>
<package-name>org.apache.commons.collections.*</package-name>
<package-name>antlr.*</package-name>
<package-name>javax.validation.*</package-name>
<package-name>org.hibernate.validator.*</package-name>
</prefer-application-packages>
After making that change, our application experienced the following run-time error trying to process any request that makes use of the validation framework:
javax.validation.ValidationException: Unable to get available provider resolvers.
at javax.validation.Validation$GenericBootstrapImpl.configure(Validation.java:259)
at web20.hibernate.validation.ValidatorFactoryConfigurator.getValidatorFactory(ValidatorFactoryConfigurator.java:39)
at web20.hibernate.validation.ValidationHandlerImpl.handleHibernateValidations(ValidationHandlerImpl.java:180)
at web20.hibernate.validation.ValidationHandlerImpl.performValidation(ValidationHandlerImpl.java:255)
at web20.hibernate.validation.ValidationHandlerImpl.validateAndFormatMessages(ValidationHandlerImpl.java:302)
at web20.hibernate.validation.ValidationHandlerImpl.validateUsingHibernateGroups(ValidationHandlerImpl.java:113)
at service.serviceapp.performValidations(serviceapp.java:392)
at service.serviceapp.performValidations(serviceapp.java:379)
at service.TransactionalServiceImpl.search(TransactionalServiceImpl.java:300)
Given that Bean Validation is part of the EE standard, I assume there is some code Bean Validation integration code which causes the problem. I see two potential solutions:
Patch the WL instance and upgrade to the Validator version you want to use
Try writing your own ValidationProvider. Internally it could just delegate to the Hibernate Validator classes. If you then add a validation.xml to your application, specifying your custom provider, WL should bootstrap this one. TBH, I don't know whether this will work. There are many unknowns and I don't know enough about the integration of WL and Bean Validation.
Personally, I think I would just try to upgrade the Validator version used in WL.
I deplyed a very simple war on JBoss EAP 6.0.1. The servlet action is ok,but System.out.print wasn't print to the console and server.log file.But System.out.println is working well,and when System.out.print and System.out.println both used,both work well.
I try the following setting,but still cann't make it work.Please help!
JAVA_OPTS="$JAVA_OPTS -Dorg.jboss.logging.Log4jService.catchSystemOut=false"
JAVA_OPTS="$JAVA_OPTS -Dorg.jboss.as.logging.per-deployment=false"
I try to add jboss-deployment-structure.xml to WEB-INF to use my own log4j,it doesn't work too.I also try to deploy the war on JBoss AS 7/JBoss EAP 6.1.0,get the same result.
It's a bug???
It doesn't really make sense that System.out.println would work, but System.out.print wouldn't. It should be printing to both the console and server.log assuming the default configuration.
The -Dorg.jboss.logging.Log4jService.catchSystemOut=false won't do anything since JBoss AS 7 doesn't use log4j. Also the -Dorg.jboss.as.logging.per-deployment=false only works on EAP 6.x, WildFly or builds off of the JBoss AS 7.1.3+ tags.
My application using tapestry 4.1.6 jar files deploys correctly in weblogic 10.3.3.0. But at runtime, I am getting NoSuchMethodException from tapestry files.Same application works fine in weblogic 9. Any ideas?
Error Log
java.lang.NoSuchMethodError: org.apache.commons.pool.impl.TapestryKeyedObjectPool.assertOpen()V
at org.apache.commons.pool.impl.TapestryKeyedObjectPool.borrowObject(TapestryKeyedObjectPool.java:941)
at org.apache.tapestry.pageload.PageSource.getPage(PageSource.java:176)
at $IPageSource_12bf9e5c33a.getPage($IPageSource_12bf9e5c33a.java)
at org.apache.tapestry.engine.RequestCycle.loadPage(RequestCycle.java:241)
at org.apache.tapestry.engine.RequestCycle.getPage(RequestCycle.java:228)
at org.apache.tapestry.engine.DirectService.service(DirectService.java:107)
at $IEngineService_12bf9e5c3ad.service($IEngineService_12bf9e5c3ad.java)
at org.apache.tapestry.services.impl.EngineServiceInnerProxy.service(EngineServiceInnerProxy.java:77)
at org.apache.tapestry.services.impl.EngineServiceOuterProxy.service(EngineServiceOuterProxy.java:72)
at org.apache.tapestry.engine.AbstractEngine.service(AbstractEngine.java:241)
at org.apache.tapestry.services.impl.InvokeEngineTerminator.service(InvokeEngineTerminator.java:54)
at $WebRequestServicer_12bf9e5c384.service($WebRequestServicer_12bf9e5c384.java)
at $WebRequestServicer_12bf9e5c380.service($WebRequestServicer_12bf9e5c380.java)
at org.apache.tapestry.services.impl.WebRequestServicerPipelineBridge.service(WebRequestServicerPipelineBridge.java:61)
at $ServletRequestServicer_12bf9e5c366.service($ServletRequestServicer_12bf9e5c366.java)
at org.apache.tapestry.request.DecodedRequestInjector.service(DecodedRequestInjector.java:55)
at $ServletRequestServicerFilter_12bf9e5c362.service($ServletRequestServicerFilter_12bf9e5c362.java)
at $ServletRequestServicer_12bf9e5c368.service($ServletRequestServicer_12bf9e5c368.java)
at org.apache.tapestry.multipart.MultipartDecoderFilter.service(MultipartDecoderFilter.java:52)
at $ServletRequestServicerFilter_12bf9e5c360.service($ServletRequestServicerFilter_12bf9e5c360.java)
at $ServletRequestServicer_12bf9e5c368.service($ServletRequestServicer_12bf9e5c368.java)
at org.apache.tapestry.services.impl.SetupRequestEncoding.service(SetupRequestEncoding.java:53)
I'd check to see if WebLogic 10.3 has a conflicting Tapestry JAR at the server class loader level. If yes, you'll want to tell WebLogic to prefer the version of Tapestry that it finds using your application class loader.
See <prefer-web-inf-classes> in weblogic.xml:
http://download.oracle.com/docs/cd/E12840_01/wls/docs103/programming/classloading.html
Note: Weblogic is often configured by default, it filters javax.* package. (X Add J2EE libraries to buildpath)