High Level Components

[Anatole Tresch]

Looking at my experience through the years, I see only a few constructs being to be model to cover all discussed so far:

Config Values and Entries

Configuration values are the instances finally used by the code reading the configuration. They could be of type String, but also other types should be possible.

Basically each values has a corresponding key, to identify a value. This so far is a key/value pair, like

  mykey=myvalue

But with the important difference that the value is not required to be a String only.

Additionally a value has additional meta-data attributes, like its type, its location/source, etc. So the concrete value is stored along with the meta-data in a  ConfigEntry:

   ConfigEntry{

   String key;

   Object value;

   Metadata metadata;

 }

Config Units

A set of entries is managed as a config unit. Hereby structural aspects should be discussed like

• Should the entries mapped as a tree, allowing for easy traverersal?¨
• Or as a flat simple key-value table.

Config Scopes, Scope Spi

Different layers of configuration can be modeled as scopes, containing the scopes configuration units. Hereby each scope is loaded/provided by according ScopeProviderSpi. This allows configuration provided by any

kind of configuration source and any context.

Scopes hereby are contextual, a method boolean isScopeAvailable() allows to determine if a scope is active in the current context, or not. Additionally scopes loaded by the same provider with different runtime

context may be different.

Scope provided by default could be for example something like:

• GLOBAL
  
• LOCAL 
  
• SYSTEM-ENV
  
• SYSTEM-PROPERTIES
• APPLICATION_RESOURCE
• WEB_RESOURCE

Aggregates, Aggregate Spi

Finally an ordered list of scopes and (optionally) how each scope may override the other (previous) scopes, can be summarized in an Aggregate. Aggregates are defined by implementations of AggregateProviderSpi. One of the advantages of modeling aggregates

explicitly is that scopes can be reused, but using the aggregate concept different overriding strategies are possible. Aggregates allow to define and customize the configuration for every use case/usage family, e.g. DevOps or application config). Similar to scopes we might defined some default aggregates, e.g.

• SYSTEM
  
• APPLICATION (EAR)
  
• WEB (WAR)
  

Still there are points to be discussed, e.g. if an aggregate is available, when at least one contained scope is available, or if it is required, that all containing scopes included are available. May be also an option to support both variants.

Readers and ConfigLocations

What we also did here in Credit Suisse is that we decoupled the mechanism how to read configuration, from the location where it is finally located. Therefore we defined the concept of a ConfigReader, which is capable of resolving the abstract configuration location, or location patterns:

  ConfigurationReadResult result = reader.readConfiguration("cfg/GLOBAL**/*.xml",  "cfg/TEST**/*.xml");

  List<ConfigItem> itemsRead = result.getItems();

  List<String> sourcesRead = result.getLocations();

On a Scope, it is sufficient then to define the location patterns only, prefixed with the readerID, e.g.

  List<String> getConfigLocations(){

    return Arrays.asList(new String[]{
      "classpath:cfg/GLOBAL**/*.xml",  "classpath:cfg/TEST**/*.xml", "file:${projectDir}/TEST/*.xml", "datasource:testDB,table=TestConfig"

    });

  }

The ConfigurationService

Finally configuration can be accessed by a ConfigurationService singleton, e.g.

  Configuration config = ConfigurationService().getInstance().getConfig("myConfig"); // custom aggregate

  Configuration config2 = ConfigurationService().getInstance().getSystemConfig(); // default aggregate

CDI integration of all that above would be trivial, e.g.

  public class A{

    @Configured(aggregate=Aggregate.APPLICATION, value="a.b.c.d.myLDAPQuery")

    private String myLDAPQuery;

    @Configured(aggregate=Aggregate.APPLICATION, value="a.b.c.d.links")

    private Map<String, URL> links;

  }

or with defaults even only

  @ConfigScope(area="a.b.c.d")

  public class A{

    @Configured

    private String myLDAPQuery;

    @Configured

    private Map<String, URL> links;

  }

So I think now I will take a break and let see, what others think...

Cheers,

Anatole

[Werner Keil]

Allow me to add my 3 øre or Rupees;-)

What quite detailed concepts and ideas here are missing is either a "Tenant", an "Environment" (or "Stage" if you like JSF 2 added the halfhearted ProjectStage enum, rather worthless in real life projects but a first step;-) or both.

If you simply look at the demo section of Multiconf
https://github.com/lhupfeldt/multiconf/tree/master/demo

leaving aside the fact it's written in Python (though a scripting language could be any JVM language including Jython or Jython-based dialects like WLST) the demo defines 5 environments/stages

devlocal = ef.Env('devlocal')
devi = ef.Env('devi')
devs = ef.Env('devs')
preprod = ef.Env('preprod')
prod = ef.Env('prod')

Regardless of the name for this, there should be an Environment or Stage interface, allowing e.g. JSF 2.3 or 3.x code to pick up on it, too. Application.getProjectStage may either be tweaked to return such a Stage/Environment item, or (considering we have much uglier things in JSF like ActionSource and ActionSource2 ;-/) deprecated in favor of something like getStage() getEnvironment() etc. If the old enum is made compatible with the first "draft" for this in JSF 2, it could be made backward-compatible, but all of EE and SE/ME and this JSR requires such environment concept, too.

The plain directory based idea baked into Java Code (see the "TEST" above) could be made a bit more flexible if you override it like XML does today, but the Multiconf example shows how you can group things more easily there. Maybe it's just wording and that "Config Unit" goes in a similar direction, but it sounds a little abstract, if this became a concrete JSR proposal or draft, we might want to tweak wordings.

As for Multiconf, the project and library you find on GitHub is used by a somewhat enhanced "professional" edition in production for over a year now. And without disclosing too much, the target containers include 

• WebLogic/OFM
• JBoss
• Tomcat/Apache
• Jetty
• Play/Scala/Akka

As well as a few others where projects have special requirements. In one of the largest Corporare Private Clouds at least in Europe where the heterogenous nature of the overall landscape seems almost ideal as inspiration for a vendor-neutral approach we'll need here, too.

Cheers,

Werner

[Anatole Tresch]

Hi Werner

 

Modeling some kind of environment makes sense, but I think it is also important not to constraint, what environments are defined (consequently an enum would not be the best solution ;-) ). May be we define (tbd) some default environments/stages, but it should be extendible since different companies have different stagings in place (we have even different ones within our own company).

If we want to model a tenant explcitily for me is a question Given a flexible mechanism similar to above, extended with some filtering should be enough to model, what is required for multitenancy. A tenant configuration hereby can be modelled by simply adding an additional tenant scope, which may return configuration data on whatever the current tenant would be.

 

For me basically, as I said, we probably only require a few but powerful and combinable concepts. And for sure - we require a common understanding what these main concepts are and how they are named ;-)

 

Cheers,

Anatole

[Werner Keil]

On Tuesday, October 22, 2013 6:40:40 PM UTC+2, Anatole Tresch wrote:

Hi Werner

 

Modeling some kind of environment makes sense, but I think it is also important not to constraint, what environments are defined (consequently an enum would not be the best solution ;-) ).

That's exactly what I kept telling the JSF EG ever since 2.0 ;-D

[Julien Viet]

the Java Compiler API address this use case with javax.tools.Location interface and javax.tools.StandardLocation enum.

hope it helps.

Julien

--
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.

[Werner Keil]

While not considered to be a 1:1 blueprint, the general approach to Flows is certainly better in Java EE 7 / JSF 2.2 and you won't see a hard-coded or enum-bound flow there;-)

https://javaserverfaces.java.net/nonav/docs/2.2/javadocs/javax/faces/flow/package-summary.html

Accessed via Application.getFlowHandler()...

If the config JSR provided improved support for staging/multi-tenancy, something like an Application.getConfig*() method (-Handler, -Context or whatever turns out to be best) could be the future.

Allowing the old legacy enum to implement an interface (see what JSR 310 does with enums or the good old Josh Bloch advice) could make them compatible with a more flexible custom-defined way of adding stages of your own. Otherwise the whole ProductStage enum and getters for it might better be deprecated, that's equally possible and e.g. JSF followed that practice so far.

Werner

[Werner Keil]

That's the sort of interface with concrete implementations as an enum I was talking about.

Done the same in a custom implementation of Unit-API for a customer, too btw. If you don't need runtime flexibility to define new units in that case it is an option, while other use cases may prefer to define them at least in their code or even at runtime...

[Werner Keil]

Not to mention, the JSF Flow API made good use of CDI, too;-)

[Arjan Tijms]

Hi,

Good to see that this discussion has started :)

I noticed (correct me if I'm wrong) that up till now the discussion here has been very much focussed on essentially making key/value pairs available to the application.

An other aspect of configuration is the ability to swap out or augment the standard deployment descriptors. A specific sub-case of this is switching between a pre-defined set of deployment descriptors that reside within the application archive. A selection is then made based on a startup parameter.

This was the main thing being asked for in https://java.net/jira/browse/JAVAEE_SPEC-19

The use case is a devops team that works on an in-house developed and deployed application. The number of stages to deploy to is thus known in advance as is the configuration that belongs to each stage.

Placeholders in a single deployment descriptor and externally supplying values for those are an alternative, but not always sufficient. For instance, I may have a development filter that I only want to be present in the servlet filter chain for the LOCAL and DEV stages, but not for BETA, QA and certainly not for LIVE. I could of course programmatically check a parameter at the start of the main filter method and if it doesn't have the right value continue the chain immediately (making the filter's logic a NOOP), but in practice this is error prone. Much better would be to just completely exclude the Filter.

There are more examples, like e.g. an extra role that is mapped to a path for LOCAL and DEV, or an extra data source etc.

[Anatole Tresch]

Hi Arjan

This might look like, but I also was already considering this feature (therefore my remark about binary types):,

• values might be of any type, as far as they can be converted out of a String.
  
• now values could be
  
• numbers, e.g. 1,2,3, 1.5, 0xFF
• booleans, e.g. true, false, yes, no
• text, e.g. "myname", "%d-%b_dddd_MM_yyyy.txt"
• URIs, URLs, e.g. http://www.domain.ch:765/rest/MyService?id=sdghf&foo=bar
• URIs could also be used as resource locators, whereas some SPI implementation can read the resource., e.g. nfs://domain.com/deployment/myapp/MyDatasource.xml

With that we could make deployment resources configurable, though we must discuss, to what extend the mechanisms should be standardized (supported by spec/RI) or we just want to enable things, be providing mechanisms that are capable of handling that. In our company, we added the concept of ConfigConverterSpi, which is capable of converting a String configuration value into the target value requested by the code to be configured:

public interface ConfigConverterSpi{

  <T> T createConfiguration(Class<T> targetType, String key, Configuration configurationNode

});

  

This could even be generalized, using the adapter pattern:

public interface Configuration { ...

  <T> T adapt(Adapter<T> adapter, String key);

}

Hereby

public interface Adapter<T>{

  Collection<Class> getSupportedTypes();

  T adapt(Configuration cfg, String key);

}

Given such a mechanism we could also provide InputStream as a value type, so the consumer may read from the stream, using the configuration (reading) logic, that already is in place.

One other advantage is that our JSR does not have to define, how all the JSRs around will best beneift from a configuration JSR. In a EE context, I assume the EE8 EG can discuss this with the several

JSRs in place, whereas other non EE JSRs can support this JSR also independently. The configuration JSR is only providing the mechanisms...

Cheers,

Anatole

[Arjan Tijms]

Hi,

On Wednesday, October 23, 2013 6:02:03 PM UTC+2, Anatole Tresch wrote:

Hi Arjan

This might look like, but I also was already considering this feature (therefore my remark about binary types):,

• values might be of any type, as far as they can be converted out of a String.
  

I did notice that part ;) So with key/value pairs the value can obviously be a complex type.

public interface ConfigConverterSpi{

  <T> T createConfiguration(Class<T> targetType, String key, Configuration configurationNode

});

Perhaps a little off-topic to this JSR, or maybe not, but conversion from and to String is a rather general concept as well. JSF has its own Converter interface for this and via java.beans.PropertyEditorManager there actually is one in the standard JDK as well (I provided an example and some background for this at http://jdevelopment.nl/switching-data-sources-datasourcedefinition). Furthermore, JAX-B has its own converters and third parties like Apache BeanUtils have ones as well.

Maybe something like a Bean Conversion JSR as analogy to the Bean Validation one wouldn't be a bad idea. On the other hand yet another JSR and yet another layer may not really be beneficial for actually getting things done.

Given such a mechanism we could also provide InputStream as a value type, so the consumer may read from the stream, using the configuration (reading) logic, that already is in place.

One other advantage is that our JSR does not have to define, how all the JSRs around will best benefit from a configuration JSR. In a EE context, I assume the EE8 EG can discuss this with the several

JSRs in place, whereas other non EE JSRs can support this JSR also independently. The configuration JSR is only providing the mechanisms...

True, although just as with the hypothetical Bean Conversion JSR that I mentioned above, this may also make things more difficult.

First and foremost it should then be clearly understood that the Configuration JSR is not directly going to make deployment descriptors configurable. I.e. this Configuration JSR would not be the thing that directly solves JAVAEE_SPEC-19.

While reading from InputStream may indeed be an important building block, there should then still be a specification of some sorts that details how an external property arrives at a specific "part" (e.g. JSF, JPA etc) of a Java EE server. 

Also, instead of specifying the deployment descriptors for each sub-spec of Java EE individually, it would be convenient if you could start a Java EE server with e.g. "-Djavax.javaee.archive-alt-dd=META-INF/dev", causing all sub-specs that read deployment descriptors to consult that folder inside the application archive before consulting the regular location. Perhaps some additional options would be handy to say if you want an override (complete replacement) or an addition.

Furthermore, there was talk of having placeholders in deployment descriptors based on EL, and then there's the idea pioneered by JSF 2.2 that applications at start-up time can push raw configuration into the deployment descriptor loading chain (see e.g. http://jdevelopment.nl/jsf-22#533).

All of that would be best handled I think in an umbrella Configuration JSR, and not (or at least not all of it) left to each individual specification. If this JSR is not going to address these concerns then there might still be something needed like a "Java EE Configuration JSR". As this "Java EE Configuration JSR" would be building upon the "Java SE Configuration JSR" (this JSR), I guess it has to wait for that latter one then to be defined and implemented. This on its turn may make it hard to reach the Java EE 8 deadline.

From the presentation at http://www.jfokus.se/jfokus13/preso/jf13_JavaEEConfiguration.pdf I also thought that this JSR would already be that "Java EE Configuration JSR" (it's even the name of the document :P), but this is thus not the case?

Again, correct me if I'm wrong as I'm still trying to understand what the exact scope is, but would the Configuration JSR as currently discussed essentially be a kind of JAX-P/JAX-B for .properties files and system properties?

[Anatole Tresch]

Hi

On Wednesday, October 23, 2013 7:36:39 PM UTC+2, Arjan Tijms wrote:

Hi,

Perhaps a little off-topic to this JSR, or maybe not, but conversion from and to String is a rather general concept as well. JSF has its own Converter interface for this and via java.beans.PropertyEditorManager there actually is one in the standard JDK as well (I provided an example and some background for this at http://jdevelopment.nl/switching-data-sources-datasourcedefinition). Furthermore, JAX-B has its own converters and third parties like Apache BeanUtils have ones as well.

Maybe something like a Bean Conversion JSR as analogy to the Bean Validation one wouldn't be a bad idea. On the other hand yet another JSR and yet another layer may not really be beneficial for actually getting things done.

Yes, you are right. But I think we have to find an feasible scope so I tend tonot create another Bean Conversion JSR. Additionally in our case, perhaps only conversion from String to something else is a topic, not the other way round...??

First and foremost it should then be clearly understood that the Configuration JSR is not directly going to make deployment descriptors configurable. I.e. this Configuration JSR would not be the thing that directly solves JAVAEE_SPEC-19.

I am quite open. Basically we should tailor a JSR, which at the end brings us one big step ahead and nevertheless is feasible according to timeline and risk. I am quite sure that we will not be able to solve everything in a first release. What such a first version at the end contains, should be part of the scope discussions here ;-)

 

While reading from InputStream may indeed be an important building block, there should then still be a specification of some sorts that details how an external property arrives at a specific "part" (e.g. JSF, JPA etc) of a Java EE server. 

Also, instead of specifying the deployment descriptors for each sub-spec of Java EE individually, it would be convenient if you could start a Java EE server with e.g. "-Djavax.javaee.archive-alt-dd=META-INF/dev", causing all sub-specs that read deployment descriptors to consult that folder inside the application archive before consulting the regular location. Perhaps some additional options would be handy to say if you want an override (complete replacement) or an addition.

Furthermore, there was talk of having placeholders in deployment descriptors based on EL, and then there's the idea pioneered by JSF 2.2 that applications at start-up time can push raw configuration into the deployment descriptor loading chain (see e.g. http://jdevelopment.nl/jsf-22#533).

That post looks very interesting. Perhaps we should put together a list of what are the configuration artifacts overall that could benefit from being configured using our JSR. Maybe we can prioritize them ans think on how concrete we can support them best.

 

All of that would be best handled I think in an umbrella Configuration JSR, and not (or at least not all of it) left to each individual specification. If this JSR is not going to address these concerns then there might still be something needed like a "Java EE Configuration JSR". As this "Java EE Configuration JSR" would be building upon the "Java SE Configuration JSR" (this JSR), I guess it has to wait for that latter one then to be defined and implemented. This on its turn may make it hard to reach the Java EE 8 deadline.

Again, for me the question is, how big a JSR'scope should be.in the first release. There are quite a couple of things to consider. My experience shows that you will have to boil down things to a minimum to be successful at the end.

 

From the presentation at http://www.jfokus.se/jfokus13/preso/jf13_JavaEEConfiguration.pdf I also thought that this JSR would already be that "Java EE Configuration JSR" (it's even the name of the document :P), but this is thus not the case?

Similar to the presentation at JavaOne, we are basically discussing the same proposal. Nevertheless I think there are at least two different aspects contained within that presentation:

- Configuration of shared resources (more a DevOps focus)

- Configuration of deployed applications (more an application, multilayer, multi-tenancy-focus)

 

Both aspects IMO share some important points. Most of them could be done in a standalone JSR with EE in mind, like Antonio suggested also. Additionally, when we concentrate on the bate main mechanisms here and try to keep other complexities out of the scope, we have a chance, that we are quite fast with a first release of the JSR. It would indeed then make sense, to add a second EE umbrella spec also. Also here, I myself do not have yet the best solution ready. I think it would be also a good idea to talk about this within the EE EG to have more opinions on what would be a good setup.

Again, correct me if I'm wrong as I'm still trying to understand what the exact scope is, but would the Configuration JSR as currently discussed essentially be a kind of JAX-P/JAX-B for .properties files and system properties?

I think, we have significant more here in scope. I just try to discuss, how we can minimize the JSR's scope, but nevertheless may achieve the most important requirements.

Summarizing I would try to say:

• one key point is, how far we want to go in defining EE integration/EE support by this JSR, i.e. if we want to have a separate EE umbrella. From a JSRs scope, it makes sense, but may be challenging to get on the EE train.
• Another option could also be, to define - as you somehow suggested - some default mappings from configuration to beans, usable then
• for datasources
• and all kind other code artifacts using Java Bean semantics
• other target types relevant for EE
• I think we have to live with Java SE as it is. I think a Bean Conversion JSR will be beyond the scope that is feasible.

WDYT?

[Werner Keil]

It isn't more than PR diagrams for now, but what WebLogic 12.1.4 (quite an understatement in the version number I'd say, given it shall also bring full Java EE 7 support;-) plans for multi-tenancy and "templating" will also be relevant to configuration, both of this and future (EE8/Config JSR compliant) versions: http://technology.amis.nl/2013/10/20/the-road-ahead-for-weblogic-12c/

Werner

[Arjan Tijms]

Hi

On Wednesday, October 23, 2013 9:53:44 PM UTC+2, Anatole Tresch wrote:

Again, for me the question is, how big a JSR'scope should be.in the first release. There are quite a couple of things to consider. My experience shows that you will have to boil down things to a minimum to be successful at the end.

This is indeed important.

Summarizing I would try to say:

• one key point is, how far we want to go in defining EE integration/EE support by this JSR, i.e. if we want to have a separate EE umbrella. From a JSRs scope, it makes sense, but may be challenging to get on the EE train.
• Another option could also be, to define - as you somehow suggested - some default mappings from configuration to beans, usable then
• for datasources
• and all kind other code artifacts using Java Bean semantics
• other target types relevant for EE
• I think we have to live with Java SE as it is. I think a Bean Conversion JSR will be beyond the scope that is feasible.

WDYT?

The Bean Conversion JSR was indeed just a thought and would be too ambitious now. Maybe at a later stadium (Java EE 9?) it might make sense to look at all the different specs and see if all the different ways in which they all do String to Object conversion can somehow be abstracted.

As for the other points, I still have a hard time wrapping my head around it to be honest. The most difficult issue seems to be the Java SE focus.

Maybe it's an idea to actually find out where Java SE support is exactly needed for. Is this just (or mainly) to support Tomcat? What other really important Java SE use cases are there these days? Command line utils like Maven and Ant? IDEs like Eclipse and Netbeans? Is there anything else that's really important?

It now mostly looks like this JSR seeks to implement an alternative to Java SE's System.getProperty and Java EE's @Resource injection for simple values, ServletContext.getInitParameter and a JNDI lookup for java:comp/env/. The last two as are currently defined in web.xml as <context-param> and <env-entry>.

But if the focus of this JSR is Java SE, how easy would it be to really provide an alternative for @Resource, ServletContext.getInitParameter etc?

Wouldn't it be easier perhaps to focus on Java EE, as that is (AFAIK) the place where advanced configuration is most needed. Maybe it's because I haven't been really involved with pure Java SE code for some time and I could easily be missing a use case, but for my Java SE application System.getProperty basically worked for me. For my Java EE applications I almost always code up some kind of "ApplicationSettingsService", e.g.

@Startup

@Singleton

@ConcurrencyManagement(BEAN)

public class ApplicationSettingsLoader {

private static final Logger logger = Logger.getLogger(ApplicationSettingsLoader.class.getName());

private Map<String, String> settings;

@PostConstruct

public void init() {

Map<String, String> mutableSettings = new HashMap<>();

String earBaseUrl = getEarBaseUrl();

loadXMLFromUrl(earBaseUrl + "/conf/application-settings.xml", mutableSettings);

String stage = getProperty("app.stage");

if (stage != null) {

loadXMLFromUrl(earBaseUrl + "/conf/" + stage + "/application-settings.xml", mutableSettings);

}

settings = unmodifiableMap(mutableSettings);

}

@Produces

@Named("applicationSettings")

@ApplicationSettings

public Map<String, String> getSettings() {

return settings;

}

@Produces

@ApplicationSetting

public String getStringSetting(InjectionPoint injectionPoint) {

String value = settings.get(injectionPoint.getMember().getName());

if (value == null) {

for (Annotation annotation : injectionPoint.getQualifiers()) {

if (annotation instanceof ApplicationSetting) {

value = ((ApplicationSetting) annotation).defaultValue();

break;

}

}

}

return value;

}

        // ...

}

But this is just one part of configuration in Java EE; access to (mostly) simple settings in application code. 

Two other important parts are swapping out and augmenting deployment descriptors, as well as the ability to use placeholders (EL) in those deployment descriptors, e.g. in web.xml or application.xml:

<data-source>

    <name>java:app/someDS</name>

    <class-name>org.example.Something</class-name>

    <url>jdbc:someDB</url>

    <user>${mycompany.someDS.user}</user>

    <password>${mycompany.someDS.password}</password>

</data-source>

Or in web.xml:

<context-param>

    <param-name>javax.faces.FACELETS_REFRESH_PERIOD</param-name>

    <param-value>${empty facelets.refresh? -1 : facelets.refresh}</param-value>

</context-param>

This is thus about configuring Java EE itself, which is currently not entirely trivial. I would really hope that a configuration JSR for Java EE addresses this and not just focus on making values available to application code.

You could say that optionally all specs could get their values from the configuration JSR, and this would probably work for the javax.faces.FACELETS_REFRESH_PERIOD example above, but not I think for the earlier data-source example. The data source is defined in web.xml by those tags. I'm not entirely sure how a "mapping from configuration to a bean" would be able to actually define a data source.

 

[nicolas de loof]

Wouldn't it be easier perhaps to focus on Java EE, as that is (AFAIK) the place where advanced configuration is most needed. Maybe it's because I haven't been really involved with pure Java SE code for some time and I could easily be missing a use case, but for my Java SE application System.getProperty basically worked for me. 

How do you manage system properties for such an application ? Do you have some external launch script to set them all ? How do you version it and distribute to various environments ? This is EXACTLY the question I expect this JSR to address.

 

[Arjan Tijms]

On Wednesday, October 30, 2013 10:22:32 PM UTC+1, nicolas de loof wrote:

Wouldn't it be easier perhaps to focus on Java EE, as that is (AFAIK) the place where advanced configuration is most needed. Maybe it's because I haven't been really involved with pure Java SE code for some time and I could easily be missing a use case, but for my Java SE application System.getProperty basically worked for me. 

How do you manage system properties for such an application ? Do you have some external launch script to set them all ? How do you version it and distribute to various environments ? This is EXACTLY the question I expect this JSR to address.

My Java SE applications have been extremely modest. Mostly some command line utils for scanning log files, an indexer, that sort of stuff. For those the configuration needs were equally modest. In most cases regular command arguments were already sufficient.

At least in my experience, Java EE applications are typically the much larger things that thus almost automatically have much larger configuration needs. This is why I also asked what the typical Java SE use cases are these days. I personally have not seen e.g. large (enterprise) Swing based applications for a long time, but maybe I'm just missing an obvious use case.

What would be handy for Java SE and Java EE servers (which themselves are almost always a Java SE app) would be the ability to specify a .properties file, such that all properties in there would be accessible as-if they were individually set as -D parameters.

E.g.

java -Dfoo=1 -Dbar=2 MyClass

and

java -propertiesFile=~/myfile.properties

I think the IBM JDK had something like this via the -Xoptionsfile

But that's digressing a bit. 

The point I tried to make is that Java SE and Java EE configuration partly have very different requirements. Deployment descriptors are an extremely important part of Java EE and its deeply rooted in all that Java EE does. If the configuration JSR wants to have any meaning for Java EE, then IMHO it really should address deployment descriptors.

[nicolas de loof]

typical JavaSE use case is Batch. Don't forget them, they are a significant percentage of Java "enterprise" development that wasn't addressed by JavaEE spec until recent interest

2013/10/30 Arjan Tijms <arjan...@gmail.com>

--

[Anatole Tresch]

Hi

On Wednesday, October 30, 2013 9:31:31 PM UTC+1, Arjan Tijms wrote:

As for the other points, I still have a hard time wrapping my head around it to be honest. The most difficult issue seems to be the Java SE focus.

I see a couple of advantages when building the JSR basically as a standalone SE one:

• Like BeanValidation it still can be integrated into EE.
• When thinking of configuration of shared resources, e.g. global datasources, shared EE extensions, transaction managers... we also have advantages running as a "standalone" component. 
• When looking at how configuration is assembled in our bank, it is a mixture of global/shared aspects with aspects that are contextual (depending on the runtime context). DevOps related configuration basically is read and used before any ears/wars are loaded, so there is also no CDI available so far (this may change with CDI 2.0...). Application (or ear levelled) configuration is much more contextual (we have the ability to deploy configuration also with the application code, as well by external resources).

 

Maybe it's an idea to actually find out where Java SE support is exactly needed for. Is this just (or mainly) to support Tomcat? What other really important Java SE use cases are there these days? Command line utils like Maven and Ant? IDEs like Eclipse and Netbeans? Is there anything else that's really important?

I would ask also the question the other way round. Do we need EE, for supporting EE? 

 

It now mostly looks like this JSR seeks to implement an alternative to Java SE's System.getProperty and Java EE's @Resource injection for simple values, ServletContext.getInitParameter and a JNDI lookup for java:comp/env/. The last two as are currently defined in web.xml as <context-param> and <env-entry>.

Definitely not.  We have also very complex scenarios in mind, e.g. configuration specific to network zones, tiers, servers, ears, applications, ear deployments, products and plugins, to mention some. Just overriding System.getProperty() will definitely not be enough.

 

But if the focus of this JSR is Java SE, how easy would it be to really provide an alternative for @Resource, ServletContext.getInitParameter etc?

Providing filtering mechanism, that can be used e.g. by JSF...? The mechanism would be defined on SE level, as a global service, but can be used by EE also. Contextual behaviour for application configuration, may be still built using CDI within config implementations.

 

Wouldn't it be easier perhaps to focus on Java EE, as that is (AFAIK) the place where advanced configuration is most needed. Maybe it's because I haven't been really involved with pure Java SE code for some time and I could easily be missing a use case, but for my Java SE application System.getProperty basically worked for me. For my Java EE applications I almost always code up some kind of "ApplicationSettingsService", e.g.

One important thing is I do not see a platform scope, it is NOT the target having it included as part of Java SE 9 or similar. I would suggest a standalone scope, which makes it usable in different SE and EE (and perhaps also ME) scenarios. For EE the config SPIs can be implemented using EE features (e.g. for implementing contextual configuration behaviour), integration with CDI should be easy.

 

Two other important parts are swapping out and augmenting deployment descriptors, as well as the ability to use placeholders (EL) in those deployment descriptors, e.g. in web.xml or application.xml:

<data-source>

    <name>java:app/someDS</name>

    <class-name>org.example.Something</class-name>

    <url>jdbc:someDB</url>

    <user>${mycompany.someDS.user}</user>

    <password>${mycompany.someDS.password}</password>

</data-source>

Or in web.xml:

<context-param>

    <param-name>javax.faces.FACELETS_REFRESH_PERIOD</param-name>

    <param-value>${empty facelets.refresh? -1 : facelets.refresh}</param-value>

</context-param>

This is thus about configuring Java EE itself, which is currently not entirely trivial. I would really hope that a configuration JSR for Java EE addresses this and not just focus on making values available to application code.

As mentioned for me one thing worth to think about is, if the JSR should rather provide a general mechanism (API/SPI) to unify all the different configuration aspects, instead of explicitly require other JSRs or even vendors to use it explicitly.

 

You could say that optionally all specs could get their values from the configuration JSR, and this would probably work for the javax.faces.FACELETS_REFRESH_PERIOD example above, but not I think for the earlier data-source example. The data source is defined in web.xml by those tags. I'm not entirely sure how a "mapping from configuration to a bean" would be able to actually define a data source.

One possibility would be to define some kind of URI (as configuration), and use an Adapter to access the concrete configuration (returning a InputStream, a URL, or a XML document), which can then be arbitrary complex. That should also work for datasources, JMS queues etc....

 

-Anatole 

[Antonio Goncalves]

As for the dilemma "targeting Java SE and/or Java EE", I would suggest that we start thinking in Profiles. At the moment, Java EE has two profiles "Web and Full". It looks like CDI 2.0 will follow the same idea (maybe it will be called "Embedded" so it can be easily embedded in other specs). We could maybe do the same. Have a "Java SE" profile so it can be used like BeanValidation or JPA in a standalone way, but also a "Java EE profile" that would benefit from the container (injection and so on). Then, only the "Java EE" profile could go under Java EE 8. So we could think of 3 components : a core component, a javase and a container.

my2cents

--

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
Software architect and Java Champion

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

[Werner Keil]

+1 for Profiles

-1 for "Embedded", that dilemma already plagues projects like Arquillian (hope not the reason why the species nearly got extinct?;-) and the gathering of EE affine people including most who participate here also showed that problem.

"Embedded Profile" for Java SE means something different, and the term "Java Embedded" has become distinct for embedded and small devices, so let's not add more confusion than the usage of these terms already caused.

"included" at least when you refer to specs may sound better, otherwise the good old "injected" and "injectable" would sure work, though CDI at least has used and defined that in its own way. 

Werner Keil | JCP Executive Committee Member | Eclipse UOMo Lead, Babel Language Champion | Java Godfather

[Anatole Tresch]

Hi all,

makes sense. In JSR 354, we also did something similar. The singleton accessors defined by the RI are backed up by a SPI that is loaded using the ServiceLoader. This SPI explicitly is meant to behave contextually in the context of EE, allowing to benefit also for loading any subsequent (sub) components and SPIs. Most of the functionality is contained in the common area. For each profile an according "umbrella artifact" can be used as dependency, e.g.

xxx-se for SE, xxx-cdi for CDI, ...

This would be an option we may also follow here.

-Anatole