I'm using the cxf-codegen-plugin to generate some classes from a WSDL. After the sources are generated, a bunch of beans get deleted (we don't need them, just the service interfaces), but there is an #XmlSeeAlso annotation in the generated source that references some of these deleted classes. We don't need the #XmlSeeAlso annotation at all, is there a way to tell the cxf-codegen-plugin to exclude certain annotations when generating sources?
I solved this by adding a tag to a maven-antrun-plugin, commenting out all the #XmlSeeAlso instances:
<target>
<replace file="${basedir}/target/generated-sources/x/x/x/Service.java" token="#XmlSeeAlso" value="//#XmlSeeAlso" />
</target>
The idea of generated code is to let it be as it is. The question is why would you like to delete files which i assume is manual work which is in contradiction to the idea of generated code.
Related
Looking for a solution that will provide us more functionality within Spring properties such as:
nested structures
maps/lists
properties referencing other properties. Example:
city.name=Toronto
city.address=#{city.name}, 123 Ave SW
I tried EProperties (Google) and Commons Configurations (Apache) but doesn't seem to integrate very well with the Spring Framework.
Also, we're using Velocity to access properties using #springMessage("city.address"), so it needs to work for that.
Does anyone know how I can achieve the above by extending the default Properties capability?
With newest versions of Spring you can use the PropertySource mechanism. You register all your PropertySource and the order in which they are searched and then you don't have to do anything, except perhaps add this to your XML:
<context:property-placeholder />
As long as you declare only one of these without specifying local property files (the "old way"), you will be able to reference property A as the value of property B, even if they are not in the same property source.
For nested structures this may help if you don't like the properties readability:
https://stackoverflow.com/a/13470704/82609
For parsing problems you can easily handle lists and other stuff like that manually very easily:
Reading a List from properties file and load with spring annotation #Value
Spring-namespaces allows you to define your own structure how spring beans could be configured. Very cool.
I have to use a 3rd party software (Assentis Docbase) which defines in its spring.schemas the following (example below simplified)
http\://com.apress.prospring2/ch07/custom.xsd=custDir:/custom.xsd
Meaning: If user defines in its spring-xml with schema-location: "http://com.apress.prospring2/ch07/custom.xsd" spring will validate this file against custom.xsd.
custDir is a directory OUTSIDE the provided jar. Does anyone have an idea how I can set this custDir to point to a valid path during junit test? I already tried -DcustDir=/pathToXsd/ but it did not work.
If I remove custDir than everything works as expected, but I can not remove it from provided spring.schemas since it is 3rd party software.
Maybe this is an issue how property-files are handled in java but I have no idea.
You may be able to "override" this entry by providing your own custom spring.schemas file with the same entry but with a location to your custom xsd file. The catch is that this is highly dependent on the order in which the spring.schemas are loaded up, but could be worth a try.
Since custDir is not a place holder, you cannot replace it the way you are doing it, I am surprised that the third party schema location is outside of the classpath.
The syntax of spring.schemas I provided in my question is a properitary definition of 3.rd party software. They implemented there own EntityResolver which manually reacts on "custDir:" and starts some magic algorithm. So I came to the following workaround.
You have to create your own my_spring.schemas which must be live in META-INF/. Than you have to make sure that spring loads my_spring.schemas and NOT spring.schemas.
I achieved it with implementing my own TestingContext which is a subclass of ClassPathXmlApplicationContext. In TestingContext I overwrote method protected void loadBeanDefinitions(DefaultListableBeanFactory beanFactory) throws IOException and filled it with implementation from org.springframework.context.support.AbstractXmlApplicationContext. The only change I made was to line beanDefinitionReader.setEntityResolver(new ResourceEntityResolver(this)) to beanDefinitionReader.setEntityResolver(new PluggableSchemaResolver(getClassLoader(), "META-INF/my_spring.schemas). And voila if I use TestingContext my own my_spring.schemas is loaded.
Drawback with this solution is that you have to provide all xsd in your jar because the default name, where spring looks up definitions has been changed.
What is a NamespaceHandler? What is the need to write our custom NamespaceHandler?
Please explain me the significance of NamespaceHandler. Provide me Any links on internet.
It handles specific XML tags found inside a file, such as <log:return />, which is the return tag inside the log namespace.
The best reference is often the Javadoc.
It is useful if you want to use your custom XML tags in an XML configuration:
http://www.theserverside.com/news/1364131/Authoring-Custom-Namespaces-in-Spring-20
If you have a framework and want to add Spring integration to your framework, it could be useful. In that case it would be more important to define the equivalent annotations.
Is there a way to specify the name of the aop.xml file with LTW? or define another name and location?
I have several software modules that I use and that all use META-INF/aop.xml with different settings.
I include these modules in a web application and then it all dependens how it's deployed/unpacked, which aop.xml file is used ..
So I discovered after long time of searching that not all LTW weaving toke place correcting as it depends with aop.xml was used ...
Basically I need to use both aop.xml files, kinda of merging both contents of the aop.xml files...
How to do this?
Ed
When using AspectJ you can use the system property org.aspectj.weaver.loadtime.configuration to point to another config file. For example:
-Dorg.aspectj.weaver.loadtime.configuration=file:META-INF/myaop.xml
Duplicate of Load time weaving in AspectJ using aop.xml.
Furthermore, the AspectJ documentation says:
When several configuration files are visible from a given weaving
class loader their contents are conceptually merged.
It is the second time that I stumble across that issue and I haven't found a good solution yet. My problem is that I want to package a framework like JAR with a default Spring context and give the user of my JAR package the possibility to use this configuration (or even an ApplicationContext implementation) to add his own bean definitions (from another config file) and to use or overwrite definitions from the default context. Does anybody know a good way to do this?
The people using your jar will have to import your .xml file in theirs, with something like this:
<import resource="classpath*:/META-INF/spring-yourframework-init.xml" />
(/META-INF/spring-yourframework-init.xml is the path of your xml in your jar. This xml file is a regular spring configuration file)