12:45 p.m.
On a different thread I came to similar conclusions. We have
a) the APIs/capabilities/services (what)
b) their configuration or QoS characteristics (in what context)
For (a) we could have
'web' - ee web profile
'full' - ee full profile
'osgi' - an empty mc/osgi kernel
'tomchat' - standalone jbossweb
For (b) modes like
a) development, single-node,on-demand, unsecured, non-optimized
b) development-ha, multi-node, on-demand, unsecured, non-optimized
c) production, single-node,eager-loading, secured, optimized
d) production-lb, multi-node, eager-loading, secured, optimized, load-balanced
e) production-ha, multi-node, eager-loading, secured, optimized, load-balanced,
replicated
The development modes would belong in the realm of community AS and the additional
production modes in the supported EAP/EWP.
Now although (b) seems orthogonal to (a) I don't know if in reality this can be
achieved
easily through command line flags of some sort. For example, enabling clustering or
applying
security and optimized settings might require too many configuration overrides. Maybe
it's
just easier to have additional profiles.
So for the AS case my proposal would be to go with the above 4 profiles, configured for
development, plus the good old 'all' profile which is 'full' & a few
extras with clustering
enabled. So:
web - ee web profile
full - ee full profile
osgi - empty mc/osgi kernel
tomchat - standalone jbossweb
all - full+clustering
'default' through some mechanism could be an alias/pointer to one of the above, so
that if
nothing is specified, for example, the 'web' profile gets loaded.
EAP/EWP would define additional production/production-ha profiles, but that's another
discussion.
/Dimitris
Sacha Labourey wrote:
The problem I see with what you are trying to do here is to actually
mix
orthogonal issues i.e. on one axis you have a functional set
(web-profile, full-profile, just-tomcat) and on another axis you have
things such as clustering/dev-friendly/secure, etc.
Actually, I am not sure what is on the other axis (clustering, etc.) are
so much a single axis (since you could decide to apply multiple of those
at the same time i.e. secure+clustering.
Anyway, can anybody see a solution where attributes "on the second axis"
(we could call that "modes") could be applied to each and every
configuration profile?
Probably not the best way to do it but:
- we could have a limited set of true profiles (i.e. full-ee, web-ee, etc.)
- we could have a "--mode" configuration on the jboss.bat/sh command
line with a syntax such as (not strictly correct, but you get the idea):
[--mode { clustered | secured | development | whatever-else }[/+]+ ]
- in configuration files, we would use a "ifdef" kind of syntax to
activate specific features based on those modes
Am I making any sense?
Obviously, as suggested by Brian, that might not be ideal for the QE
team though.
Cheers,
sacha
On Thu, Feb 11, 2010 at 16:47, Stan Silvert <ssilvert(a)redhat.com
<mailto:ssilvert@redhat.com>> wrote:
Hi Sacha, when did you come back to work? :-)
I like Sacha's basic idea here. Having EE6 in the name helps a lot.
And I also like 'bootstrap' better than 'minimal'.
I think we still need to decide exactly how many configurations we are
going to ship. Awhile back, Brian asked me to open a jira to change
this stuff in M3. It looks like that would be the time to nail this
down.
https://jira.jboss.org/jira/browse/JBAS-7651
Besides EE6, the other two things that we seem to need in the shipped
configurations are (clustered or not-clustered) and (development or
production).
Here's another stab at the naming:
bootstrap - same as minimal
EE6-web - EE6 web profile
EE6-standard - same as today's 'standard'. I guess we still need this
for TCK?
EE6-full-dev - super-fast boot time, less logging, delayed startup of
admin console, unsecured consoles, JSF2 PROJECT_STAGE set to
"Development"
EE6-full-prod - immediate startup of admin console, secured consoles,
JSF2 PROJECT_STAGE set to "Production"
EE6-dev-cluster - same as full-EE6-dev, but with clustered services
available
EE6-prod-cluster - same as full-EE6-prod, but with clustered services
available
Sacha Labourey wrote:
> Hello, since I've been contributing lots of code recently, let me
> chime in ;)
>
> What about:
>
> * EE6-full (aka all)
> * EE6-web (aka default)
> * bootstrap (aka minimal)
>
>
> Reasoning:
>
> * reading the thread, even yourself aren't sure if all=default or
> all=default+more stuff, what is the difference between standard
> and default, etc. Why not making it explicit IN THE NAME
itself?
> * "minimal" name is not good IMO since people might think it is
> minimal in terms of middleware development (or related), but
> this is really just a bootstrap with nothing on it. So call it
> bootstrap, or WebOS or kernel.
> * "default" is really just a trick to know which one to load
"by
> default", but it doesn't give any clue on what it actually
> contains. Why not make JBoss AS start by default the
> configuration that has a "++" in front of its name - or
> something similar i.e. "++bootstrap" or "++EE6-web".
Or, if you
> don't want people to rename configuration folders, create a
> "XXX.is.the.default" empty file in the server folder, where
XXX
> is the default configuration that will be started unless asked
> otherwise.
> * I agree that jbossweb might need to be rebranded. I'd relate to
> the Tomcat brand somehow (such as Tamcot or Tomchat or Tomkatz
> ;) well, I am sure you'll find smarter ideas :) )
>
>
> BTW, are all "server/XXX/lib" now centralized in a common folder and
> refered to by name in a configuration file or are they still being
> replicated all over the place in each and every configuration?
>
> Cheers,
>
>
> sacha
>
>
>
> On Thu, Feb 11, 2010 at 14:39, Dimitris Andreadis
<dandread(a)redhat.com <mailto:dandread@redhat.com>
> <mailto:dandread@redhat.com <mailto:dandread@redhat.com>>>
wrote:
>
> I see it's changed already, but doesn't it look horrible? Maybe
> just drop '-standalone' or
> where are our naming gurus? :-)
>
> ./server/
> all
> default
> jbossweb-standalone
> minimal
> standard
> _______________________________________________
> jboss-development mailing list
> jboss-development(a)lists.jboss.org
<mailto:jboss-development@lists.jboss.org>
> <mailto:jboss-development@lists.jboss.org
<mailto:jboss-development@lists.jboss.org>>
> https://lists.jboss.org/mailman/listinfo/jboss-development
>
>
>
------------------------------------------------------------------------
>
> _______________________________________________
> jboss-development mailing list
> jboss-development(a)lists.jboss.org
<mailto:jboss-development@lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/jboss-development
_______________________________________________
jboss-development mailing list
jboss-development(a)lists.jboss.org
<mailto:jboss-development@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/jboss-development