[DISCUSS] New descriptor format

classic Classic list List threaded Threaded
59 messages Options
123
Reply | Threaded
Open this post in threaded view
|

[DISCUSS] New descriptor format

David Blevins-2
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


Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] New descriptor format

David Blevins-2

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

Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] New descriptor format

Romain Manni-Bucau
In reply to this post by David Blevins-2
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*
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] New descriptor format

David Blevins-2

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

Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] New descriptor format

Romain Manni-Bucau
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*
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] New descriptor format

David Blevins-2

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

Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] New descriptor format

exabrial
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!
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] New descriptor format

Romain Manni-Bucau
In reply to this post by David Blevins-2
right

*Romain Manni-Bucau*
*Twitter: @rmannibucau*
*Blog: http://rmannibucau.wordpress.com*
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] New descriptor format

David Blevins-2


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

Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] New descriptor format

Romain Manni-Bucau
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*
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] New descriptor format

David Blevins-2
In reply to this post by exabrial

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

Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] New descriptor format

kmalhi
In reply to this post by David Blevins-2
    <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
Karan Singh Malhi
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] New descriptor format

kmalhi
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
Karan Singh Malhi
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] New descriptor format

Romain Manni-Bucau
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*
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] New descriptor format

Bjorn Danielsson
In reply to this post by David Blevins-2
David Blevins <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] New descriptor format

Enrico Olivelli
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


Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] New descriptor format

Romain Manni-Bucau
In reply to this post by Bjorn Danielsson
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*
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] New descriptor format

Romain Manni-Bucau
In reply to this post by Enrico Olivelli
-> 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 <[hidden email]>

> 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
>
>
>
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] New descriptor format

Enrico Olivelli
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*
>
>

Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] New descriptor format

Romain Manni-Bucau
>
>
>>  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
123