RE: Cocoon 2.2 block+sitemap question
I think the main question is if it (block-b) is protected software which cannot
be distributed to your client. If that is no issue, you could for instance try
out if you can replace the value of the @src from
servlet:block-b:/document
to
${document-pattern}
and inject this as a property into the sitemap using
cocoon-spring-configurator. The property then would get a different value
depending on the environment profile which is loaded at initialization of the
spring context.
If my proposal is a suitable approach feel free to ask for more information
if you get stuck.
Kind regards,
Robby Pelssers
-Oorspronkelijk bericht-
Van: Fawzib Rojas [mailto:f_ro...@spectron-msim.com]
Verzonden: wo 3-11-2010 13:29
Aan: users@cocoon.apache.org
Onderwerp: Re: Cocoon 2.2 block+sitemap question
I have a webapp (war) that we use at our company it has a few blocks
(let say block-a to block-d), I want to install that war at our clients
but they should not have block-b. The simplest option would be just
remove that block and serve a simple document if its not found. The
other option is have 2 projects one for us one for clients which seems
extra work since the only difference is:
a) block-b not included
b) change a matcher in block-a sitemap from this:
to this:
On 11/2/2010 11:17 AM, Robby Pelssers
begin_of_the_skype_highlighting end_of_the_skype_highlighting wrote:
> I have a more urgent question to you...
>
> why would you want to sometimes not include block-b??? I think your design
> should be reconsidered drastically because this makes no sense to me... so
> i'll await your reponse for a good reason ;-)
>
> Robby
>
>
> -Oorspronkelijk bericht-
> Van: Fawzib Rojas [mailto:f_ro...@spectron-msim.com]
> Verzonden: di 2-11-2010 14:43
> Aan: users@cocoon.apache.org
> Onderwerp: Cocoon 2.2 block+sitemap question
>
> I have 2 blocks (block-a and block-b) and I want to serve an xml from
> block-b in block-a so i did the following:
>
> block-a/block-servlet-service.xml:
> context-path="blockcontext:/block-a/">
>
>
>
>
>
> block-a/sitemap.xml:
>
>
>
>
>
>
>
> That way i can read the my document using /block-a/document. In certain
> instances block-b wont be included in the war so I want the
> /block-a/document to go to a default document in block-a so I thought of
> adding an error handler, something like this:
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> Since the connection in the block-a/block-servlet-service.xml cannot be
> made the war is not loaded so this method wont work. Is there another
> way to do this?
>
> -
> To unsubscribe, e-mail: users-unsubscr...@cocoon.apache.org
> For additional commands, e-mail: users-h...@cocoon.apache.org
>
>
>
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@cocoon.apache.org
> For additional commands, e-mail: users-h...@cocoon.apache.org
<>
-
To unsubscribe, e-mail: users-unsubscr...@cocoon.apache.org
For additional commands, e-mail: users-h...@cocoon.apache.org
Re: Cocoon 2.2 block+sitemap question
I have to admit that your design is somewhat odd. Apparently you have a particular block in your webapp that is only to be used by your company but not by your clients. There is no obvious solution. You could create a Makefile for running make or a shell script on *nix boxes. It would copy the relevant blocks of your webapp into a separate folder, then automatically replaces the relevant portions of your block a sitemap into something else that does not rely on block b, and, finally, run maven to create the war for your clients. You can do this each time you want to deploy a stripped webapp to your clients. This would be a fully automated solution. If you deploy your webapp to your own server that is also accessible by your clients, you could consider to make a small modification in the block-a sitemap. Before serving the document, first call a flowscript function that decides whether or not block b in fact should called. If not, then continue with a pipeline in block a that servers the document from block-a-resources/document.xml, otherwise continue with a pipeline that calls block b. The flowscript could check whether or not the request is from within the company or from outside (e.g. by IP addresses). Best regards, Andre On 11/03/2010 02:29 PM, Fawzib Rojas wrote: I have a webapp (war) that we use at our company it has a few blocks (let say block-a to block-d), I want to install that war at our clients but they should not have block-b. The simplest option would be just remove that block and serve a simple document if its not found. The other option is have 2 projects one for us one for clients which seems extra work since the only difference is: a) block-b not included b) change a matcher in block-a sitemap from this: to this: On 11/2/2010 11:17 AM, Robby Pelssers wrote: I have a more urgent question to you... why would you want to sometimes not include block-b??? I think your design should be reconsidered drastically because this makes no sense to me... so i'll await your reponse for a good reason ;-) Robby -Oorspronkelijk bericht- Van: Fawzib Rojas [mailto:f_ro...@spectron-msim.com] Verzonden: di 2-11-2010 14:43 Aan:users@cocoon.apache.org Onderwerp: Cocoon 2.2 block+sitemap question I have 2 blocks (block-a and block-b) and I want to serve an xml from block-b in block-a so i did the following: block-a/block-servlet-service.xml: block-a/sitemap.xml: That way i can read the my document using /block-a/document. In certain instances block-b wont be included in the war so I want the /block-a/document to go to a default document in block-a so I thought of adding an error handler, something like this: Since the connection in the block-a/block-servlet-service.xml cannot be made the war is not loaded so this method wont work. Is there another way to do this? - To unsubscribe, e-mail:users-unsubscr...@cocoon.apache.org For additional commands, e-mail:users-h...@cocoon.apache.org - To unsubscribe, e-mail:users-unsubscr...@cocoon.apache.org For additional commands, e-mail:users-h...@cocoon.apache.org -- Andre H. Juffer | Phone: +358-8-553 1161 Biocenter Oulu and | Fax: +358-8-553-1141 Department of Biochemistry | Email: andre.juf...@oulu.fi University of Oulu, Finland | WWW: www.biochem.oulu.fi/Biocomputing/ StruBioCat | WWW: www.strubiocat.oulu.fi NordProt | WWW: www.nordprot.org Triacle Biocomputing | WWW: www.triacle-bc.com - To unsubscribe, e-mail: users-unsubscr...@cocoon.apache.org For additional commands, e-mail: users-h...@cocoon.apache.org
Re: Cocoon 2.2 block+sitemap question
I have a webapp (war) that we use at our company it has a few blocks (let say block-a to block-d), I want to install that war at our clients but they should not have block-b. The simplest option would be just remove that block and serve a simple document if its not found. The other option is have 2 projects one for us one for clients which seems extra work since the only difference is: a) block-b not included b) change a matcher in block-a sitemap from this: to this: On 11/2/2010 11:17 AM, Robby Pelssers wrote: I have a more urgent question to you... why would you want to sometimes not include block-b??? I think your design should be reconsidered drastically because this makes no sense to me... so i'll await your reponse for a good reason ;-) Robby -Oorspronkelijk bericht- Van: Fawzib Rojas [mailto:f_ro...@spectron-msim.com] Verzonden: di 2-11-2010 14:43 Aan: users@cocoon.apache.org Onderwerp: Cocoon 2.2 block+sitemap question I have 2 blocks (block-a and block-b) and I want to serve an xml from block-b in block-a so i did the following: block-a/block-servlet-service.xml: block-a/sitemap.xml: That way i can read the my document using /block-a/document. In certain instances block-b wont be included in the war so I want the /block-a/document to go to a default document in block-a so I thought of adding an error handler, something like this: Since the connection in the block-a/block-servlet-service.xml cannot be made the war is not loaded so this method wont work. Is there another way to do this? - To unsubscribe, e-mail: users-unsubscr...@cocoon.apache.org For additional commands, e-mail: users-h...@cocoon.apache.org - To unsubscribe, e-mail: users-unsubscr...@cocoon.apache.org For additional commands, e-mail: users-h...@cocoon.apache.org
[2.2] RCL not only for dev ?
Hi all, As I work on 2.2 for Lenya I figured out a "strange" comportment with rcl. We have this blocks 1) webapp-welcome with goal mvn jetty:run 2) webapp with an rcl.properties 3) export that is call from a usecase component in usecase block. This export have this bean declaration : When I mvn jetty:run then call the export.importExampleContent component I have this error [1] : UsecaseView can't be cast to UsecaseView... hummm, strange no ? :) If I add this line in the webapp/rcl.properties : org.apache.lenya.module.export.block%classes-dir=../org.apache.lenya.module.export/target/classes No still error. Any ideas due to ? Eclipse, jetty, bad configuration,... ? When publish this will also occur when I try to publish as a war ? Thanks for any light. ++ [1] org.apache.cocoon.ProcessingException: Error calling function executeUsecase at getUsecase - file:///home/florent/devel/dev-lenya/lenyaSources/NEXT-VERSION/TRUNK/org.apache.lenya.core.api/../org.apache.lenya.core.usecase/target/classes/COB-INF/usecases.js:64 at executeUsecase - file:///home/florent/devel/dev-lenya/lenyaSources/NEXT-VERSION/TRUNK/org.apache.lenya.core.api/../org.apache.lenya.core.usecase/target/classes/COB-INF/usecases.js:381 at - file:///home/florent/devel/dev-lenya/lenyaSources/NEXT-VERSION/TRUNK/org.apache.lenya.core.api/../org.apache.lenya.core.usecase/target/classes/COB-INF/sitemap.xmap:119:46 at - file:///home/florent/devel/dev-lenya/lenyaSources/NEXT-VERSION/TRUNK/org.apache.lenya.core.api/../org.apache.lenya.core.usecase/target/classes/COB-INF/sitemap.xmap:117:45 at org.apache.cocoon.ProcessingException.throwLocated(ProcessingException.java:143) at org.apache.cocoon.components.flow.javascript.LocationTrackingDebugger.getException(LocationTrackingDebugger.java:111) at org.apache.cocoon.components.flow.javascript.fom.FOM_JavaScriptInterpreter.callFunction(FOM_JavaScriptInterpreter.java:629) at org.apache.cocoon.components.treeprocessor.sitemap.CallFunctionNode.invoke(CallFunctionNode.java:109) at org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:55) at org.apache.cocoon.components.treeprocessor.sitemap.MatchNode.invoke(MatchNode.java:87) at org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:78) at org.apache.cocoon.components.treeprocessor.sitemap.PipelineNode.invoke(PipelineNode.java:143) at org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:78) at org.apache.cocoon.components.treeprocessor.sitemap.PipelinesNode.invoke(PipelinesNode.java:81) at org.apache.cocoon.components.treeprocessor.ConcreteTreeProcessor.process(ConcreteTreeProcessor.java:241) at org.apache.cocoon.components.treeprocessor.ConcreteTreeProcessor.process(ConcreteTreeProcessor.java:173) at org.apache.cocoon.components.treeprocessor.TreeProcessor.process(TreeProcessor.java:247) at org.apache.cocoon.components.treeprocessor.sitemap.MountNode.invoke(MountNode.java:117) at org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:55) at org.apache.cocoon.components.treeprocessor.sitemap.MatchNode.invoke(MatchNode.java:87) at org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:78) at org.apache.cocoon.components.treeprocessor.sitemap.PipelineNode.invoke(PipelineNode.java:143) at org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:78) at org.apache.cocoon.components.treeprocessor.sitemap.PipelinesNode.invoke(PipelinesNode.java:81) at org.apache.cocoon.components.treeprocessor.ConcreteTreeProcessor.process(ConcreteTreeProcessor.java:241) at org.apache.cocoon.components.treeprocessor.ConcreteTreeProcessor.process(ConcreteTreeProcessor.java:173) at org.apache.cocoon.components.treeprocessor.TreeProcessor.process(TreeProcessor.java:247) at org.apache.cocoon.components.treeprocessor.sitemap.MountNode.invoke(MountNode.java:117) at org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:55) at org.apache.cocoon.components.treeprocessor.sitemap.MatchNode.invoke(MatchNode.java:87) at org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:78) at org.apache.cocoon.components.treeprocessor.sitemap.PipelineNode.invoke(PipelineNode.java:143) at org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.in
