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 CollectionString IMPORT_ALIASES =
Arrays.asList(import, include);
private
David Blevins david.blev...@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
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
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
- 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
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
now everything work fine !
I tested with BASIC and FORM authentication
Thank you very much
- Enrico
Il 24/08/2012 10:48, Romain Manni-Bucau ha scritto:
mea culpa, i rewrote the test to make code a bit more reaadble and forget
to remove the !,
i updated both points, still wonder if we could
great to hear :)
*Romain Manni-Bucau*
*Twitter: @rmannibucau*
*Blog: http://rmannibucau.wordpress.com*
2012/8/24 Enrico Olivelli eolive...@gmail.com
now everything work fine !
I tested with BASIC and FORM authentication
Thank you very much
- Enrico
Il 24/08/2012 10:48, Romain
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
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;
}
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
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
On Aug 24, 2012, at 2:27 AM, Bjorn Danielsson wrote:
David Blevins david.blev...@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]
##
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
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
*
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 {
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
...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:
...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)
19 matches
Mail list logo
