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:
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)
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
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 jeano...@gmail.com
Regarding tag names i'd remove upercase characters at the beginning, not
really
Ok then, no issue to not use caps ;-)
2012/9/10 Romain Manni-Bucau rmannibu...@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
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.
David Blevins david.blev...@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
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.
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
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
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
-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.
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.
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.
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
/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
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
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
Not a perf issue, we already scan.
' 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.
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*
://openejb.979440.n4.nabble.com/DISCUSS-New-descriptor-format-tp4657040p4657106.html
Sent from the OpenEJB Dev mailing list archive at Nabble.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 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
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;
}
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.
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
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
.nabble.com/DISCUSS-New-descriptor-format-tp4657040p4657092.html
Sent from the OpenEJB Dev mailing list archive at Nabble.com.
)
.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.
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
.n4.nabble.com/DISCUSS-New-descriptor-format-tp4657040p4657095.html
Sent from the OpenEJB Dev mailing list archive at Nabble.com.
...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)
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
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
.nabble.com/DISCUSS-New-descriptor-format-tp4657040p4657047.html
Sent from the OpenEJB Dev mailing list archive at Nabble.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
43 matches
Mail list logo
