Scope of a possible JSR

[Anatole Tresch]

When thinking on a possible JSR I see different options possible:

• we can define it as a EE only JSR, which then may be part of EE 8.
• we can define it as a standalone JSR, which would be usable also in SE.

Here some thought I see as advantages defining it as standalone JSR:

• When looking at requirements that configuration should also support application server configuration (if supported by the vendor), configuration must also be available and accessible outside of an EE context (in the system classpath). Saying that we require a configuration service that basically must be executable in standalone mode.
• A configuration service, defined standalone, still must support different configuration scopes (somehow similar to contexts in CDI). Therefore, even when defined on SE, it will be usable also in a EE context.
• Basically when configuration is defined standalone, also non EE environments, such as Jetty, or Tomcat can use it easily (but that might also be possible for an EE variant).
• We do not directly have impact on application server vendors, which may reduce complexity in such a JSR.
• DevOps aspects can be easily supported (but not defined!)

On the other side there are also some disadvantages:

• Targeting/integration with EE might be more complex, since EE is only a partial aspect.
• We might not be able to assume CDI as a precondition, so in some areas, we probably would have to go for some extra miles.

So, what do you think?

[nicolas de loof]

I also think this should be a standalone-JSR, targeting SE. 

I don't see EE to be more complex in this context. If you can configure a resource/parameter to a standalone JRE, why wouldn't it be complex to do the same on EE container assuming you provide the adequate SPI ? 

CDI is another topic. I think the configuration has to be accessible with base API - I like the good old System.getProperty, that already can be used to configure most existing frameworks. We for sure can define some integration capabilities within CDI to make it nicer, and for sample support datatype conversion or access to complex, structured data

[Anatole Tresch]

The thing is that a standalone JSR should also work in a EE context. This also a precondition, when we want to have a chance that also further EE JSRs would support such a configuration JSR in the future, thus enabling cloud configuration for the whole EE stack. And when you go into EE, you will have some additional complexities, that are not coverable using system properties. System (and environment) properties work well, for global settings (e.g. on VM/domain level), but because of their global characteristics are not feasible on ear or war level. 

In general I think we require the possibility to read configuration from arbitrary sources. Different vendors (or companies) have different ways to define/distribute/consume configuration and there will not be any common consense, what is the best way to go here. As an example:

- one wants to provide configuration as local files, or access it as a loadable jar file from a maven repository.

- others may want to use a database for storing the configuration.

- others may have rest/SOAP services defined in their SOA layers.

- other even do a combination of all

- others may use a distributed data grid like Hazelcast

- ... (the possibilities are endless)

Additionally there are also the topics of configuration defaults and overriding of configuration. In this context application code (ears, wars, or even smaller units like products and modules) may ship out of the box with according default values, that may be overridden by the concrete (deployment specific) configuration, or by more detailed/finer grained layers. This use cases also have similar complexities, since any thinkable combination of applications, products, features etc. will be possible. When thinking on framework design additional layers to domain/ear/war would be required, that such a JSR should support, too.

Summarizing configuration for me is not a unidimensional collection of system properties or values. I personally see it as an ordered collection of unidirectional graphs (or trees?), where the ordering defines the overriding relationships, We may discuss how far we want to go in enabling the possibilities of overriding mechanisms, such as combination, replacement, exclusion etc.

The good thing is, that all the complexities so far mentioned can be modelled by only a few powerful and simple concepts:

Final Value (any type), ConfigEntry, ConfigUnit, Scopes, Configuration(aggregate), ConfigurationService

CDI, I agree is just on top of it, as a glue layer. We should be careful to not rebuild CDI once more ;-)

 

[nicolas de loof]

>  System (and environment) properties work well, for global settings (e.g. on VM/domain level), but because of their global characteristics are not feasible on ear or war level. 

Why ? This is just a classloading problem / interception for System.getProperty() to make it application-local can solve this

 

> In general I think we require the possibility to read configuration from arbitrary sources. Different vendors (or companies) have different ways to define/distribute/consume configuration and there will not be any common consense, what is the best way to go here. As an example: ...

This is implementation detail for application container on way to store and access configuration. JSR should not focus on this, but define common contract.

I can understand benefit for an higher-order configuration API, but my concern is that it does have to rely on existing configuration practices - most common is System.properties as placeholders (typically Spring-based applications). If new API is the sole way to access configuration we will have to wait for a decade for frameworks then users to adopt it.

(please enable replying to group by email, can't use inline commenting within google groups web UI)

[Anatole Tresch]

On Sunday, October 20, 2013 9:45:02 AM UTC+2, nicolas de loof wrote:

>  System (and environment) properties work well, for global settings (e.g. on VM/domain level), but because of their global characteristics are not feasible on ear or war level. 

Why ? This is just a classloading problem / interception for System.getProperty() to make it application-local can solve this

 

This is on the Java platform level, no way to intercept this. OpenJDK will also never be adapted to support such a feature.

 

> In general I think we require the possibility to read configuration from arbitrary sources. Different vendors (or companies) have different ways to define/distribute/consume configuration and there will not be any common consense, what is the best way to go here. As an example: ...

This is implementation detail for application container on way to store and access configuration. JSR should not focus on this, but define common contract.

Completely agree. 

 

I can understand benefit for an higher-order configuration API, but my concern is that it does have to rely on existing configuration practices - most common is System.properties as placeholders (typically Spring-based applications). If new API is the sole way to access configuration we will have to wait for a decade for frameworks then users to adopt it.

Perhaps you to clarify that for me. Using .properties files to store configuration is not a problem for me, and yes, should be possible out of the box (though there are good reasons not to do so).

Providing a possibility to access configuration as java.util.Properties or java.util.Map could also be discussed.

[nicolas de loof]

no way to intercept it ? 

why not ? AOP and classloader transformation can do this easily. 

[nicolas de loof]

Perhaps you to clarify that for me. Using .properties files to store configuration is not a problem for me, and yes, should be possible out of the box (though there are good reasons not to do so).

Providing a possibility to access configuration as java.util.Properties or java.util.Map could also be discussed.

This is not about using properties file or whatever format to store data, but to get System..getProperty() "localized" to container.

This is de-factor standard

[nicolas de loof]

To resume my expectation on this JSR :

1. MANAGEMENT, not just configuration API. If you don't include a standard and Ops-compliant way to declare/update/query configuration from system script this will just be another useless spec for operational point of view. Just a new API will be huge effort just to standardize a framework - I've user apache commons-configuration for years for sample, and lots of other (better) framework exist

2. not reinvent the wheel. I'm fine with new API, CDI integration, etc, as long as this is a higher-level entry point but still use existing configuration models. Spring apps, Play apps, most JavaEE frameworks, do use system properties. Don't forget them.

2013/10/20 nicolas de loof <nicolas...@gmail.com>

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

[Antonio Goncalves]

Hi all,

As for the scope of this JSR, it should be SE based with EE in mind. We have several examples and should do the same :

How to get an EntityManager or a Bean Validator in Java SE ?

EntityManagerFactory emf =Persistence.createEntityManagerFactory("coursePU");

EntityManager em = emf.createEntityManager();

ValidatorFactory vf = Validation.buildDefaultValidatorFactory();

Validator validator = vf.getValidator();

How to get an EntityManager or a Bean Validator in Java EE ?

@PersistenceContext

private EntityManager em;

@Inject

private Validator v;

So I expect to have the same for the config : 

ConfigServiceFactory csf = Config.createConfigServiceFactory();

ConfigService cs = csf.createConfigService();

The EE container is then responsable to manage the lifecycle of the ConfigService. So when you are running inside the container, you just go : 

@Inject

private ConfigService cs;

> enabling cloud configuration

During the EE 8 meeting we had at J1, it looks like we won't have any Cloud in the next release, so let's make it simple for a v1.0, and leave the ConfigService to configure a single app running on a single node. Then we will see for a 1.1 or a 2.0.

Some information about the future. It looks like CDI 2.0 will have an "embedded profile". We can get Pete Muir to work with us on this, but if it's the case, then having basic CDI will be easy and cheap (small footprint and small dependency). It would be easier to rely on CDI (like some specs already do like JTA 1.2 or JSF 2.2) and not reinvent the wheel.

Another information. It looks like JMX 2.0 is starting again. If it's the case, we should contact them and see what's happening in this space (I know one idea was to have REST interface to an MBean). Having MBeans on JavaConfig would be a plus.

Antonio

[Werner Keil]

I would be more comfortable if it didn't rely on AOP.

Spring has some fancy variants for JPA templates via AOP and I saw projects with large clients getting themselves into a horrible mess that way...

I assume you only mentioned it as an example, not suggested to explicitely use it?;-)

[nicolas de loof]

just a sample, my first idea was to use a ClassFileTransformer to intercept System.getProperty and make it container-local. This is really a JavaEE implementation detail, maybe we just don't need to consider this option and have the same global system properties injected on all apps. JavaEE don't offer application isolation anyway (I don't think we want to start a multi-tenancy JSR here :P). 

For your information, at CloudBees we use a javaagent to inject system properties from platform configuration store. So we can inject config to any container. Resource injection is another stuff, that require container specific code as there's no standard API to programmatically manage resources - but here we are.

 

2013/10/22 Werner Keil <werne...@gmail.com>

I would be more comfortable if it didn't rely on AOP.

Spring has some fancy variants for JPA templates via AOP and I saw projects with large clients getting themselves into a horrible mess that way...

I assume you only mentioned it as an example, not suggested to explicitely use it?;-)

--

[Mark Struberg]

+1 for standalone SE JSR.

The CDI part is nice to have, but easy to do as additional add-on. 

We should also be able to rely on JSR-330 for the spec - except @Nonbinding. But we've had the same issue in JBatch already (@JobProperties). But not sure how Spring dealt with it yet.

LieGrue,

strub

[Antonio Goncalves]

Just to let you know that CDI 2.0 will do "its best" to get splitted into several parts (dependency injection, scoping, bean discovery, events...). We will quickly know if this is doable or not. If yes, why not depend entirely in the "CDI Injection part" (knowing that CDI 2.0 will bring bootstraping in Java SE) ?

--

You received this message because you are subscribed to the Google Groups "java-config" group.
To unsubscribe from this group and stop receiving emails from it, send an email to java-config...@googlegroups.com.
Visit this group at http://groups.google.com/group/java-config.

To view this discussion on the web visit https://groups.google.com/d/msgid/java-config/233bd0fc-edbc-48b3-bc34-49d919b6bde3%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Antonio Goncalves
Software architect, Java Champion and Pluralsight author

Web site | Twitter | LinkedIn | Pluralsight | Paris JUG | Devoxx France

[Anatole Tresch]

That also matches my short discussion with Antoine Sabont Durant. If we have CDI 2.0 also enabled on SE/system level, we can benefit from its capabilities instead of building them up ourselves.

To view this discussion on the web visit https://groups.google.com/d/msgid/java-config/CA%2BZZq991J9pbVk7NOm%3DqVfYTFKnr6iV3Jw19CbjpDmAQJ7yYxA%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

--

Anatole Tresch

Java Lead Engineer, JSR Spec Lead
Glärnischweg 10
CH - 8620 Wetzikon

Switzerland, Europe Zurich, GMT+1

Twitter:  @atsticks

Blogs: http://javaremarkables.blogspot.ch/

Google: atsticks
Mobile  +41-76 344 62 79

[Mark Struberg]

This is also a chicken and egg problem. 

In DeltaSpike we did split this cleanly between the pure Java part with ConfigSource and ConfigResolver and the CDI part with @Exclude, @ConfigParam, etc.

The *huge* benefit in doing so is that you can use the configuration mechanism inside your CDI Extensions! If you would rely on CDI for the whole mechanism, then you would again need something else to configure your Extensions...

LieGrue,

strub

[Antonio Goncalves]

Really interesting point.... I'll talk to the CDI 2.0 guys about this.

To view this discussion on the web visit https://groups.google.com/d/msgid/java-config/6cb165d4-c383-4a0e-87b6-424c56070867%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Anatole Tresch]

Hi all,

Yep, that is correct. Currently there is much discussion ongoing with Oracle about the scope of the Java EE configuration JSR. The scope we discussed as of now was quite wide, which IMO makes sense, since configuration is a common concept. Java EE configuration will quite probably focus more on EE interoperability and Oracle definitively wants to have the SE scope to be excluded. So I assume

• that the EE configuration JSR (1) will focus on portability and configuration of EE aspects (mainly deployment descriptors). Hereby I really want to see this JSR to enable the possibility to feed its content from an external source.
  
• that we might start another SE/standalone configuration JSR (2), where we will focus on the other aspects going beyond EE, or required to feed an EE configuration source.

This also has the advantage that we can really focus on configuration and its complexities in (2) and are basically not constraint to the EE 8 timelines as in (1). Also it will reduce scope in (2), since EE is supported, but not directly required. Similar is for (1), where focus is on EE related aspects only (which is still huge).

I thing these things will sort out within the next days/weeks.

Regards,

Anatole

 

To view this discussion on the web visit https://groups.google.com/d/msgid/java-config/6cb165d4-c383-4a0e-87b6-424c56070867%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

[Antonio Goncalves]

"we might start another SE/standalone configuration JSR (2)"

This is something I really want to address at a Java EE level. I think that a spec could be splitted in different "parts" (let's call it like that for now, as Profile / Module are already used). So that could mean JConfig could be splitted in several parts, at least EE and SE. Same spec, but different use cases.

Just for thoughts...

To view this discussion on the web visit https://groups.google.com/d/msgid/java-config/CAFJiDbdsi-kKXtvC%3D63kZy95bF%2BURPTVOY11_7zUk3in3ay95A%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.