[java-config] Staging

[Antonio Goncalves]

Hi all,

Configuration also comes with staging. This is maybe something we can talk about first, and then, if we think it's appropriate to standardize it, take it to the Java EE level. At the moment, only JSF mentions staging : https://blogs.oracle.com/rlubke/entry/jsf_2_0_new_feature2

The other specs do not mention it at all. We could maybe try to define a standard EE staging, but more important, having a way so projects can extend the model and create then own staging.

So, in my radar I have JSF 

• Development
  
• UnitTest
  
• SystemTest
  
• Extension
• Production

and DeltaSpike (http://deltaspike.apache.org/projectstage.html) : 

• Development
  
• UnitTest
  
• SystemTest
  
• IntegrationTest
  
• Staging
  
• Production
  

So do you think we should digg that a bit and bring it to EE (so every spec takes staging into account) ?

--
Antonio Goncalves
Software architect and Java Champion

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

[nicolas de loof]

Why should we standardize various environment ? Any team may have distinct intermediate steps between dev and production, or various production targets.

What we need is just to embrace multi-environment.

2013/10/30 Antonio Goncalves <antonio....@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.

[Anatole Tresch]

Hi all,

I would not do that. As Nicolas mentioned there are plenty of variants here. Even in Credit Suisse we have different stages within the same company, since big application families have their own additional staging mechanisms. Additionally there are also multiple deployments of the same application/service in two different versions within the same stage (e.g. productive test environments). Finally configuration must also be filtered, identified based on additional properties:

- stage

- tier

- target platform/OS

- SLA

- deployed server

- network zone

- legal unit

- security aspects

So I would to say, we need a flexible definition, what a runtime Environment is (stage is a very important, but very flexible setup), and how configuration is selected/filtered for a concrete runtime environment/context. Similarly we need a flexible SPI that defines what the current Environment is, since this is also user specific.

-Anatole

[Antonio Goncalves]

Sorry, I didn't explain it clearly. I'm talking about the Java EE plateform, not the projects.

The idea is more to standardize a way to define staging (e.g. in a type safe way like DeltaSpike) and then take it to Java EE. Java EE can then standardize staging at the plateform level. That would mean that is you run the app server in "Development", Bean Validation will increase its logs to DEBUG, the EJB container will not optimize pool threads and so on. At the moment, only JSF uses this staging to change it's behavior. 

So, if we define a way "to define staging", the EE platform can use it internally with its own lifecycle (e.g. dev, test, integration, prod) and projects can have their own lifecyle. But both will be defined with the same paradigms.

--

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.

[nicolas de loof]

I'm not sure I like this feature. If application server changes it's behavior when I run my app on development then I can't reproduce production bugs.

2013/10/31 Antonio Goncalves <antonio....@gmail.com>

[Antonio Goncalves]

That's already what happens with JSF. I'm gonna ask Ed Burns what exactly is made internally. I'll keep you posted.

[Antonio Goncalves]

Email from Ed Burns : 

"Yes, we do behave differently depending on staging.  There are two

levels:

1. Spec assertions that declare what implementations may or must do based on ProjectStage.

Search the JSF PDF for ProjectStage and you'll find things like:

2.6.1.4 An implementation may perform caching of resource metadata to
improve performance if ProjectStage is ProjectStage.Production.

3.6.2.1 If ProjectStage is Development, the "displayName",
"shortDescription"...are exposed using the corresponding methods on the
composite component BeanDescriptor.

6.2.3 If ProjectStage is Development, the runtime must guarantee that
the above debug information is available to be included in any Facelet
based error page using the <ui:include> with a src attribute equal to
the string javax.faces.error.xhtml.

7.4.2 If none of the above steps found a matching <navigation-case>, if
ProjectStage is not Production, render a message in the page that
explains that there was no match for this outcome.

There are several others.

2. Whatever implementations want to do based on ProjectStage.

The spec can't say anything about this, but I know some impls do things
based on this."

If we standardize a way of define stages (again, I think the type safe one from DeltaSpike could be a good start), then I can take it back to Java EE. Java EE could standardize a staging lifecycle that all the specs could implement and do then own think.

[Anatole Tresch]

Hi all,

OK, I think I got the point. Perhaps this would be an option. I think, if the EE umbrella EG thinks this would be a good idea (and there is a common understanding which are the useful ones ;-) ), we might provide it. But I would still expect that this stage is only one element that defines a concrete target environment, so the environment can still be customized additionally, e.g. something like

public final class Environment implements Serializable{

  ...

  public Stage getStage(){ ... }

 

  ...

}

In the context of the whole EE area such a unified mechanism could be quite useful I think.

-Anatole

[Antonio Goncalves]

Ok. I'll take this topic to the EE expert group (once it's created)

On Thu, Oct 31, 2013 at 10:42 PM, Anatole Tresch <atst...@gmail.com> wrote:

Hi all,

[Mark Struberg]

I understand the sentiment when it comes to project stages. 

They basically work fine if you don't overuse them. 

There is some point though where you should move your app to a 'feature configuration'. 

In my experience it doesn't make sense to add an own ProjectStage for each customer or installation. If you need this then it's much better to move your app into a more product oriented beast and use kind of feature-sets to enable or disable certain functionality.

But especially the distinction between 'development' and 'beyond' via the ProjectStage proved to be very important. In Dev you usually like to use much more mocked infrastructure and much less caching. 

LieGrue,

strub