You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@aries.apache.org by Sergey Beryozkin <sb...@gmail.com> on 2015/05/18 15:09:13 UTC
Namespaces annotation in blueprint-parser
Hi All,
We've been experimenting recently with registering custom namespace
handlers manually in a non-OSGI environment, with blueprint-web and
blueprint-noosgi components.
It works quite well but as soon as it started working it became obvious
it can be tricky for users to do the manual registration, and it would
be good to have some basic automation support around it.
At the moment Aries NamespaceHandler does have a way to tell what
namespaces it supports. I opened [1] to have a new annotation added for
namespace handler implementations optionally advertise the supported
namespaces.
I've updated a Blueprint Web listener locally that checks a context
property listing the required handler classes only, and the CXF test
that depends on the local updated snapshot is now looking very neat.
The other possible enhancement going forward, once Namespaces is in
blueprint-parsers, would be to ship an optional ServletContainerInitializer.
But the 1st step is to get the annotation shipped. Hope the above and
the comments at [1] makes sense
Thanks, Sergey
[1] https://issues.apache.org/jira/browse/ARIES-1322
Re: Namespaces annotation in blueprint-parser
Posted by Sergey Beryozkin <sb...@gmail.com>.
Did one more update to a blueprint-web listener - it also check for
META-INF/blueprint.handlers.
blueprint.handlers is a more effective way of listing the handlers
compared to a similar Spring alternative involving two files due to
Blueprint NamespaceHandler ability to pull a resource based on a schema
URI plus the recently introduced Namespaces annotation that the handlers
can be optionally annotated with...
Exploring a servlet container initializer is still an option but I guess
we have quite a good coverage now for supporting Blueprint handlers in
no osgi contexts
Sergey
On 18/05/15 17:46, Sergey Beryozkin wrote:
> See r1680054 (same as in the patch),
>
> any concerns - let me know please; hope this little feature would be of
> interest
>
> Sergey
>
> On 18/05/15 17:09, Sergey Beryozkin wrote:
>> See a patch to
>> https://issues.apache.org/jira/browse/ARIES-1323
>>
>> The description of ARIES-1323 shows the example.
>>
>> I've updated blueprint-web BlueprintContextListener to load the handlers
>> itself if a contextual property is available. This is not an ultimate
>> solution but makes it much simpler to continue experimenting with
>> blueprint-web + blueprint-noosgi. As I said, the servlet initializer
>> using the auto-discovered handles can also be created at a later stage.
>>
>> Perhaps the only possible concern is that I've changed a signature in a
>> protected BlueprintContextListener method, from
>>
>> protected NamespaceHandlerSet getNamespaceHandlerSet(ClassLoader tccl)
>> to
>> protected NamespaceHandlerSet getNamespaceHandlerSet(ServletContext
>> servletContext, ClassLoader tccl);
>>
>> as the default implementation needs a reference to ServletContext.
>> I've added the previous signature so I honestly do not expect anyone has
>> already tried overriding it and I guess it is better to do it right
>> later rather than never, but I can easily update
>> BlueprintContextListener to keep that original signature if someone feel
>> strongly about getting it changed
>>
>> Thanks, Sergey
>>
>> On 18/05/15 16:30, Sergey Beryozkin wrote:
>>> Hi
>>>
>>> See in revision 1680044.
>>> Going to update the list shortly about the minor updates to
>>> blueprint-web which utilize a new Namespaces annotation
>>>
>>> Thanks, Sergey
>>> On 18/05/15 14:09, Sergey Beryozkin wrote:
>>>> Hi All,
>>>>
>>>> We've been experimenting recently with registering custom namespace
>>>> handlers manually in a non-OSGI environment, with blueprint-web and
>>>> blueprint-noosgi components.
>>>> It works quite well but as soon as it started working it became obvious
>>>> it can be tricky for users to do the manual registration, and it would
>>>> be good to have some basic automation support around it.
>>>>
>>>> At the moment Aries NamespaceHandler does have a way to tell what
>>>> namespaces it supports. I opened [1] to have a new annotation added for
>>>> namespace handler implementations optionally advertise the supported
>>>> namespaces.
>>>>
>>>> I've updated a Blueprint Web listener locally that checks a context
>>>> property listing the required handler classes only, and the CXF test
>>>> that depends on the local updated snapshot is now looking very neat.
>>>>
>>>> The other possible enhancement going forward, once Namespaces is in
>>>> blueprint-parsers, would be to ship an optional
>>>> ServletContainerInitializer.
>>>>
>>>> But the 1st step is to get the annotation shipped. Hope the above and
>>>> the comments at [1] makes sense
>>>>
>>>> Thanks, Sergey
>>>>
>>>>
>>>> [1] https://issues.apache.org/jira/browse/ARIES-1322
>>>
>>
>
>
--
Sergey Beryozkin
Talend Community Coders
http://coders.talend.com/
Blog: http://sberyozkin.blogspot.com
Re: Namespaces annotation in blueprint-parser
Posted by Sergey Beryozkin <sb...@gmail.com>.
See r1680054 (same as in the patch),
any concerns - let me know please; hope this little feature would be of
interest
Sergey
On 18/05/15 17:09, Sergey Beryozkin wrote:
> See a patch to
> https://issues.apache.org/jira/browse/ARIES-1323
>
> The description of ARIES-1323 shows the example.
>
> I've updated blueprint-web BlueprintContextListener to load the handlers
> itself if a contextual property is available. This is not an ultimate
> solution but makes it much simpler to continue experimenting with
> blueprint-web + blueprint-noosgi. As I said, the servlet initializer
> using the auto-discovered handles can also be created at a later stage.
>
> Perhaps the only possible concern is that I've changed a signature in a
> protected BlueprintContextListener method, from
>
> protected NamespaceHandlerSet getNamespaceHandlerSet(ClassLoader tccl)
> to
> protected NamespaceHandlerSet getNamespaceHandlerSet(ServletContext
> servletContext, ClassLoader tccl);
>
> as the default implementation needs a reference to ServletContext.
> I've added the previous signature so I honestly do not expect anyone has
> already tried overriding it and I guess it is better to do it right
> later rather than never, but I can easily update
> BlueprintContextListener to keep that original signature if someone feel
> strongly about getting it changed
>
> Thanks, Sergey
>
> On 18/05/15 16:30, Sergey Beryozkin wrote:
>> Hi
>>
>> See in revision 1680044.
>> Going to update the list shortly about the minor updates to
>> blueprint-web which utilize a new Namespaces annotation
>>
>> Thanks, Sergey
>> On 18/05/15 14:09, Sergey Beryozkin wrote:
>>> Hi All,
>>>
>>> We've been experimenting recently with registering custom namespace
>>> handlers manually in a non-OSGI environment, with blueprint-web and
>>> blueprint-noosgi components.
>>> It works quite well but as soon as it started working it became obvious
>>> it can be tricky for users to do the manual registration, and it would
>>> be good to have some basic automation support around it.
>>>
>>> At the moment Aries NamespaceHandler does have a way to tell what
>>> namespaces it supports. I opened [1] to have a new annotation added for
>>> namespace handler implementations optionally advertise the supported
>>> namespaces.
>>>
>>> I've updated a Blueprint Web listener locally that checks a context
>>> property listing the required handler classes only, and the CXF test
>>> that depends on the local updated snapshot is now looking very neat.
>>>
>>> The other possible enhancement going forward, once Namespaces is in
>>> blueprint-parsers, would be to ship an optional
>>> ServletContainerInitializer.
>>>
>>> But the 1st step is to get the annotation shipped. Hope the above and
>>> the comments at [1] makes sense
>>>
>>> Thanks, Sergey
>>>
>>>
>>> [1] https://issues.apache.org/jira/browse/ARIES-1322
>>
>
--
Sergey Beryozkin
Talend Community Coders
http://coders.talend.com/
Blog: http://sberyozkin.blogspot.com
Re: Namespaces annotation in blueprint-parser
Posted by Sergey Beryozkin <sb...@gmail.com>.
See a patch to
https://issues.apache.org/jira/browse/ARIES-1323
The description of ARIES-1323 shows the example.
I've updated blueprint-web BlueprintContextListener to load the handlers
itself if a contextual property is available. This is not an ultimate
solution but makes it much simpler to continue experimenting with
blueprint-web + blueprint-noosgi. As I said, the servlet initializer
using the auto-discovered handles can also be created at a later stage.
Perhaps the only possible concern is that I've changed a signature in a
protected BlueprintContextListener method, from
protected NamespaceHandlerSet getNamespaceHandlerSet(ClassLoader tccl)
to
protected NamespaceHandlerSet getNamespaceHandlerSet(ServletContext
servletContext, ClassLoader tccl);
as the default implementation needs a reference to ServletContext.
I've added the previous signature so I honestly do not expect anyone has
already tried overriding it and I guess it is better to do it right
later rather than never, but I can easily update
BlueprintContextListener to keep that original signature if someone feel
strongly about getting it changed
Thanks, Sergey
On 18/05/15 16:30, Sergey Beryozkin wrote:
> Hi
>
> See in revision 1680044.
> Going to update the list shortly about the minor updates to
> blueprint-web which utilize a new Namespaces annotation
>
> Thanks, Sergey
> On 18/05/15 14:09, Sergey Beryozkin wrote:
>> Hi All,
>>
>> We've been experimenting recently with registering custom namespace
>> handlers manually in a non-OSGI environment, with blueprint-web and
>> blueprint-noosgi components.
>> It works quite well but as soon as it started working it became obvious
>> it can be tricky for users to do the manual registration, and it would
>> be good to have some basic automation support around it.
>>
>> At the moment Aries NamespaceHandler does have a way to tell what
>> namespaces it supports. I opened [1] to have a new annotation added for
>> namespace handler implementations optionally advertise the supported
>> namespaces.
>>
>> I've updated a Blueprint Web listener locally that checks a context
>> property listing the required handler classes only, and the CXF test
>> that depends on the local updated snapshot is now looking very neat.
>>
>> The other possible enhancement going forward, once Namespaces is in
>> blueprint-parsers, would be to ship an optional
>> ServletContainerInitializer.
>>
>> But the 1st step is to get the annotation shipped. Hope the above and
>> the comments at [1] makes sense
>>
>> Thanks, Sergey
>>
>>
>> [1] https://issues.apache.org/jira/browse/ARIES-1322
>
Re: Namespaces annotation in blueprint-parser
Posted by Sergey Beryozkin <sb...@gmail.com>.
Hi
See in revision 1680044.
Going to update the list shortly about the minor updates to
blueprint-web which utilize a new Namespaces annotation
Thanks, Sergey
On 18/05/15 14:09, Sergey Beryozkin wrote:
> Hi All,
>
> We've been experimenting recently with registering custom namespace
> handlers manually in a non-OSGI environment, with blueprint-web and
> blueprint-noosgi components.
> It works quite well but as soon as it started working it became obvious
> it can be tricky for users to do the manual registration, and it would
> be good to have some basic automation support around it.
>
> At the moment Aries NamespaceHandler does have a way to tell what
> namespaces it supports. I opened [1] to have a new annotation added for
> namespace handler implementations optionally advertise the supported
> namespaces.
>
> I've updated a Blueprint Web listener locally that checks a context
> property listing the required handler classes only, and the CXF test
> that depends on the local updated snapshot is now looking very neat.
>
> The other possible enhancement going forward, once Namespaces is in
> blueprint-parsers, would be to ship an optional
> ServletContainerInitializer.
>
> But the 1st step is to get the annotation shipped. Hope the above and
> the comments at [1] makes sense
>
> Thanks, Sergey
>
>
> [1] https://issues.apache.org/jira/browse/ARIES-1322