You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@karaf.apache.org by Charles Moulliard <cm...@gmail.com> on 2010/12/23 18:48:34 UTC
jetty.xml --> spring jetty.xml
Hi,
I would like to suggest that we use spring bean syntax to configure
the jetty server. As the spring beans xml syntax is much more
supported by all the developers, that would simplify the configuration
of the jetty.xml file instead of the proprietary syntax used.
http://wiki.eclipse.org/Jetty/Howto/Spring
Regards,
Charles Moulliard
Sr. Principal Solution Architect - FuseSource
Apache Committer
Blog : http://cmoulliard.blogspot.com
Twitter : http://twitter.com/cmoulliard
Linkedin : http://www.linkedin.com/in/charlesmoulliard
Skype: cmoulliard
Re: jetty.xml --> spring jetty.xml
Posted by Guillaume Nodet <gn...@gmail.com>.
As i said I think the security config should be per endpoint, don't
you? Which means the problem isn't on the component or even global,
but rather at the endpoint level.
What if we simply improve the servlet itself to do the authentication
directly, based on the endpoint uri? It's quite easy to do and we
already have the code available in the webconsole/branding karaf
module (it would need to be changed to retrieve the parameters from
the enpoint uri obviously).
On Friday, December 24, 2010, Charles Moulliard <cm...@gmail.com> wrote:
> The problem that we have with camel-servlet is that if we provide a
> securityHandler using parameter (like we do for camel-jetty), then the
> component becomes specific to jetty and in fact camel-servlet can be
> deployed in every j2ee server.
>
> Does it make sense to deploy camel-servlet in a WAR on Karaf just to
> have the security features ?
>
>
> On Fri, Dec 24, 2010 at 1:04 PM, Guillaume Nodet <gn...@gmail.com> wrote:
>> The security bits need to be configured per servlet or per webapp, not
>> globally. Only the authenticator (jaas) can be configured globally.
>>
>> For example, the web console uses the HTTP osgi service and creates
>> its own HttpContext to do the authentication. If you just expose a
>> servlet from an OSGi bundle, exporting a filter or a webapp security
>> config will work. If you deploy a real war/wab you can use the
>> web.xml
>>
>> For camel, I'm not sure how this is done, so not sure what's the best
>> way, but it should be done per endpoint imho, using the url parameters
>> to cinfigure the auhthenticqtion mechanism (basic, digest, ssl...)
>>
>> On Friday, December 24, 2010, Charles Moulliard <cm...@gmail.com> wrote:
>>> It is very difficult to transform spring bean xml into jetty xml
>>> syntax. Here is what I attempt to do but without success
>>>
>>> So it is not possible now to configure jetty + jaas on Karaf
>>>
>>> <Call name="addBean">
>>> <Arg>
>>> <New class="org.eclipse.jetty.plus.jaas.JAASLoginService">
>>> <Set name="name">ldap</Set>
>>> <Set name="loginModuleName">ldap</Set>
>>> <Set name="roleClassNames">
>>> <Array type="java.lang.String">
>>> <Item>org.apache.karaf.jaas.modules.RolePrincipal</Item>
>>> </Array>
>>> </Set>
>>> </New>
>>> </Arg>
>>> </Call>
>>> <Call name="addBean">
>>> <Arg>
>>> <New class="org.eclipse.jetty.http.security.Constraint">
>>> <Set name="name">BASIC</Set>
>>> <Set name="roles">
>>> <Array type="java.lang.String">
>>> <Item>admin</Item>
>>> </Array>
>>> </Set>
>>> <Set name="authenticate">true</Set>
>>> </New>
>>> </Arg>
>>> </Call>
>>>
>>> <Call name="addBean">
>>> <Arg>
>>> <New class="org.eclipse.jetty.security.ConstraintMapping">
>>> <Set name="constraint">
>>> <Array type="org.eclipse.jetty.http.security.Constraint">
>>> <Item>
>>> <New class="org.eclipse.jetty.http.security.Constraint">
>>> <Set name="name">BASIC</Set>
>>> <Set name="roles">
>>> <Array type="java.lang.String">
>>>
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com
Re: jetty.xml --> spring jetty.xml
Posted by Charles Moulliard <cm...@gmail.com>.
The problem that we have with camel-servlet is that if we provide a
securityHandler using parameter (like we do for camel-jetty), then the
component becomes specific to jetty and in fact camel-servlet can be
deployed in every j2ee server.
Does it make sense to deploy camel-servlet in a WAR on Karaf just to
have the security features ?
On Fri, Dec 24, 2010 at 1:04 PM, Guillaume Nodet <gn...@gmail.com> wrote:
> The security bits need to be configured per servlet or per webapp, not
> globally. Only the authenticator (jaas) can be configured globally.
>
> For example, the web console uses the HTTP osgi service and creates
> its own HttpContext to do the authentication. If you just expose a
> servlet from an OSGi bundle, exporting a filter or a webapp security
> config will work. If you deploy a real war/wab you can use the
> web.xml
>
> For camel, I'm not sure how this is done, so not sure what's the best
> way, but it should be done per endpoint imho, using the url parameters
> to cinfigure the auhthenticqtion mechanism (basic, digest, ssl...)
>
> On Friday, December 24, 2010, Charles Moulliard <cm...@gmail.com> wrote:
>> It is very difficult to transform spring bean xml into jetty xml
>> syntax. Here is what I attempt to do but without success
>>
>> So it is not possible now to configure jetty + jaas on Karaf
>>
>> <Call name="addBean">
>> <Arg>
>> <New class="org.eclipse.jetty.plus.jaas.JAASLoginService">
>> <Set name="name">ldap</Set>
>> <Set name="loginModuleName">ldap</Set>
>> <Set name="roleClassNames">
>> <Array type="java.lang.String">
>> <Item>org.apache.karaf.jaas.modules.RolePrincipal</Item>
>> </Array>
>> </Set>
>> </New>
>> </Arg>
>> </Call>
>> <Call name="addBean">
>> <Arg>
>> <New class="org.eclipse.jetty.http.security.Constraint">
>> <Set name="name">BASIC</Set>
>> <Set name="roles">
>> <Array type="java.lang.String">
>> <Item>admin</Item>
>> </Array>
>> </Set>
>> <Set name="authenticate">true</Set>
>> </New>
>> </Arg>
>> </Call>
>>
>> <Call name="addBean">
>> <Arg>
>> <New class="org.eclipse.jetty.security.ConstraintMapping">
>> <Set name="constraint">
>> <Array type="org.eclipse.jetty.http.security.Constraint">
>> <Item>
>> <New class="org.eclipse.jetty.http.security.Constraint">
>> <Set name="name">BASIC</Set>
>> <Set name="roles">
>> <Array type="java.lang.String">
>> <Item>admin</Item>
>> </Array>
>> </Set>
>> <Set name="authenticate">true</Set>
>> </New>
>> </Item>
>> </Array>
>> </Set>
>> <Set name="pathSpec">/*</Set>
>> </New>
>> </Arg>
>> </Call>
>>
>> <Call name="addBean">
>> <Arg>
>> <New class="org.eclipse.jetty.security.ConstraintSecurityHandler">
>> <Set name="authenticator">
>> <New
>> class="org.eclipse.jetty.security.authentication.BasicAuthenticator"/>
>> </Set>
>> <Set name="constraintMappings">
>> <Array type="org.eclipse.jetty.security.ConstraintMapping">
>> <New class="org.eclipse.jetty.security.ConstraintMapping">
>> <Set name="constraint">
>> <Array type="org.eclipse.jetty.http.security.Constraint">
>> <Item>
>> <New class="org.eclipse.jetty.http.security.Constraint">
>> <Set name="name">BASIC</Set>
>> <Set name="roles">
>> <Array type="java.lang.String">
>> <Item>admin</Item>
>> </Array>
>> </Set>
>> <Set name="authenticate">true</Set>
>> </New>
>> </Item>
>> </Array>
>> </Set>
>> <Set name="pathSpec">/*</Set>
>> </New>
>> </Array>
>> </Set>
>>
>> <New class="org.eclipse.jetty.plus.jaas.JAASLoginService">
>> <Set name="name">ldap</Set>
>> <Set name="loginModuleName">ldap</Set>
>> <Set name="roleClassNames">
>> <Array type="java.lang.String">
>> <Item>org.apache.karaf.jaas.modules.RolePrincipal</Item>
>> </Array>
>> </Set>
>> </New>
>>
>> <Set name="strict">false</Set>
>> <Set name="identityService">identityService</Set>
>> </New>
>> </Arg>
>> </Call>
>>
>> On Fri, Dec 24, 2010 at 10:29 AM, Guillaume Nodet <gn...@gmail.com> wrote:
>>> Yeah, but it's just a bit nicer, as we can already do that using the
>>> etc/jetty.xml, so I think it's not very high priority improvement.
>>>
>>> On Friday, December 24, 2010, Charles Moulliard <cm...@gmail.com> wrote:
>>>> The less resources + time consuming approach is to extend ConfigAdmin
>>>> (as you propose) and use the file :
>>>>
>>>> org.ops4j.pax.web.cfg file
>>>>
>>>> and adding parameters that we need to instantiate the constraint,
>>>> constraintMapping and securityHandler of Jetty
>>>>
>>>>
>>>> On Fri, Dec 24, 2010 at 8:26 AM, Guillaume Nodet <gn...@gmail.com> wrote:
>>>>> On Friday, December 24, 2010, Charles Moulliard <cm...@gmail.com> wrote:
>>>>>> Indeed this will not be easy as pax-web must be changed because it
>>>>>> uses a method of jetty to load the resource file (jetty.xml).
>>>>>
>>>>> Yes, that's clearly not an easy task.
>>>>>
>>>>>
>>>>>>
>>>>>> public void start() {
>>>>>> LOG.debug("Starting " + this);
>>>>>> try {
>>>>>> //PAXWEB-193 suggested we should open this up for external configuration
>>>>>> URL jettyResource = getClass().getResource("/jetty.xml");
>>>>>> File serverConfigurationFile = getServerConfigDir();
>>>>>> if (serverConfigurationFile != null) {
>>>>>> if (LOG.isDebugEnabled())
>>>>>> LOG.debug("found server configuration file: "+serverConfigurationFile);
>>>>>> if (!serverConfigurationFile.isDirectory() &&
>>>>>> serverConfigurationFile.canRead()) {
>>>>>> if (LOG.isDebugEnabled()) {
>>>>>> LOG.debug("server config dir is readable and exists");
>>>>>> }
>>>>>> String fileName = serverConfigurationFile.getName();
>>>>>> if (fileName.equalsIgnoreCase("jetty.xml"))
>>>>>> jettyResource = serverConfigurationFile.toURI().toURL();
>>>>>> }
>>>>>> }
>>>>>> if (jettyResource != null) {
>>>>>> ClassLoader loader =
>
> --
> Cheers,
> Guillaume Nodet
> ------------------------
> Blog: http://gnodet.blogspot.com/
> ------------------------
> Open Source SOA
> http://fusesource.com
>
Re: jetty.xml --> spring jetty.xml
Posted by Guillaume Nodet <gn...@gmail.com>.
The security bits need to be configured per servlet or per webapp, not
globally. Only the authenticator (jaas) can be configured globally.
For example, the web console uses the HTTP osgi service and creates
its own HttpContext to do the authentication. If you just expose a
servlet from an OSGi bundle, exporting a filter or a webapp security
config will work. If you deploy a real war/wab you can use the
web.xml
For camel, I'm not sure how this is done, so not sure what's the best
way, but it should be done per endpoint imho, using the url parameters
to cinfigure the auhthenticqtion mechanism (basic, digest, ssl...)
On Friday, December 24, 2010, Charles Moulliard <cm...@gmail.com> wrote:
> It is very difficult to transform spring bean xml into jetty xml
> syntax. Here is what I attempt to do but without success
>
> So it is not possible now to configure jetty + jaas on Karaf
>
> <Call name="addBean">
> <Arg>
> <New class="org.eclipse.jetty.plus.jaas.JAASLoginService">
> <Set name="name">ldap</Set>
> <Set name="loginModuleName">ldap</Set>
> <Set name="roleClassNames">
> <Array type="java.lang.String">
> <Item>org.apache.karaf.jaas.modules.RolePrincipal</Item>
> </Array>
> </Set>
> </New>
> </Arg>
> </Call>
> <Call name="addBean">
> <Arg>
> <New class="org.eclipse.jetty.http.security.Constraint">
> <Set name="name">BASIC</Set>
> <Set name="roles">
> <Array type="java.lang.String">
> <Item>admin</Item>
> </Array>
> </Set>
> <Set name="authenticate">true</Set>
> </New>
> </Arg>
> </Call>
>
> <Call name="addBean">
> <Arg>
> <New class="org.eclipse.jetty.security.ConstraintMapping">
> <Set name="constraint">
> <Array type="org.eclipse.jetty.http.security.Constraint">
> <Item>
> <New class="org.eclipse.jetty.http.security.Constraint">
> <Set name="name">BASIC</Set>
> <Set name="roles">
> <Array type="java.lang.String">
> <Item>admin</Item>
> </Array>
> </Set>
> <Set name="authenticate">true</Set>
> </New>
> </Item>
> </Array>
> </Set>
> <Set name="pathSpec">/*</Set>
> </New>
> </Arg>
> </Call>
>
> <Call name="addBean">
> <Arg>
> <New class="org.eclipse.jetty.security.ConstraintSecurityHandler">
> <Set name="authenticator">
> <New
> class="org.eclipse.jetty.security.authentication.BasicAuthenticator"/>
> </Set>
> <Set name="constraintMappings">
> <Array type="org.eclipse.jetty.security.ConstraintMapping">
> <New class="org.eclipse.jetty.security.ConstraintMapping">
> <Set name="constraint">
> <Array type="org.eclipse.jetty.http.security.Constraint">
> <Item>
> <New class="org.eclipse.jetty.http.security.Constraint">
> <Set name="name">BASIC</Set>
> <Set name="roles">
> <Array type="java.lang.String">
> <Item>admin</Item>
> </Array>
> </Set>
> <Set name="authenticate">true</Set>
> </New>
> </Item>
> </Array>
> </Set>
> <Set name="pathSpec">/*</Set>
> </New>
> </Array>
> </Set>
>
> <New class="org.eclipse.jetty.plus.jaas.JAASLoginService">
> <Set name="name">ldap</Set>
> <Set name="loginModuleName">ldap</Set>
> <Set name="roleClassNames">
> <Array type="java.lang.String">
> <Item>org.apache.karaf.jaas.modules.RolePrincipal</Item>
> </Array>
> </Set>
> </New>
>
> <Set name="strict">false</Set>
> <Set name="identityService">identityService</Set>
> </New>
> </Arg>
> </Call>
>
> On Fri, Dec 24, 2010 at 10:29 AM, Guillaume Nodet <gn...@gmail.com> wrote:
>> Yeah, but it's just a bit nicer, as we can already do that using the
>> etc/jetty.xml, so I think it's not very high priority improvement.
>>
>> On Friday, December 24, 2010, Charles Moulliard <cm...@gmail.com> wrote:
>>> The less resources + time consuming approach is to extend ConfigAdmin
>>> (as you propose) and use the file :
>>>
>>> org.ops4j.pax.web.cfg file
>>>
>>> and adding parameters that we need to instantiate the constraint,
>>> constraintMapping and securityHandler of Jetty
>>>
>>>
>>> On Fri, Dec 24, 2010 at 8:26 AM, Guillaume Nodet <gn...@gmail.com> wrote:
>>>> On Friday, December 24, 2010, Charles Moulliard <cm...@gmail.com> wrote:
>>>>> Indeed this will not be easy as pax-web must be changed because it
>>>>> uses a method of jetty to load the resource file (jetty.xml).
>>>>
>>>> Yes, that's clearly not an easy task.
>>>>
>>>>
>>>>>
>>>>> public void start() {
>>>>> LOG.debug("Starting " + this);
>>>>> try {
>>>>> //PAXWEB-193 suggested we should open this up for external configuration
>>>>> URL jettyResource = getClass().getResource("/jetty.xml");
>>>>> File serverConfigurationFile = getServerConfigDir();
>>>>> if (serverConfigurationFile != null) {
>>>>> if (LOG.isDebugEnabled())
>>>>> LOG.debug("found server configuration file: "+serverConfigurationFile);
>>>>> if (!serverConfigurationFile.isDirectory() &&
>>>>> serverConfigurationFile.canRead()) {
>>>>> if (LOG.isDebugEnabled()) {
>>>>> LOG.debug("server config dir is readable and exists");
>>>>> }
>>>>> String fileName = serverConfigurationFile.getName();
>>>>> if (fileName.equalsIgnoreCase("jetty.xml"))
>>>>> jettyResource = serverConfigurationFile.toURI().toURL();
>>>>> }
>>>>> }
>>>>> if (jettyResource != null) {
>>>>> ClassLoader loader =
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com
Re: jetty.xml --> spring jetty.xml
Posted by Charles Moulliard <cm...@gmail.com>.
It is very difficult to transform spring bean xml into jetty xml
syntax. Here is what I attempt to do but without success
So it is not possible now to configure jetty + jaas on Karaf
<Call name="addBean">
<Arg>
<New class="org.eclipse.jetty.plus.jaas.JAASLoginService">
<Set name="name">ldap</Set>
<Set name="loginModuleName">ldap</Set>
<Set name="roleClassNames">
<Array type="java.lang.String">
<Item>org.apache.karaf.jaas.modules.RolePrincipal</Item>
</Array>
</Set>
</New>
</Arg>
</Call>
<Call name="addBean">
<Arg>
<New class="org.eclipse.jetty.http.security.Constraint">
<Set name="name">BASIC</Set>
<Set name="roles">
<Array type="java.lang.String">
<Item>admin</Item>
</Array>
</Set>
<Set name="authenticate">true</Set>
</New>
</Arg>
</Call>
<Call name="addBean">
<Arg>
<New class="org.eclipse.jetty.security.ConstraintMapping">
<Set name="constraint">
<Array type="org.eclipse.jetty.http.security.Constraint">
<Item>
<New class="org.eclipse.jetty.http.security.Constraint">
<Set name="name">BASIC</Set>
<Set name="roles">
<Array type="java.lang.String">
<Item>admin</Item>
</Array>
</Set>
<Set name="authenticate">true</Set>
</New>
</Item>
</Array>
</Set>
<Set name="pathSpec">/*</Set>
</New>
</Arg>
</Call>
<Call name="addBean">
<Arg>
<New class="org.eclipse.jetty.security.ConstraintSecurityHandler">
<Set name="authenticator">
<New
class="org.eclipse.jetty.security.authentication.BasicAuthenticator"/>
</Set>
<Set name="constraintMappings">
<Array type="org.eclipse.jetty.security.ConstraintMapping">
<New class="org.eclipse.jetty.security.ConstraintMapping">
<Set name="constraint">
<Array type="org.eclipse.jetty.http.security.Constraint">
<Item>
<New class="org.eclipse.jetty.http.security.Constraint">
<Set name="name">BASIC</Set>
<Set name="roles">
<Array type="java.lang.String">
<Item>admin</Item>
</Array>
</Set>
<Set name="authenticate">true</Set>
</New>
</Item>
</Array>
</Set>
<Set name="pathSpec">/*</Set>
</New>
</Array>
</Set>
<New class="org.eclipse.jetty.plus.jaas.JAASLoginService">
<Set name="name">ldap</Set>
<Set name="loginModuleName">ldap</Set>
<Set name="roleClassNames">
<Array type="java.lang.String">
<Item>org.apache.karaf.jaas.modules.RolePrincipal</Item>
</Array>
</Set>
</New>
<Set name="strict">false</Set>
<Set name="identityService">identityService</Set>
</New>
</Arg>
</Call>
On Fri, Dec 24, 2010 at 10:29 AM, Guillaume Nodet <gn...@gmail.com> wrote:
> Yeah, but it's just a bit nicer, as we can already do that using the
> etc/jetty.xml, so I think it's not very high priority improvement.
>
> On Friday, December 24, 2010, Charles Moulliard <cm...@gmail.com> wrote:
>> The less resources + time consuming approach is to extend ConfigAdmin
>> (as you propose) and use the file :
>>
>> org.ops4j.pax.web.cfg file
>>
>> and adding parameters that we need to instantiate the constraint,
>> constraintMapping and securityHandler of Jetty
>>
>>
>> On Fri, Dec 24, 2010 at 8:26 AM, Guillaume Nodet <gn...@gmail.com> wrote:
>>> On Friday, December 24, 2010, Charles Moulliard <cm...@gmail.com> wrote:
>>>> Indeed this will not be easy as pax-web must be changed because it
>>>> uses a method of jetty to load the resource file (jetty.xml).
>>>
>>> Yes, that's clearly not an easy task.
>>>
>>>
>>>>
>>>> public void start() {
>>>> LOG.debug("Starting " + this);
>>>> try {
>>>> //PAXWEB-193 suggested we should open this up for external configuration
>>>> URL jettyResource = getClass().getResource("/jetty.xml");
>>>> File serverConfigurationFile = getServerConfigDir();
>>>> if (serverConfigurationFile != null) {
>>>> if (LOG.isDebugEnabled())
>>>> LOG.debug("found server configuration file: "+serverConfigurationFile);
>>>> if (!serverConfigurationFile.isDirectory() &&
>>>> serverConfigurationFile.canRead()) {
>>>> if (LOG.isDebugEnabled()) {
>>>> LOG.debug("server config dir is readable and exists");
>>>> }
>>>> String fileName = serverConfigurationFile.getName();
>>>> if (fileName.equalsIgnoreCase("jetty.xml"))
>>>> jettyResource = serverConfigurationFile.toURI().toURL();
>>>> }
>>>> }
>>>> if (jettyResource != null) {
>>>> ClassLoader loader = Thread.currentThread().getContextClassLoader();
>>>> try
>>>> {
>>>> Thread.currentThread().setContextClassLoader(
>>>> getClass().getClassLoader() );
>>>> LOG.debug("Configure using resource " + jettyResource);
>>>> XmlConfiguration configuration = new XmlConfiguration(jettyResource);
>>>>
>
> --
> Cheers,
> Guillaume Nodet
> ------------------------
> Blog: http://gnodet.blogspot.com/
> ------------------------
> Open Source SOA
> http://fusesource.com
>
Re: jetty.xml --> spring jetty.xml
Posted by Guillaume Nodet <gn...@gmail.com>.
Yeah, but it's just a bit nicer, as we can already do that using the
etc/jetty.xml, so I think it's not very high priority improvement.
On Friday, December 24, 2010, Charles Moulliard <cm...@gmail.com> wrote:
> The less resources + time consuming approach is to extend ConfigAdmin
> (as you propose) and use the file :
>
> org.ops4j.pax.web.cfg file
>
> and adding parameters that we need to instantiate the constraint,
> constraintMapping and securityHandler of Jetty
>
>
> On Fri, Dec 24, 2010 at 8:26 AM, Guillaume Nodet <gn...@gmail.com> wrote:
>> On Friday, December 24, 2010, Charles Moulliard <cm...@gmail.com> wrote:
>>> Indeed this will not be easy as pax-web must be changed because it
>>> uses a method of jetty to load the resource file (jetty.xml).
>>
>> Yes, that's clearly not an easy task.
>>
>>
>>>
>>> public void start() {
>>> LOG.debug("Starting " + this);
>>> try {
>>> //PAXWEB-193 suggested we should open this up for external configuration
>>> URL jettyResource = getClass().getResource("/jetty.xml");
>>> File serverConfigurationFile = getServerConfigDir();
>>> if (serverConfigurationFile != null) {
>>> if (LOG.isDebugEnabled())
>>> LOG.debug("found server configuration file: "+serverConfigurationFile);
>>> if (!serverConfigurationFile.isDirectory() &&
>>> serverConfigurationFile.canRead()) {
>>> if (LOG.isDebugEnabled()) {
>>> LOG.debug("server config dir is readable and exists");
>>> }
>>> String fileName = serverConfigurationFile.getName();
>>> if (fileName.equalsIgnoreCase("jetty.xml"))
>>> jettyResource = serverConfigurationFile.toURI().toURL();
>>> }
>>> }
>>> if (jettyResource != null) {
>>> ClassLoader loader = Thread.currentThread().getContextClassLoader();
>>> try
>>> {
>>> Thread.currentThread().setContextClassLoader(
>>> getClass().getClassLoader() );
>>> LOG.debug("Configure using resource " + jettyResource);
>>> XmlConfiguration configuration = new XmlConfiguration(jettyResource);
>>>
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com
Re: jetty.xml --> spring jetty.xml
Posted by Charles Moulliard <cm...@gmail.com>.
The less resources + time consuming approach is to extend ConfigAdmin
(as you propose) and use the file :
org.ops4j.pax.web.cfg file
and adding parameters that we need to instantiate the constraint,
constraintMapping and securityHandler of Jetty
On Fri, Dec 24, 2010 at 8:26 AM, Guillaume Nodet <gn...@gmail.com> wrote:
> On Friday, December 24, 2010, Charles Moulliard <cm...@gmail.com> wrote:
>> Indeed this will not be easy as pax-web must be changed because it
>> uses a method of jetty to load the resource file (jetty.xml).
>
> Yes, that's clearly not an easy task.
>
>
>>
>> public void start() {
>> LOG.debug("Starting " + this);
>> try {
>> //PAXWEB-193 suggested we should open this up for external configuration
>> URL jettyResource = getClass().getResource("/jetty.xml");
>> File serverConfigurationFile = getServerConfigDir();
>> if (serverConfigurationFile != null) {
>> if (LOG.isDebugEnabled())
>> LOG.debug("found server configuration file: "+serverConfigurationFile);
>> if (!serverConfigurationFile.isDirectory() &&
>> serverConfigurationFile.canRead()) {
>> if (LOG.isDebugEnabled()) {
>> LOG.debug("server config dir is readable and exists");
>> }
>> String fileName = serverConfigurationFile.getName();
>> if (fileName.equalsIgnoreCase("jetty.xml"))
>> jettyResource = serverConfigurationFile.toURI().toURL();
>> }
>> }
>> if (jettyResource != null) {
>> ClassLoader loader = Thread.currentThread().getContextClassLoader();
>> try
>> {
>> Thread.currentThread().setContextClassLoader(
>> getClass().getClassLoader() );
>> LOG.debug("Configure using resource " + jettyResource);
>> XmlConfiguration configuration = new XmlConfiguration(jettyResource);
>> configuration.configure(m_server);
>> }
>> finally
>> {
>> Thread.currentThread().setContextClassLoader( loader );
>> }
>> }
>> m_server.start();
>> } catch (Exception e) {
>> LOG.error(e);
>> }
>> }
>>
>> By the way, why don't we expose as a OSGI service the HTTP parameters
>> that we need to configure the Jetty Server. In this case, xml file +
>> blueprint can be used to configure the HTTP Parameters interface and
>> then we can inject this reference in pax-web to provide all the info
>> required to configure Jetty Server (port number, session timeout,
>> beans definition to configure securityHandler, .....)
>
> Some of them are already exposed through ConfigAdmin, but even if we
> add some, it may still be limited. But I agree that could be a way to
> go, as pax-web already supports ConfigAdmin and reloading of the
> configuration (which is lost when modifying the jetty.xml btw).
> I'm not sure why we would use an OSGi service to access this config though.
>
>>
>> Otherwise, we can create for Karaf project a bundle extending OSGI
>> HTTP. We can mix the work done with camel-jetty + blueprint + Apache
>> Felix HTTP to reach this goal ....
>
> I would definitely try to avoid that as that's really *A LOT* of work.
>
>
>>
>>
>>
>> On Thu, Dec 23, 2010 at 7:05 PM, Guillaume Nodet <gn...@gmail.com> wrote:
>>> If we were to change, I'd rather use a blueprint config coupled with
>>> some ConfigAdmin support so that we can change the jetty configuration
>>> more easily.
>>> Though I don't think it's that easy to switch, as pax-web needs to be
>>> enhanced I'd think.
>>>
>>> On Thu, Dec 23, 2010 at 18:48, Charles Moulliard <cm...@gmail.com> wrote:
>>>> Hi,
>>>>
>>>> I would like to suggest that we use spring bean syntax to configure
>>>> the jetty server. As the spring beans xml syntax is much more
>>>> supported by all the developers, that would simplify the configuration
>>>> of the jetty.xml file instead of the proprietary syntax used.
>>>>
>>>> http://wiki.eclipse.org/Jetty/Howto/Spring
>>>>
>>>> Regards,
>>>>
>>>> Charles Moulliard
>>>>
>>>> Sr. Principal Solution Architect - FuseSource
>>>> Apache Committer
>>>>
>>>> Blog : http://cmoulliard.blogspot.com
>>>> Twitter : http://twitter.com/cmoulliard
>>>> Linkedin : http://www.linkedin.com/in/charlesmoulliard
>>>> Skype: cmoulliard
>>>>
>>>
>>>
>>>
>>> --
>>> Cheers,
>>> Guillaume Nodet
>>> ------------------------
>>> Blog: http://gnodet.blogspot.com/
>>> ------------------------
>>> Open Source SOA
>>> http://fusesource.com
>>>
>>
>
> --
> Cheers,
> Guillaume Nodet
> ------------------------
> Blog: http://gnodet.blogspot.com/
> ------------------------
> Open Source SOA
> http://fusesource.com
>
Re: jetty.xml --> spring jetty.xml
Posted by Guillaume Nodet <gn...@gmail.com>.
On Friday, December 24, 2010, Charles Moulliard <cm...@gmail.com> wrote:
> Indeed this will not be easy as pax-web must be changed because it
> uses a method of jetty to load the resource file (jetty.xml).
Yes, that's clearly not an easy task.
>
> public void start() {
> LOG.debug("Starting " + this);
> try {
> //PAXWEB-193 suggested we should open this up for external configuration
> URL jettyResource = getClass().getResource("/jetty.xml");
> File serverConfigurationFile = getServerConfigDir();
> if (serverConfigurationFile != null) {
> if (LOG.isDebugEnabled())
> LOG.debug("found server configuration file: "+serverConfigurationFile);
> if (!serverConfigurationFile.isDirectory() &&
> serverConfigurationFile.canRead()) {
> if (LOG.isDebugEnabled()) {
> LOG.debug("server config dir is readable and exists");
> }
> String fileName = serverConfigurationFile.getName();
> if (fileName.equalsIgnoreCase("jetty.xml"))
> jettyResource = serverConfigurationFile.toURI().toURL();
> }
> }
> if (jettyResource != null) {
> ClassLoader loader = Thread.currentThread().getContextClassLoader();
> try
> {
> Thread.currentThread().setContextClassLoader(
> getClass().getClassLoader() );
> LOG.debug("Configure using resource " + jettyResource);
> XmlConfiguration configuration = new XmlConfiguration(jettyResource);
> configuration.configure(m_server);
> }
> finally
> {
> Thread.currentThread().setContextClassLoader( loader );
> }
> }
> m_server.start();
> } catch (Exception e) {
> LOG.error(e);
> }
> }
>
> By the way, why don't we expose as a OSGI service the HTTP parameters
> that we need to configure the Jetty Server. In this case, xml file +
> blueprint can be used to configure the HTTP Parameters interface and
> then we can inject this reference in pax-web to provide all the info
> required to configure Jetty Server (port number, session timeout,
> beans definition to configure securityHandler, .....)
Some of them are already exposed through ConfigAdmin, but even if we
add some, it may still be limited. But I agree that could be a way to
go, as pax-web already supports ConfigAdmin and reloading of the
configuration (which is lost when modifying the jetty.xml btw).
I'm not sure why we would use an OSGi service to access this config though.
>
> Otherwise, we can create for Karaf project a bundle extending OSGI
> HTTP. We can mix the work done with camel-jetty + blueprint + Apache
> Felix HTTP to reach this goal ....
I would definitely try to avoid that as that's really *A LOT* of work.
>
>
>
> On Thu, Dec 23, 2010 at 7:05 PM, Guillaume Nodet <gn...@gmail.com> wrote:
>> If we were to change, I'd rather use a blueprint config coupled with
>> some ConfigAdmin support so that we can change the jetty configuration
>> more easily.
>> Though I don't think it's that easy to switch, as pax-web needs to be
>> enhanced I'd think.
>>
>> On Thu, Dec 23, 2010 at 18:48, Charles Moulliard <cm...@gmail.com> wrote:
>>> Hi,
>>>
>>> I would like to suggest that we use spring bean syntax to configure
>>> the jetty server. As the spring beans xml syntax is much more
>>> supported by all the developers, that would simplify the configuration
>>> of the jetty.xml file instead of the proprietary syntax used.
>>>
>>> http://wiki.eclipse.org/Jetty/Howto/Spring
>>>
>>> Regards,
>>>
>>> Charles Moulliard
>>>
>>> Sr. Principal Solution Architect - FuseSource
>>> Apache Committer
>>>
>>> Blog : http://cmoulliard.blogspot.com
>>> Twitter : http://twitter.com/cmoulliard
>>> Linkedin : http://www.linkedin.com/in/charlesmoulliard
>>> Skype: cmoulliard
>>>
>>
>>
>>
>> --
>> Cheers,
>> Guillaume Nodet
>> ------------------------
>> Blog: http://gnodet.blogspot.com/
>> ------------------------
>> Open Source SOA
>> http://fusesource.com
>>
>
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com
Re: jetty.xml --> spring jetty.xml
Posted by Charles Moulliard <cm...@gmail.com>.
Indeed this will not be easy as pax-web must be changed because it
uses a method of jetty to load the resource file (jetty.xml).
public void start() {
LOG.debug("Starting " + this);
try {
//PAXWEB-193 suggested we should open this up for external configuration
URL jettyResource = getClass().getResource("/jetty.xml");
File serverConfigurationFile = getServerConfigDir();
if (serverConfigurationFile != null) {
if (LOG.isDebugEnabled())
LOG.debug("found server configuration file: "+serverConfigurationFile);
if (!serverConfigurationFile.isDirectory() &&
serverConfigurationFile.canRead()) {
if (LOG.isDebugEnabled()) {
LOG.debug("server config dir is readable and exists");
}
String fileName = serverConfigurationFile.getName();
if (fileName.equalsIgnoreCase("jetty.xml"))
jettyResource = serverConfigurationFile.toURI().toURL();
}
}
if (jettyResource != null) {
ClassLoader loader = Thread.currentThread().getContextClassLoader();
try
{
Thread.currentThread().setContextClassLoader(
getClass().getClassLoader() );
LOG.debug("Configure using resource " + jettyResource);
XmlConfiguration configuration = new XmlConfiguration(jettyResource);
configuration.configure(m_server);
}
finally
{
Thread.currentThread().setContextClassLoader( loader );
}
}
m_server.start();
} catch (Exception e) {
LOG.error(e);
}
}
By the way, why don't we expose as a OSGI service the HTTP parameters
that we need to configure the Jetty Server. In this case, xml file +
blueprint can be used to configure the HTTP Parameters interface and
then we can inject this reference in pax-web to provide all the info
required to configure Jetty Server (port number, session timeout,
beans definition to configure securityHandler, .....)
Otherwise, we can create for Karaf project a bundle extending OSGI
HTTP. We can mix the work done with camel-jetty + blueprint + Apache
Felix HTTP to reach this goal ....
On Thu, Dec 23, 2010 at 7:05 PM, Guillaume Nodet <gn...@gmail.com> wrote:
> If we were to change, I'd rather use a blueprint config coupled with
> some ConfigAdmin support so that we can change the jetty configuration
> more easily.
> Though I don't think it's that easy to switch, as pax-web needs to be
> enhanced I'd think.
>
> On Thu, Dec 23, 2010 at 18:48, Charles Moulliard <cm...@gmail.com> wrote:
>> Hi,
>>
>> I would like to suggest that we use spring bean syntax to configure
>> the jetty server. As the spring beans xml syntax is much more
>> supported by all the developers, that would simplify the configuration
>> of the jetty.xml file instead of the proprietary syntax used.
>>
>> http://wiki.eclipse.org/Jetty/Howto/Spring
>>
>> Regards,
>>
>> Charles Moulliard
>>
>> Sr. Principal Solution Architect - FuseSource
>> Apache Committer
>>
>> Blog : http://cmoulliard.blogspot.com
>> Twitter : http://twitter.com/cmoulliard
>> Linkedin : http://www.linkedin.com/in/charlesmoulliard
>> Skype: cmoulliard
>>
>
>
>
> --
> Cheers,
> Guillaume Nodet
> ------------------------
> Blog: http://gnodet.blogspot.com/
> ------------------------
> Open Source SOA
> http://fusesource.com
>
Re: jetty.xml --> spring jetty.xml
Posted by Guillaume Nodet <gn...@gmail.com>.
If we were to change, I'd rather use a blueprint config coupled with
some ConfigAdmin support so that we can change the jetty configuration
more easily.
Though I don't think it's that easy to switch, as pax-web needs to be
enhanced I'd think.
On Thu, Dec 23, 2010 at 18:48, Charles Moulliard <cm...@gmail.com> wrote:
> Hi,
>
> I would like to suggest that we use spring bean syntax to configure
> the jetty server. As the spring beans xml syntax is much more
> supported by all the developers, that would simplify the configuration
> of the jetty.xml file instead of the proprietary syntax used.
>
> http://wiki.eclipse.org/Jetty/Howto/Spring
>
> Regards,
>
> Charles Moulliard
>
> Sr. Principal Solution Architect - FuseSource
> Apache Committer
>
> Blog : http://cmoulliard.blogspot.com
> Twitter : http://twitter.com/cmoulliard
> Linkedin : http://www.linkedin.com/in/charlesmoulliard
> Skype: cmoulliard
>
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com