> -----Original Message----- > From: Robert Simmons [mailto:[EMAIL PROTECTED]] > Sent: Sunday, January 26, 2003 7:55 AM > To: [EMAIL PROTECTED]; [EMAIL PROTECTED] > Subject: Re: Smileys Cocoon sample... the sequel > > > I do all my database work in the EJBs on the server side using JDO. JDO is > basically god for persisting Java objects. =) > > I can probably figure out how to connect the suckers. In fact if > I'm not too > far off I can drop them in the container and just grab an initial context.
Yes - though the details of how you were getting the initial context in your servlet were not in the files I got and it bears some thinking. Were you relying on properties declared in your container (which I guess if you're running the servlet in jboss that comes for free?) or are you doing a properties.put(...) there? When integrating JMS into cocoon for a project a year ago, I remember trying to think through the best portable strategies for looking up JNDI resources but have forgotten some of the issues that surfaced. > However what I'm trying to envision is my reader deploying this > and shot of > reproducing the build file or telling my users to unpack the cocoon war, I > don't know what to do exactly. Unpacking the war (or using a tar.gz or zip instead of war?) the most straight forward I think, no? Do I understand right that the reader will have to do some cocoon user functions? For example, do they need to edit a sitemap? > If there was one jar they could include, it > would be perfect. I envision a user being able to download a jar file that > has every one of the classes all jared into one cocoon-all.jar and then > dropping it as one unit in their WEB-INF/lib directory but I'm > not sure how > to accomplish that. This is a very interesting idea and I think I see the appeal. It bears thought about whether it's possible, or feasible (or better than working on the war). Normally cocoon is deployed as a web application itself. It may share resources with other webapps, but I'm not sure there's much trail blazed on integrating it into another webapp when it now has to share web.xml, classloader (?), servlet mappings, etc. Can you give an example of what kind of webapp you see it integrating into? I guess an .ear? What other servlets would need to be configured for the webapp? Without having done much deep thinking about this yet, I'd say the safe and fast way is to use a strategy that involves deploying cocoon as a standalone webapp that shares resources or referrs to others unless you can help me understand more problems that presents in your use. > I would also need to know if the path to the cocoon > properties file and the xconf files are hardcoded as I would like to file > them away too. the location and name of cocoon.xconf is specified as an init param in web.xml and can theoretically be changed (actually the default location was changed at one point), though it would be interesting if it has been done - there could be hidden gotchas since the vast majority have seen no need to move it. While I've heard a desire among the developers (by the way, I'm just a user and contributor who pays a lot of attention to the development issues) to get more user-level configuration out of cocoon.xconf, there are still some important things to be set there for many users (datasources for instance). So far, not in your case though. Not sure what other properties file you mean? web.xml is part of the servlet spec and probably can't be messed with/moved. There is more configuration in there than desired but no suggestion put forward as yet on how to move it elsewhere. The location and name of sitemap.xmap is specified in cocoon.xconf and can be changed, though I think rarely done for the "root" sitemap. > but now I'm talking about developing on cocoon and > that's what > I was trying to avoid. Sigh. Yes, you are now definitely talking about things that would be new, if possible. I still don't see the need. Adding and editing a few files in a webapp can be done simply. You could provide a setup that involves only adding files possibly which would make things less intimidating, no? Geoff > > -- Robert. > > > ----- Original Message ----- > From: "Luca Morandini" <[EMAIL PROTECTED]> > To: "Cocoon-users" <[EMAIL PROTECTED]> > Cc: <[EMAIL PROTECTED]> > Sent: Sunday, January 26, 2003 1:35 PM > Subject: Smileys Cocoon sample... the sequel > > > > Robert, > > > > I've developed a tentative Cocoon implemtation of your sample. > > > > 1) I've defined a suitable selector in order to switch to different > contents according to its value: > > <map:selector name="command-selector" > > src="org.apache.cocoon.selection.RequestParameterSelector"> > > <parameter-name>command</parameter-name> > > </map:selector> > > > > 2) Then use it to make the actual switching: > > <map:match name="wildcard" pattern="*.html"> > > <map:select type="command-selector"> > > <map:when test="SysAdminView"> > > <map:generate type="file" src="cocoon:/sp-getall-smileys.xml"/> > > </map:when> > > <map:when test="SmileyEditView"> > > <map:generate type="file" src="cocoon:/sp-get-smiley.xml"/> > > </map:when> > > <map:otherwise> > > <map:generate type="file" src="documents/smileys.xml"/> > > </map:otherwise> > > </map:select> > > <map:transform src="stylesheets/jconfer-page.xsl"/> > > <map:serialize type="html"/> > > </map:match> > > > > You may notice that now you don't have to aearch the servlets > to understand > how the content-reading switching works, it is all in > > one place: the pipeline. > > > > This begs the question: where can you get your content from ? > Or, better, > how Cocoon deals with RDBMS (which are the most common > > persistence mechanism around). > > > > Well, I use (as you may infer from the names I gave to contents URIs), > Stored Procedures via SQLTransformer. Probably not the > > fastest way, but sure the most flexible and SoC-oriented. > > > > You can use DatabaseActions, ESQL, or EJBs... which is the > option appealing > most to you, I guess. > > How to get an EJB from Cocoon... no idea sorry, I steered well clear of > JSP, Servlets and EJBs. > > > > Regards, > > > > --------------------------------------------- > > Luca Morandini > > GIS Consultant > > [EMAIL PROTECTED] > > http://utenti.tripod.it/lmorandini/index.html > > --------------------------------------------- > > > > > > > > --------------------------------------------------------------------- > > Please check that your question has not already been answered in the > > FAQ before posting. <http://xml.apache.org/cocoon/faq/index.html> > > > > To unsubscribe, e-mail: <[EMAIL PROTECTED]> > > For additional commands, e-mail: <[EMAIL PROTECTED]> > > > > > --------------------------------------------------------------------- > Please check that your question has not already been answered in the > FAQ before posting. <http://xml.apache.org/cocoon/faq/index.html> > > To unsubscribe, e-mail: <[EMAIL PROTECTED]> > For additional commands, e-mail: <[EMAIL PROTECTED]> > > > --------------------------------------------------------------------- Please check that your question has not already been answered in the FAQ before posting. <http://xml.apache.org/cocoon/faq/index.html> To unsubscribe, e-mail: <[EMAIL PROTECTED]> For additional commands, e-mail: <[EMAIL PROTECTED]>
