Another idea that I had while looking through CDI is supporting a unit
of work logging feature LOG4J2-1630 [1] might be supportable with
something similar to @ConversationScoped in CDI [2].
[1]: https://issues.apache.org/jira/browse/LOG4J2-1630
[2]:
https://docs.jboss.org/cdi/api/2.0/javax/enterp
ScriptRef is a fairly simple conversion: you'd either add @Inject on
its current constructor (we'd make ScriptManager a singleton or
similar scope) and potentially adding a configuration scope annotation
on the name parameter (the default scope in javax.inject is supposed
to be effectively a protot
Yes, these sound like great starting points. I'll work on a proof of
concept of what I imagine the classes can look like after implementing
the new injection system.
On Mon, 4 Nov 2019 at 22:48, Ralph Goers wrote:
>
> PatternLayout and RFC5424Layout use the Configuration to pass to Converters,
>
PatternLayout and RFC5424Layout use the Configuration to pass to Converters,
primarily so they can use the Interpolator. CronTriggeringPolicy and
IdlePurgePolicy access the Configuration to get to the ConfigurationScheduler.
ScriptPatternSelector, and all other Script plugins, accesses the Con
Do you have any example plugins that might be a good example to showcase
the scopes and qualifiers model? Preferably a plugin that injects a
Configuration in order to obtain some other services or other ad hoc type
plugins. Any plugin using just attributes (and elements and values) would
be trivial
I see what you did with the annotation processor. I figured I’d be able to
add more metadata in the service class generated basically. If we can
identify the various logical scopes in the library, I think that could lead
to less potential bugs.
On Sun, Nov 3, 2019 at 14:14 Ralph Goers wrote:
> I
I have a couple of comments:
It isn’t really possible for me to know what you are suggesting without seeing
some examples of how plugins would be defined.
I have a suspicion the scopes could get nasty. Some plugins would be tied to
the LoggerContext, which essentially has a lifetime of the Class
Oh, almost forgot to mention my other main goal here: I have a
hypothesis that if designed our APIs with inversion of control in
mind, programmatic configuration and extension should be _much_ easier
to support while maintaining backward compatibility, too. While the
configuration framework itself
I've been working on this part time over the weekends lately, and
after exploring a bit of Guice and CDI, I've come to the conclusion
that if we were to rebase the plugin system on any annotation style,
it seems as though CDI provides a fairly good set of extensions to
javax.inject which would pote
Part of this is to make it simpler to access globally configured
things without having to pass around a Configuration everywhere. If
plugins can declare the explicit parts of the API they need access to
rather than the full Configuration, that should make tests a bit
lighter and easier to write.
O
FWIW, I don’t think @Inject is a good replacement for @PluginFactory. @Inject
is essentially the same as @Autowired. It should be placed on fields where you
want the implementation to be injected. @Inject specified on a method implies
that the method parameters should be injected. I don’t thin
Ok, but given @Scope and @Qualifier can only be used to annotate the existing
PluginElement, PluginAttribute and PluginValue annotations I am not sure what
they buy you. They can’t be used to replace the existing annotations as they
are only allowed to be used on annotation declarations. I agre
I want to make it simpler to write plugins. Increase testability, reuse
more standard APIs that others would be more familiar with (easier
onboarding), and make it simpler to implement some tangentially related
feature ideas.
As for the builder versus factory annotation, there was already special
I still don’t understand what the benefit is. IIUC your plan is to add the
@Scope and @Qualifier annotations to the @PluginElement and @PluginAttribute.
If that somehow helps, great, as it is will be invisible to plugin developers.
One thing I find odd is that Builders were annotated with @Plu
To clarify on the mapping between javax.inject and the existing
annotations, I believe this would work:
@PluginFactory can be replaced by @Inject
@PluginElement is a @Scope annotation
@PluginAttribute is a @Qualifier annotation
@PluginConfiguration could be a scope or singleton, but it's redundant
Ok, I see the issue. I won’t add a dependency on the API. I do want to try
refactoring the 3.x API to use an annotation model similar to that. I’ll
show a proof of concept sometime soon.
On Tue, Oct 8, 2019 at 18:50, Ralph Goers
wrote:
> I don’t understand. You can’t add javax.inject stuff into
I don’t understand. You can’t add javax.inject stuff into our namespace without
changing the package name. And if you change the package name I don’t see any
benefit at all as the current names are much clearer.
I have no problem with Configurations being a plugin except it will currently
cause
I'm thinking that the old annotations can be supported in terms of the
javax.inject API. As for requiring a jar, that's why I've also
suggested just adopting the annotations into our own package
somewhere.
Either way this is done, my general goal is to untangle other areas in
the core API that cou
I don’t see how that relates. The proposal as I understand it is to replace the
existing annotations with annotations from javax.inject, which would require a
JEE jar.
Ralph
> On Oct 8, 2019, at 1:31 PM, Jochen Wiedmann wrote:
>
> On Tue, Oct 8, 2019 at 10:26 PM Ralph Goers
> wrote:
>>
>>
I also don’t think it is a good idea for other reasons:
1. The annotations you are reeferencing a s replacements for the current ones
seem to be a stretch. For example it isn’t clear to me why @Qualifier has
anything to do with @PluginAttribute. It just seems far more confusing.
2. You would stil
On Tue, Oct 8, 2019 at 10:26 PM Ralph Goers wrote:
>
> IIUC this will require a dependency on a Java EE jar? For that reason alone,
> no.
Don't think so. A simple (mostly JSR 330 compliant) provider can be
implemented in a few classes:
https://github.com/jochenw/afw/tree/master/afw-core/src/ma
IIUC this will require a dependency on a Java EE jar? For that reason alone,
no.
Ralph
> On Oct 8, 2019, at 1:23 PM, Gary Gregory wrote:
>
> That sounds good Matt, I say go for it.
>
> Gary
>
> On Tue, Oct 8, 2019, 16:08 Matt Sicker wrote:
>
>> I've been doing some experiments with the pl
That sounds good Matt, I say go for it.
Gary
On Tue, Oct 8, 2019, 16:08 Matt Sicker wrote:
> I've been doing some experiments with the plugin system for 3.x
> lately, and I've recently pushed some changes toward that end. One of
> the insights I gained from it was that some of our plugin annota
I've been doing some experiments with the plugin system for 3.x
lately, and I've recently pushed some changes toward that end. One of
the insights I gained from it was that some of our plugin annotations
were redundant (result: @PluginBuilderFactory merged into
@PluginFactory; @PluginBuilderAttribu
24 matches
Mail list logo
