On 12/01/2013 10:30, Simone Tripodi wrote:
Salut Eric!
please forget the *version* field for a moment, as I wrote before it
was just fake metadata that I accidentally chose just because it was
the first it came in my mind, the purpose is only qualifying the
discovered services implementation
You mean the version attribute of your example can be statically loaded from a
properties file for example?
It could work as well, my initial proposal was specifying the
qualifiers directly in the META-INF/services files, i.e.
file META-INF/services/org.acme.CreditCardProcessor
-----------------------------------------------------------------
org.acme.VisaCreditCardProcessor; type=Visa; somethingElse=value1
org.acme.MastercardCreditCardProcessor; type=Mastercard; somethingElse=value2
but at after a second thought I realized that this format would make
that files useless with traditional ServiceLoader API... any other
idea?
Hi Simo,
Although quite easy and understandable, this solution implies:
- Reuse/extend and already existing file, which can introduce some
confusion and lower adpation in existing SPI project (people don't like
changing something that works, and they are right).
- Format limitation (no hierarchy, bloated line...).
- Often, you want to specify the implementation, and not falling on the
first one found present in the classpath.
I've got a use case where the implementation has to be chosen via
configuration. For Apache James, we define the type of mailbox
implementation in a mailbox.conf file (can be maildir, jpa, hbase...).
All those different implementation can further be configured (the
qualifiers : e.g. (non)caching,...).
For now, we use custom spring BeanFactoryPostProcessor... but I would
love to delegate all that work to an injecting framework.
We are also using commons-configuration and one point we miss is to able
to reload the configuration (meaning to reinject I guess).
commons-configuration allows us to read the "qualifiers" from files in
an arbitrary format (so not only from the META-INF/service files).
For completeness, we are OSGIing the modules, but this will not bring
anything regarding the configuration/injection/reload.
Just thinking loud.
Thx,
Eric
I guess the example you gave with the version is not about loading different
version of a same implementation, but just defining which concrete
implementation to choose.
You got it! :)
Any other idea is welcome!
-Simo
http://people.apache.org/~simonetripodi/
http://simonetripodi.livejournal.com/
http://twitter.com/simonetripodi
http://www.99soft.org/
