You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Carsten Ziegeler <cz...@apache.org> on 2007/08/27 13:38:24 UTC
The future of the cron block
I'm wondering what the opinion about the future of our cron block is? Do
we need such a thing at all? Could we just use the quartz support of Spring?
If we keep it, should we refactor it?
Now, I'm asking this because currently I need a scheduling service in a
non Cocoon environment (OSGi based). I thought of just using our cron
block but soon found out that there is no separation between api and
impl, a lot of Cocoon specific stuff mixed in, dependencies to Avalon
directly in the API etc.
My feeling is that if we think about keeping this block, we should clean
it up and solve these issues.
WDYT?
Carsten
--
Carsten Ziegeler
cziegeler@apache.org
Re: The future of the cron block
Posted by Reinhard Poetz <re...@apache.org>.
Grzegorz Kossakowski wrote:
> Reinhard Poetz pisze:
>> Carsten Ziegeler wrote:
>>> I'm wondering what the opinion about the future of our cron block is? Do
>>> we need such a thing at all? Could we just use the quartz support of
>>> Spring?
>>>
>>> If we keep it, should we refactor it?
>>>
>>> Now, I'm asking this because currently I need a scheduling service in a
>>> non Cocoon environment (OSGi based). I thought of just using our cron
>>> block but soon found out that there is no separation between api and
>>> impl, a lot of Cocoon specific stuff mixed in, dependencies to Avalon
>>> directly in the API etc. My feeling is that if we think about keeping
>>> this block, we should clean it up and solve these issues.
>> What use cases does the cron block handle? I used it long time ago to
>> trigger pipelines. If I can do this from within a Spring without having a
>> HTTP request, I have no problem to deprecate it.
>
> What do you mean by "without having HTTP request"? Did you have in mind
> "without having *external* HTTP request" that must go through servlet
> container etc?
>
> Actually, we have plenty of HTTP request in Cocoon 2.2; each servlet: call is
> a new, internal HTTP request.
... that means that I can use the SourceResolver in a Spring bean and resolve a
servlet URI and this will work properly, won't it?
If yes, this would good enough for me to vote +1 for a the cron block deprecation.
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
--------------------------------------------------------------------
Re: The future of the cron block
Posted by Grzegorz Kossakowski <gk...@apache.org>.
Reinhard Poetz pisze:
> Carsten Ziegeler wrote:
>> I'm wondering what the opinion about the future of our cron block is? Do
>> we need such a thing at all? Could we just use the quartz support of
>> Spring?
>>
>> If we keep it, should we refactor it?
>>
>> Now, I'm asking this because currently I need a scheduling service in a
>> non Cocoon environment (OSGi based). I thought of just using our cron
>> block but soon found out that there is no separation between api and
>> impl, a lot of Cocoon specific stuff mixed in, dependencies to Avalon
>> directly in the API etc.
>> My feeling is that if we think about keeping this block, we should clean
>> it up and solve these issues.
>
> What use cases does the cron block handle? I used it long time ago to
> trigger pipelines. If I can do this from within a Spring without having
> a HTTP request, I have no problem to deprecate it.
What do you mean by "without having HTTP request"? Did you have in mind "without having *external*
HTTP request" that must go through servlet container etc?
Actually, we have plenty of HTTP request in Cocoon 2.2; each servlet: call is a new, internal HTTP
request.
--
Grzegorz Kossakowski
http://reflectingonthevicissitudes.wordpress.com/
Re: The future of the cron block
Posted by Reinhard Poetz <re...@apache.org>.
Carsten Ziegeler wrote:
> I'm wondering what the opinion about the future of our cron block is? Do
> we need such a thing at all? Could we just use the quartz support of Spring?
>
> If we keep it, should we refactor it?
>
> Now, I'm asking this because currently I need a scheduling service in a
> non Cocoon environment (OSGi based). I thought of just using our cron
> block but soon found out that there is no separation between api and
> impl, a lot of Cocoon specific stuff mixed in, dependencies to Avalon
> directly in the API etc.
> My feeling is that if we think about keeping this block, we should clean
> it up and solve these issues.
What use cases does the cron block handle? I used it long time ago to trigger
pipelines. If I can do this from within a Spring without having a HTTP request,
I have no problem to deprecate it.
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
--------------------------------------------------------------------
Re: The future of the cron block
Posted by Grzegorz Kossakowski <gk...@apache.org>.
Joerg Heinicke pisze:
> On 27.08.2007 7:38 Uhr, Carsten Ziegeler wrote:
>
>> I'm wondering what the opinion about the future of our cron block is? Do
>> we need such a thing at all? Could we just use the quartz support of
>> Spring?
>
> I'd go with Spring's Quartz integration. Our cron block has (most
> probably) nothing to do with XML processing but is only about
> configuration of Quartz. That's a framework concern and in general I'd
> like to see those delegated more and more to Spring instead of coming
> with our own implementation.
I have never used Cron block but what Joerg says sounds reasonable and I agree with opinion that we
should not try to reinvent the wheel if there is a solution that is maintained and satisfies our needs.
--
Grzegorz Kossakowski
http://reflectingonthevicissitudes.wordpress.com/
Re: The future of the cron block
Posted by Joerg Heinicke <jo...@gmx.de>.
On 27.08.2007 7:38 Uhr, Carsten Ziegeler wrote:
> I'm wondering what the opinion about the future of our cron block is? Do
> we need such a thing at all? Could we just use the quartz support of Spring?
I'd go with Spring's Quartz integration. Our cron block has (most
probably) nothing to do with XML processing but is only about
configuration of Quartz. That's a framework concern and in general I'd
like to see those delegated more and more to Spring instead of coming
with our own implementation.
Joerg
Re: The future of the cron block
Posted by Grzegorz Kossakowski <gk...@apache.org>.
Leszek Gawron pisze:
> Carsten Ziegeler wrote:
>> I'm wondering what the opinion about the future of our cron block is? Do
>> we need such a thing at all? Could we just use the quartz support of
>> Spring?
>>
>> If we keep it, should we refactor it?
>>
>> Now, I'm asking this because currently I need a scheduling service in a
>> non Cocoon environment (OSGi based). I thought of just using our cron
>> block but soon found out that there is no separation between api and
>> impl, a lot of Cocoon specific stuff mixed in, dependencies to Avalon
>> directly in the API etc.
>> My feeling is that if we think about keeping this block, we should clean
>> it up and solve these issues.
>>
>> WDYT?
> I have stopped using cron block as soon as Spring guys introduced their
> own integration. It would be enough to create a helper class that allows
> to call a pipeline easily in Spring pure environment and deprecate the
> rest. Oh wait, there is such class: PipelineUtil...
This will probably not work, PipelineUtil can only work inside existing request because it relies on
environmental data that must be set up externally, see getObjectModel() method in PipelineUtil:
/**
* Helper method to get the current object model.
*/
protected static Map getObjectModel() {
final WebApplicationContext webAppContext =
WebAppContextUtils.getCurrentWebApplicationContext();
final ProcessInfoProvider infoProvider =
(ProcessInfoProvider)webAppContext.getBean(ProcessInfoProvider.ROLE);
return infoProvider.getObjectModel();
}
To be sure that everything is set up, I guess that everything must go through DispatcherServlet.
--
Grzegorz Kossakowski
http://reflectingonthevicissitudes.wordpress.com/
*** My Internet Service Provider breaks my internet connection ***
*** incessantly so I'll not be able to respond to e-mails ***
*** regularly and my work will be somehow irregular. ***
*** I'm already trying to switch ISP but it will take handful amount of time. ***
Re: The future of the cron block
Posted by Leszek Gawron <lg...@mobilebox.pl>.
Carsten Ziegeler wrote:
> I'm wondering what the opinion about the future of our cron block is? Do
> we need such a thing at all? Could we just use the quartz support of Spring?
>
> If we keep it, should we refactor it?
>
> Now, I'm asking this because currently I need a scheduling service in a
> non Cocoon environment (OSGi based). I thought of just using our cron
> block but soon found out that there is no separation between api and
> impl, a lot of Cocoon specific stuff mixed in, dependencies to Avalon
> directly in the API etc.
> My feeling is that if we think about keeping this block, we should clean
> it up and solve these issues.
>
> WDYT?
I have stopped using cron block as soon as Spring guys introduced their
own integration. It would be enough to create a helper class that allows
to call a pipeline easily in Spring pure environment and deprecate the
rest. Oh wait, there is such class: PipelineUtil...
--
Leszek Gawron http://www.mobilebox.pl/krs.html
CTO at MobileBox Ltd.