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
Related
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.
I'm triying to run a JavaFX Rest client using CXF. A very simple test. When I try to get an URL I get the org.apache.cxf.BusException: No conduit initiator was found for the namespace http://cxf.apache.org/transports/http. I took a look at some related questions here, but no luck. Any help would be appreciated.
Then only maven dependency I added was cxf-rt-rs-client 3.1.0
The code is:
WebClient client = WebClient.create("http://www.stackoverflow.com");
client.type("text/html").accept("text/html");
System.out.println(client.get());
Stacktrace:
Caused by: org.apache.cxf.BusException: No conduit initiator was found for the namespace http://cxf.apache.org/transports/http.
at org.apache.cxf.bus.managers.ConduitInitiatorManagerImpl.getConduitInitiator(ConduitInitiatorManagerImpl.java:110)
at org.apache.cxf.endpoint.AbstractConduitSelector.getSelectedConduit(AbstractConduitSelector.java:104)
at org.apache.cxf.endpoint.UpfrontConduitSelector.selectConduit(UpfrontConduitSelector.java:77)
at org.apache.cxf.message.ExchangeImpl.getConduit(ExchangeImpl.java:159)
at org.apache.cxf.interceptor.MessageSenderInterceptor.getConduit(MessageSenderInterceptor.java:71)
at org.apache.cxf.interceptor.MessageSenderInterceptor.handleMessage(MessageSenderInterceptor.java:46)
at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:307)
at org.apache.cxf.jaxrs.client.AbstractClient.doRunInterceptorChain(AbstractClient.java:624)
at org.apache.cxf.jaxrs.client.WebClient.doChainedInvocation(WebClient.java:1100)
The shading overwrites bus-extension.txt file. Programmatically your can fix it by initializing it.
void initializeCxf() {
final Bus defaultBus = BusFactory.getDefaultBus();
final ConduitInitiatorManager extension = defaultBus.getExtension(ConduitInitiatorManager.class);
extension.registerConduitInitiator("http://cxf.apache.org/transports/http", new HTTPTransportFactory());
}
Based on the comment by #hba you can also try following in case the above does not work
extension.registerConduitInitiator("http://cxf.apache.org/transports/http", new HTTPTransportFactory(defaultBus));
You are fine with your Maven dependencies.
Client construction looks a bit off per CXF 3.x guides, wherein JAX-RS 2.0 is supported.
See AX-RS 2.0 Client API.
Try this code:
WebTarget target = ClientBuilder.newClient().target("http://stackoverflow.com/");
Response response = target.request().get();
System.out.println(response.getEntity().getClass().getName());
Using this code, you will learn the response entity is an input stream .. a sequence of characters being the HTML content of the StackOverflow home page.
If you're feeling adventurous, and to demonstrate I'm not a charlatan, add the following dependency to your POM:
<dependency>
<groupId>org.apache.commons</groupId>
<artifactId>commons-io</artifactId>
<version>1.3.2</version>
</dependency>
and then attempt this:
WebTarget target = ClientBuilder.newClient().target("http://stackoverflow.com/");
System.out.println(IOUtils.toString((InputStream) target.request().get().getEntity(), "UTF-8"));
You will be rewarded with a textual rendering (on standard output) of the StackOverflow home page – equivalent to performing a "view source" operation in your browser.
I don't know what your ultimate goal is, but if you're attempting to build anything useful from information on the StackExchange network, I suggest use of their APIs documented here.
Best of luck!
I got the same exception when using Apache CXF REST client in JavaFX project. The code is below:
MyClass rest = (MyClass) JAXRSClientFactory.create(endpoint, MyClass.class, Collections.singletonList(new JacksonJsonProvider()));
System.out.println("Service health: " + rest.health());
A test with plain Java project works fine with the same code and same dependencies. It is apparently a conflict between JavaFX and Apache CXF. I am trying to figure out why.
If you guys already solved this issue, that should be great to update this thread, which is the only result on Google search.
Updated solution:
After a while, I found that the default Maven project does not include enough the dependencies in the plugin "maven-dependency-plugin". I tried to add more packages in the list but still not work. So the final solution is in this thread: How to package an Apache CXF application into a monolithic JAR with the Maven "shade" plugin. Shade plugin is much better and works.
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 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.
Trying my hand at CDI for the first time. I'm using Glassfish v3. When I deploy my app, I get the following failure:
java.io.IOException:
com.sun.enterprise.admin.cli.remote.RemoteFailureException:
Exception while loading the app :
org.glassfish.deployment.common.DeploymentException:
java.lang.IncompatibleClassChangeError:
com.example.arizona.client.ArizonaService
and
com.example.arizona.client.ArizonaService$App
disagree on InnerClasses attribute
at
com.fuhrer.idea.glassfish.server.GlassfishServer3.doParseResponse(GlassfishServer3.java:28)
at
com.fuhrer.idea.glassfish.server.GlassfishServer3Base.parseResponse(GlassfishServer3Base.java:156)
at
com.fuhrer.idea.glassfish.server.GlassfishServer3Base.invoke(GlassfishServer3Base.java:127)
at
com.fuhrer.idea.glassfish.server.GlassfishServer3Base.handleDeployment(GlassfishServer3Base.java:78)
at
com.fuhrer.idea.javaee.server.JavaeeServerInstance$2.run(JavaeeServerInstance.java:131)
I should mention that I'm not even actually using injection, or any other CDI features yet. This is just trying to get the dependencies straightened out.
I've had the same issue, but with Weld in Tomcat. Problem for me was caused by changing an inner class definition to a normal class. Resulted, in my case, in having the old innerclass still in the classes directory but with a new parent class.
Cleaning the classes directory worked for me.
Nearly a year later I'm sorry to say that I never solved this, and for various reasons moved on to another stack altogether: Tomcat, Wicket and Wicket-CDI, all of which have worked great for me.