You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cxf.apache.org by Sergey Beryozkin <sb...@progress.com> on 2009/11/23 11:45:54 UTC

Re: [New feature] Logging in ATOM Feeds and pushing to client

Hi Andy

I've just had a chance to read the documentation you put in place, I think it is very impressive. Just CC-ing to the dev list, as 
this feature is still being developed, given that CXF 2.2.6 will only be released early next year.

I have just few comments. They're more about some additional configs/etc

- At the moment the log events are embedded inside feeds, which is fine, especially when the batch size is greater than one...I feel 
it would make sense to let users choose that a single Atom entry (not wrapped by a feed) should be pushed if a batch size is equal 
to 1.
Perhaps it can done by default (batch size1 -> entry, >=1 -> feed of entries) but let users to enable/disable this entry-only 
delivery.

For ex, the remote URI can point to some other feed (collection) which the client exposes to its own consumers, so it might be 
useful to let them simply point to a feed URI and CXF will just POST individual entries to it, it will be just a normal AtomPub 
collection update.
And if users have chosen to push, say, only fatal log events, then sending an entry per log event would not put much stress on the 
CXF...

- Atom specific : users should be able to choose how a log record is embedded inside a given entry. I like the idea of putting it 
into atom:entry:/atom:content of type application/xml, however some users may prefer the Atom extenstions, so it will be an 
atom:entry/log:logRecord...The latter option might work well for json given that Abdera supports JSON, not sure though...but also 
let add an html content to the entry/content, in addition to the xml content added directly to the entry element.

- It would be nice to let users easily inject customized WebClients (ex, preferring JSON or set with some additional headers, etc) 
from Spring, but it may actually be quite easy to do, they'll have to reconfigure a WebDeliverer bean and possibly list a default 
retrier bean ?

- I like the idea of letting users to select multiple loggers(packages)/levels...It should cover most of cases. Perhaps, going 
forward, we may let them choose not only by level but also by level and category, category only, etc...

- At the moment, the delivery will stop if a single delivery fails, unless a retry strategy is configured. I think it is reasonable. 
But I'm thinking of having a property such as a 'send and forget' one, but we can enable it once WebClient start supporting one 
ways.

That is mostly it,
thanks, Sergey



>
> Recent builds started to expose initial effort of JAXRS extension in area of
> logging -- ability to handle log events, pack as ATOM Feeds and push to the
> client. Documentation is available here:
> http://cwiki.apache.org/CXF20DOC/jax-rs.html#JAX-RS-ATOMpushstylelogging. I
> would like to validate future steps with community so feel free to share
> your comments here.
>
> cheers, andy.
> -- 
> View this message in context: 
> http://old.nabble.com/-New-feature--Logging-in-ATOM-Feeds-and-pushing-to-client-tp26452485p26452485.html
> Sent from the cxf-user mailing list archive at Nabble.com.
> 


Re: [New feature] Logging in ATOM Feeds and pushing to client

Posted by Sergey Beryozkin <sb...@progress.com>.
Hi Andy

>>
>> - At the moment the log events are embedded inside feeds,  [...] it would
>> make sense to let users choose that a single Atom entry
>>
> Agree, can be done easily as next strategy (converter class) so user has
> full control of pair of format (converter) and batch size. I have to take a
> look on AtomPub spec, I am still new to Atom stuff ;)

It may make sense to have a single WebDeliverer but initialized with both AtomFeed and AtomEntry providers, and if the Element is an 
instance of Entry then it will set the type to be application/atom+xml;type=entry...

Perhaps we can default to an 'entry' if the batch size = 1, so that users can avoid specifying converter classes...I kind of like 
the idea of letting users to specify, if possible, non-class-specific properties, but letting them to name individual converters can 
be useful too...

<snip/>

>>
>> - It would be nice to let users easily inject customized WebClients (ex,
>> preferring JSON or set with some additional headers, etc)
>> from Spring, but it may actually be quite easy to do, they'll have to
>> reconfigure a WebDeliverer bean and possibly list a default
>> retrier bean ?
>>
> You can do it now on Spring XML confing level (without annotations so far),
> more or less like this:
>
> <bean id="wc" class="...WebClient" ... />
> <bean id="wcd" class="...ext.logging.atom.WebClientDeliverer">
>  <constructor-arg><ref bean="wc" /><constructor-arg>
> </bean>
> <bean class="...ext.logging.atom.AtomPushBean">
>  <property name="deliverer"><ref bean="wcd"></property>
>  ...
> </bean>

This looks fine ...

>
> I can imagine more tricky but for me dirty way (it is NOT DONE so far);
> WebClientDeliverer used by default may have injected field like this:
> @Resource("atom-deliverer") WebClient webclient;
> and use it if injected by spring. This way one may simply define bean with
> this hardcoded name and it is picked up wiring AtomPushBean, e.g.:
>
> <bean id="atom-deliverer" class="...WebClient" ... />
> <bean class="...ext.logging.atom.AtomPushBean" .. />
>  <!-- deliverer not customized here -->
> </bean>
>

I agree, probably does not make sense,

> <bean id="wcd" class="...ext.logging.atom.WebClientDeliverer">
>  <constructor-arg><ref bean="wc" /><constructor-arg>
> </bean>

is not too difficult

thanks
Sergey

>
> Thanks for your thoughts Sergey,
> cheers, andy.
>
> -- 
> View this message in context: 
> http://old.nabble.com/-New-feature--Logging-in-ATOM-Feeds-and-pushing-to-client-tp26452485p26476716.html
> Sent from the cxf-user mailing list archive at Nabble.com.
> 


Re: [New feature] Logging in ATOM Feeds and pushing to client

Posted by amichalec <an...@gmail.com>.
Hi Sergey,
good points


Sergey Beryozkin-2 wrote:
> 
> Just CC-ing to the dev list, as this feature is still being developed,
> given that CXF 2.2.6 will only be released early next year.
> 
Agreed. I mentioned 2.2.6 in documentation to avoid confusion like this "I
am using latest available release 2.2.5 and there is not ATOM logging as
documentation describes". We can even say that it is available from "CXF
2.2.6 (or latest unstable snapshot version)". 


Sergey Beryozkin-2 wrote:
> 
> - At the moment the log events are embedded inside feeds,  [...] it would
> make sense to let users choose that a single Atom entry
> 
Agree, can be done easily as next strategy (converter class) so user has
full control of pair of format (converter) and batch size. I have to take a
look on AtomPub spec, I am still new to Atom stuff ;)


Sergey Beryozkin-2 wrote:
> 
> - Atom specific : users should be able to choose how a log record is
> embedded inside a given entry. I like the idea of putting it 
> into atom:entry:/atom:content of type application/xml, however some users
> may prefer the Atom extenstions, so it will be an 
> atom:entry/log:logRecord...
> 
Already done yesterday, you can find SingleEntryExtensionCoverter and
MultiEntryExtensionConverter classes in trunk.


Sergey Beryozkin-2 wrote:
> 
> - It would be nice to let users easily inject customized WebClients (ex,
> preferring JSON or set with some additional headers, etc) 
> from Spring, but it may actually be quite easy to do, they'll have to
> reconfigure a WebDeliverer bean and possibly list a default 
> retrier bean ?
> 
You can do it now on Spring XML confing level (without annotations so far),
more or less like this:

<bean id="wc" class="...WebClient" ... />
<bean id="wcd" class="...ext.logging.atom.WebClientDeliverer">
  <constructor-arg><ref bean="wc" /><constructor-arg>
</bean>
<bean class="...ext.logging.atom.AtomPushBean">
  <property name="deliverer"><ref bean="wcd"></property>
  ...
</bean>

I can imagine more tricky but for me dirty way (it is NOT DONE so far);
WebClientDeliverer used by default may have injected field like this:
@Resource("atom-deliverer") WebClient webclient;
and use it if injected by spring. This way one may simply define bean with
this hardcoded name and it is picked up wiring AtomPushBean, e.g.:

<bean id="atom-deliverer" class="...WebClient" ... />
<bean class="...ext.logging.atom.AtomPushBean" .. />
  <!-- deliverer not customized here -->
</bean>



Sergey Beryozkin-2 wrote:
> 
> - At the moment, the delivery will stop if a single delivery fails, unless
> a retry strategy is configured. I think it is reasonable. 
> But I'm thinking of having a property such as a 'send and forget' one, but
> we can enable it once WebClient start supporting one 
> ways.
> 
Yes, I did "stop if a single delivery fails" intentionally; pressure is on
decorating deliverers. Send and forget also can be done as decorator of
deliverer - the one always returning "success" regardless returned value of
real deliverer. We can place this FireAndForgetDeliverer as predefined
strategy next to RetryingDeliverer.

Thanks for your thoughts Sergey,
cheers, andy.

-- 
View this message in context: http://old.nabble.com/-New-feature--Logging-in-ATOM-Feeds-and-pushing-to-client-tp26452485p26476716.html
Sent from the cxf-user mailing list archive at Nabble.com.