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.
Related
In my Spring application, I am trying to use property-placeholder with profiles test,dev,prod. Also I would like to be able to load the default properties common which are common for all profiles.
<context:property-placeholder
ignore-resource-not-found="false"
location="classpath:application-common.properties,classpath:application-test.properties"/>
This however doesn't work correctly. I am not yet using the variable ${spring.profiles.active}, because it doesn't work correctly even without it. What happens is that whatever is after the hyphen application- is loaded in alphabetical order. Loaded is only the first one, the other one is ignored. So in this case, only -common is loaded. Strange thing is, if I remove the hyphen, it load both files.
Is there some hidden behaviour I am not aware of?
You can use #PropertySource to load 'common' property file.
#PropertySource({
"classpath:application-common.properties"
})
Load environment specific property file by using spring.profiles.active while running your application.
For example , spring.profiles.active=dev
When I create a new Configuration in the "Hibernate Configuration" tab, the Session Factory node correctly shows the entities that are listed in the persistence.xml file of the main project, but fails to find all entities from a library project.
I'm using annotation configuration.
This is due to the way persistence.xml works.
You can add an external jar to persistence.xml using the <jar-file> element. The tricky bit is to make it work in Eclipse, where compiled classes are spread around different projects.
As suggested by this answer, you can do so with a relative "file:" url:
<persistence-unit name="myPersistenceUnit">
<jar-file>file:../../LibraryProject1/bin</jar-file>
<jar-file>file:../../LibraryProject2/bin</jar-file>
The "current folder" is the compiler output folder ("bin" in my case) i.e. the one containing META-INF if persistence.xml is located at /MainProject/src/main/resources/META-INF/persistence.xml
I use maven. My web application contains two modules and each has it's own spring context. First is packed to jar, the second one to war. The second one uses first module's jar and calls it's methods.
I need to add property file, which will be used by first module (via spring context). The main issue is that I should be able to access/edit this property file after war deployment.
How can I provide such a property file, that will be used in first jar module and can be changed after war module deployment?
Thanks.
Sorry, don't see the problem, you need to describe that better. From what I understood this is the way to go:
place a.properties in src/main/resources in the JAR module
use a PropertyPlaceholderConfigurer to make the properties available in the Spring context
it'll be packed in root of the JAR
the JAR ends up in WEB-INF/lib of the WAR which again is "root of the classpath" so to speak
Update, 2013-06-09
(question was updated based on comments to initial answer above)
Essentially what you seem to be looking for (still not quite sure) is how to load properties from a properties file that is not packaged with your WAR/JAR.
In this case you can skip all of the above steps except 2.
Use a PropertyPlaceholderConfigurer and specify the location of the file as classpath*:a.properties (see below)
Place a.properties anywhere on the classpath outside the WAR file.
Warning! Of course you can now edit the properties independently from releasing the WAR file but since Spring initializes the beans on application start and since all beans are singletons by default changes to the properties file won't become effective until you restart the app.
XML example
<bean class="....PropertyPlaceholderConfigurer">
<property name="location" value="classpath*:a.properties" />
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.
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)