Suggestion for how you limit builds to not have aspect weaving?...

[rickcr]

Probably a really basic question but I'm looking for the approach you take to making it easy (at build time or run time based on a property) to not having an aspect applied?

Currently I have a single timeMethod aspect that I'd like to only be applied based on an property found in my application.properties file.

I'm not exactly sure of how to do the above, so instead for now I have my web.xml load a profile and then I'm toggling on the profile name:

	<env-entry>
		<env-entry-name>spring.profiles.active</env-entry-name>
		<env-entry-type>java.lang.String</env-entry-type>
		<env-entry-value>${env}</env-entry-value>
	</env-entry>

Then in my config...

	<beans profile="local">
		<bean id="timeMethodAspect" class="com.foo.service.TimeMethodAspect"/>
	</beans>

"env" is a property that gets set when maven does its build of the war and it pulls that value from the filter.

The above works but I don't like it. I want to toggle specifically on something like "applyAspects" read from a property...

applyAspects=true

This way I could easily turn the application of the aspects on or off across any environment. (Note, it's fine if it's a build time thing.. doesn't have to be at run time.)

What's the best approach to achieve what I want to do ? Thanks.

[Marten Deinum]

You don't want it to be a build time thing but a runtime thing... Basically a build time thing means doing everything again (testing etc.) because you create a new artifact (at least that would be in my book). The same goes for the env stuff it should be environment specific and not based on the build (just my 2ct).

The simplest way is to simply let the aspect check if it is enabled or not that way you can simply always add it and let the aspect decide if it needs to be applied or not.

Another solution would be to simply import an additional context.xml file (whic is placed outside the war) which contains the optional aspects (the file can be an empty context.xml file). Drawback is that other beans can be overriden with this approach when not carefully applied.

I guess I would simply go with the profile stuff. You can have multiple profiles active so you can create a profile only for your aspect and enable/disable this at will, the spring.profiles.active property can be specifed by a system/environment/jndi property the latter can be simply configured in the general context.xml of the application specific context.xml (when on tomcat).

[rickcr]

The simplest way is to simply let the aspect check if it is enabled or not that way you can simply always add it and let the aspect decide if it needs to be applied or not.

When you see the simplest way - how is this actually done? My aspect is defined like...

@Aspect
public class TimeMethodAspect {
	private final static Logger logger = LoggerFactory.getLogger(TimeMethodAspect.class);

	@Around("within(com.foo.service..*)")
	public Object execute(ProceedingJoinPoint ourMethod) throws Throwable { ...

And it's mapped as a bean in my xml config. Where am I making this decision to decide whether it's applied or not? Sure I can put some logic within the execute method .. if (somePropertyIsTrue) { .. } but I doubt that's what you're referring to since I wouldn't want all the aspects applied (even if they don't do anything.)

Another solution would be to simply import an additional context.xml file (whic is placed outside the war) which contains the optional aspects (the file can be an empty context.xml file). Drawback is that other beans can be overriden with this approach when not carefully applied.

I guess I would simply go with the profile stuff. You can have multiple profiles active so you can create a profile only for your aspect and enable/disable this at will, the spring.profiles.active property can be specifed by a system/environment/jndi property the latter can be simply configured in the general context.xml of the application specific context.xml (when on tomcat).

Both of these ideas seem pretty cool as well. I might go with the latter where the profile prop sits in the context.xml