You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomee.apache.org by David Blevins <da...@gmail.com> on 2012/08/23 23:04:13 UTC
[DISCUSS] New descriptor format
So as Romain mentions in the "feedback on cxf config" email we were kicking around ideas on better configuration. As that was partially implemented, just wanted to post more explicitly on it and make it clear the topic is completely open for discussion and ideas.
Descriptors tend to last for several years, so getting one we all like is really important. The more feedback the better.
[Please respond inline and don't top-post or the thread will be unreadable. Just trim the email down to the parts that pertain to the response and respond below the part]
# The Trouble with our non-extensible descriptors
The issue with the current descriptor(s) is that it would be nice to have one file to rule them all. Rather than resources.xml and openejb-jar.xml and now application.properties or module.properties, have just one that:
- fits any current scenario
- room for any future need
# Modeling internal objects
So here is one idea which models after internal objects we have `AppContext`, `ModuleContext` and `BeanContext`
http://svn.apache.org/repos/asf/openejb/trunk/openejb/container/openejb-core/src/main/java/org/apache/openejb/AppContext.java
http://svn.apache.org/repos/asf/openejb/trunk/openejb/container/openejb-core/src/main/java/org/apache/openejb/ModuleContext.java
http://svn.apache.org/repos/asf/openejb/trunk/openejb/container/openejb-core/src/main/java/org/apache/openejb/BeanContext.java
And their parent class, `DeploymentContext`
http://svn.apache.org/repos/asf/openejb/trunk/openejb/container/openejb-core/src/main/java/org/apache/openejb/DeploymentContext.java
That xml might look like this:
<AppContext>
<Configuration>
<AsynchronousPool>
CorePoolSize = 10
MaximumPoolSize = 10
</AsynchronousPool>
<AnyPropertyPrefix>
someproperty = foo
</AnyPropertyPrefix>
<org.quartz>
scheduler.instanceName = my-app
scheduler.instanceId = my-bean
threadPool.threadCount = 10
threadPool.class = org.superbiz.MyCustomThreadPool
plugin.LogPlugin.class = org.superbiz.MyLogPlugin
plugin.LogPlugin.active = true
</org.quartz>
</Configuration>
<ModuleContext>
<BeanContext id="CalculatorBean">
<Configuration>
<cxf.jaxws>
in-interceptors = wss4j
</cxf.jaxws>
</Configuration>
</BeanContext>
</ModuleContext>
<Resources>
<Service id="wss4j" class-name="org.apache.openejb.server.cxf.config.WSS4JInInterceptorFactory" factory-name="create">
action = UsernameToken
passwordType = PasswordText
passwordCallbackClass = org.superbiz.ws.security.PasswordCallbackHandler
</Service>
<Service .../>
<Resource .../>
</Resources>
<AppContext>
## Configuration
The "<Configuration>" bucket is essentially a properties bucket and would be identical to application.properties. All the data declared in "<Configuration>" would go straight into AppContext.getProperties().
The tags are simply "fanciness" for being lazy. So this is:
<Configuration>
<AsynchronousPool>
CorePoolSize = 10
MaximumPoolSize = 10
</AsynchronousPool>
<AnyPropertyPrefix>
someproperty = foo
</AnyPropertyPrefix>
<org.quartz>
scheduler.instanceName = my-app
scheduler.instanceId = my-bean
threadPool.threadCount = 10
threadPool.class = org.superbiz.MyCustomThreadPool
plugin.LogPlugin.class = org.superbiz.MyLogPlugin
plugin.LogPlugin.active = true
</org.quartz>
</Configuration>
.. would be the same as this:
<Configuration>
AsynchronousPool.CorePoolSize = 10
AsynchronousPool.MaximumPoolSize = 10
AnyPropertyPrefix.someproperty = foo
org.quartz.scheduler.instanceName = my-app
org.quartz.scheduler.instanceId = my-bean
org.quartz.threadPool.threadCount = 10
org.quartz.threadPool.class = org.superbiz.MyCustomThreadPool
org.quartz.plugin.LogPlugin.class = org.superbiz.MyLogPlugin
org.quartz.plugin.LogPlugin.active = true
</Configuration>
Both would actually function. User preference would dictate which is used.
Thoughts? Given the choice, which would you use? See any third options that might be cooler?
AppContext, ModuleContext, and BeanContext would each get a `<Configuration>` bucket. There might be a better name than `<Configuration>`. Maybe `<Properties>` or perhaps even better, `<Options>` ?
Here's an example of how we use these Options:
public static AsynchronousPool create(AppContext appContext) {
Options options = appContext.getOptions();
int corePoolSize = options.get("AsynchronousPool.CorePoolSize", 10);
// Default setting is for a fixed pool size, MaximumPoolSize==CorePoolSize
int maximumPoolSize = Math.max(options.get("AsynchronousPool.MaximumPoolSize", corePoolSize), corePoolSize);
// Default QueueSize is bounded using the MaximumPoolSize
int size = options.get("AsynchronousPool.QueueSize", maximumPoolSize);
// Keep Threads inactive threads alive for 60 seconds by default
Duration keepAliveTime = options.get("AsynchronousPool.KeepAliveTime", new Duration(60, TimeUnit.SECONDS));
// All threads can be timed out by default
boolean allowCoreThreadTimeout = options.get("AsynchronousPool.AllowCoreThreadTimeOut", true);
// If the user explicitly set the QueueSize to 0, we default QueueType to SYNCHRONOUS
ExecutorBuilder.QueueType defaultQueueType = (size == 0) ? ExecutorBuilder.QueueType.SYNCHRONOUS : ExecutorBuilder.QueueType.LINKED;
BlockingQueue queue = options.get("AsynchronousPool.QueueType", defaultQueueType).create(options, "AsynchronousPool", size);
ThreadFactory factory = new DaemonThreadFactory("AsynchronousPool");
Duration duration = options.get("AsynchronousPool.OfferTimeout", new Duration(30, TimeUnit.SECONDS));
RejectedExecutionHandler handler = new OfferRejectedExecutionHandler(duration);
ThreadPoolExecutor threadPoolExecutor = new ThreadPoolExecutor(corePoolSize
, maximumPoolSize
, keepAliveTime.getTime()
, keepAliveTime.getUnit() != null ? keepAliveTime.getUnit() : TimeUnit.SECONDS
, queue
, factory
, handler
);
threadPoolExecutor.allowCoreThreadTimeOut(allowCoreThreadTimeout);
return new AsynchronousPool(threadPoolExecutor);
}
## EJB vs Pojo
Some of the things we need to configure are not EJBs and don't have the BeanContext object internally. These are typically Pojo @WebService and JAX-RS resources and still need many of the same configuration related to @WebService related and JAX-RS.
There are two thoughts on how to deal with that:
- Let people use BeanContext anyway
- Make a new element
If we made a new element it might look like this:
<AppContext>
<ModuleContext>
<BeanContext id="CalculatorBean">
<Configuration>
<cxf.jaxws>
in-interceptors = wss4j
</cxf.jaxws>
</Configuration>
</BeanContext>
<Pojo id="org.foo.bar">
<Configuration>
<cxf.jaxws>
in-interceptors = wss4j
</cxf.jaxws>
</Configuration>
</Pojo>
</ModuleContext>
</AppContext>
Pojo's don't have names like EJBs so if we use the same xml element, users will need to know to use a class name as the ID for a pojo and the ejbName if it's a bean.
Ideas on something better? Better names maybe? Perhaps `<PojoContext>` for consistency. Perhaps get really basic and `<ClassContext>` ?
## Standalone apps vs apps with many modules
In scenarios where there is an actual EAR file there will be several jars and wars and each will need the ability to have it's own `<ModuleContext>` and configure the `<BeanContext>` and more that apply now to modules as well as anything in the future that might be needed or desired for configuring a module.
In this EAR situation, allowing `<ModuleContext>` to be a root element in say a file named module-context.xml would do the trick.
That isn't the normal case, however. In most cases it's a simple war file which in Java EE terms makes it a "standalone application". With a standalone application internally you still get an AppContext, but it will only contain one ModuleContext. From a user's perspective it is just one thing. Do we want to make users always use `<ModuleContext>` or do we want to implicitly allow anything that might go into a `<ModuleContext>` to also reside in `<AppContext>`?
So for example, instead of:
<AppContext>
<ModuleContext>
<BeanContext id="CalculatorBean">
<Configuration>
<cxf.jaxws>
in-interceptors = wss4j
</cxf.jaxws>
</Configuration>
</BeanContext>
<Pojo id="org.foo.bar">
<Configuration>
<cxf.jaxws>
in-interceptors = wss4j
</cxf.jaxws>
</Configuration>
</Pojo>
</ModuleContext>
</AppContext>
Allow this:
<AppContext>
<BeanContext id="CalculatorBean">
<Configuration>
<cxf.jaxws>
in-interceptors = wss4j
</cxf.jaxws>
</Configuration>
</BeanContext>
<Pojo id="org.foo.bar">
<Configuration>
<cxf.jaxws>
in-interceptors = wss4j
</cxf.jaxws>
</Configuration>
</Pojo>
</AppContext>
The Pros are nearly inverse to the Cons.
For requiring `<ModuleContext>`:
Pros:
- Clearly states what applies to that one jar (module)
- Flexibility to add to `<ModuleContext>` without worry of adverse impact on also allowing those things in `<AppContext>`
- If `id` is left off of `<ModuleContext id="foo">`, we can assume that to be the only module in the standalone application.
Cons:
- Feels unnatural in a standalone application scenario
- If a user specifies more than one `<ModuleContext>` of a standalone application we will have to treat that as a deployment error
- If `id` is left off of `<ModuleContext id="foo">` of an ear we will have to treat that as a deployment error
For allowing `<AppContext>` to serve implicitly as a `<ModuleContext>`:
Pros:
- Feels natural in a standalone application scenario
Cons:
- Must be treated as an error in a ear scenario
- If a user does both and puts `<BeanContext>` elements under `<AppContext>` and under a `<ModuleContext>` it is awkward at best, possibly an error if definitions conflict
- We'll be restricted in that anything we might want to add to `<ModuleContext>` in the future must also make sense in `<AppContext>`
Do we have any thoughts on that? Preferences or other ideas? Does it help if we make a different containing element with a better name, perhaps `<StandaloneContext>`?
<AppContext>
<StandaloneContext>
<BeanContext id="CalculatorBean">
<Configuration>
<cxf.jaxws>
in-interceptors = wss4j
</cxf.jaxws>
</Configuration>
</BeanContext>
<Pojo id="org.foo.bar">
<Configuration>
<cxf.jaxws>
in-interceptors = wss4j
</cxf.jaxws>
</Configuration>
</Pojo>
</StandaloneContext>
<Resources>
<Resource ...>
<Service ...>
</Resources>
</AppContext>
Or perhaps we want an entirely different root element for standalone apps?
<StandaloneAppContext>
<BeanContext id="CalculatorBean">
<Configuration>
<cxf.jaxws>
in-interceptors = wss4j
</cxf.jaxws>
</Configuration>
</BeanContext>
<Pojo id="org.foo.bar">
<Configuration>
<cxf.jaxws>
in-interceptors = wss4j
</cxf.jaxws>
</Configuration>
</Pojo>
<Resources>
<Resource ...>
<Service ...>
</Resources>
</StandaloneAppContext>
Or maybe since EARs are the least common scenario, we give them the funny root element:
<EnterpriseAppContext>
<ModuleContext id="FooModule">
<BeanContext id="CalculatorBean">
<Configuration>
<cxf.jaxws>
in-interceptors = wss4j
</cxf.jaxws>
</Configuration>
</BeanContext>
<Pojo id="org.foo.bar">
<Configuration>
<cxf.jaxws>
in-interceptors = wss4j
</cxf.jaxws>
</Configuration>
</Pojo>
</ModuleContext>
<Resources>
<Resource ...>
<Service ...>
</Resources>
</EnterpriseAppContext>
Looking forward to as many responses as possible.
-David
Re: [DISCUSS] New descriptor format
Posted by Romain Manni-Bucau <rm...@gmail.com>.
in app ctx using <ModuleContext><Configuration /></ModuleContext> should be
fine
then in module-ctx.xml same but without AppContext root tag
wdyt?
*Romain Manni-Bucau*
*Twitter: @rmannibucau*
*Blog: http://rmannibucau.wordpress.com*
Re: [DISCUSS] New descriptor format
Posted by David Blevins <da...@gmail.com>.
On Aug 23, 2012, at 3:22 PM, David Blevins wrote:
>
> On Aug 23, 2012, at 2:37 PM, Romain Manni-Bucau wrote:
>
>> probably the ejbname usage is the issue, if the deployment is global the id
>> should be ;)
>
> So your vote would be for using the deployment id?
>
> <AppContext>
> <BeanContext id="fooApp/greenModule/CalculatorBean">
> </BeanContext>
> <BeanContext id="fooApp/blueModule/CalculatorBean">
> </BeanContext>
> <BeanContext id="fooApp/redModule/CoolBean">
> </BeanContext>
> <BeanContext id="fooApp/redModule/NeatBean">
> </BeanContext>
> <AppContext>
>
On Aug 23, 2012, at 3:39 PM, Romain Manni-Bucau wrote:
> right
Any proposals on how we would get properties into the ModuleContext?
-David
Re: [DISCUSS] New descriptor format
Posted by Romain Manni-Bucau <rm...@gmail.com>.
right
*Romain Manni-Bucau*
*Twitter: @rmannibucau*
*Blog: http://rmannibucau.wordpress.com*
Re: [DISCUSS] New descriptor format
Posted by Jean-Louis MONTEIRO <je...@gmail.com>.
Ok then, no issue to not use caps ;-)
2012/9/10 Romain Manni-Bucau <rm...@gmail.com>
> about tag names it is currently "equalsIgnorecase" and i want to keep it ;)
>
> *Romain Manni-Bucau*
> *Twitter: @rmannibucau*
> *Blog: http://rmannibucau.wordpress.com*
>
>
>
>
> 2012/9/10 Jean-Louis MONTEIRO <je...@gmail.com>
>
> > Regarding tag names i'd remove upercase characters at the beginning, not
> > really xml conventions.
> > +1 to start with something simple even if incomplete. It's always easier
> to
> > add things than to remove.
> >
> > If we want to have something clean, complete with all suggestions in, I
> > feel like we won't have anything until months (years?).
> >
> > Jean-Louis
> >
> > 2012/9/10 Romain Manni-Bucau <rm...@gmail.com>
> >
> > > a little up since a minimum of this descriptor is mandatory for next
> > > release IMO.
> > >
> > > the webservices (soap/rest) config is today not very user friendly and
> i
> > > absolutely want an answer for *next* release. This is just a subset of
> > the
> > > config we are talking about: properties tag + bean (pojo or not)
> > properties
> > >
> > > any way to find a solution quickly about it?
> > >
> > > my thought is mainly we can use the following:
> > >
> > > <application> <!-- i'd ignore the name in the parsing for the moment
> -->
> > > <Properties>
> > > <!-- nested or not, just use what you need/want/like -->
> > > </Properties>
> > >
> > > <!-- here are the choices -->
> > > <Ejb>
> > > <Properties>
> > > foo = bar
> > > </Properties>
> > > </Ejb>
> > > <Pojo>
> > > <Properties>
> > > foo = bar
> > > </Properties>
> > > </Pojo>
> > >
> > > </application>
> > >
> > > Then we have the question of the module/war: my thought is pretty
> simple
> > on
> > > it: to find a pojo/ejb in a war/module (from its id) or globally it is
> > > simply a search algorithm so we could then really easily accept both
> > config
> > > (knowing the previous config will be used at least for 80% of apps). So
> > for
> > > next release i'd go for previous format
> > >
> > > then this format is extensible and not fixed IMO so for me it sounds
> fine
> > >
> > > wdyt?
> > >
> > > *Romain Manni-Bucau*
> > > *Twitter: @rmannibucau*
> > > *Blog: http://rmannibucau.wordpress.com*
> > >
> > >
> > >
> > >
> > > 2012/9/2 Romain Manni-Bucau <rm...@gmail.com>
> > >
> > > > hmm,
> > > >
> > > > if you speak about info tree it is only regarding perf for me.
> > > >
> > > > all the cloud stuff should be managed from a provisionning tool
> > (puppet,
> > > > chef...). All other solution sounds pretty "manually done". The cloud
> > > point
> > > > if to keep the (dynamic) config in a single node then propagate it
> from
> > > > template.
> > > >
> > > > Well, do we have any choice at this point or are we still discussing?
> > > >
> > > >
> > > >
> > > > *Romain Manni-Bucau*
> > > > *Twitter: @rmannibucau*
> > > > *Blog: http://rmannibucau.wordpress.com*
> > > >
> > > >
> > >
> >
>
Re: [DISCUSS] New descriptor format
Posted by Romain Manni-Bucau <rm...@gmail.com>.
about tag names it is currently "equalsIgnorecase" and i want to keep it ;)
*Romain Manni-Bucau*
*Twitter: @rmannibucau*
*Blog: http://rmannibucau.wordpress.com*
2012/9/10 Jean-Louis MONTEIRO <je...@gmail.com>
> Regarding tag names i'd remove upercase characters at the beginning, not
> really xml conventions.
> +1 to start with something simple even if incomplete. It's always easier to
> add things than to remove.
>
> If we want to have something clean, complete with all suggestions in, I
> feel like we won't have anything until months (years?).
>
> Jean-Louis
>
> 2012/9/10 Romain Manni-Bucau <rm...@gmail.com>
>
> > a little up since a minimum of this descriptor is mandatory for next
> > release IMO.
> >
> > the webservices (soap/rest) config is today not very user friendly and i
> > absolutely want an answer for *next* release. This is just a subset of
> the
> > config we are talking about: properties tag + bean (pojo or not)
> properties
> >
> > any way to find a solution quickly about it?
> >
> > my thought is mainly we can use the following:
> >
> > <application> <!-- i'd ignore the name in the parsing for the moment -->
> > <Properties>
> > <!-- nested or not, just use what you need/want/like -->
> > </Properties>
> >
> > <!-- here are the choices -->
> > <Ejb>
> > <Properties>
> > foo = bar
> > </Properties>
> > </Ejb>
> > <Pojo>
> > <Properties>
> > foo = bar
> > </Properties>
> > </Pojo>
> >
> > </application>
> >
> > Then we have the question of the module/war: my thought is pretty simple
> on
> > it: to find a pojo/ejb in a war/module (from its id) or globally it is
> > simply a search algorithm so we could then really easily accept both
> config
> > (knowing the previous config will be used at least for 80% of apps). So
> for
> > next release i'd go for previous format
> >
> > then this format is extensible and not fixed IMO so for me it sounds fine
> >
> > wdyt?
> >
> > *Romain Manni-Bucau*
> > *Twitter: @rmannibucau*
> > *Blog: http://rmannibucau.wordpress.com*
> >
> >
> >
> >
> > 2012/9/2 Romain Manni-Bucau <rm...@gmail.com>
> >
> > > hmm,
> > >
> > > if you speak about info tree it is only regarding perf for me.
> > >
> > > all the cloud stuff should be managed from a provisionning tool
> (puppet,
> > > chef...). All other solution sounds pretty "manually done". The cloud
> > point
> > > if to keep the (dynamic) config in a single node then propagate it from
> > > template.
> > >
> > > Well, do we have any choice at this point or are we still discussing?
> > >
> > >
> > >
> > > *Romain Manni-Bucau*
> > > *Twitter: @rmannibucau*
> > > *Blog: http://rmannibucau.wordpress.com*
> > >
> > >
> >
>
Re: [DISCUSS] New descriptor format
Posted by Jean-Louis MONTEIRO <je...@gmail.com>.
Regarding tag names i'd remove upercase characters at the beginning, not
really xml conventions.
+1 to start with something simple even if incomplete. It's always easier to
add things than to remove.
If we want to have something clean, complete with all suggestions in, I
feel like we won't have anything until months (years?).
Jean-Louis
2012/9/10 Romain Manni-Bucau <rm...@gmail.com>
> a little up since a minimum of this descriptor is mandatory for next
> release IMO.
>
> the webservices (soap/rest) config is today not very user friendly and i
> absolutely want an answer for *next* release. This is just a subset of the
> config we are talking about: properties tag + bean (pojo or not) properties
>
> any way to find a solution quickly about it?
>
> my thought is mainly we can use the following:
>
> <application> <!-- i'd ignore the name in the parsing for the moment -->
> <Properties>
> <!-- nested or not, just use what you need/want/like -->
> </Properties>
>
> <!-- here are the choices -->
> <Ejb>
> <Properties>
> foo = bar
> </Properties>
> </Ejb>
> <Pojo>
> <Properties>
> foo = bar
> </Properties>
> </Pojo>
>
> </application>
>
> Then we have the question of the module/war: my thought is pretty simple on
> it: to find a pojo/ejb in a war/module (from its id) or globally it is
> simply a search algorithm so we could then really easily accept both config
> (knowing the previous config will be used at least for 80% of apps). So for
> next release i'd go for previous format
>
> then this format is extensible and not fixed IMO so for me it sounds fine
>
> wdyt?
>
> *Romain Manni-Bucau*
> *Twitter: @rmannibucau*
> *Blog: http://rmannibucau.wordpress.com*
>
>
>
>
> 2012/9/2 Romain Manni-Bucau <rm...@gmail.com>
>
> > hmm,
> >
> > if you speak about info tree it is only regarding perf for me.
> >
> > all the cloud stuff should be managed from a provisionning tool (puppet,
> > chef...). All other solution sounds pretty "manually done". The cloud
> point
> > if to keep the (dynamic) config in a single node then propagate it from
> > template.
> >
> > Well, do we have any choice at this point or are we still discussing?
> >
> >
> >
> > *Romain Manni-Bucau*
> > *Twitter: @rmannibucau*
> > *Blog: http://rmannibucau.wordpress.com*
> >
> >
>
Re: [DISCUSS] New descriptor format
Posted by David Blevins <da...@gmail.com>.
On Sep 11, 2012, at 1:09 PM, Romain Manni-Bucau wrote:
> i'd say the appcontext until the module is specified explicitely (next
> version IMO).
I think that can work. As long as we plan to add a module context it should be fine.
-David
>
> 2012/9/11 David Blevins <da...@gmail.com>
>
>>
>> On Sep 9, 2012, at 11:25 PM, Romain Manni-Bucau wrote:
>>
>>> <application> <!-- i'd ignore the name in the parsing for the moment -->
>>> <Properties>
>>> <!-- nested or not, just use what you need/want/like -->
>>> </Properties>
>>
>> The question I have is where do these properties go? Do they go into the
>> org.apache.openejb.AppContext or org.apache.openejb.ModuleContext?
>>
>>
>> -David
>>
>>
Re: [DISCUSS] New descriptor format
Posted by Romain Manni-Bucau <rm...@gmail.com>.
i'd say the appcontext until the module is specified explicitely (next
version IMO). I really hate the BDA like configs and we don't really need
it today
sounds logical and consistent with modularity but never a solution in real
life
*Romain Manni-Bucau*
*Twitter: @rmannibucau*
*Blog: http://rmannibucau.wordpress.com*
2012/9/11 David Blevins <da...@gmail.com>
>
> On Sep 9, 2012, at 11:25 PM, Romain Manni-Bucau wrote:
>
> > <application> <!-- i'd ignore the name in the parsing for the moment -->
> > <Properties>
> > <!-- nested or not, just use what you need/want/like -->
> > </Properties>
>
> The question I have is where do these properties go? Do they go into the
> org.apache.openejb.AppContext or org.apache.openejb.ModuleContext?
>
>
> -David
>
>
Re: [DISCUSS] New descriptor format
Posted by David Blevins <da...@gmail.com>.
On Sep 9, 2012, at 11:25 PM, Romain Manni-Bucau wrote:
> <application> <!-- i'd ignore the name in the parsing for the moment -->
> <Properties>
> <!-- nested or not, just use what you need/want/like -->
> </Properties>
The question I have is where do these properties go? Do they go into the org.apache.openejb.AppContext or org.apache.openejb.ModuleContext?
-David
Re: [DISCUSS] New descriptor format
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Currently you can use module tag with a module id.
But thats not the 80% of cases i want to cover here and we are not limited
in future to extend it. Im fine to get the same tag in different section.
We spoke of a webapp tag too
Wdyt?
Le 12 sept. 2012 04:10, "David Blevins" <da...@gmail.com> a écrit :
>
> On Sep 9, 2012, at 11:25 PM, Romain Manni-Bucau wrote:
>
> > <application> <!-- i'd ignore the name in the parsing for the moment -->
> > <Properties>
> > <!-- nested or not, just use what you need/want/like -->
> > </Properties>
> >
> > <!-- here are the choices -->
> > <Ejb>
> > <Properties>
> > foo = bar
> > </Properties>
> > </Ejb>
> > <Pojo>
> > <Properties>
> > foo = bar
> > </Properties>
> > </Pojo>
> >
> > </application>
>
> Ignoring EJBs for a moment and focusing just on pojos. How would I
> configure this:
>
> colors.ear
> META-INF/app-ctx.xml
> orange.war
> WEB-INF/classes/org.superbiz.ColorWebService
> red.war
> WEB-INF/classes/org.superbiz.ColorWebService
>
>
>
>
> <application>
> <Pojo class="org.superbiz.ColorWebService">
> <Properties>
> color = rojo
> </Properties>
> </Pojo>
> <Pojo class="org.superbiz.ColorWebService">
> <Properties>
> color = anaranjado
> </Properties>
> </Pojo>
> </application>
>
>
> How do I uniquely configure the ColorWebService for each module?
>
>
> -David
Re: [DISCUSS] New descriptor format
Posted by David Blevins <da...@gmail.com>.
On Sep 9, 2012, at 11:25 PM, Romain Manni-Bucau wrote:
> <application> <!-- i'd ignore the name in the parsing for the moment -->
> <Properties>
> <!-- nested or not, just use what you need/want/like -->
> </Properties>
>
> <!-- here are the choices -->
> <Ejb>
> <Properties>
> foo = bar
> </Properties>
> </Ejb>
> <Pojo>
> <Properties>
> foo = bar
> </Properties>
> </Pojo>
>
> </application>
Ignoring EJBs for a moment and focusing just on pojos. How would I configure this:
colors.ear
META-INF/app-ctx.xml
orange.war
WEB-INF/classes/org.superbiz.ColorWebService
red.war
WEB-INF/classes/org.superbiz.ColorWebService
<application>
<Pojo class="org.superbiz.ColorWebService">
<Properties>
color = rojo
</Properties>
</Pojo>
<Pojo class="org.superbiz.ColorWebService">
<Properties>
color = anaranjado
</Properties>
</Pojo>
</application>
How do I uniquely configure the ColorWebService for each module?
-David
Re: [DISCUSS] New descriptor format
Posted by Romain Manni-Bucau <rm...@gmail.com>.
a little up since a minimum of this descriptor is mandatory for next
release IMO.
the webservices (soap/rest) config is today not very user friendly and i
absolutely want an answer for *next* release. This is just a subset of the
config we are talking about: properties tag + bean (pojo or not) properties
any way to find a solution quickly about it?
my thought is mainly we can use the following:
<application> <!-- i'd ignore the name in the parsing for the moment -->
<Properties>
<!-- nested or not, just use what you need/want/like -->
</Properties>
<!-- here are the choices -->
<Ejb>
<Properties>
foo = bar
</Properties>
</Ejb>
<Pojo>
<Properties>
foo = bar
</Properties>
</Pojo>
</application>
Then we have the question of the module/war: my thought is pretty simple on
it: to find a pojo/ejb in a war/module (from its id) or globally it is
simply a search algorithm so we could then really easily accept both config
(knowing the previous config will be used at least for 80% of apps). So for
next release i'd go for previous format
then this format is extensible and not fixed IMO so for me it sounds fine
wdyt?
*Romain Manni-Bucau*
*Twitter: @rmannibucau*
*Blog: http://rmannibucau.wordpress.com*
2012/9/2 Romain Manni-Bucau <rm...@gmail.com>
> hmm,
>
> if you speak about info tree it is only regarding perf for me.
>
> all the cloud stuff should be managed from a provisionning tool (puppet,
> chef...). All other solution sounds pretty "manually done". The cloud point
> if to keep the (dynamic) config in a single node then propagate it from
> template.
>
> Well, do we have any choice at this point or are we still discussing?
>
>
>
> *Romain Manni-Bucau*
> *Twitter: @rmannibucau*
> *Blog: http://rmannibucau.wordpress.com*
>
>
Re: [DISCUSS] New descriptor format
Posted by Romain Manni-Bucau <rm...@gmail.com>.
hmm,
if you speak about info tree it is only regarding perf for me.
all the cloud stuff should be managed from a provisionning tool (puppet,
chef...). All other solution sounds pretty "manually done". The cloud point
if to keep the (dynamic) config in a single node then propagate it from
template.
Well, do we have any choice at this point or are we still discussing?
*Romain Manni-Bucau*
*Twitter: @rmannibucau*
*Blog: http://rmannibucau.wordpress.com*
Re: [DISCUSS] New descriptor format
Posted by Bjorn Danielsson <bj...@lists.cuspycode.com>.
David Blevins <da...@gmail.com> wrote:
> In terms of clustered environments, we have a rather interesting
> setup I'm really looking forward to putting to the test. We put a
> lot of work into canonicalizing configuration down to this one
> universal tree that is easily serializable. Think of it as an
> AST -- it's not pretty to look at like source code, but the actual
> configuration with the fanciness stripped away.
I like this concept. And being a former LISP hacker, I love ASTs :)
> In this setup you can theoretically boot several servers with
> essentially no configuration files, just give each node the
> fully canonicalized configuration and they can just construct
> the related runtime objects.
How do you propose to give each node the config data?
When working with cloud deployments, I find myself moving
application config stuff away from the local filesystem to
the database server, for reasons that are fairly obvious.
Even if I have to hook up a WebDAV file system mount to reflect
the content of the database, this is still worth the extra
effort since there is only one place to update when the
config data needs to be changed.
--
Bjorn Danielsson
Cuspy Code AB
Re: [DISCUSS] New descriptor format
Posted by David Blevins <da...@gmail.com>.
On Aug 30, 2012, at 4:49 PM, Anthony Fryer wrote:
> Are you guys thinking of providing an mbean interface to the java config api?
> I used to work a fair bit on weblogic and they had configuration mbeans that
> you could use to change the configuration. I think this is how they manage
> clustered environments where the admin server talks to the managed servers
> via the mbean interface. The configuration mbeans would update the xml
> configuration file as well to persist the configuration changes. There was
> a clear delineation between configuration and runtime mbeans. Sounds like
> the java config api could form the basis of configuration mbeans if you
> wanted to go down that path.
We have some MBeans in place already for runtime configuration and definitely we plan to have more. Currently what is there for runtime is full configuration of the Stateless container (it has a lot of pooling options) and the ability to redeploy persistence units (free up memory) and datasources (resets pools).
More comprehensive configuration MBeans would definitely be great.
In terms of clustered environments, we have a rather interesting setup I'm really looking forward to putting to the test. We put a lot of work into canonicalizing configuration down to this one universal tree that is easily serializable. Think of it as an AST -- it's not pretty to look at like source code, but the actual configuration with the fanciness stripped away. In this setup you can theoretically boot several servers with essentially no configuration files, just give each node the fully canonicalized configuration and they can just construct the related runtime objects.
Some info here:
- http://tomee.apache.org/dev/configuration-and-assembly.html
Effectively all the config stuff is really synonymous to adding another "source code" format that we will eventually "compile" down to the same medium.
It does make it quite tricky to reverse that process. If someone make a change to something at runtime, to then go the other direction and push that out to config files becomes tricky -- what particular source file format did they use?
On the positive side it also allows us to support descriptors of other vendors quite easily. We just translate them into our own on the fly. So far that just works for GlassFish descriptors and to a lesser extent Geronimo descriptors.
-David
Re: [DISCUSS] New descriptor format
Posted by Anthony Fryer <ap...@hotmail.com>.
Are you guys thinking of providing an mbean interface to the java config api?
I used to work a fair bit on weblogic and they had configuration mbeans that
you could use to change the configuration. I think this is how they manage
clustered environments where the admin server talks to the managed servers
via the mbean interface. The configuration mbeans would update the xml
configuration file as well to persist the configuration changes. There was
a clear delineation between configuration and runtime mbeans. Sounds like
the java config api could form the basis of configuration mbeans if you
wanted to go down that path.
--
View this message in context: http://openejb.979440.n4.nabble.com/DISCUSS-New-descriptor-format-tp4657040p4657176.html
Sent from the OpenEJB Dev mailing list archive at Nabble.com.
Re: [DISCUSS] New descriptor format
Posted by David Blevins <da...@gmail.com>.
On Aug 28, 2012, at 5:29 AM, Romain Manni-Bucau wrote:
> For java api, why not events like in cdi? We didnt mention it but we cant
> do everything at every moment so i think good event could be a good
> solution. An event could get a addResource method for instance
Definitely a callback mechanism would be the thing that drives it.
-David
Re: [DISCUSS] New descriptor format
Posted by Romain Manni-Bucau <rm...@gmail.com>.
For java api, why not events like in cdi? We didnt mention it but we cant
do everything at every moment so i think good event could be a good
solution. An event could get a addResource method for instance
Re: [DISCUSS] New descriptor format
Posted by stratwine <to...@gmail.com>.
exabrial wrote
>
> The only thing I'm picky about is having "one way" of specifying the data.
> Having multiple ways to specify the same thing will likely confuse
> newcowers:
>
> <Configuration>
> <AsynchronousPool>
> CorePoolSize = 10
>
> <Configuration>
> AsynchronousPool.CorePoolSize = 10
>
+1 for having "one way" of specifying the data.
0 for aliases - thinking not having aliases might be better for clarity i.e
not having "pojocontexts,pojos" and just have one name ? For example, if you
are to email an admin, to add certain property to "pojocontexts" but if the
admin is only aware of "pojos" (it might be a little confusing ?)
+1 for "grep"able property names.
As for naming of the elements is concerned, the word "context" is a little
"programmer"ish and not towards admins
Would losing the "context" suffix be better ?
So we would just be having names like App, Module,Beans.. or otherwise like
AppConfig,ModuleConfig.. ?
+1 towards the naming of the element as 'Properties' rather than
'Configuration' -for reinforcing the syntax.
+1 for staying with properties (when it comes to properties vs pure xml with
xsd ).
Properties look a lot cleaner/extensible. Better documentation/validation
might help.
If we are staying with properties, what kind of validations could be added ?
-Vishwa
--
View this message in context: http://openejb.979440.n4.nabble.com/DISCUSS-New-descriptor-format-tp4657040p4657130.html
Sent from the OpenEJB Dev mailing list archive at Nabble.com.
Re: [DISCUSS] New descriptor format
Posted by David Blevins <da...@gmail.com>.
On Aug 23, 2012, at 3:37 PM, exabrial wrote:
> A couple of things...
>
> What about a typesafe Java Configuration descriptor? Would it be possible to
> use both a compiled class and a .java file? I don't think either of these
> have been tried on a ApplicationServer (yet!)
We actually have (close to) that already, just not exposed.
- http://openejb.apache.org/dev/configuration-and-assembly.html
Our @ApplicationComposer API allows you to build up the app in code. I've sometimes wondered if people might like to actually deploy like that.
You can certainly do that with an embedded server, but could be useful for a "regular" server.
Having a class that we execute for creating the application would be a fairly easy thing to add. Did you want to give it a try? Could be a fun experiment with an nice way to get started hacking.
> If OpenEJB/TomEE stays XML, I would greatly prefer to have an XSD that has
> all possible attributes and options built into it. This sounds old
> fashioned, but hitting cntrl-space in Eclipse while editing an XML file
> makes configuration a snap. It makes for less trips back to the
> online-documentation and mailing list too :)
That's good feedback. It means no properties, but that might be overall better.
We could still use properties internally, but in terms of the xml it definitely changes things.
> The only thing I'm picky about is having "one way" of specifying the data.
> Having multiple ways to specify the same thing will likely confuse
> newcowers:
>
> <Configuration>
> <AsynchronousPool>
> CorePoolSize = 10
>
> <Configuration>
> AsynchronousPool.CorePoolSize = 10
>
> My .02!
Thanks, this definitely crossed my mind and thought "this could be bad too". It's good to hear input. The more the better.
We'll have to live with the result for several years, so getting this right is key.
-David
Re: [DISCUSS] New descriptor format
Posted by exabrial <ex...@gmail.com>.
A couple of things...
What about a typesafe Java Configuration descriptor? Would it be possible to
use both a compiled class and a .java file? I don't think either of these
have been tried on a ApplicationServer (yet!)
If OpenEJB/TomEE stays XML, I would greatly prefer to have an XSD that has
all possible attributes and options built into it. This sounds old
fashioned, but hitting cntrl-space in Eclipse while editing an XML file
makes configuration a snap. It makes for less trips back to the
online-documentation and mailing list too :)
The only thing I'm picky about is having "one way" of specifying the data.
Having multiple ways to specify the same thing will likely confuse
newcowers:
<Configuration>
<AsynchronousPool>
CorePoolSize = 10
<Configuration>
AsynchronousPool.CorePoolSize = 10
My .02!
--
View this message in context: http://openejb.979440.n4.nabble.com/DISCUSS-New-descriptor-format-tp4657040p4657047.html
Sent from the OpenEJB Dev mailing list archive at Nabble.com.
Re: [DISCUSS] New descriptor format
Posted by David Blevins <da...@gmail.com>.
On Aug 23, 2012, at 2:37 PM, Romain Manni-Bucau wrote:
> probably the ejbname usage is the issue, if the deployment is global the id
> should be ;)
So your vote would be for using the deployment id?
<AppContext>
<BeanContext id="fooApp/greenModule/CalculatorBean">
</BeanContext>
<BeanContext id="fooApp/blueModule/CalculatorBean">
</BeanContext>
<BeanContext id="fooApp/redModule/CoolBean">
</BeanContext>
<BeanContext id="fooApp/redModule/NeatBean">
</BeanContext>
<AppContext>
-David
Re: [DISCUSS] New descriptor format
Posted by Romain Manni-Bucau <rm...@gmail.com>.
probably the ejbname usage is the issue, if the deployment is global the id
should be ;)
*Romain Manni-Bucau*
*Twitter: @rmannibucau*
*Blog: http://rmannibucau.wordpress.com*
Re: [DISCUSS] New descriptor format
Posted by David Blevins <da...@gmail.com>.
On Aug 23, 2012, at 2:15 PM, Romain Manni-Bucau wrote:
> 2) about hierarchy:
> a) beancontext should be in appcontext since it is global so it should
> be in the root tag that's why current implementation uses BeanContexts as
> parent, wonder if we should support Ejbs and Ejb instead of BeanContexts
> and BeanContexts
It's not so cut and dry. DeploymentIds are global, ejbNames are not. If someone sets the openejb.deploymentid.format to say "{appName}/{moduleName}/{ejbName}" then that would break a descriptor that is using just `<BeanContext id="MyEjbName">`
If we want the BeanContext id to be the ejbName, we need to know what module it lives in.
-David
Re: [DISCUSS] New descriptor format
Posted by Romain Manni-Bucau <rm...@gmail.com>.
some thoughts:
1) about configuration: i already love both so +1 to keep both
2) about hierarchy:
a) beancontext should be in appcontext since it is global so it should
be in the root tag that's why current implementation uses BeanContexts as
parent, wonder if we should support Ejbs and Ejb instead of BeanContexts
and BeanContexts
b) about Pojo -1 for PojoContext, currently it is Pojos and Pojo
c) -1 for Options, +1 to keep Configuration or Properties
well my point is mainly i prefer to have user semantic that openejb/tomee
semantic (option is purely internal)
*Romain Manni-Bucau*
*Twitter: @rmannibucau*
*Blog: http://rmannibucau.wordpress.com*
Re: [DISCUSS] New descriptor format
Posted by Romain Manni-Bucau <rm...@gmail.com>.
-1 for servercontext, i'd prefer producers with read only context if
mandatory or the opposite, a serverbuilder making all the conf fluent in a
single method.
Re: [DISCUSS] New descriptor format
Posted by Jean-Louis MONTEIRO <je...@gmail.com>.
>
>
> Both would actually function. User preference would dictate which is used.
>
> Thoughts? Given the choice, which would you use? See any third options
> that might be cooler?
>
> AppContext, ModuleContext, and BeanContext would each get a
> `<Configuration>` bucket. There might be a better name than
> `<Configuration>`. Maybe `<Properties>` or perhaps even better,
> `<Options>` ?
>
I prefer the properties tag first because we always used it, then (as
already mentioned) because it reinforce the syntax we wanna use, and last
because almost all the container can the configured (overridden) by system
properties.
The fully qualified names is better IMO.
Ideas on something better? Better names maybe? Perhaps `<PojoContext>`
> for consistency. Perhaps get really basic and `<ClassContext>` ?
>
ClassContext is ok for me as soon as we allow inheritance. I mean, define
ClassContext (even for an ejb or an abstract name) and allow ejb (ie.
BeanContext) inherit from it. That's useful when configurations are similar
and painful to maintain for a lot of ejbs (wss4j for example) or when we
want to deploy an ejb more than one.
> ## Standalone apps vs apps with many modules
>
>
No special opinion. I'd say more or less like Karan, the less to remember,
the better. With the validation framework and good messages, that should
work fine.
Otherwise a new root tag is also great.
BTW, like exabrial sample (on pastee). Would be great to also support such
a mechanism.
Regarding XSD versus properties, definitely +1 for properties.
XSD can be fine in IDE, but it will be painful for end users and for use to
maintain and move forward.
Hope it helps.
I'm happy to contribute if necessary.
Jean-Louis
Re: [DISCUSS] New descriptor format
Posted by Romain Manni-Bucau <rm...@gmail.com>.
updated the trunk:
http://svn.apache.org/repos/asf/openejb/trunk/openejb/container/openejb-core/src/test/resources/complete-app-ctx.xml
a lot of tags have aliases and are not case sensitive:
private static final Collection<String> IMPORT_ALIASES =
Arrays.asList("import", "include");
private static final Collection<String> APPLICATION_ALIASES =
Arrays.asList("appcontext", "application");
private static final Collection<String> POJOS_ALIASES =
Arrays.asList("pojocontexts", "pojos");
private static final Collection<String> POJO_ALIASES =
Arrays.asList("pojo");
private static final Collection<String> MODULE_ALIASES =
Arrays.asList("modulecontext", "module", "beancontexts", "ejbs");
private static final Collection<String> BEAN_CONTEXT_ALIASES =
Arrays.asList("ejb", "beancontext");
private static final Collection<String> CONFIGURATION_ALIASES =
Arrays.asList("configuration", "properties", "settings");
private static final Collection<String> RESOURCES_ALIASES =
Arrays.asList("resources");
private static final Collection<String> SERVICE_ALIASES =
Arrays.asList("service");
private static final Collection<String> RESOURCE_ALIASES =
Arrays.asList("resource");
*Romain Manni-Bucau*
*Twitter: @rmannibucau*
*Blog: http://rmannibucau.wordpress.com*
Re: [DISCUSS] New descriptor format
Posted by Karan Malhi <ka...@gmail.com>.
I think having the capability of splitting the config file into multiple
xml files and then assembling them through an <import> element, would be
nice
Lets say a.xml and b.xml have some configuration, then c.xml could do the
following:
<import file='a.xml'/>
<import file='b.xml/>
.... configuration of the rest of c.xml goes here
Not sure if the above is feasible, but seems like a nice and well known way
of giving an option to the user to split the configuration in chunks.
--
Karan Singh Malhi
twitter.com/KaranSinghMalhi
Re: [DISCUSS] New descriptor format
Posted by Karan Malhi <ka...@gmail.com>.
<Configuration>
> AsynchronousPool.CorePoolSize = 10
> AsynchronousPool.MaximumPoolSize = 10
> AnyPropertyPrefix.someproperty = foo
> org.quartz.scheduler.instanceName = my-app
> org.quartz.scheduler.instanceId = my-bean
> org.quartz.threadPool.threadCount = 10
> org.quartz.threadPool.class = org.superbiz.MyCustomThreadPool
> org.quartz.plugin.LogPlugin.class = org.superbiz.MyLogPlugin
> org.quartz.plugin.LogPlugin.active = true
> </Configuration>
>
> Thoughts? Given the choice, which would you use? See any third options
> that might be cooler?
>
> I'd use the 2nd option.
> AppContext, ModuleContext, and BeanContext would each get a
> `<Configuration>` bucket. There might be a better name than
> `<Configuration>`. Maybe `<Properties>` or perhaps even better,
> `<Options>` ?
>
> <Settings> could be an option too. <Options> seems more like command-line
options to me so I would say no to that. .
> Ideas on something better? Better names maybe? Perhaps `<PojoContext>`
> for consistency. Perhaps get really basic and `<ClassContext>` ?
>
> <PojoContext> would be my choice
> ## Standalone apps vs apps with many modules
>
> <AppContext>
> <ModuleContext>
>
.....
> </ModuleContext>
> </AppContext>
I would prefer a single ModuleContext nested within an AppContext . The
lesser elements one has to remember, the better it is.
--
Karan Singh Malhi
twitter.com/KaranSinghMalhi
Re: [DISCUSS] New descriptor format
Posted by David Blevins <da...@gmail.com>.
On Aug 24, 2012, at 2:27 AM, Bjorn Danielsson wrote:
> David Blevins <da...@gmail.com> wrote:
>> [Please respond inline and don't top-post or the thread will be unreadable.
>> Just trim the email down to the parts that pertain to the response and respond
>> below the part]
>>
>> ## Configuration
>>
>> [Nested XML vs property-name prefixes]
>>
>> Both would actually function. User preference would dictate which is used.
>>
>> Thoughts? Given the choice, which would you use? See any third options that
>> might be cooler?
>
> I would most likely use the second format. I grep config files all the time.
Great point.
>> AppContext, ModuleContext, and BeanContext would each get a `<Configuration>`
>> bucket. There might be a better name than `<Configuration>`. Maybe
>> `<Properties>` or perhaps even better, `<Options>` ?
>
> I prefer <Properties> for the simple reason that it reinforces the idea that
> the syntax is that of a Java properties file (with XML escapes, nota bene).
Three voices for <Properties> so far. (love getting feedback)
>> ## EJB vs Pojo
>>
>> - Let people use BeanContext anyway
>> - Make a new element
>
> I believe having different elements here is probably a good idea, to avoid
> blurring the distinction between EJBs and POJOs.
Starting to lean that way too.
>> Ideas on something better? Better names maybe? Perhaps `<PojoContext>` for
>> consistency. Perhaps get really basic and `<ClassContext>` ?
>
> Or maybe <ManagedObjectContext> ?
> Otherwise I think I prefer <PojoContext> over <ClassContext>.
Maybe even <ManagedObject>?
>> ## Standalone apps vs apps with many modules
>>
>> Or perhaps we want an entirely different root element for standalone apps?
>
> How about <WebAppContext> for the standalone?
> I think that name is intuitive for the standalone WAR case.
That might be smart. There's sort of an open ended question in this regard.
Some settings only work on the "application" level and not the "module" level. A prime example is the AsynchronousPool config. We create one AsynchronousPool for the whole application.
The fact that a "module" can also be the entire application really messes with config. Specifically, using official JavaEE terms:
- a .war file deployed by itself, no ear file, is called a "Standalone Application". Same goes for an EJB jar deployed by itself.
- that same war file deployed in an .ear is then just a module.
So the question is what should we allow people to get away with in terms of config?
For a war deployed as standalone application, should you be allowed to set AsynchronousPool properties in <WebAppContext>/<Properties>?
If yes:
- If that same .war file is deployed with another .war file in an ear and both war files attempt to set AsynchronousPool properties in <WebAppContext>/<Properties>, what would be the outcome?
If no:
- Then there must theoretically be some clearly marked "Application" level configuration element or section where the user must set AsynchronousPool properties.
sub-issue: what happens if the user combines this war in an ear and deploys it? what is the outcome of N modules having potentially conflicting "application" config?
You sort of come back to the same issue either way.
There seem to be only two (maybe three) possible outcomes what is essentially the same problem:
- Ignore or error. Moving a standalone war into an ear would cause any application-level config to be invalid. The result would be to ignore it or fail the deployment.
- Merge the application level configs and try to make it work. Ignore or fail on conflicts.
- Internally, don't have application-level config and allow everything to be done at the module-level. If you don't want two AsynchronousPools when you combine two wars together, you need to take care and clean that up.
Not entirely sure that last option will be possible all the time and it does sort of mess up the property inheritance we have. If you specify "-DAsynchronousPool.CorePoolSize=10" at boot or in conf/system.properties that sets the default for all applications unless they explicitly set "AsynchronousPool.CorePoolSize=3" or something in the application.properties or this new config file.
Would really love some thoughts.
-David
Re: [DISCUSS] New descriptor format
Posted by Romain Manni-Bucau <rm...@gmail.com>.
personnally i really don't like the "managed" word wherever it is since
everything is managed (pojo, cdi, jsf, ..) so i find it confusing, no?
about webapp, ear, jar i'd prefer to be able to keep the same root
(understand to be able to copy a config file from jar to war to ear)...but
maybe just a hack (==aliases)
*Romain Manni-Bucau*
*Twitter: @rmannibucau*
*Blog: http://rmannibucau.wordpress.com*
Re: [DISCUSS] New descriptor format
Posted by Romain Manni-Bucau <rm...@gmail.com>.
i added it:
http://svn.apache.org/repos/asf/openejb/trunk/openejb/container/openejb-core/src/test/resources/complete-app-ctx.xml
*Romain Manni-Bucau*
*Twitter: @rmannibucau*
*Blog: http://rmannibucau.wordpress.com*
Re: [DISCUSS] New descriptor format
Posted by Enrico Olivelli <eo...@gmail.com>.
Il 24/08/2012 22:42, David Blevins ha scritto:
> On Aug 24, 2012, at 8:41 AM, Enrico Olivelli wrote:
>
>>>> I would like to use this to have a place for the admin to write all the
>>>> config of the application, so I need only application scoped resources
>>>> <Configuration>
>>>> administratoraddress='**myaddress@mydomain'
>>>> </Configuration>
>>>>
>>>> class NotificationSenderBean {
>>>> @Resource(...) String administratoraddress;
>>>> }
>>>>
>>>>
>>> sounds like you want our env-entries.properties feature, will dig a bit to
>>> see if i can add it now to make a proposal
>>>
>> I know that this already works with web.xml, but I don't like that admins edit web.xml
>>
>> @Resource(mappedName="administratoraddress") String administratoraddress;
>>
>> <env-entry>
>>
>> <env-entry-name>administratoraddress</env-entry-name>
>>
>> <env-entry-type>java.lang.String</env-entry-type>
>>
>> <env-entry-value>myaddress@xzxxxx</env-entry-value>
>>
>> </env-entry>
> This is currently possible via the env-entries.properties file.
>
> http://tomee.apache.org/custom-injection.html
Very smart!
I'l try soon
I could not find this doc on the website, and many other
http://tomee.apache.org/documentation.html has few links :-(
>
> We should probably add an element for that as well.
>
> Perhaps <EnvEntryProperties>, <EnvProperties>, or something? (other ideas?)
>
Yes, it would be great to only one config file !
> -David
>
Re: [DISCUSS] New descriptor format
Posted by David Blevins <da...@gmail.com>.
On Aug 24, 2012, at 1:53 PM, exabrial wrote:
> @TomEEModuleConfiguration("my-application-name")
> public class ConfigModule {
>
> @Inject
> private ServerContext context;
>
> @ConfigurationId(env = "Development")
> public void getDevConfig(ModuleConfig config) {
>
> DataSourceConfig dataSourceConfig =
>
> createResourceConfig(MySqlDataSource.class).setUserName("bob").setPassword("thebuilder").setHostName("localhost")
Did some experimenting with this. As I mentioned we have a (mostly) strongly typed API we use internally:
- http://openejb.apache.org/dev/configuration-and-assembly.html
The only part of that that isn't strongly typed are of course the individual name=value pairs, but other than that the API is pretty good. Everything (xml, properties, you name it) boils down to the configuration and assembly API eventually. Nothing sneaks by that hasn't gone through it at some point.
Anyway, I did some experimenting with hacking up strongly typed versions of the various things you can configure in a tomee.xml file.
- http://svn.apache.org/repos/asf/openejb/trunk/openejb/container/openejb-core/src/main/java/org/apache/openejb/config/typed/DataSourceBuilder.java
I generated these based off the possible configuration options for each. The format modeled after the Amazon AWS API for EC2 which has both "get" and "set" methods as well as builder methods. They prefix all builder methods with "with", which I kind of like as it makes it easy to find all the builder methods in an IDE -- just type ".with" then hit the tab completion.
Anyway, here's a sample usage:
- http://svn.apache.org/repos/asf/openejb/trunk/openejb/container/openejb-core/src/test/java/org/apache/openejb/config/typed/util/ServerContextTest.java
public void test() throws Exception {
final ServerContext serverContext = new ServerContext();
serverContext.createTransactionManager(new TransactionManagerBuilder()
.withDefaultTransactionTimeout(3, TimeUnit.MINUTES)
.withBufferSizeKb(1024)
.withMaxBuffers(10));
serverContext.createSecurityService(new SecurityServiceBuilder()
.withDefaultUser("unknown"));
serverContext.createContainer(new StatelessContainerBuilder()
.withStrictPooling(true)
.withMaxSize(11)
.withMinSize(5)
.withReplaceAged(true)
.withMaxAge(1, TimeUnit.DAYS)
.withIdleTimeout(30, TimeUnit.MINUTES)
.withSweepInterval(3, TimeUnit.MINUTES)
);
serverContext.createResource(new DataSourceBuilder()
.id("FooDataSource")
.withJtaManaged(true)
.withJdbcDriver("org.hsqldb.jdbcDriver")
.withJdbcUrl(new URI("jdbc:hsqldb:mem:hsqldb"))
.withAccessToUnderlyingConnectionAllowed(false)
.withMaxActive(10)
.withMaxIdle(5)
.withMinEvictableIdleTime(15, TimeUnit.MINUTES)
.withTimeBetweenEvictionRuns(5, TimeUnit.MINUTES)
);
}
Here is what an xml version of the above code might look like (I generated the builders with JAXB annotations on them so they could easily be built from xml):
<ServerContext>
<TransactionManager
id="TransactionManager"
defaultTransactionTimeoutSeconds="180"
txRecovery="false"
bufferSizeKb="1024"
checksumEnabled="true"
adler32Checksum="true"
flushSleepTimeMilliseconds="50"
logFileDir="txlog"
logFileExt="log"
logFileName="howl"
maxBlocksPerFile="-1"
maxBuffers="10"
maxLogFiles="2"
minBuffers="4"
threadsWaitingForceThreshold="-1"
/>
<SecurityService
id="SecurityService"
defaultUser="unknown"/>
<StatelessContainer
id="StatelessContainer"
accessTimeout="30 SECONDS"
maxSize="11"
minSize="5"
strictPooling="true"
maxAge="1 DAYS"
replaceAged="true"
replaceFlushed="false"
maxAgeOffset="-1"
idleTimeout="30 MINUTES"
garbageCollection="false"
sweepInterval="3 MINUTES"
callbackThreads="5"
closeTimeout="5 MINUTES"
/>
<DataSource
id="FooDataSource"
jtaManaged="true"
jdbcDriver="org.hsqldb.jdbcDriver"
jdbcUrl="jdbc:hsqldb:mem:hsqldb"
userName="sa"
passwordCipher="PlainText"
defaultAutoCommit="true"
initialSize="0"
maxActive="10"
maxIdle="5"
minIdle="0"
maxWait="-1"
testOnBorrow="true"
testOnReturn="false"
testWhileIdle="false"
timeBetweenEvictionRunsMillis="300000"
numTestsPerEvictionRun="3"
minEvictableIdleTimeMillis="900000"
poolPreparedStatements="false"
maxOpenPreparedStatements="0"
accessToUnderlyingConnectionAllowed="false"
ignoreDefaultValues="false"
/>
</ServerContext>
I don't consider any of this perfect, just sort of experimenting with the feedback.
-David
Re: [DISCUSS] New descriptor format
Posted by exabrial <ex...@gmail.com>.
Here's the format I suggest. See it with syntax highlighting:
(https)pastee(dot)org(slash)7tj7r
The main advantages are:
* It's extensible (XML w/ XSD isn't extensible)
* It's typesafe (Properties are not typesafe)
* It's discoverable (Properties are not discoverable)
* It's still readable
* It's testable (XML is, properties aren't)
* It has exactly "one way" of doing things.
* It could integrate with CDI qualifiers.
@TomEEModuleConfiguration("my-application-name")
public class ConfigModule {
@Inject
private ServerContext context;
@ConfigurationId(env = "Development")
public void getDevConfig(ModuleConfig config) {
DataSourceConfig dataSourceConfig =
createResourceConfig(MySqlDataSource.class).setUserName("bob").setPassword("thebuilder").setHostName("localhost")
.setPort(3306);
DataSource newDataSource =
config.addServerResource(dataSourceConfig);
config.addConfig(bind(Resource.class).withName("jdbc/myAppDataSource").annotatingType(DataSource.class)
.to(newDataSource));
}
@DefaultConfiguration
@ConfigurationId(env = "Production")
public void getProdConfig(ModuleConfig config) {
config.addConfig(bind(Resource.class).withName("jdbc/anotherDataSource").annotatingType(DataSource.class)
.to(context.lookup(DataSource.class,
"jdbc/anotherDataSource")));
}
}
* To extend the format, TomEE authors just add new properties or classes on
the classpath
* I like the notion of "environments". The current environment could be set
with JMX, the server's http console, or in the tomee.properties under
tomcat/conf
* I'd like to have these descriptors in the ear/war/jar itself, but if they
could be also placed in tomcat/lib this would be a huge benefit to server
administrators
* This could integrate with CDI really well!
* This is groundbreaking. No other app server has ever done this!
--
View this message in context: http://openejb.979440.n4.nabble.com/DISCUSS-New-descriptor-format-tp4657040p4657092.html
Sent from the OpenEJB Dev mailing list archive at Nabble.com.
Re: [DISCUSS] New descriptor format
Posted by David Blevins <da...@gmail.com>.
On Aug 24, 2012, at 8:41 AM, Enrico Olivelli wrote:
>>> I would like to use this to have a place for the admin to write all the
>>> config of the application, so I need only application scoped resources
>>> <Configuration>
>>> administratoraddress='**myaddress@mydomain'
>>> </Configuration>
>>>
>>> class NotificationSenderBean {
>>> @Resource(...) String administratoraddress;
>>> }
>>>
>>>
>> sounds like you want our env-entries.properties feature, will dig a bit to
>> see if i can add it now to make a proposal
>>
> I know that this already works with web.xml, but I don't like that admins edit web.xml
>
> @Resource(mappedName="administratoraddress") String administratoraddress;
>
> <env-entry>
>
> <env-entry-name>administratoraddress</env-entry-name>
>
> <env-entry-type>java.lang.String</env-entry-type>
>
> <env-entry-value>myaddress@xzxxxx</env-entry-value>
>
> </env-entry>
This is currently possible via the env-entries.properties file.
http://tomee.apache.org/custom-injection.html
We should probably add an element for that as well.
Perhaps <EnvEntryProperties>, <EnvProperties>, or something? (other ideas?)
-David
Re: [DISCUSS] New descriptor format
Posted by Enrico Olivelli <eo...@gmail.com>.
>> I would like to use this to have a place for the admin to write all the
>> config of the application, so I need only application scoped resources
>> <Configuration>
>> administratoraddress='**myaddress@mydomain'
>> </Configuration>
>>
>> class NotificationSenderBean {
>> @Resource(...) String administratoraddress;
>> }
>>
>>
> sounds like you want our env-entries.properties feature, will dig a bit to
> see if i can add it now to make a proposal
>
I know that this already works with web.xml, but I don't like that
admins edit web.xml
@Resource(mappedName="administratoraddress") String administratoraddress;
<env-entry>
<env-entry-name>administratoraddress</env-entry-name>
<env-entry-type>java.lang.String</env-entry-type>
<env-entry-value>myaddress@xzxxxx</env-entry-value>
</env-entry>
- Enrico
Re: [DISCUSS] New descriptor format
Posted by Romain Manni-Bucau <rm...@gmail.com>.
>
>
>> BeanProperties
>
hmm today it is properties but it could be more (i think in another
version we could add some static injections for instance or kind of
interceptors)
> BeanConfig/BeanConfiguration
>
here i wonder is Bean is not linked to ejbs (that's the case in our
code)...open question
> SimpleBean
>
simple sounds for me like a default
> AdministeredObject
>
too prod oriented IMO
> ConfigureBean
>
Playing with configure seems more consistent for me
> SimpleComponent
component is ambiguous IMO
Well i don't really care addind aliases, i think pojo is important for dev
and some aliases should be added for others, just need to make 1 or 2
choices, maybe we need a vote when the format will be fixed
>
>
> -> about resource: if you declare a resource it will work but the resource
>> will be application scoped at least, do you ask to be able to declare a
>> resource for a single bean?
>>
> I would like to use this to have a place for the admin to write all the
> config of the application, so I need only application scoped resources
> <Configuration>
> administratoraddress='**myaddress@mydomain'
> </Configuration>
>
> class NotificationSenderBean {
> @Resource(...) String administratoraddress;
> }
>
>
sounds like you want our env-entries.properties feature, will dig a bit to
see if i can add it now to make a proposal
Re: [DISCUSS] New descriptor format
Posted by Enrico Olivelli <eo...@gmail.com>.
Il 24/08/2012 11:50, Romain Manni-Bucau ha scritto:
> -> for properties: both will be supported i guess
> -> here (well today at least) Pojo part is mainly application config (which
> rest provider, which cxf features...) so pojo is fine but your comment is
> interesting and we should add aliases for "admin" ...any idea?
BeanProperties
BeanConfig/BeanConfiguration
SimpleBean
AdministeredObject
ConfigureBean
SimpleComponent
> -> about resource: if you declare a resource it will work but the resource
> will be application scoped at least, do you ask to be able to declare a
> resource for a single bean?
I would like to use this to have a place for the admin to write all the
config of the application, so I need only application scoped resources
<Configuration>
administratoraddress='myaddress@mydomain'
</Configuration>
class NotificationSenderBean {
@Resource(...) String administratoraddress;
}
>
> *Romain Manni-Bucau*
> *Twitter: @rmannibucau*
> *Blog: http://rmannibucau.wordpress.com*
>
>
Re: [DISCUSS] New descriptor format
Posted by Romain Manni-Bucau <rm...@gmail.com>.
-> for properties: both will be supported i guess
-> here (well today at least) Pojo part is mainly application config (which
rest provider, which cxf features...) so pojo is fine but your comment is
interesting and we should add aliases for "admin" ...any idea?
-> about resource: if you declare a resource it will work but the resource
will be application scoped at least, do you ask to be able to declare a
resource for a single bean?
*Romain Manni-Bucau*
*Twitter: @rmannibucau*
*Blog: http://rmannibucau.wordpress.com*
2012/8/24 Enrico Olivelli <eo...@gmail.com>
> I would most likely use the second format. I grep config files all the
> time.
> +1 it is better to write fully qualified properties names
>
>
> I prefer <Properties> for the simple reason that it reinforces the idea
>> that the syntax is that of a Java properties file (with XML escapes, nota
>> bene).
>>
> +1 it is simple
>
> Otherwise I think I prefer <PojoContext> over <ClassContext>.
>>
> I think that config files are mostly for deployers/IT admins, so "Pojo" is
> a stop word.
>
> I prefer
> AppContext --> for EAR and/or single collapsed application in a WAR
> WebAppContext --> for WARs
> ModuleContext --> for EJB Jars
> Properties/Configuration --> for any managed bean/pojo
>
>
> One question: It is possible to create a bean and map it directly to the
> JNDI namespace of the component ? so that it is available using @Resource
>
> - Enrico
>
>
>
Re: [DISCUSS] New descriptor format
Posted by Enrico Olivelli <eo...@gmail.com>.
I would most likely use the second format. I grep config files all the time.
+1 it is better to write fully qualified properties names
> I prefer <Properties> for the simple reason that it reinforces the
> idea that the syntax is that of a Java properties file (with XML
> escapes, nota bene).
+1 it is simple
> Otherwise I think I prefer <PojoContext> over <ClassContext>.
I think that config files are mostly for deployers/IT admins, so "Pojo"
is a stop word.
I prefer
AppContext --> for EAR and/or single collapsed application in a WAR
WebAppContext --> for WARs
ModuleContext --> for EJB Jars
Properties/Configuration --> for any managed bean/pojo
One question: It is possible to create a bean and map it directly to the
JNDI namespace of the component ? so that it is available using @Resource
- Enrico
Re: [DISCUSS] New descriptor format
Posted by Bjorn Danielsson <bj...@lists.cuspycode.com>.
David Blevins <da...@gmail.com> wrote:
> [Please respond inline and don't top-post or the thread will be unreadable.
> Just trim the email down to the parts that pertain to the response and respond
> below the part]
>
> ## Configuration
>
>[Nested XML vs property-name prefixes]
>
> Both would actually function. User preference would dictate which is used.
>
> Thoughts? Given the choice, which would you use? See any third options that
> might be cooler?
I would most likely use the second format. I grep config files all the time.
> AppContext, ModuleContext, and BeanContext would each get a `<Configuration>`
> bucket. There might be a better name than `<Configuration>`. Maybe
> `<Properties>` or perhaps even better, `<Options>` ?
I prefer <Properties> for the simple reason that it reinforces the idea that
the syntax is that of a Java properties file (with XML escapes, nota bene).
> ## EJB vs Pojo
>
> - Let people use BeanContext anyway
> - Make a new element
I believe having different elements here is probably a good idea, to avoid
blurring the distinction between EJBs and POJOs.
> Ideas on something better? Better names maybe? Perhaps `<PojoContext>` for
> consistency. Perhaps get really basic and `<ClassContext>` ?
Or maybe <ManagedObjectContext> ?
Otherwise I think I prefer <PojoContext> over <ClassContext>.
> ## Standalone apps vs apps with many modules
>
> Or perhaps we want an entirely different root element for standalone apps?
How about <WebAppContext> for the standalone?
I think that name is intuitive for the standalone WAR case.
--
Bjorn Danielsson
Cuspy Code AB
Re: [DISCUSS] New descriptor format
Posted by David Blevins <da...@gmail.com>.
On Aug 23, 2012, at 2:04 PM, David Blevins wrote:
> [Please respond inline and don't top-post or the thread will be unreadable. Just trim the email down to the parts that pertain to the response and respond below the part]
In case people wonder what responding inline or "bottom posting" looks like, I'm doing it now :) I trimmed out the parts that don't apply to my response (which is a lot in this situation) and you can just read top down.
Small example:
http://en.wikipedia.org/wiki/Posting_style#Bottom-posting
Makes it easier for people to jump in on specific parts of a large conversation.
-David
Re: [DISCUSS] New descriptor format
Posted by Thiago Veronezi <th...@veronezi.org>.
>> ...It does has uses outside EJB projects. JEE allows you to inject a @Resource
inside a servlet for instance.
Yes. That's what I meant. :O)
Re: [DISCUSS] New descriptor format
Posted by exabrial <ex...@gmail.com>.
...It does has uses outside EJB projects. JEE allows you to inject a
@Resource inside a servlet for instance. I like the idea of being "optional"
as well. This implementation would allow one to build a properties
implementation on top of it.
--
View this message in context: http://openejb.979440.n4.nabble.com/DISCUSS-New-descriptor-format-tp4657040p4657095.html
Sent from the OpenEJB Dev mailing list archive at Nabble.com.
Re: [DISCUSS] New descriptor format
Posted by Thiago Veronezi <th...@veronezi.org>.
>>This is what I want. https://pastee.org/7tj7r
I like it! It could be added to another project, something like
"tomee-config", so it would be just an include to the EJB projects; and it
wont hurt any other container.
[]s,
Thiago
Re: [DISCUSS] New descriptor format
Posted by exabrial <ex...@gmail.com>.
So I sent two mails to the mailing list, the second one was accepted, the
first one hasn't. Sorry for the confusion!
--
View this message in context: http://openejb.979440.n4.nabble.com/DISCUSS-New-descriptor-format-tp4657040p4657089.html
Sent from the OpenEJB Dev mailing list archive at Nabble.com.
Re: [DISCUSS] New descriptor format
Posted by exabrial <ex...@gmail.com>.
Let me explain a few things about the format I suggested...
It's extensible because TomEE authors can add new configuration classes to
the classpath in the future. this is better than XML and Properties. With
an XML format, we're "locked in" to a particular XSD and isn't extensible.
Properties are extensible fortunately.
It's typesafe because it'll be hard to make mistakes: the compiler will
catch them. XML is typesafe with an XSD. Properties is not typesafe, the
only way to check it is to run it or manually compare it against the
documentation.
I included configuration environment IDs: @ConfigurationId(env =
"Development") My hope is the TomEE console could maybe say, "choose a
configuration name" when you deploy the ear.
I also hope this could be put on the server classpath somewhere, like in
tomcat/lib. That way you could deploy the ear once, then later an
administrator could redploy the configuration independently.
--
View this message in context: http://openejb.979440.n4.nabble.com/DISCUSS-New-descriptor-format-tp4657040p4657088.html
Sent from the OpenEJB Dev mailing list archive at Nabble.com.
Re: [DISCUSS] New descriptor format
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Not a perf issue, we already scan.
Re: [DISCUSS] New descriptor format
Posted by Thiago Veronezi <th...@veronezi.org>.
>>I'm sorry but I think that for devs it would be good (think about
@DatasourceDefinition / CDI alternatives...)
>>But for "production" it will never be used administrators do not compile
java code
>>IT security policies will never allow to let passwords and other
top-secret info to be hard coded in java files
What about a generated config file under a folder like "tomee_conf_files"?
During startup or deployment, Tomee would generate the configuration files
for all the "TomEEModuleConfiguration" it founds. At the end, we would have
a structure like:
..\apache-tomee-plus-1.0.0\tomee_conf_files
..\apache-tomee-plus-1.0.0\tomee_conf_files\app_A_conf.xml
..\apache-tomee-plus-1.0.0\tomee_conf_files\app_B_conf.xml
..\apache-tomee-plus-1.0.0\tomee_conf_files\app_C_conf.xml
..\apache-tomee-plus-1.0.0\tomee_conf_files\app_D_conf.xml
The configuration files would be like what the guys proposed before, and
they would have the default "production" values defined by the developer.
We could also create a maven plugin that generates these files for us
during the project build process. It would create war files like...
app_A.war
|-- images/
|-- index.html
|-- jsps/
|-- WEB-INF/
|-- app_A_conf.xml
This way we wouldn't impact the server deployment performance.
[]s,
Thiago.
Re: [DISCUSS] New descriptor format
Posted by Romain Manni-Bucau <rm...@gmail.com>.
if we try to summarize:
1) current descriptor looks like
http://svn.apache.org/repos/asf/openejb/trunk/openejb/container/openejb-core/src/test/resources/complete-app-ctx.xml
2) the root tag could be enhanced specifying if we are in a webapp, an ear,
a standalone module... (is it aliases or different xml files?)
3) a java config could be added -> meta config (== annotations) or event
config (we already have events in openejb server != cdi events)
If i forgot sthg please copy/paste the summary to try to get a complete one
Here my thoughts on these points:
1) seems fine for me
2) aliases can manage everything IMO, the advantage: a war file can work in
a standalone mode or an ear
3) +1 for events since it will always be more powerful, for instance about
cxf endpoint config you'll get the endpoint so all the cxf config; with
meta you'll be as limited as today (properties + known properties)
*Romain Manni-Bucau*
*Twitter: @rmannibucau*
*Blog: http://rmannibucau.wordpress.com*
Re: [DISCUSS] New descriptor format
Posted by Enrico Olivelli <eo...@gmail.com>.
+1
Il 26/08/2012 04:25, Anthony Fryer ha scritto:
> I think 95% of users will want a text based file for configuration. If that
> text file is being parsed by a java config api that's fine, but so long as
> the text file option exists I think that's the most important thing for the
> majority of users.
>
>
>
> --
> View this message in context: http://openejb.979440.n4.nabble.com/DISCUSS-New-descriptor-format-tp4657040p4657106.html
> Sent from the OpenEJB Dev mailing list archive at Nabble.com.
Re: [DISCUSS] New descriptor format
Posted by Anthony Fryer <ap...@hotmail.com>.
I think 95% of users will want a text based file for configuration. If that
text file is being parsed by a java config api that's fine, but so long as
the text file option exists I think that's the most important thing for the
majority of users.
--
View this message in context: http://openejb.979440.n4.nabble.com/DISCUSS-New-descriptor-format-tp4657040p4657106.html
Sent from the OpenEJB Dev mailing list archive at Nabble.com.
Re: [DISCUSS] New descriptor format
Posted by Romain Manni-Bucau <rm...@gmail.com>.
if we go to java as an alternative we can send events:
public void configureRestEndpointX(@Observes BeforeEndpointConfiguration
endpointEvent); for instance
*Romain Manni-Bucau*
*Twitter: @rmannibucau*
*Blog: http://rmannibucau.wordpress.com*
Re: [DISCUSS] New descriptor format
Posted by exabrial <ex...@gmail.com>.
>>IT security policies will never allow to let passwords and other top-secret
info to be hard coded in java files
Right now they're stored in text files ;)
The idea is that this JavaConfig isn't hard-compiled into your project with
the rest of your classes... You would likely want this class to be compiled
_by itself_, not _necessarily_ hard coded in the ear/war... I would hope you
could deploy an ear/war once and reconfigure multiple times.
A few more rebuttals:
* Performance shouldn't be an issue. TomEE already does all sorts of scans
on classes. We're reusing an asset we've already created :)
* Typing "javac -cp ./tomee/lib/* MyAppsTomEEConfig.java" shouldn't be
beyond the reach of server administrators. The idea would be to keep the API
simple so it could be edited with VIM
* The Java Config API could easily be the base for any text based
implementation (XML or prop files)
* Honestly, I'm tired of the old way of doing things. XML or prop files
mean's we'll end up being a lot like Glassfish and JBoss. I'd rather
experiment and try setting a new trend rather than imitating the
competition.
I come from a shop that was WebSphere/AIX based with strict deployment
'standards' and what not, so I think I understand why you're concerned.
--
View this message in context: http://openejb.979440.n4.nabble.com/DISCUSS-New-descriptor-format-tp4657040p4657104.html
Sent from the OpenEJB Dev mailing list archive at Nabble.com.
Re: [DISCUSS] New descriptor format
Posted by Enrico Olivelli <eo...@gmail.com>.
I'm sorry but I think that for devs it would be good (think about
@DatasourceDefinition / CDI alternatives...)
But for "production" it will never be used
administrators do not compile java code
IT security policies will never allow to let passwords and other
top-secret info to be hard coded in java files
- Enrico
Il 24/08/2012 20:28, exabrial ha scritto:
> OK guys...
>
> This is what I want. https://pastee.org/7tj7r
>
> It's extensible.
> It's readable.
> It's typesafe.
> It's testable.
> It has exactly "one way" of doing things.
> It could integrate with CDI qualifiers.
> It's awesome.
>
>
> @TomEEModuleConfiguration("my-application-name")
> public class ConfigModule {
>
> @Inject
> private ServerContext context;
>
> @ConfigurationId(env = "Development")
> public void getDevConfig(ModuleConfig config) {
>
> DataSourceConfig dataSourceConfig =
>
> createResource(MySqlDataSource.class).setUserName("bob").setPassword("thebuilder").setHostName("localhost")
> .setPort(3306);
>
> DataSource newDataSource =
> config.addServerResource(dataSourceConfig);
>
> config.addConfig(bind(Resource.class).withName("jdbc/myAppDataSource").annotatingType(DataSource.class)
> .to(newDataSource));
> }
>
> @ConfigurationId(env = "Production")
> public void getProdConfig(ModuleConfig config) {
>
> config.addConfig(bind(Resource.class).withName("jdbc/anotherDataSource").annotatingType(DataSource.class)
> .to(context.lookup(DataSource.class,
> "jdbc/anotherDataSource")));
> }
> }
>
>
>
>
> --
> View this message in context: http://openejb.979440.n4.nabble.com/DISCUSS-New-descriptor-format-tp4657040p4657087.html
> Sent from the OpenEJB Dev mailing list archive at Nabble.com.
Re: [DISCUSS] New descriptor format
Posted by exabrial <ex...@gmail.com>.
OK guys...
This is what I want. https://pastee.org/7tj7r
It's extensible.
It's readable.
It's typesafe.
It's testable.
It has exactly "one way" of doing things.
It could integrate with CDI qualifiers.
It's awesome.
@TomEEModuleConfiguration("my-application-name")
public class ConfigModule {
@Inject
private ServerContext context;
@ConfigurationId(env = "Development")
public void getDevConfig(ModuleConfig config) {
DataSourceConfig dataSourceConfig =
createResource(MySqlDataSource.class).setUserName("bob").setPassword("thebuilder").setHostName("localhost")
.setPort(3306);
DataSource newDataSource =
config.addServerResource(dataSourceConfig);
config.addConfig(bind(Resource.class).withName("jdbc/myAppDataSource").annotatingType(DataSource.class)
.to(newDataSource));
}
@ConfigurationId(env = "Production")
public void getProdConfig(ModuleConfig config) {
config.addConfig(bind(Resource.class).withName("jdbc/anotherDataSource").annotatingType(DataSource.class)
.to(context.lookup(DataSource.class,
"jdbc/anotherDataSource")));
}
}
--
View this message in context: http://openejb.979440.n4.nabble.com/DISCUSS-New-descriptor-format-tp4657040p4657087.html
Sent from the OpenEJB Dev mailing list archive at Nabble.com.