Re: [C3] Can i18n transformer use an internal pipeline as bundle?

Hi Alberto,

Yes, servlet-service is used if acting as a transformer or a serializer. If
you use generator, there is no need to specify servlet-service.

I used servlet:/ protocol in many generator cases and from within
XIncludeTransformer (x:xinclude) but not as a map:parameter so far.

Greetings,
Greg


2014/1/17 Alberto Brosich <[email protected]>

>
> Hi Greg,
>
> I already took a look to the sample sitemap and I found the following
> example:
>
>      <map:match pattern="internal-only/simple-xml">
>         <map:generate src="sax-pipeline/simple.xml" />
>         <map:transform src="sax-pipeline/simple.xslt">
>           <map:parameter name="myParam"
> value="3-{jexl:cocoon.request.ssf}" />
>         </map:transform>
>         <map:serialize type="xml" />
>       </map:match>
>
>       <map:match pattern="ssf/local-internal-only">
>         <map:generate src="servlet:/internal-only/simple-xml" />
>         <map:serialize type="xml" />
>       </map:match>
>
> Second match uses "servlet:" protocol. The "internal-only/simple-xml"
> match is used as source of data.
> So I supposed it is something similar to my needs. i18n bundle parameter
> needs a "source of data", usually a file (better, a group of file, as
> java.util.ResourceBundle is). In this case no "service-consumer" or
> "servlet-service" are used.
>
> Reading the sample sitemap I understood that "service-consumer" and
> "servlet-service" are used when you want to use a match as transformer
> or serializer.
>
> I understood wrong?
>
> Regards
>
> Alberto
>
>
>
> On Fri, 2014-01-17 at 11:32 +0100, gelo1234 wrote:
> > Hello Alberto,
> >
> >
> > One more thing is that any map:transform or map:serialize must have:
> > type="servlet-service" with servlet:/ protocol.
> >
> >
> >
> > Greetings,
> > Greg
> >
> >
> >
> > 2014/1/17 gelo1234 <[email protected]>
> >         Hello Alberto,
> >
> >
> >         Have you defined
> >
> >         <map:match pattern="translations_*.properties">
> >
> >
> >         with:
> >         <map:generate type="service-consumer"/> ?
> >
> >
> >         Otherwise:
> >
> >         <map:parameter name="bundle"
> >
> >
> value="servlet:/translations_{jexl:cocoon.request.lang}.properties" />
> >
> >
> >         will not work as expected.
> >
> >
> >         Take a look at C3 samples sitemap.xmap [1] which shows correct
> >         definition of service consumer.
> >
> >
> >         Greetings,
> >         Greg
> >
> >         [1]
> >
> http://svn.apache.org/repos/asf/cocoon/cocoon3/trunk/cocoon-sample/src/main/resources/COB-INF/sitemap.xmap
> >
> >
> >
> >         2014/1/17 Alberto Brosich <[email protected]>
> >
> >                 Hi,
> >
> >                 I'm migrating a 2.1 cocoon application to 3.0, using
> >                 beta1-SNAPSHOT
> >                 because I need the sql transformer.
> >                 As I wrote in the subject, I'm need to specify an
> >                 internal pipeline as
> >                 bundle for the i18n transformer, because the
> >                 properties file has to be
> >                 derived from database. Using a plain file it works.
> >                 I tried several urls using "servlet:" protocol, but
> >                 without success.
> >
> >                 I have the following internal pipeline:
> >                 <map:match pattern="translations_*.properties">
> >
> >                 and I tried several bundles urls like:
> >                 <map:parameter name="bundle"
> >                 value="servlet:/translations" />
> >                 or
> >                 <map:parameter name="bundle"
> >
> value="servlet:/translations_{jexl:cocoon.request.lang}.properties" />
> >
> >                 The exception is:
> >                 org.apache.cocoon.pipeline.SetupException:
> >                 java.util.MissingResourceException: Can't find bundle
> >                 for base name
> >                 servlet:/translations, locale en
> >
> >                 What I doing wrong?
> >
> >                 Best regards
> >
> >                 Alberto
> >
> >
> >
> ---------------------------------------------------------------------
> >                 To unsubscribe, e-mail:
> >                 [email protected]
> >                 For additional commands, e-mail:
> >                 [email protected]
> >
> >
> >
> >
> >
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [email protected]
> For additional commands, e-mail: [email protected]
>
>