Ｉam using jboss fuse63 on eap6.4, to make camel context defined with spring DSL run after deploying the camel app as war, I have to use a listener class in web.xml, and use the listener class to start camel context as the following:
ApplicationContext contextCommon = new FileSystemXmlApplicationContext("camel-context-common.xml");
DefaultCamelContext camelContextCommon = (DefaultCamelContext)contextCommon.getBean("_camelContext_common");
try {
camelContextCommon.start();
...
The abstract of my spring DSL is as the following(autoStartup="true" is defined):
<beans ...">
<bean class="test.CommonProcessor" id="commProcessor"/>
<camelContext autoStartup="true" id="_camelContext_common"
shutdownRunningTask="CompleteAllTasks" xmlns="http://camel.apache.org/schema/spring">
Is there a way to make camel context run automatically on eap without using java code to start it?
Best regards
Yes, there is easy way. You have to correctly name your Spring XML file which contains Camel route. The file naming convention requires to include the -camel-context.xml suffix.
In your case, rename camel-context-common.xml file to common-camel-context.xml. If you do that then Camel subsystem will automatically start up camel contexts.
Yes, there is a great way to do this. Use the Wildfly-Camel subsystem and the very handy quickstarts for examples.
If you are using productised versions, you can use Fuse/EAP for this.
Good Luck,
Rick
Related
I am refactoring a JEE REST (using JAX-RS 2.0) application as a Spring Boot application. My old app is packaged in a .war and has a jar file with entities and the persistence.xml configuration file for JPA. This jar is copied into WEB-INF/lib directory. I know Spring JPA works a different way and I don't use persistence.xml now but I wonder if I can package my JPA entity classes in a jar and include them in my Spring Boot apps just like I am doing now. This way I can easily reuse that jar in different Spring Boot Applications.
I'm pretty certain you can do this since I have done the same on one of my projects very recently. The only thing you need to do is make sure that you add an #EntityScan annotation on your main Spring Boot config class with the base package of your entities in the JAR.
#EntityScan("my.external.jar.entity.package")
Spring Boot doesn't really care whether the JPA entities are packages as a separate jar or included into the application. Its a runtime framework and in runtime classes can be loaded from the jar (it should reside in BOOT-INF/lib or 'directly' from the *.class files in the spring boot artifact.
Now there is a rule in spring boot, that says that it will scan for beans (including entities) only in the package where your "main" class resides or under it. This is done in order to avoid long process of analysis of, say, third-party classes that you might use. These third-party classes are usually not spring aware at all, at certainly do not contain any spring beans.
Example:
Say, you place your "main" class (the one annotated with #SpringBootApplication) in the package: com.mycompany.myapp
In this case, the following packages will be scanned (just a couple of examples):
com.mycompany.myapp
com.mycompany.myapp.web
com.mycompany.myapp.services.bl
com.mycompany.myapp.whatever.doesnt.matter
...
The following packages won't be scanned however (again, examples, not the full list):
com.mycompany
com.anothercompany
org.hibernate
If you want to to "alter" this default rule and place the entities in the package that doesn't adhere this convention, for example com.mycompany.jpa.entities then you should indeed use #EntityScan annotation as our colleagues have already suggested.
You can read about this topic here. You might also need to get familiar with #EnableJpaRepositories if you're using spring data but, while related, its a different topic.
In my case I had this problem, and after importing the library in the application's pom.xml, in the SpringBoot Project Main class, insert an #EntityScan annotation with the first package and *. Like this: #EntityScan ("br.*")
I am using spring aop and have defined some aspects. Spring LTW is enabled on my tomcat.
In my application context:
<context:load-time-weaver/>
<aop:aspectj-autoproxy proxy-target-class="false"/>
Aspects are working fine too! but the target class is proxied! causing ClassCastException: can not convert $Proxy...
Note that I don't my target classes to be proxied!
If you are using AspectJ LTW you only need the tag
<context:load-time-weaver/>
in your Spring context file. So you can remove,
<aop:aspectj-autoproxy proxy-target-class="false"/>
If the target class is proxied is because LTW with AspectJ is not configured in a good way, for this reason is not AspectJ who is handling your advices, and is Spring who is doing that. For this reason you see proxy based target class.
Check this links,
http://static.springsource.org/spring/docs/3.2.2.RELEASE/spring-framework-reference/html/aop.html#aop-aj-ltw
http://static.springsource.org/spring/docs/3.2.2.RELEASE/spring-framework-reference/html/aop.html#aop-aj-ltw-environments
I've searched for an answer to my problem on google and various forums, but couldn't find a solution. I'm currently trying to modify the persistence.xml at runtime by adding a persistence unit to the file.
The solutions for this question were always "pass a Map of properties when creating an EntityManagerFactory (or EntityManager)" but i need to save the new persistence unit in the persistence.xml, because the application is going to have 100 or even more persistence unit's, one for each tenant that will register to the service, each tenant will have his own database. I'm currently using EclipseLink 2.3.3 as my JPA implementation, EJB 3.1 and jboss 7.1.1.Final as my application server.
Is it possible to modify the persistence.xml at runtime (on the fly)?
The persistence.xml is a deployed artifact, so would be difficult to modify at runtime. I think passing a properties map to createEntityManagerFactory is your best solution, what issue are you having with this?
You may also want to try using the PersistenceProvider API, createContainerEntityManagerFactory() that takes a PersistenceUnitInfo.
Also, consider using EclipseLink's multi-tenant support,
http://www.eclipse.org/eclipselink/documentation/2.5/solutions/multitenancy.htm
I want to test an enterprise java bean (that should later be deployed to a JBoss server) using JUnit. But I don't exactly know how tools I can use for this. Plain JUnit fails because of the missing EJB Container and the caused lack of needed injections.
Googling a bit around lead me to a library called JBoss EJB embedded container, but it seems that it is obsolete. I also couldn't find any source or binary files to download.
So please help, what's a easy way to locally generate a "mock" container that is able to run the JUnit tests on the enterprise beans?
Greetings
Ben
I suggest you to have a look at Arquillian:
Arquillian enables you to test your business logic in a remote or embedded container. Alternatively, it can deploy an archive to the container so the test can interact as a remote client.
There is still a living Embedded JBoss AS. The Seam Framework also provides a testing environment with an embedded JBoss to run component tests (with TestNG) of your application.
openEJB is an embedded EJB container that's a perfect fit for unit testing EJBs. You can test them outside your normal app server. And, it's fast! And, it spins up fast! And, it has an Eclipse plugin for easy management! Gotta love it! It's been around for a while, there are plenty of tutorials on how to set it up and use it, so you shouldn't have problems with it.
You can use a EJB remote client in your JUnit program to test your EJB. Only drawback is that you have to have a running Application Server during testing.
Check out this blog entry for an example on how to invoke a EJB remotely.
It's been awhile, but I always wrote my EJBs as simple wrappers of POJOs. An interface would define the methods, and both the POJO and the EJB (session, of course) would implement that interface.
I could fully test the "business logic" of the POJOs without any container issues. Then if I had the server running, I could run the same tests against the session bean, just by testing against the client instead of the POJO...
Since I did not need the JNDI stuff (e.g. Cannot instantiate class: org.jnp.interfaces.NamingContextFactory) altogether in my DAO (ORM interface) tests it was enough for me to
include the hibernate jars in the classpath
remove/outcomment the <jta-data-source>...</jta-data-source> part in my persistence.xml
inject/assign your own entitymanagerfactory with Persistence.createEntityManagerFactory( "my-persistence-unit-name" )
I typically use groovy to construct simple bean but the Spring IDE plugin to eclipse fails to build when I try to set a property that is generated by groovy without an explicit setter. For example,
class MyGrooyClass {
def propertyA
}
and in the spring configuration file I have something that looks like:
<bean id="MyGroovyClassBean" class="MyGroovyClass">
<property name="propertyA" value="someValue"/>
</bean>
The spring builder says there is no such property but it is in the bytecode since it is automatically generated by groovy. If I don't validate that bean, everything works, so spring can resolve the property, but it seems to be an issue with the plugin. Is there a way to work around this or to disable validating a particular bean?
EDIT: I can construct the bean using the groovy specific syntax
<lang:groovy id="..." script-source="...">
<lang:property name="propertyA" value="someValue"/>
</lang>
but it seems odd that I should need to do this just for the plugin.
Thanks,
Jeff
It definitely looks like a bug in the Spring IDE plugin. I've also had issues where the content assist does not show auto-complete for properties of a Groovy bean.
I see the same issue in the project I am working on. Consequently I do not use the Spring Validator.
As confirmed by Chris Dail, this is a bug in the Spring IDE plugin. I posted it in the Spring forums http://forum.springsource.org/showthread.php?p=271607&posted=1#post271607 and it has been fixed in the nightly build.