Use of java.util.ServiceLoader

[Matt Sicker]

This was added back in 1.6, and I still don't see it used very often. It
seems like a more effective method of making customizable service classes
than all system properties all the time (even though you can technically
just make a log4j2.component.properties file to set them). I think we could
use it for simple plugins that aren't log4j-core plugins (or even in
log4j-core), or we could make a sort of replacement class that's similar.

If you don't already know how ServiceLoader<S> works, it looks for
META-INF/services/the.full.class.name files which contain a FQCN of the
implementation class. I'm not particularly sure about the order in which
things are loaded, but it's certainly useful when you combine it with
something like the @Order annotation we have and then sort them based on
that.

I know why we didn't use it for LoggerContextFactory what with the
additional properties to be specified for a provider. However, I don't see
why we haven't used it for other service classes.

[Ralph Goers]

Yes, I looked at it and purposely decided not to use it for the LoggerContextFactory. I wanted to do API version checking to make sure what we were binding with is compatible.

As for using it for other stuff, I am not really sure how or why ServiceLoader was bypassed.

Ralph

This was added back in 1.6, and I still don't see it used very often. It seems like a more effective method of making customizable service classes than all system properties all the time (even though you can technically just make a log4j2.component.properties file to set them). I think we could use it for simple plugins that aren't log4j-core plugins (or even in log4j-core), or we could make a sort of replacement class that's similar.
I know why we didn't use it for LoggerContextFactory what with the additional properties to be specified for a provider. However, I don't see why we haven't used it for other service classes.
--

[Matt Sicker]

Let me compile a list of example service classes that could benefit from
using ServiceLoader. I'll be back soon.

Post by Ralph Goers
Yes, I looked at it and purposely decided not to use it for the
LoggerContextFactory. I wanted to do API version checking to make sure
what we were binding with is compatible.
As for using it for other stuff, I am not really sure how or why
ServiceLoader was bypassed.
Ralph
This was added back in 1.6, and I still don't see it used very often. It
seems like a more effective method of making customizable service classes
than all system properties all the time (even though you can technically
just make a log4j2.component.properties file to set them). I think we could
use it for simple plugins that aren't log4j-core plugins (or even in
log4j-core), or we could make a sort of replacement class that's similar.
If you don't already know how ServiceLoader<S> works, it looks for
META-INF/services/the.full.class.name files which contain a FQCN of the
implementation class. I'm not particularly sure about the order in which
things are loaded, but it's certainly useful when you combine it with
that.
I know why we didn't use it for LoggerContextFactory what with the
additional properties to be specified for a provider. However, I don't see
why we haven't used it for other service classes.
--

[Matt Sicker]

It's actually a bit more complicated than I thought. Sometimes, the
properties are there for overriding the default (usually with another
log4j-provided class instead of a custom one). I'll have to delve into this
a bit more.

Post by Matt Sicker
Let me compile a list of example service classes that could benefit from
using ServiceLoader. I'll be back soon.

Post by Ralph Goers
Yes, I looked at it and purposely decided not to use it for the
LoggerContextFactory. I wanted to do API version checking to make sure
what we were binding with is compatible.
As for using it for other stuff, I am not really sure how or why
ServiceLoader was bypassed.
Ralph
This was added back in 1.6, and I still don't see it used very often. It
seems like a more effective method of making customizable service classes
than all system properties all the time (even though you can technically
just make a log4j2.component.properties file to set them). I think we could
use it for simple plugins that aren't log4j-core plugins (or even in
log4j-core), or we could make a sort of replacement class that's similar.
If you don't already know how ServiceLoader<S> works, it looks for
META-INF/services/the.full.class.name files which contain a FQCN of the
implementation class. I'm not particularly sure about the order in which
things are loaded, but it's certainly useful when you combine it with
that.
I know why we didn't use it for LoggerContextFactory what with the
additional properties to be specified for a provider. However, I don't see
why we haven't used it for other service classes.
--

--

[Matt Sicker]

So far I've figured out that you can specify multiple classes in a
ServiceLoader file. Each line can have a class. And the order things are
parsed are determined by ClassLoader.getResources() (which I'd assume is
classpath order). This could really use a sort of extension that allowed
prioritizing services.

Post by Matt Sicker
It's actually a bit more complicated than I thought. Sometimes, the
properties are there for overriding the default (usually with another
log4j-provided class instead of a custom one). I'll have to delve into this
a bit more.

Post by Matt Sicker
Let me compile a list of example service classes that could benefit from
using ServiceLoader. I'll be back soon.

Post by Ralph Goers
Yes, I looked at it and purposely decided not to use it for the
LoggerContextFactory. I wanted to do API version checking to make sure
what we were binding with is compatible.
As for using it for other stuff, I am not really sure how or why
ServiceLoader was bypassed.
Ralph
This was added back in 1.6, and I still don't see it used very often. It
seems like a more effective method of making customizable service classes
than all system properties all the time (even though you can technically
just make a log4j2.component.properties file to set them). I think we could
use it for simple plugins that aren't log4j-core plugins (or even in
log4j-core), or we could make a sort of replacement class that's similar.
If you don't already know how ServiceLoader<S> works, it looks for
META-INF/services/the.full.class.name files which contain a FQCN of the
implementation class. I'm not particularly sure about the order in which
things are loaded, but it's certainly useful when you combine it with
that.
I know why we didn't use it for LoggerContextFactory what with the
additional properties to be specified for a provider. However, I don't see
why we haven't used it for other service classes.
--

--

--

[Gary Gregory]

Are we getting side tracked here? Is this all required for 2.1. We got up
to RC3 this weekend. It seems we should go to RC4 and then continue on
2.2-SNAP.

Gary

Post by Matt Sicker
So far I've figured out that you can specify multiple classes in a
ServiceLoader file. Each line can have a class. And the order things are
parsed are determined by ClassLoader.getResources() (which I'd assume is
classpath order). This could really use a sort of extension that allowed
prioritizing services.

Post by Matt Sicker
It's actually a bit more complicated than I thought. Sometimes, the
properties are there for overriding the default (usually with another
log4j-provided class instead of a custom one). I'll have to delve into this
a bit more.

Post by Matt Sicker
Let me compile a list of example service classes that could benefit from
using ServiceLoader. I'll be back soon.

Post by Ralph Goers
Yes, I looked at it and purposely decided not to use it for the
LoggerContextFactory. I wanted to do API version checking to make sure
what we were binding with is compatible.
As for using it for other stuff, I am not really sure how or why
ServiceLoader was bypassed.
Ralph
This was added back in 1.6, and I still don't see it used very often.
It seems like a more effective method of making customizable service
classes than all system properties all the time (even though you can
technically just make a log4j2.component.properties file to set them). I
think we could use it for simple plugins that aren't log4j-core plugins (or
even in log4j-core), or we could make a sort of replacement class that's
similar.
If you don't already know how ServiceLoader<S> works, it looks for
META-INF/services/the.full.class.name files which contain a FQCN of
the implementation class. I'm not particularly sure about the order in
which things are loaded, but it's certainly useful when you combine it with
that.
I know why we didn't use it for LoggerContextFactory what with the
additional properties to be specified for a provider. However, I don't see
why we haven't used it for other service classes.
--

--

--

--

[Remko Popma]

+1 I would also like to release what we have now.

Sent from my iPhone

Are we getting side tracked here? Is this all required for 2.1. We got up to RC3 this weekend. It seems we should go to RC4 and then continue on 2.2-SNAP.
Gary

So far I've figured out that you can specify multiple classes in a ServiceLoader file. Each line can have a class. And the order things are parsed are determined by ClassLoader.getResources() (which I'd assume is classpath order). This could really use a sort of extension that allowed prioritizing services.

It's actually a bit more complicated than I thought. Sometimes, the properties are there for overriding the default (usually with another log4j-provided class instead of a custom one). I'll have to delve into this a bit more.

Let me compile a list of example service classes that could benefit from using ServiceLoader. I'll be back soon.

Post by Ralph Goers
Yes, I looked at it and purposely decided not to use it for the LoggerContextFactory. I wanted to do API version checking to make sure what we were binding with is compatible.
As for using it for other stuff, I am not really sure how or why ServiceLoader was bypassed.
Ralph

This was added back in 1.6, and I still don't see it used very often. It seems like a more effective method of making customizable service classes than all system properties all the time (even though you can technically just make a log4j2.component.properties file to set them). I think we could use it for simple plugins that aren't log4j-core plugins (or even in log4j-core), or we could make a sort of replacement class that's similar.
I know why we didn't use it for LoggerContextFactory what with the additional properties to be specified for a provider. However, I don't see why we haven't used it for other service classes.
--

--

--

--

--
Java Persistence with Hibernate, Second Edition
JUnit in Action, Second Edition
Spring Batch in Action
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory

[Matt Sicker]

Of course I'm getting side tracked, it's what I do!

Post by Remko Popma
+1 I would also like to release what we have now.
Sent from my iPhone
Are we getting side tracked here? Is this all required for 2.1. We got up
to RC3 this weekend. It seems we should go to RC4 and then continue on
2.2-SNAP.
Gary

Post by Matt Sicker
So far I've figured out that you can specify multiple classes in a
ServiceLoader file. Each line can have a class. And the order things are
parsed are determined by ClassLoader.getResources() (which I'd assume is
classpath order). This could really use a sort of extension that allowed
prioritizing services.

Post by Matt Sicker
It's actually a bit more complicated than I thought. Sometimes, the
properties are there for overriding the default (usually with another
log4j-provided class instead of a custom one). I'll have to delve into this
a bit more.

Post by Matt Sicker
Let me compile a list of example service classes that could benefit
from using ServiceLoader. I'll be back soon.

Post by Ralph Goers
Yes, I looked at it and purposely decided not to use it for the
LoggerContextFactory. I wanted to do API version checking to make sure
what we were binding with is compatible.
As for using it for other stuff, I am not really sure how or why
ServiceLoader was bypassed.
Ralph
This was added back in 1.6, and I still don't see it used very often.
It seems like a more effective method of making customizable service
classes than all system properties all the time (even though you can
technically just make a log4j2.component.properties file to set them). I
think we could use it for simple plugins that aren't log4j-core plugins (or
even in log4j-core), or we could make a sort of replacement class that's
similar.
If you don't already know how ServiceLoader<S> works, it looks for
META-INF/services/the.full.class.name files which contain a FQCN of
the implementation class. I'm not particularly sure about the order in
which things are loaded, but it's certainly useful when you combine it with
that.
I know why we didn't use it for LoggerContextFactory what with the
additional properties to be specified for a provider. However, I don't see
why we haven't used it for other service classes.
--

--

--

--

--
Java Persistence with Hibernate, Second Edition
<http://www.manning.com/bauer3/>
JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
Spring Batch in Action <http://www.manning.com/templier/>
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory

[Remko Popma]

:-)

Sent from my iPhone

Post by Matt Sicker
Of course I'm getting side tracked, it's what I do!

Post by Remko Popma
+1 I would also like to release what we have now.
Sent from my iPhone

Are we getting side tracked here? Is this all required for 2.1. We got up to RC3 this weekend. It seems we should go to RC4 and then continue on 2.2-SNAP.
Gary

So far I've figured out that you can specify multiple classes in a ServiceLoader file. Each line can have a class. And the order things are parsed are determined by ClassLoader.getResources() (which I'd assume is classpath order). This could really use a sort of extension that allowed prioritizing services.

It's actually a bit more complicated than I thought. Sometimes, the properties are there for overriding the default (usually with another log4j-provided class instead of a custom one). I'll have to delve into this a bit more.

Let me compile a list of example service classes that could benefit from using ServiceLoader. I'll be back soon.

Post by Ralph Goers
Yes, I looked at it and purposely decided not to use it for the LoggerContextFactory. I wanted to do API version checking to make sure what we were binding with is compatible.
As for using it for other stuff, I am not really sure how or why ServiceLoader was bypassed.
Ralph

This was added back in 1.6, and I still don't see it used very often. It seems like a more effective method of making customizable service classes than all system properties all the time (even though you can technically just make a log4j2.component.properties file to set them). I think we could use it for simple plugins that aren't log4j-core plugins (or even in log4j-core), or we could make a sort of replacement class that's similar.
I know why we didn't use it for LoggerContextFactory what with the additional properties to be specified for a provider. However, I don't see why we haven't used it for other service classes.
--

--

--

--

--
Java Persistence with Hibernate, Second Edition
JUnit in Action, Second Edition
Spring Batch in Action
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory

--