Thank you Rahul. In fact we were investigating the possibility of having our
own protocol handlers, but we noticed that the resolve() method of
PathResolver returned a string, not an URL. What did you have in mind?

2011/6/7 Rahul Akolkar <rahul.akol...@gmail.com>

> On Mon, Jun 6, 2011 at 5:35 PM, Dario D <darac1...@gmail.com> wrote:
> > Hello,
> >
> > Would it be possible to have a PathResolver implementation which treats
> the
> > "src" element as a pointer to a database entry where content is stored,
> or
> > an in-memory object? Of course, I could make a PathResolver
> implementation
> > which will parse the value of "src" make a query to the database,
> download
> > the content to a file, and then return file path as the result of the
> > resolvePath() method. However, I would like to skip the step of making a
> > file on the disk just for the purpose of loading the "src" content.
> Ideally,
> > this PathResolver implementation would be able to read content directly
> from
> > a memory object (perhaps a cache of some sort), without the need of
> creating
> > a file. I'm planning to use SCXML in a high-throughtput environment and I
> > feel that writing files on the disk and then reading them back will slow
> the
> > process down a bit.
> >
> > One of the requirements for the application is to be able to split SCXML
> > files into many reusable modules, thus the need to use the "src" element.
> >
> > Any thoughts?
> <snip/>
>
> Requirement is reasonable, my suggestion would be to investigate using
> your own scheme for the resolved URLs and providing a custom stream
> protocol handler that reads from memory or cache as desired. For more
> on how to do this, see the java.net.URL class docs, in particular, the
> portion here:
>
>
> http://download.oracle.com/javase/1.4.2/docs/api/java/net/URL.html#URL(java.lang.String,%20java.lang.String,%20int,%20java.lang.String)
>
> Separately, you should be aware that the src attribute has been
> removed from the SCXML spec in favor of standard techniques like
> XInclude, though Commons SCXML will continue to support it till the
> next major release.
>
> -Rahul
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
> For additional commands, e-mail: user-h...@commons.apache.org
>
>

Reply via email to