On 07.10.2006 14:43, Laurent Perez wrote:
I'm using JSPs an Cocoon 2.2, but I still don't understand if I did the "right" integration : basically, my usecase requires custom JSP tags to be able to retrieve XML from sitemap patterns. Under 2.1, I wrote an integration method starting up a CocoonBean instance and use resolveURI() on it, but it was quite ugly, so since I was already using Spring, I switched to 2.2 and what I did was to add a setter for a SourceResolver in my base custom tag class and then "dependency inject" it via my applicationContext.xml in spring/ folder (my base custom tag class uses a @Configurable to let the injections work).
This is indeed a really complex integration and goes beyond the standard case. You are using JSPs as templating language inside Cocoon which it was never targetted for, but only as XML producer decoupled from the rest of Cocoon.
The wiring works, all my custom tags can use the injected resolver, but I HAD to enable the Cocoon JSPReader (map:match pattern="**.jsp", map:read src(...) type="jsp") to deliver my jsps, otherwise the called resolver would throw an exception saying it requires an Environment setup in order to work. So, it looks like I'm still using a 2.2 environment abstraction, but your post confuses me : would the block:/ protocol ease my integration?
Wondering about your problem I had a look into the code - and the environment abstraction indeed still exists. I thought it already has been removed. I send this mail to dev list too, maybe somebody can comment on this (Daniel, Carsten ?)
For your integration (custom tags accessing Cocoon) the block protocol probably can't help. But instead of a CocoonBean you would be able to use the RequestProcessor, which should be much more lightweight.
Jörg --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
