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:
<map:pipeline>
<map:match pattern="document">
<map:generate src="servlet:block-b:/document" />
<map:serialize type="xml" />
</map:match>
</map:pipeline>
to this:
<map:pipeline>
<map:match pattern="document">
<map:generate type="file" src="block-a-resources/document.xml" />
<map:serialize type="xml"/>
</map:match>
</map:pipeline>
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:
<servlet:context mount-path="/block-a"
context-path="blockcontext:/block-a/">
<servlet:connections>
<entry key="block-b" value-ref="com.my-company.block-b.service"/>
</servlet:connections>
</servlet:context>
block-a/sitemap.xml:
<map:pipeline>
<map:match pattern="document">
<map:generate src="servlet:block-b:/document" />
<map:serialize type="xml" />
</map:match>
</map:pipeline>
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:
<map:pipeline>
<map:match pattern="document">
<map:generate src="servlet:block-b:/document" />
<map:serialize type="xml" />
</map:match>
<map:handle-errors>
<map:select type="exception">
<map:when test="error">
<map:generate type="file" src="block-a-resources/document.xml" />
<map:serialize type="xml"/>
</map:when>
</map:select>
</map:handle-errors>
</map:pipeline>
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
