Determine Active Annotation processor at runtime

[Oliver Libutzki]

Hi everyone,

Xtend's active annotations are bound to an Annotation Processor in a static way by using the @Active annotation. I wonder if it's possible to override/customize the behaviour of the Annotation processor at runtime.

In other words I would like to use a DI framework which provides the concrete processor implementation. Unfortunately I do not know where to store the DI container. Holding the Injector (Guice) or ApplicationContext (Spring) in a static variable seems not to be a good idea as I'm not aware of the lifecycle of the static variable, especially while working in my IDE.

Is there any Xtend concept I could use?

Thanks fpr your answer.

Kind regards

Oliver

[Sven Efftinge (sven@efftinge.de)]

Hi Oliver,

the compiler uses a fresh URLClassLoader with fresh classes every time the sources have changed and there is no dispose hook or something similar that would inform you about the end of life. 

So you should not keep any references to classes (and instances).

Sven

--
You received this message because you are subscribed to the Google Groups "Xtend Programming Language" group.
To unsubscribe from this group and stop receiving emails from it, send an email to xtend-lang+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Oliver Libutzki]

Hi Sven,

thanks for answering.

Does it make sense to file a feature request? Or does this requirement break the architecture in a way that it can't be implemented?

Kind regards
Oliver

[Sven Efftinge (sven@efftinge.de)]

As it would certainly complicate things, learning about the motivation behind it would be important.

Kind regards
Oliver

[Oliver Libutzki]

I develop a framework which is customizable at runtime level by binding custom implementations of interfaces using Spring. The concept is pretty much the same Xtext uses in conjunction with Google Guice. The framework provides some default implementation and framework user can enhance the behaviour by binding their customized implementation.

The framework relies on code generation and validation rules provided by active annotations. So Xtend is used as an internal DSL for my domain. The domain concepts are refelcted by active annotations.

Sometimes the possibility to bind another implementation at runtime level is not sufficient, so I would like to customize the AA processor in order to add some validations or generate different/additional code. Currently the binding between an active annoation and it's processor is static. Xtend instantiates the the Annotation processor which is referenced by the @Active annotation. There is not way to bind a custom implementation.

The only workaround is to define another Active annotation with a different annotation processor which reuses parts of the original annotation processor and adds some additional stuff. That's ok, but I prefer to have one annotation which can be customized. In other worlds, I don't want to change my DSL just because I want to customize the code generator or a certain validation rule.

I hope this clarifies my motiviation, otherwise feel free to ask further questions. ;-)

[Oliver Libutzki]

After explaining my motiviation: Shall I open an issue or do you know any solution with Xtend 2.11?

[Sven Efftinge (sven@efftinge.de)]

Where and how would you want to configure the extensions?

2017-02-20 6:54 GMT+01:00 Oliver Libutzki <oliver_...@gmx.de>:

After explaining my motiviation: Shall I open an issue or do you know any solution with Xtend 2.11?

--

[Oliver Libutzki]

Hi Sven,

I have created a Maven project in order to show this: https://github.com/OLibutzki/Xtend-Dynamic-AA

I explained the structure here: https://github.com/OLibutzki/Xtend-Dynamic-AA/blob/master/README.md

Kind regards

Oliver

On Monday, February 20, 2017 at 9:34:21 AM UTC+1, Sven Efftinge wrote:

Where and how would you want to configure the extensions?

2017-02-20 6:54 GMT+01:00 Oliver Libutzki <oliver_...@gmx.de>:

After explaining my motiviation: Shall I open an issue or do you know any solution with Xtend 2.11?

--
You received this message because you are subscribed to the Google Groups "Xtend Programming Language" group.

To unsubscribe from this group and stop receiving emails from it, send an email to xtend-lang+...@googlegroups.com.

[Oliver Libutzki]

Did you find the time to have a look, Sven?

[Sven Efftinge (sven@efftinge.de)]

I had a brief look now. 

So the initial request was about the lifecycle, I think using static variable is just right, as the classes and classloader will be thrown away if the code changes, but otherwise be reused. Are there any reasons you explicitly need to dispose the application context?

2017-02-27 11:46 GMT+01:00 Oliver Libutzki <oli...@libutzki.de>:

Did you find the time to have a look, Sven?

--

[Oliver Libutzki]

No, there is no reason to dispose it explicitly. I just did not know when the classes and the classloader are thrown away. If it's disposed every time the code changes that's exactly the behaviour I need.

So you do not see any issues with this approach? The only downside might be the performance as Spring's application context is reinitialzed on code changes.

Am Montag, 27. Februar 2017 14:55:45 UTC+1 schrieb Sven Efftinge:

I had a brief look now. 

So the initial request was about the lifecycle, I think using static variable is just right, as the classes and classloader will be thrown away if the code changes, but otherwise be reused. Are there any reasons you explicitly need to dispose the application context?

2017-02-27 11:46 GMT+01:00 Oliver Libutzki <oli...@libutzki.de>:

Did you find the time to have a look, Sven?

--
You received this message because you are subscribed to the Google Groups "Xtend Programming Language" group.

To unsubscribe from this group and stop receiving emails from it, send an email to xtend-lang+...@googlegroups.com.

[Sven Efftinge (sven@efftinge.de)]

Yes.

To unsubscribe from this group and stop receiving emails from it, send an email to xtend-lang+unsubscribe@googlegroups.com.

[Oliver Libutzki]

Ok, many thanks for your efforts.

[Oliver Libutzki]

For thosewho are interested: I updated https://github.com/OLibutzki/Xtend-Dynamic-AA 

The Spring boot dependencies are removed. Instead of this a simpler (and much faster) approach is used: The classpath is scanned for META-INF/generator.factories files which link to the concrete Annotation processor class. You can influence the used processor by providing an order.

[Micael Pedrosa]

This is interesting, because sometimes developers at companies just don't want to use Xtend! And AA has a dependency on the compiler.

With this, pure Java developers can still use the Xtend AA if a container is provided.