userland vs SPI

[Mark Struberg]

Hi!

I'd like to share a few ideas and thoughts we've learned while doing Apache MyFaces CODI and DeltaSpike. Some might not so clear and other ideas might be be obvious and well known. But it's still good to speak them out and enlist them properly to have all the involved people talk about the exact same thing.

I'll gonna split my thoughts into separate mail threads and like to start with a fairly obvious but very important one. Actually one of the most important decissions we need to make

What audience does the spec target?

Imo there are 4 different groups of people, and all need a slightly different set of interfaces

1.) Users ('userland' developers) who program their applications and need some ways to 'query' for some active configuration. (please help me to find a  better term. Something which really sticks). This is the classical API.

2.) Users (operation folks) who need to configure the application to fit their environment. E.g. configure SOAP endpoints and define the login URL of the current environment. Is there a standard way for configuring those values?

3.) Users (operation-devs) who need to 'tweak' the container integration for javaee-config. Like applying a PKI chain for some configured values (or do you like to store db passwords in plaintext?). Another usage would be to add additional 'ConfigSources', e.g. picking values from an application database. This could probably be split into 'customisation' which is deployed inside the application vs one which is deployed on the container level. But this should not make much difference from the SPI. Actually this IS the SPI we imo need.

4.) Users (container vendors) who need to integrate the javaee-config mechanism into their container. Is this configuration container specific or javaee-config-impl specific? Or should this be part of the spec to allow people to exchange javaee-config impls or at least tweak them in a portable way? Example I think of is the PersistenceUnitInfo from the JPA spec. This could also ease other technologies to integrate with javaee-config. 

All those points surely need more detailed discussions once but it should be enough to clarify which parts we like to address. Also keep in mind that a good documentation/spec/project management doesn't only define what it likes to achieve but also to very clearly define the non-goals!

LieGrue,

strub 

[Antonio Goncalves]

Hi,

The Java EE 7 specification (EE.2.11) defines "Platform roles" :

* Java EE Product Provider

* Application Component Provider

* Application Assembler

* Deployer

* System administrator

* Tools Provider

* System component provider

I always found this a bit funny to standardize "roles" in an organisation, but it helps to figure out interactions sometimes. Maybe it's time to add new roles or change the definition of existing ones. In the spec, the Deployer is the one dealing with some sort of configuration.

Antonio

--
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/10482793-25ab-4242-afe8-a447220ee77d%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