You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cocoon.apache.org by Justin Fagnani-Bell <ju...@paraliansoftware.com> on 2002/08/01 20:16:35 UTC
Initialization and background threads
Hi List,
The web app I'm developing with Cocoon needs to initialize a few
things at startup and perform some tasks in the background like database
cleanup, checking for mail, automating site updates. Is there a good way
to integrate this with Cocoon?
For the initialization, I'm reading in an XML file to create resources
available to my Cocoon components. I'd like to use the same parser
configured for Cocoon. I've though about adding something like this to
cocoon.xconf:
<init-param>
<param-name>load-class</param-name>
<param-value>MyClass</param-value>
</init-param>
and using a static initializer to perform the initialization and start
the background thread, but I don't see how I could get access to the
Cocoon environment. I'd like to be able to access components and
resources through Cocoon.
Thanks,
Justin
---------------------------------------------------------------------
Please check that your question has not already been answered in the
FAQ before posting. <http://xml.apache.org/cocoon/faq/index.html>
To unsubscribe, e-mail: <co...@xml.apache.org>
For additional commands, e-mail: <co...@xml.apache.org>
RE: webmail
Posted by Conal Tuohy <co...@paradise.net.nz>.
Aaargh ... not enough coffee this morning. My previous message was supposed
to go to Justin directly. My humble apologies for posting off-topic
(would've been OK on the Cocoon-dev list) and in HTML.
Con
---------------------------------------------------------------------
Please check that your question has not already been answered in the
FAQ before posting. <http://xml.apache.org/cocoon/faq/index.html>
To unsubscribe, e-mail: <co...@xml.apache.org>
For additional commands, e-mail: <co...@xml.apache.org>
webmail
Posted by Conal Tuohy <co...@paradise.net.nz>.
Hi Justin
Just a note to keep you up to date on where I'm at, and maybe provoke some
response:
I've been reading more and more, and thinking and drawing architectural
diagrams ... it's more complicated than I first thought. I think this is an
issue for your project too.
Currently I'm still thinking that the JavaMail access should be a Source,
not implementing XMLizable, i.e. it would provide messages in the
"message/rfc822" format. So that hasn't changed.
The parsing to XML should probably be done by either an XMLizer, or a
Generator. Or possibly, another Source, layered on top of the MIME source.
This is the issue that's exercising me at the moment. The fact is that a
MIME message is not a simple data type: it is in fact a kind of file-system,
with other files and directories in it (the MIME-parts).
The big thing which I'd been neglecting was how to provide access to these
MIME-parts (i.e. a PART of a message) to the relevant components of Cocoon.
For instance, a MIME message may contain a part which is in "text/html"
format, and this html may refer (with an IMG tag) to an image which is in
another part of the MIME message, with an "image/gif" mime-type for
instance. To render this doc to a web-browser as html, or as PDF or
whatever, it will be necessary for the Cocoon pipeline to extract this gif
image from within the message, and feed it to the browser or Batik, as
required. Concretely, the web app will have to generate a web page
containing an IMG with href = some url which Cocoon can then use to find the
gif image from inside that particular message.
Much the same applies to MIME-parts which contain message attachments of
some arbitrary mime-type ("application/octet-stream" is a good one) which
Cocoon can't do anything useful with, but which a browser might understand,
or at least download as files.
I have to do this because my list archive needs to handle attachments.
It seems to me I've got 2 main options:
1) XMLize everything
Currently I'm tending towards using an XMLizer which will convert a
"message/rfc822" byte-stream into SAX events (possibly using the XMSG schema
rather than the XMTP schema I've used before: http://www.w3.org/TR/xmsg/ -
I'm not sure about this yet)
This XMLizer would handle all the MIME-parts (even non-xml parts would be
returned as "lumps" of data) and these could therefore be handled using the
various XML-processing mechanisms: Xinclude, XSLT, etc, etc, even without
necessarily being able to process their actual contents. So a GIF image
MIME-part would appear as a <data> element in the SAX stream:
http://www.w3.org/TR/xmsg/#N632 containing some text-encoded GIF data (i.e.
Base64 encoded). For a binary mime-part, Cocoon processing would be limited
to kind of "routing" it through to the browser, without transforming it on
the way. To use this technique, we'd also need a MIMEPartSerializer which
would decode this part into a binary stream, for return to a browser.
Of course, MIME-parts of XML would be parsed fully, and mime-parts of HTML
would be converted to XHTML with JTidy.
Using this approach, to refer to a MIME-part in the sitemap, you would
generate the full message, then extract the part using a transformer for
instance. There'd be no need to encode everything into the source url used
in the sitemap, and this keeps the Source simple (means we can use a
FileSource to read emails from individual files, too).
2) Handle non-XML parts in their native format
I'm not so clear on how this one would work, but I haven't yet ruled it out
entirely ... I still need to get it clear in my head.
We'd need some component that would return a MIME-part from within a
message, in a native format. It seems to me that it will need to implement
Source (as far as Cocoon is concerned, this is the interface for reading a
non-XML resource). But it must be able to get the MIME-part from either a
file or url or from some kind of JavaMail source. So it would be a Source
layered on top of some other source (AFAIK this would be a unique pattern in
Cocoon, but not unreasonable given the nature of MIME-messages).
I'm not sure if this is really a runner: the MIME-parts contain more data
than a Source could provide. For instance, a Content-Disposition. This is
one reason why I'm inclining towards the XMLizer approach. The trouble is
that Cocoon is set up for doing magic with XML, but non-XML data is either
converted to XML or else just passed through with a Reader. There's no
facility for "pipelines" of non-XML data.
----------------------------------------------------------------------------
----
Whew! I've got another busy day today for another client and may not get
anything done on it, but over the weekend I'll spend some more time on it
and hopefully begin some actual programming work.
I've also been trying to define a URL scheme for referring to JavaMail
resources. This also relates to the "cid:" and "mid:" schemes which are used
for hyperlinks within a given MIME message, though as I said, I'd prefer to
leave this out of the javamail or pop or whatever URLs and deal with it
inside the Cocoon pipeline.
It also relates to how to represent the contents of a JavaMail FOLDER to
Cocoon: whether directly as XML or with mime-type "Multipart/report"
http://www.ohse.de/uwe/rfc/rfc1892.html or "Multipart/digest"
http://deesse.univ-lemans.fr:8003/Connected/RFC/1521/19.html which can then
be XMLized with a Cocoon XMLizer. See
http://www.w3.org/Protocols/rfc1341/7_2_Multipart.html for details of
multipart formats.
Anyway ... I'm off now to have some lunch and then I have to visit a client.
I hope your work is going ok.
Con
Re: Initialization and background threads
Posted by Justin <ju...@netwerkelectric.com>.
I knew I'd find it as soon as I sent the email. It's in the FAQ.
Thanks to all those who would have responded ;)
Justin
On Sunday, August 4, 2002, at 05:16 PM, Justin Fagnani-Bell wrote:
> On Thursday, August 1, 2002, at 04:35 PM, Vadim Gritsenko wrote:
>
>>> From: Justin Fagnani-Bell [mailto:justin@paraliansoftware.com]
>>>
>>> The web app I'm developing with Cocoon needs to initialize a few
>>> things at startup and perform some tasks in the background like
>>> database
>>> cleanup, checking for mail, automating site updates. Is there a good
>>> way
>>> to integrate this with Cocoon?
>>
>> It's not first time this question was asked, and here is the usual
>> answer: follow implementation of HSQLDB built-in server in
>> hsqldb/Server.java and in hsqldb/ServerImpl.java. See how it is
>> declared
>> in cocoon.roles and cocoon.xconf.
>>
>> Vadim
>
> Thanks Vadim, your help is much appreciated.
>
> There is there a way to do this without modifying cocoon.roles, right?
> I don't want to have to rebuild the cocoon jar file if I change my
> roles. I know there's the user.roles file, but right now I can't find
> the docs on it, or the example. I know I've seen it somewhere... I
> think I've also seen the role specified directly in cocoon.xconf.
>
> Justin
>
---------------------------------------------------------------------
Please check that your question has not already been answered in the
FAQ before posting. <http://xml.apache.org/cocoon/faq/index.html>
To unsubscribe, e-mail: <co...@xml.apache.org>
For additional commands, e-mail: <co...@xml.apache.org>
Re: Initialization and background threads
Posted by Justin Fagnani-Bell <ju...@paraliansoftware.com>.
On Thursday, August 1, 2002, at 04:35 PM, Vadim Gritsenko wrote:
>> From: Justin Fagnani-Bell [mailto:justin@paraliansoftware.com]
>>
>> The web app I'm developing with Cocoon needs to initialize a few
>> things at startup and perform some tasks in the background like
>> database
>> cleanup, checking for mail, automating site updates. Is there a good
>> way
>> to integrate this with Cocoon?
>
> It's not first time this question was asked, and here is the usual
> answer: follow implementation of HSQLDB built-in server in
> hsqldb/Server.java and in hsqldb/ServerImpl.java. See how it is declared
> in cocoon.roles and cocoon.xconf.
>
> Vadim
Thanks Vadim, your help is much appreciated.
There is there a way to do this without modifying cocoon.roles, right? I
don't want to have to rebuild the cocoon jar file if I change my roles.
I know there's the user.roles file, but right now I can't find the docs
on it, or the example. I know I've seen it somewhere... I think I've
also seen the role specified directly in cocoon.xconf.
Justin
---------------------------------------------------------------------
Please check that your question has not already been answered in the
FAQ before posting. <http://xml.apache.org/cocoon/faq/index.html>
To unsubscribe, e-mail: <co...@xml.apache.org>
For additional commands, e-mail: <co...@xml.apache.org>
RE: Initialization and background threads
Posted by Vadim Gritsenko <va...@verizon.net>.
> From: Justin Fagnani-Bell [mailto:justin@paraliansoftware.com]
>
> Hi List,
>
> The web app I'm developing with Cocoon needs to initialize a few
> things at startup and perform some tasks in the background like
database
> cleanup, checking for mail, automating site updates. Is there a good
way
> to integrate this with Cocoon?
>
> For the initialization, I'm reading in an XML file to create resources
> available to my Cocoon components. I'd like to use the same parser
> configured for Cocoon. I've though about adding something like this to
> cocoon.xconf:
>
> <init-param>
> <param-name>load-class</param-name>
> <param-value>MyClass</param-value>
> </init-param>
>
> and using a static initializer to perform the initialization and start
> the background thread, but I don't see how I could get access to the
> Cocoon environment. I'd like to be able to access components and
> resources through Cocoon.
It's not first time this question was asked, and here is the usual
answer: follow implementation of HSQLDB built-in server in
hsqldb/Server.java and in hsqldb/ServerImpl.java. See how it is declared
in cocoon.roles and cocoon.xconf.
Vadim
> Thanks,
> Justin
---------------------------------------------------------------------
Please check that your question has not already been answered in the
FAQ before posting. <http://xml.apache.org/cocoon/faq/index.html>
To unsubscribe, e-mail: <co...@xml.apache.org>
For additional commands, e-mail: <co...@xml.apache.org>