I'm using Spring 3.0.5, and was wondering if it's possible, to somehow exclude aspect classes from being loaded that have been annotated with the #Aspect stereotype, but at the same time, include other aspect annotated classes? It seems to be an all or nothing if you're going the annotation route(which I am) I've tried looking at the and but can;t seem to find anything that hints at this.
The reason for this is that I have a central core library which contains aspects, but I may not want to include these aspects in every project I create using this central library.
Thanks.
This is a long time for an answer...
If you are using AspectJ annotations with Spring AOP and not AspectJ runtime or compile-time weaving then you're in luck. Spring will only pick up #Aspect annotated classes if they're annotated with something like #Component as well. Spring does not consider #Aspect a candidate for component scanning. If you're using XML configuration, simply remove that bean from your config.
I would suggest NOT using component scanning that would hit a core library. For example, if your app is com.example.myapp1 and your core library is com.example.corelibrary.* make sure your component scanning is looking at com.example.myapp1 ONLY and not com.example.
It is not safe to component scan outside of your app's base package because of this exact reason. Pull in the individual aspects with an XML config for the bean.
Related
I want to implement some content-caching on my Camel 2.23.2 routes. While researching I came across Camel's JCache component which, according to the documentation, should have a JCachePolicy that would:
"The JCachePolicy is an interceptor around a route that caches the "result of the route" - the message body - after the route is completed. If next time the route is called with a "similar" Exchange, the cached value is used on the Exchange instead of executing the route."
Which is basically exactly what I'm looking for. However, as it turns out this policy is only available in Camel 3.x and higher.
So my question is, how might I recreate this functionality in Camel 2.23.2?
The solution was quite simple. In the Camel 3.x branch the policy package is available and in it are only two files. The actual policy and the processor.
As it turns out, pending more testing, these files work very well with little adjustment.
On the policy you need to change the method definition for the "wrap" and "beforeWrap" methods. These require the routeContext, not the Route. But moving from the RouteContext to the route is simple enough.
On the processor, the main change is using the correct package for "DelegateAsyncProcessor" it extends.
With those changes everything seemingly works as documented. I used the ehcache spring boot starter in my pom without any further change to have it work with ehcache as it's cachemanager.
One other remark, when you want to use this, the model you want to cache needs to be serializable.
I want to know what is Route-builders in Apache camel? And why is it used for?
I have a project where JMS and apache camel are used but i dont know what is routebuilder.
In advance: I am not 100% sure about the long answer, so please correct me if I am fundamentally wrong here!
Short:
The basic definition given by the official apache camel docu states:
The RouteBuilder is a base class which is derived from to create
routing rules using the DSL. Instances of RouteBuilder are then added
to the CamelContext.
Long:
Routebuilder is an abstract class. When implementing your own route, you usually extend from that RouteBuilder class (as the citation above already stated).
As a consequence you must implement the method configure() in which you implement the route (from()/.to()/.process() etc.)
I am pretty sure it is possible to implement a route without extending RouteBuilder, but then you would have to rebuild the framework given by apache camel. The whole syntax (from()/.to()/.process() etc.) for implementing routes is provided by extending Routebuilder class.
Apache Camel is a framework. In order to use the framework your "route class" must inherit from the base classes of the given framework. Otherwise you would not be able use the framework, which already offers a huge part of the implementation.
If Claus Ibsen answers your question, stick to his answer, he knows virtually everything about apache camel.
Application depends on a number of spring data projects including Neo4j, Solr and Jpa. I recently had to update spring-data-solr to Snapshot-3.0.0.M1 (to eliminate another dependency conflict). I think one of the transitive dependency is causing a conflict with neo4j. If I remove spring-neo4j from project, error (see below) seem to go away.
I have a attached a sample project that recreates the issue. Run Test Class AccountServiceJpaTester.testSaveAccount()
Download sample project from here
Caused by: org.springframework.beans.factory.NoSuchBeanDefinitionException: No qualifying bean of type 'java.lang.Class>' available: expected at least 1 bean which qualifies as autowire candidate. Dependency annotations: {}
at org.springframework.beans.factory.support.DefaultListableBeanFactory.raiseNoMatchingBeanFound(DefaultListableBeanFactory.java:1456)
at org.springframework.beans.factory.support.DefaultListableBeanFactory.doResolveDependency(DefaultListableBeanFactory.java:1087)
at org.springframework.beans.factory.support.DefaultListableBeanFactory.resolveDependency(DefaultListableBeanFactory.java:1049)
at org.springframework.beans.factory.support.ConstructorResolver.resolveAutowiredArgument(ConstructorResolver.java:833)
at org.springframework.beans.factory.support.ConstructorResolver.createArgumentArray(ConstructorResolver.java:740)
... 60 more
Spring data projects are all based on a common infrastructure (spring data commons).
If you use several projects in the spring data family (in your case neo4j, solr, jpa), you have to make sure they are all based on a common version of the infrastructure.
In your case, spring-data-solr 3.0.0 M1 is based on spring-data-commons 2.x whereas JPA and Neo4j use spring-data-commons 1.x.
A good way of managing this is to use the spring data BOM. This is explained on the spring data homepage.
To manage the portfolio, a BOM (Bill of Materials - see this example) is published with a curated set of dependencies on the individual project
If you need to update to newer versions than the ones included in the BOM, make sure they are based on the same infrastructure version.
i tried to have aspectj for camel processor, but it is not working. My pointcut is below:
#Around("execution(* org.apache.camel.processor.UnmarshalProcessor.*(..))")
Will it possible to do aspect for camel processor?? if yes, help.
Yes, you can if you put the library on the inpath in a compile-time weaving scenario, creating modified versions of the 3rd party class files and using them during runtime.
In a load-time weaving scenario you can also do it dynamically if the weaving agent is loaded before the Camel classes, which should usually be the case.
As a work-around you can change the pointcut type from execution() to call(), intercepting the callers in your own code rather than the callee in the 3rd party library.
So you have at least three options, all of which work with AspectJ (not in an "AOP lite" variant like Spring AOP though).
'org.apache.cxf.tools.wsdlto.WSDLToJava' converts wsdl to java classes.
Is it using JAXB internally?How come this command is able to generate classes like how 'xjc' creates?Can somebody explain me how it works?
CXF uses xjc internally for code generation.
Refer to following for more information (from CXF official page)
In CXF versions prior to 2.3.0, the xjc plugins were shaded directly into the big cxf bundle jar. In 2.3.0, they were removed from the jar and are placed individually into the lib directory of the distribution. The xjc plugins are only code generation utilities and not used at all at runtime which is why they were pulled out.
The Apache CXF XJC-Utils subproject provides a bunch of utilities for working with JAXB to generate better or more usable code.
Currently, it consists of the following modules:
cxf-xjc-plugin Provides a maven wrapper around the JAXB XJC utility
cxf-xjc-dv Initialize fields mapped from elements/attributes with their default values
cxf-xjc-ts Implements the toString() method
cxf-xjc-boolean Generate getters named getXXX() for Booleans instead of isXXX()
cxf-xjc-wsdlextension Adds extensions methods to allow generated beans to be used as WSDL4J extensors
cxf-xjc-bug671 Provides a workaround for https://jaxb.dev.java.net/issues/show_bug.cgi?id=671
- Not needed for JAXB >=2.1.12
WSDL2Java is a command line tool that generates Java classes from an existing WSDL document. Generated classes represent client stubs, server skeletons and data types that will helps you to write client side and server Java programs for Web services defined in the WSDL document.
DEFAULT_FRONTEND_NAME = "jaxws";
DEFAULT_DATABINDING_NAME = "jaxb";
For details,
http://cxf.apache.org/docs/wsdl-to-java.html http://grepcode.com/file/repo1.maven.org/maven2/org.apache.cxf/cxf-bundle/2.0.6/org/apache/cxf/tools/wsdlto/WSDLToJava.java