And what about adding a few standard properties to a) ?
In EJBContainer (
http://docs.oracle.com/javaee/6/api/javax/ejb/embeddable/EJBContainer.html)
there are only 3 standard properties : APP_NAME, MODULES, PROVIDER.
Anything extra is implementation specific. A bit like JPA 2.0 where
properties in persistence.xml starting with javax.persistence are standard,
others are not.
You could think of common properties that make sense for all implementation
(HTTP port for ex) and then leave the implementation. This way you could
have :
// Creates a web container based on the default implementation
WebContainer webc = WebContainer.createWebContainer()
// Creates a web container based on the default implementation and
overrides the standard HTTP port
Map<String, Object> properties = new HashMap<String, Object>();
properties.put(WebContainer.HTTP_PORT, 8080);
properties.put("implementationSpecificProperty, "foo"));
WebContainer webc = WebContainer.createWebContainer()
What do you think ?
Antonio
On Thu, Feb 9, 2012 at 16:12, Mark Thomas <markt_at_apache.org> wrote:
> On 09/02/2012 14:23, Antonio Goncalves wrote:
> > Any thoughts ?
>
> The Servlet specification deliberately places container configuration
> outside of the specification scope. I'm thinking of things like: IP
> address and port to bind to; host name(s) for HTTP virtual hosting;
> configuration of SSL certificates; provision of required JNDI resources;
> credential stores to authenticate against etc.
>
> While defaults are available for these which might be good enough for
> unit testing there are far more use cases where some form of
> configuration would be required. Any such configuration currently uses a
> container specific API.
>
> That appears to leave the following options:
> a) Use the existing container specific APIs to create and a configure a
> container.
> b) Add the API along the lines you suggest and use this to create the
> container followed by container specific API to configure it.
> c) Expand the proposed API and scope of the Servlet spec to include
> container configuration and then use the new API to create and configure
> the container.
>
> I am strongly against c).
>
> I don't really see the point of b) since one needs to use a container
> specific API anyway.
>
> That leaves a), the current position.
>
> Mark
>
--
Antonio Goncalves
Software architect and Java Champion
Web site <http://www.antoniogoncalves.org> |
Twitter<http://twitter.com/agoncal>|
Blog <http://feeds.feedburner.com/AntonioGoncalves> |
LinkedIn<http://www.linkedin.com/in/agoncal>| Paris
JUG <http://www.parisjug.org>