> On May 30, 2022, at 2:26 PM, Matt Sicker wrote:
>
> When I was working on the previous iteration of the DI API, I had a
> BeanProcessor which generated different metadata for different annotation
> scenarios. It wasn’t too complex compared to the existing annotation
> processor, though I
> On May 30, 2022, at 1:41 PM, Volkan Yazıcı wrote:
>
> On Mon, May 30, 2022 at 6:52 PM Ralph Goers
> wrote:
>
>>> On May 30, 2022, at 2:01 AM, Volkan Yazıcı wrote:
>>> Following up on the responses, I will ask another question: In 3.x, can't
>>> we deprecate either key or name and stick
When I was working on the previous iteration of the DI API, I had a
BeanProcessor which generated different metadata for different annotation
scenarios. It wasn’t too complex compared to the existing annotation processor,
though I ended up sticking with the existing processor for now since that
On Mon, May 30, 2022 at 6:52 PM Ralph Goers
wrote:
> > On May 30, 2022, at 2:01 AM, Volkan Yazıcı wrote:
> > Following up on the responses, I will ask another question: In 3.x, can't
> > we deprecate either key or name and stick to only one?
>
> Why? What problem does this solve?
>
> > For
The annotations could index even more info if we wanted. ConverterKeys is
another annotation that was introduced due to, uh, I don’t know why actually.
Seems like it could use PluginAliases already to define extra converter keys.
Non-core namespace plugins could potentially make use of some of
> On May 30, 2022, at 2:01 AM, Volkan Yazıcı wrote:
>
>> plugin entry interfaces
>
> As Matt has indicated, we indeed need to keep `PluginEntry#interfaces` for
> lazy loading – plus a new `PluginEntry#order` field.
>
>> plugin name vs key
>
> Following up on the responses, I will ask
> plugin entry interfaces
As Matt has indicated, we indeed need to keep `PluginEntry#interfaces` for
lazy loading – plus a new `PluginEntry#order` field.
> plugin name vs key
Following up on the responses, I will ask another question: In 3.x, can't
we deprecate either key or name and stick to
And now that I just started working on Map> injection, I
see where this could would have otherwise been used. When streaming through
plugins, right now, all plugin classes in that namespace get loaded to at least
check their ordering annotations (another bit of metadata that could be indexed
And I think one bit of confusion with plugin keys/names/etc. is that this is
mostly relevant for either Core plugins (since that determines the element name
used in configurations) or for any other plugin namespace that uses aliases for
plugin classes, though some of those plugin namespaces
1. Plugin key is separate from the plugin name due to automatically
filling in some info from elementType, though I've rearranged the code
a bit in 3.x to make this part less confusing.
2. It's only @Configurable (Core) plugins that use the element type,
printable, and deferChildren options. I
> On May 27, 2022, at 6:54 AM, Volkan Yazıcı wrote:
>
> Matt, some more questions/remarks:
>
> 1. AFAIU, plugin `key` is the normalized `name`. Right? If so, what is
> the purpose of the `name`?
See PluginElementVisitor (at least in 2.x)
@Override
public PluginEntry visitType(final
Matt, some more questions/remarks:
1. AFAIU, plugin `key` is the normalized `name`. Right? If so, what is
the purpose of the `name`?
2. I was expecting `PluginEntry` to be simplified similar to `Plugin`
and only contain a `String key`, `String name`, and `String className`. For
And to answer your initial question, something could be Configurable and not a
Plugin, but that would only have the effect of putting it in the Core
namespace. The rest of the annotation only has interpretation in
Injector::configure.
—
Matt Sicker
> On May 23, 2022, at 15:48, Matt Sicker
Configurable and Plugin were combined as a single annotation before,
but the Core-category/namespace-specific configurability options don't
apply to other types of plugins, so I separated them. The benefit of
separating them is so that people don't get the strange idea that it's
possible to use
Matt, maybe I am not getting it but... I understand your explanation about
Configurable-vs-Plugin, yet my question still stands: Can something be
`@Configurable` but not `@Plugin`? If I am not mistaken, every single
`@Configurable` usage is followed by a `@Plugin`. Hence, I am inclined to
make
Those lazy wrappers are an insignificant detail. Feel free to simplify.
Configurable is a namespace annotation, not a name annotation. Plugin is a name
annotation that gets indexed.
If you’d like fancier conditional annotations, please describe what parts you
want. I don’t want to port over
Great work Matt! I have some questions/remarks:
1. Why did we introduce `LazyInt`, `LazyBoolean`, etc. rather than
simply leveraging `Lazy`? If the concern is nullability, we could have
checked the `supplier` response against `null` in `Lazy` itself.
2. Why is `Configurable` not
Having to make changes when recompiling is fine.
Ralph
> On May 20, 2022, at 4:14 PM, Matt Sicker wrote:
>
> Not beyond the fact that @Plugin moved packages and already breaks
> recompiling plugins from 2.x to 3.x. However, the metadata is loaded from 2.x
> plugins via the .dat files, and
Not beyond the fact that @Plugin moved packages and already breaks recompiling
plugins from 2.x to 3.x. However, the metadata is loaded from 2.x plugins via
the .dat files, and that still loads the metadata appropriately. There’s at
least one test in JsonTemplateLayout for comparing behavior to
I assume all of this stuff doesn’t break compatibility with 2.x plugins?
Ralph
> On May 20, 2022, at 2:36 PM, Matt Sicker wrote:
>
> By the way, I hope my latest commit renaming categories to namespaces
> and moving some annotation metadata around should help clarify the
> scope of things. In
By the way, I hope my latest commit renaming categories to namespaces
and moving some annotation metadata around should help clarify the
scope of things. In particular, I made an alias annotation for Core
category/namespace plugins called @Configurable which makes their use
case more obvious.
I’d like to add more ConditionalOn annotations for the @Factory methods, or at
least something like “if no binding exists for this key already, here it is”
which is analogous to @ConditionalOnMissingBean in Spring. That would make the
DefaultCallback code easier to write without using the
> On May 19, 2022, at 12:15 AM, Volkan Yazıcı wrote:
>
> In the last couple of weeks, I have been interrogating Matt on why and how
> of the 3.x plugin infra. This inevitably led to some code archaeology. I
> will try to share my take out of this exercise.
>
> 1.x required users to type the
In the last couple of weeks, I have been interrogating Matt on why and how
of the 3.x plugin infra. This inevitably led to some code archaeology. I
will try to share my take out of this exercise.
1.x required users to type the fully-qualified class names of components
(appenders, layouts, etc.)
24 matches
Mail list logo
