Weblogic 12c HibernateValidator ClassLoading issue - weblogic

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.

Related

Hibernate IllegalArgumentException persistence.xml does not exist - unit test without persistence.xml

I am using OpenEJB in some unit (integration) tests for my database module, following this example here: http://tomee.apache.org/examples-trunk/application-composer/README.html
I am using an #Module annotation to provide PersistenceUnit java object as opposed to a 'test' persistence.xml file and I am overriding the provider to use hibernate (for specific reasons) as below.
unit.setProvider(org.hibernate.jpa.HibernatePersistenceProvider.class);
Using version 4.2.11.Final version of Hibernate this works fine, but in upgrading to 4.3.8.Final i am now getting an IllegalArgumentException stating that no persistence.xml exists.
Caused by: java.lang.IllegalArgumentException: File [FullParthToMyJar.jar:file:FullParthToMyJar.jar!/META-INF/persistence.xml] referenced by given URL [file:FullParthToMyJar/jar:file:FullParthToMyJar.jar!/META-INF/persistence.xml] does not exist
Is there anyway to stop this scanning from occuring as my project maven enforcer plugin is forcing me to use the later version.
Thanks.
Thanks for your response, but we ended up using a persistence.xml file to avoid losing time, which fixed the issue.

Defining userDao in AppFuse 3.5

I am following the tutorials on http://appfuse.org/display/APF/Tutorials and I am confused on the "Register a personDao bean definition" section.
If it is necessary to register dao beans in the applicationContext.xml (or in applicationContext-dao.xml as I have seen it in an older version of an AppFuse application that I've been working with)... why is it not necessary to also register the userDao bean in the same way?
I have an alternate motive for asking this question as well...
I've been trying to port an application from an older version of the AppFuse framework (same application I mentioned above). But when I attempt to navigate to any page other than the ones that come with the original code, I get "Page not found" errors. Which is why I have gone back to the tutorials... I really want to get a handle on this since I am taking over someone else's code and they are no longer available for comment.
In addition, when adding the personDao to applicationContext.xml, IDEA complains "Required properties missing: 'sessionFactory'". When adding the line: , it then complains "Cannot resolve bean 'sessionFactory'"
It isn't necessary to register the userDao bean because it's already been done for you. The applicationContext-dao.xml file is included in the appfuse-hibernate (or appfuse-jpa) JAR file and it's imported into tests and in web.xml.
In it, it has the following:
<!-- Activates scanning of #Repository -->
<context:component-scan base-package="org.appfuse.dao"/>
You can see the file online at http://source.appfuse.org/browse/~br=release-3.5.0/appfuse/data/hibernate/src/main/resources/applicationContext-dao.xml?r=7486012b603604294be9384475b3750865c93bb6

Worklight 5.0.5: Loader constraint violation when running Application Builder

during "Build All and Deploy" of a worklight application, I get the following error.
An internal error occurred during: "Worklight application builder".
loader constraint violation: when resolving method "org.apache.commons.io.FileUtils.iterateFiles(Ljava/io/File;Lorg/apache/commons/io/filefilter/IOFileFilter;Lorg/apache/commons/io/filefilter/IOFileFilter;)Ljava/util/Iterator;"
the class loader (instance of org/eclipse/osgi/internal/baseadaptor/DefaultClassLoader)
of the current class, com/worklight/builder/skins/impl/SkinBuilderImpl,
and the class loader (instance of org/eclipse/osgi/internal/baseadaptor/DefaultClassLoader)
for resolved class, org/apache/commons/io/FileUtils,
have different Class objects for the type leUtils.iterateFiles(Ljava/io/File;Lorg/apache/commons/io/filefilter/IOFileFilter;Lorg/apache/commons/io/filefilter/IOFileFilter;)Ljava/util/Iterator;
used in the signature
Console output is
[2013-03-26 15:30:13] Worklight Server started successfully on localhost:8080
[2013-03-26 15:30:13] Activating Worklight project: AA...
[2013-03-26 15:30:28] FWLSE3005I: Application raw reports are disabled.
[2013-03-26 15:30:28] FWLST0010I: ====== Started server for project AA-project-customization; Worklight version=5.0.5.20130115-0926-developer-edition
[2013-03-26 15:30:28] Activation done.
[2013-03-26 15:30:28] Starting build process: application 'ap', all environments
I believe this bug is also discussed in https://www.ibm.com/developerworks/forums/thread.jspa?threadID=465649 (read only)
For me it seems that this bug is pretty well reproducable.
It occurs every time another plugin is installed which contains/uses the org.apache.commons.io package
In my case I have an org.apache.commons.io_2.0.1.v201105210651.jar in my plugins folder (which was delivered by Sonar 2.4.0). It contains the same java classes as plugins\com.worklight.worklight-3rd-parties_5.0.5.20130115-0926\target\dependency.
This is also a matter of ordering, as the error only occurs if Worklight is installed AFTER another org.apache.commons.io-using package was installed.
So I strongly believe that the problem is because there are different classes with the same (package) name (WHY ??)
I thought about setting classloader preferences (parent first etc). but I don´t know how and I don´t know where to set.
Just deleting the 3rd parties .jar´s only leads to other errors ...
Any hints are greatly appreciated.
Thank you very much !
As a workaround, can you try and delete the commons.io plugin from your eclipse?
Hopefully, Sonar is using import-package and not require-bundle, and it will work, and this way Worklight won't have conflicts.

Error Deploying portlets

I am trying to setup some boiler plate code in my local workspace which uses weblogic10.3. I have a documentation that asks me to import Content.jar from /wlportal_10.3/content-mgmt/lib into window->preferences-->Weblogic-->Shared Library which I did. However when I try to deploy portlet this is the error am getting
Error Deployer BEA-149107 An attempt was made to deploy library 'content' with specified specification version '10.3.2' and implementation version '10.3.2 '. However, the library manifest has specification version '10.3.2' and implementation version '10.3.2'

Unable to load proxy factory factory exception

I am having this annoying error while running my Nhibernate project. It was running okey and all of a sudden it just start asking for a file in this path "d:\CSharp\NH\NH\nhibernate\src\NHibernate\Bytecode\AbstractBytecodeProvider.cs" and when cancel, it throws an exception saying it says
Unable to load type 'NHibernate.ByteCode.Castle.ProxyFactoryFactory, NHibernate.ByteCode.Castle' during configuration of proxy factory class.
Possible causes are:
- The NHibernate.Bytecode provider assembly was not deployed.
- The typeName used to initialize the 'proxyfactory.factory_class' property of the session-factory section is not well formed.
Solution:
Confirm that your deployment folder contains one of the following assemblies:
NHibernate.ByteCode.LinFu.dll
NHibernate.ByteCode.Castle.dll
It is become frustrating for me... need help please -:)
Make sure that you have following dlls copied to the output folder and loaded by your process:
NHibernate.ByteCode.Castle.dll
Castle.Core.dll
NHibernate.dll
Iesi.Collections.dll
log4net.dll
And your NHibernate configuration has this line:
<property name="proxyfactory.factory_class">
NHibernate.ByteCode.Castle.ProxyFactoryFactory, NHibernate.ByteCode.Castle
</property>
As an option, you can try to upgrade to latest version of NHibernate - 3.2. They have a built in proxy generator so it should be simpler for you. You will not need these additional dlls. Just remove the config line above if you use NHibernate 3.2.
If for some reasons you can not upgrade to 3.2 you may consider using different byte code providers. NHibernate supports 3 of them out of the box. Try LinFu or Spring:
NHibernate.ByteCode.Castle.ProxyFactoryFactory
NHibernate.ByteCode.LinFu.ProxyFactoryFactory
NHibernate.ByteCode.Spring.ProxyFactoryFactor
Upgrade to the latest version and you will not need an external proxyfactory anymore.