I want to change Spring AOP to pure aspectJ in spring framework.
Spring AOP is used like below.
<aop:config >
<aop:pointcut id="testopiaLogging" expression="execution(public * cosmos..*SVC.*(..))" />
<aop:aspect ref="testopiaLoggingAspect">
<aop:after-throwing method="throwError" throwing="exception" pointcut-ref="testopiaLogging"/>
<aop:after-returning method="log" returning="retVal" pointcut-ref="testopiaLogging"/>
</aop:aspect>
</aop:config>
and I'll change it to pure aspectJ accroding to below url's page
http://static.springsource.org/spring/docs/3.0.x/spring-framework-reference/html/aop.html#aop-using-aspectj
spring-aspect.jar is set in classpath.
So I made aop.xml.
<aspectj>
<weaver>
<include within="cosmos.*" />
</weaver>
<aspects>
<aspect name="com.sds.testopia.logger.aop.TestopiaAspect" />
</aspects>
</aspectj>
Next, I can't know very well.. I guess that I will use Load Time Weaver and
Log Aspect File have to change .aj foramt using aspect, point-cut keyword and making jar..
I want to get specific and detail explanation. thx.
AspectJ doesn't work with Spring's XML-style AOP. You need to use either traditional AspectJ (.aj) or the annotation based #AspectJ (.java) format. But you can't create AspectJ aspects using XML (only Spring AOP aspects).
Related
Recently Started off on Camunda BPMN And immediately felt the need of Extending the properties under extension elements for my usecase.
Currently Camunda offers CamundaProperty which is good enough, but not for my use case where I want to have a specific property tag across the BPMN and collect only those properties.
Example:
<bpmn:extensionElements>
<demo:properties>
<demo:property name="entitlement" value="assign" />
<demo:property name="processProp" value="enabled" />
</demo:properties>
<camunda:properties>
<camunda:property name="entitlement" value="assign" />
<camunda:property name="processProp" value="enabled" />
</camunda:properties>
</bpmn:extensionElements>
I am Extending BpmnModelElementInstanceImpl class to achieve the same and register my demo tag in the xml.
But the process engine fails to recognize the tag.
Please guide me in solving this issue.
I'm trying to create a Kotlin Vert.x language support module and I need a way to compile Kotlin files and load the results with a ClassLoader. I've tried using kotlin-compiler library and found K2JVMCompiler class, but it seems to support only command-line-style arguments with its exec method. Is there a way to compile a Kotlin file in runtime (possibly without having to save and read .class files) and immediately load the generated classes? (Kind of like Groovy does.) If not, do you have any useful compiler arguments suggestions or pretty much any advices?
This feels like an XY Problem. You want to know how to compile Kotlin on the fly so that you can more easily use Vert.x by running from Kotlin source files instead of compiled code. But really the recommended path for Vert.x usage is to create a simple bit of code that deploys your verticle within compiled code.
In the question, your link for language support says Vert.x 2 in the path "vertx.io/vertx2/language_support.html"; which is different than how it is now done in Vert.x 3. I think you are merging two thoughts into one. First that Vert.x 3 wants you to run Java/Kotlin files from source (it doesn't really; that was a Vert.x 2 thing they moved away from for compiled languages), and second that you need custom language support (you don't).
You should try to use Vert.x 3 by running compiled code. To do so, build your classes and run your own main() that deploys a verticle programatically. Your code would be simple as:
import io.vertx.core.Vertx
fun main(args: Array<String>) {
val vertx = Vertx.vertx()
vertx.deployVerticle(SomeVerticleOfMine())
}
Alternatively, the docs for running and deploying from the command-line say:
Vert.x will compile the Java source file on the fly before running it. This is really useful for quickly prototyping verticles and great for demos. No need to set-up a Maven or Gradle build first to get going!
And really it is indeed just for prototyping and quick testing, and it isn't any faster than letting your IDE do the same and running from the compiled classes. You also then have debugging features of the IDE which are infinitely valuable.
For a few helper libraries for using Kotlin with Vert.x, view these options:
Vert.x 3 module for Klutter - I am the author, one of my libraries
Vert.x 3 helpers for Kotlin - by Cy6erGn0m
Kovert, a REST framework for Vert.x 3 - I am the author, one of my libraries
Vert.x nubes - not Kotlin specific, but makes Vert.x-Web friendlier for JVM languages.
There is a full sample project of running Vert.x + Kovert (specifically start with the App class). You can look at the code of Kovert to do your own similar work of starting and running Vert.x nicely, with Promises or however you wish. The docs for Kovert have links to code for starting Vertx and also starting a Verticle to use Vert.x-Web, so more sample code you can read. But it helps to understand Injekt (light-weight dependency registry), Kovenant (promises library), and Klutter configuration injection to understand the complete sample.
Other quick note, Vert.x has codegen support for other languages, but since you can call all of the Java version directly, it does not need to support Kotlin either.
Kotlin 1.1 comes with javax.script (JSR-223) support, which means you can use it as scripting engine similarly to JavaScript with Nashorn.
I'm using the JAXB-2 Maven Plugin to generate classes from an XSD. One element has a maxOccurs of 50000 so the secure processing feature causes an exception for violating the 5000 limit.
Changing the XSD is not an option so as a workaround I added the "-nv" parameter to turn off strict validation. So I got my classes but it doesn't feel like a real solution.
Is there a way to set the MAX_OCCUR_NODE_LIMIT?
is it possible to write an AspectJ pointcut that matches the usage of a specific operator with a specific type?
Some background information: I'm working on a project where we have to use a legacy Java library (pre 5.0, before the enum keyword) which comes with several "pseudo-enum" types, i.e. normal Java classes that define static constants of its own type. Those "feel" very much like enums, but using them like enums can result in an error. Therefore I'd like AspectJ to mark uses of == with objects of one of these types as an error, if that is possible. I have googled this and consulted the normally very helpful book AspectJ in action, but so far without success. Any help is appreciated.
== is not the same as equals(), and is implemented by the JVM, and as far as I can tell cannot be modified by aspectj. Also, I don't think that AspectJ is the correct tool for this job.
A better approach would be to implement a Checkstyle rule or similar for your project to allow you indicate these points. You could have them as errors or warnings. See Writing Checks for Checkstyle for more information.
This would require some coding, but so would the aspectJ solution.
Checkstyle has an eclipse plugin as well as a maven plugin, so you could have these errors appearing as you work in the IDE.
I have a project that builds with maven2 and runs a series of JUnit test cases against the code. This has worked fine up until this point, where I now have 2 tests that must run in a certain sequence for things to work correctly, let's say TestA and Test (A then B). Unfortunately, maven2 doesn't understand this, so I'm looking for a way of convincing it that it needs to run the tests in this order.
The problem is that I'm setting some final static fields in TestB, but I'm doing this from TestA, which itself uses those fields, and successful execution of the test depends on those fields being set to their new values (there is absolutely no way around this, otherwise I would have taken that road long before now). So, it is imperative that TestA loads first, and it will of course cause TestB to be loaded when tries to access it. However, maven2 has decided that it will run TestB then TestA, which means those final fields are already set and cannot be changed.
So what I'm looking for is either a way to specify the order in which the tests are executed (A then B, every time), or a way to easily cause TestB to be reloaded by whichever classloader that JUnit uses.
EDIT - one other option might be some option like the old JUnit GUI tool has, that causes all classes to be reloaded for each test. I have looked and looked and not found such a flag in the maven junit plugin, if such a thing exists, then that would also work.
Fork mode can force each test to run in its own JVM so every class is re-loaded for each test.
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-surefire-plugin</artifactId>
<configuration>
<forkMode>pertest</forkMode>
</configuration>
</plugin>
The test order in JUnit is intentionally undefined, this is not a Maven issue and it's probably just luck that your tests were running OK up until now.
Sal's answer addresses your question directly, however forking the JVM on each test for large test counts can hugely increase your build time.
An alternative approach would be to use a testing library such as PowerMock (it currently works with EasyMock and Mockito) to clear the static fields in TestB's initialisation, this avoids the need for any JVM forking, and ensures your tests are portable.
From the PowerMock website:
PowerMock is a framework that extend other mock libraries such as EasyMock with more powerful capabilities. PowerMock uses a custom classloader and bytecode manipulation to enable mocking of static methods, constructors, final classes and methods, private methods, removal of static initializers and more. By using a custom classloader no changes need to be done to the IDE or continuous integration servers which simplifies adoption. Developers familiar with EasyMock will find PowerMock easy to use, since the entire expectation API is the same, both for static methods and constructors. PowerMock extends the EasyMock API with a small number of methods and annotations to enable the extra features. From version 1.1 PowerMock also has basic support for Mockito.