Qi4j configuration and Qi4j services

[michaelp]

Hi guys, 

Recently I found the need to use Qi4j configuration. Reading the related article (http://qi4j.org/2.0/howto-configure-service.html) a question popped up: Would it be possible to use 

@This 

Configuration<AbcConfig> config

without introducing a service, e.g. from an entity composite, or is the whole configuration mechanism tightly coupled with the use of service composites?

Also, on another note, the last part of the aforementioned article describes how to use the same service with different configurations. What I couldn't find is how to search for a service instance based on the service type (class) AND identity. Is this possible in a more convenient way than using the module#findServices() method?

Cheers,

Michael

[Paul Merlin]

Hi Michael,

michaelp a écrit :

Hi guys, 

Recently I found the need to use Qi4j configuration. Reading the related article (http://qi4j.org/2.0/howto-configure-service.html) a question popped up: Would it be possible to use 

@This 

Configuration<AbcConfig> config

without introducing a service, e.g. from an entity composite, or is the whole configuration mechanism tightly coupled with the use of service composites?

No. It is.
What do you want to achieve exactly?

Also, on another note, the last part of the aforementioned article describes how to use the same service with different configurations. What I couldn't find is how to search for a service instance based on the service type (class) AND identity. Is this possible in a more convenient way than using the module#findServices() method?

@Service @IdentifiedBy("some-id") YourServiceType field;

should do the job. See the org.qi4j.api.service.qualifier package.


Cheers

/Paul

[Niclas Hedhman]

The Configuration is tied very tightly to Services. But you could have services whose sole purpose is to deliver configuration information to transients and so on.

You can also change the identity of your Service via the identifiedBy() modifier in service assembly, i.e. when you declare the Service in your bootstrap code, in case you need it a bit more dynamic in your runtime.

Niclas

--
You received this message because you are subscribed to the Google Groups "qi4j-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to qi4j-dev+u...@googlegroups.com.
To post to this group, send email to qi4j...@googlegroups.com.
Visit this group at http://groups.google.com/group/qi4j-dev.
For more options, visit https://groups.google.com/d/optout.

--
Niclas Hedhman, Software Developer
河南南路555弄15号1901室。
http://www.qi4j.org - New Energy for Java

I live here; http://tinyurl.com/3xugrbk
I work here; http://tinyurl.com/6a2pl4j
I relax here; http://tinyurl.com/2cgsug

[michaelp]

Thanks to both for your replies. I don't mind using a service to handle the configuration(s) (I do it already), I was just wondering if I could do this independently. So now it's clear to me that these two go together.

Regarding service lookup, I was thinking more in the direction of something like:

findService(Class type, String identity)

similar to:

uow.get(Class entityType, String identity)

but I guess the annotation suggested by Paul should do.

Cheers,

Michael

[Niclas Hedhman]

More often than not, identification is not needed. By using "Visibility" you can often have the same service in many modules without conflict. It becomes an exercise in setting up the application structure...

--

You received this message because you are subscribed to the Google Groups "qi4j-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to qi4j-dev+u...@googlegroups.com.
To post to this group, send email to qi4j...@googlegroups.com.
Visit this group at http://groups.google.com/group/qi4j-dev.
For more options, visit https://groups.google.com/d/optout.

[michaelp]

Yes, I understand now the concept. So instead of using different identifiers, use different modules to organize the application layers.

Back to Qi4j configuration & services, I would like to share the overall context I am working on, and hopefully sparkle some further discussion on the topic.

In our application, we have a number of what we call "capabilities". Each capability is an independent REST service, and has its own set of configuration properties, although some properties are common to all capabilities. Each capability may also define different property values depending on the "flavor", i.e. whether it is assembled for execution in development, testing, or production mode.

In addition, we use the notion of "tower" to assemble and deploy a group of capabilities on a given (virtual) machine for a given purpose. In doing so, the tower has a set of configuration properties acting as switches of the capabilities. Each such property corresponds to a capability and takes the value on/off. So, if the property corresponding to capability X is set to on (off), then that capability will (not) be assembled by that tower. Also, like capabilities, each tower defines different configurations corresponding to the different flavors, while the selected flavor at the tower level is propagated at the capability level.

We have implemented the above scheme by using the Qi4j configuration mechanism as follows:

• Each capability defines a Configuration entity along with a Configuration service
  
• The Configuration service of each capability is registered with three different ids corresponding to the three different flavors (dev/test/prod). A .properties file exists for each such id.
  
• Each tower uses a common Tower Configuration entity along with a common Tower Configuration service.
  
• Similar to capabilities, the Tower Configuration Service is registered with three different ids that correspond to the flavors dev/test/prod, and uses the three corresponding .properties files. 
  

So the main idea is to keep the flat structure of .properties files and enforce hierarchical relations like inheritance at the Configuration entity level.

A few questions are :

• Since we basically followed the respective tutorials, is this the only way how to use Qi4j configuration or are there other alternatives too? 
• What is the overhead of multiple instances of the same service per capability? Should we consider a generic configuration service instead?

Any feedback and food for thought is welcome!

Cheers,

Michael

[Niclas Hedhman]

Perhaps, the only thing I think worth commenting is that you may not have considered the difference between Assembly and Configuration.

In Spring, there is practically no distinction between the two. It doesn't matter if you are going to change a port number, or change the implementation to be used for a bean.

In Qi4j, we thought very hard at this question long time ago.

  1. Configuration is a "live" entity, and can be updated in runtime, just like any entity, and saved if you choose a persistent store for it. It is primarily intended to be used for what we on the desktop call 'settings', not for 'installs'. The properties file for Configurations was intended as a bootstrap of configuration, and that many, at least in production, would use an persistent Entity Store for it.

  2. Assembly must happen before activating the application. There have been plans to allow for modifying the assembly in runtime, but no one has found it to be important enough to do the work.

  3. Since Assembly can change the implementations, it is very powerful to assemble variants of the same applications. For instance, perhaps in 'dev' you simply don't add the security concerns, or in production there is additional Audit SideEffects that goes to some dedicated system for that.

It sounds to me, that a lot of focus is on "Configuration", but I think the most exciting part will be in the different Assemblies.

To answer your questions;

* Configuration is tied strongly to Services. And can't be used with something else.

* Overhead of Services? Well, a service is a composite and each instance is in the same neighborhood of overhead as a Transient or Value. The Configuration is an actual Entity composite, so its overhead is identical. The only additional overhead is a hashmap for identities of services.

In general, strive for small cohesive parts and compose them into larger composites when needed. It is totally possible to have 5 interfaces and combine them all into a single Service at bootstrap, and when you use that large service, it is still visible as each of its composed interfaces.

Cheers

Niclas