Re: XSLT is Dead ?!
Derek Hohls wrote: At least, according to this article: http://java.dzone.com/news/death-xslt-web-frameworks Maybe some of the developers, or other power users here, would like to comment at this blog - I see Cocoon also gets a dig in the ribs ... Without commenting on this specific article, my only general comment is that you'll find articles for specific technologies/projects and you'll find as many articles against these (I guess the most famous topic in our area is Maven). Who's is wrong and who's right? Or more important: is there such an easy answer? I definitly doubt this. There isn't such a thing as the one programming language that rules the world or the one framework that makes everyone happy and is the golden hammer. Everyone is free to use what he thinks works best for him. Ok, coming back to the original topic :) Looking at the past 9 years where I've been using Cocoon and done a lot of projects with Cocoon and XSLT, I think it was a great tool by the time. And XSLT helped a lot in getting up to speed (once you managed the high entrance barrier to Cocoon itself). There are a lot of use cases still today for XSLT when it comes to create web sites. It really helps to separate the content from the layout. But in the end that's a matter how you design your application. I see a lot of people using other frameworks than Cocoon and pass the output from that framework to XSLT after the framework has rendered the content. So I don't think that XSLT itself is dead. The attraction of Cocoon as a separate framework has decreased, but that's definitly not due to XSLT. Carsten -- Carsten Ziegeler cziege...@apache.org - To unsubscribe, e-mail: users-unsubscr...@cocoon.apache.org For additional commands, e-mail: users-h...@cocoon.apache.org
Re: XSLT is Dead ?!
Derek Hohls wrote: Carsten I had hoped comments like these would be added to the blog :) I usually do not comment blog entries - sorry :) One other point, you say: The attraction of Cocoon as a separate framework has decreased, but that's definitely not due to XSLT. Why do you say Cocoon's attractiveness is decreasing... should we all be looking around for a new framework to hop onto? :) I think this is one of the questions that can't be answered in general and everyone has to make his own decision. There is nothing wrong with using Cocoon today and continuing using it. It's a great, solid, stable and powerful framework, there is a community behind it etc. Still today I think there is nothing out there which is as powerful as Cocoon. But on the downside are the high learning curve, missing integration with the hot stuff from today (OSGi, scripting etc.). And I think it's obvious by just looking at the developer and user list that the interest in Cocoon is definitly decreasing. If people are starting new projects or looking for something exciting they usually don't end up with Cocoon as we don't play in the technology hype market. So, if you're happy with Cocoon, use it - if you think something else is more suited for your project, use that :) Carsten -- Carsten Ziegeler cziege...@apache.org - To unsubscribe, e-mail: users-unsubscr...@cocoon.apache.org For additional commands, e-mail: users-h...@cocoon.apache.org
Re: Access Settings object of Spring Configurator inside sitemap.xmap?
Gabriel Gruber wrote: hi, just a quick one... is it possible to access the settings object of the cocoon spring configurator (to get the supposed cache dir) within the sitemap ? or do I have to write my own input module in order to get that running? There is already the SettingsInputModule which should be configured as global. The key for the cache dir should be org.apache.cocoon.cache.directory, so global:org.apache.cocoon.cache.directory should refer to the value. HTH Carsten -- Carsten Ziegeler cziege...@apache.org - To unsubscribe, e-mail: users-unsubscr...@cocoon.apache.org For additional commands, e-mail: users-h...@cocoon.apache.org
Re: Problems building block
Hi, thanks for spotting this - I accidentally committed a new module with this name. I just corrected it in svn, so it should work now. Carsten Jose Luis Carmona wrote: I tried to do the mvn -P allblocks install from the root of coocon but i had this problem, [DEBUG] org.apache.commons:javaflow:jar:1.0-SNAPSHOT [INFO] [ERROR] BUILD FAILURE [INFO] [INFO] Project 'org.apache.cocoon:cocoon-xml-util' is duplicated in the reactor [INFO] [DEBUG] Trace org.apache.maven.BuildFailureException: Project 'org.apache.cocoon:cocoon-xml-util' is duplicated in the reactor at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:318) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:129) at org.apache.maven.cli.MavenCli.main(MavenCli.java:287) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) at org.codehaus.classworlds.Launcher.main(Launcher.java:375) Caused by: org.apache.maven.project.DuplicateProjectException: Project 'org.apache.cocoon:cocoon-xml-util' is duplicated in the reactor at org.apache.maven.project.ProjectSorter.init(ProjectSorter.java:79) at org.apache.maven.execution.ReactorManager.init(ReactorManager.java:59) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:302) ... 10 more [INFO] [INFO] Total time: 1 minute 33 seconds [INFO] Finished at: Wed Jan 07 17:25:19 CET 2009 [INFO] Final Memory: 72M/1016M [INFO] Thanks Grzegorz , Jose Jose Luis Carmona pisze: Hi, I've downloaded the complete repository from http://svn.apache.org/repos/asf/cocoon/trunk; and I've tried to build the block blocks\cocoon-xmldb\cocoon-xmldb-impl but i have problems with the cocoon-spring-configurator block. I've used the command mvn -e clean install. You should either switch dependency of xmldb-impl so it depends on released version of cocoon-spring-configurator or just try to build everything from root so all SNAPSHOT dependencies of xmldb-impl will be built first. - To unsubscribe, e-mail: users-unsubscr...@cocoon.apache.org For additional commands, e-mail: users-h...@cocoon.apache.org -- Carsten Ziegeler cziege...@apache.org - To unsubscribe, e-mail: users-unsubscr...@cocoon.apache.org For additional commands, e-mail: users-h...@cocoon.apache.org
Re: Component configuration: Spring vs. Avalon
Alexander Daniel wrote: In Cocoon 2.2 the file generator is defined directly as Spring component whereas the XSLT transformer is still defined in a xconf via the Avalon bridge. A definition via the Avalon bridge also creates a pool for the component visible as xsltPooled. Does this have any performance reasons or are there any other reasons why the XSLT transformer is not defined as Spring component? The reason is (I think) much simpler: noone ported the Avalon code so far. Without measuring it, I think we can't really tell which approach is faster. Java used to be slow when it comes to object creation and deleting them, but that has changed. So today, pools are considered slower. On the other hand, the xslt transformer is not just one simple small java object, there is a lot going on when an instance is created. But I guess if programmed correctly, the non-pool version should be at least as fast as the pooled version if not faster. HTH Carsten -- Carsten Ziegeler [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Spring and getComponent()
Patrick Heiden wrote: Hello together! Within flowscripts that references 'old' avalon components via someVar = cocoon.getComponent(..) there was a need to release those componente via cocoon.release(..). Is this still the way with C22 when obtaining references to some business-beans, defined in someAppCtx.xml ? Or is there no impact since Spring handles bean creation/destruction??a The release of a component was more or less only required for pooled components. As a user of a component you never know if the component is pooled, single threaded or whatever, you simply always release with Avalon. Spring itself has no pooling of components, therefore a release is not required anymore. In addition, for Avalon components which are pooled we implemented an auto-release after the end of a request. HTH Carsten -- Carsten Ziegeler [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Too many aspects in session
Hi, the only help I can give you is that this stuff is obviously from the cocoon portal. I'm not that sure if this is caused by the portal itself or if this can be caused by your code. But I guess that this might depend on your portal configuration and which features you use. I know that this answer is a little bit vague, but it's too long ago that I used the portal the last time :( Sorry Carsten Iulian Radu wrote: Hi, I have in my session the following attribute org.apache.cocoon.portal.impl.PortalServiceInfo/portal/org.apache.cocoon.portal.event.impl.DefaultEventConverterE which have a lot of org.apache.cocoon.portal.event.impl.ChangeAspectDataEvent values. Does anyone have idea from where comes this (from cocoon or from my code)? Thank you in advance, Iulian -- Carsten Ziegeler [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Announce] Apache Lenya 2.0.2 released
Andreas Kuehne wrote: Hi Andreas, intersting to hear lenya team's view on 2.2 / maven ! I'm shure there are many projects around not willing / not able to migarte to Cocoon 2.2 / Maven. What about a formal (sub-)project to maintain the 2.1.* thread ? And let's give it a diffent name ( like 'cocoon granite' ) to avoid the the smell of a dead version walking ... Imho, there is no need to use maven if you want to use Cocoon 2.2. Things might be easier (or not - depending on your pov) if you use maven, but it is not a requirement. Just download the required jars and use them as libs. Carsten -- Carsten Ziegeler [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Cocoon Authentication: Getting the User object after logging in
Magnus Haraldsen Amundsen schrieb:
Using Cocoon 2.2 RC2 and the Cocoon Authentication block.
First the sitemap uses
map:act type=cauth-is-logged-in
map:parameter name=application value=Sublima/
[…]
/map:act
map:redirect-to uri={request:contextPath}/login/
To check if the user is logged in.
The user logs in and we use a Java class that extends
AbstractSecurityHandler to do the username/password check and that
returns a User object.
We can set additional attributes to this User object using
User.setAttribute(key, value) and we want to do this to control which
role the user has.
In the other Java code we use the ApplicationManager to see if the user
is logged in, by calling ApplicationManager.isLoggedIn(“Sublima”).
How do we get the User object that were created upon login? We can’t
find any methods in ApplicationManager that returns User.
Have a look at the ApplicationUtil class. If you have access to the
objectModel map (don't know how to get this in 2.2), you can use the
static methods. If not, create an instance of the ApplicationUtil class
and call getUser().
HTH
Carsten
--
Carsten Ziegeler
[EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Problem with auth block
Magnus Haraldsen Amundsen schrieb:
map:match pattern=admin/emner/*
map:act type=cauth-is-logged-in
map:parameter name=application value=Sublima/
map:call
function=com.computas.sublima.app.controller.admin.TopicController
map:parameter name=mode value=emner/
map:parameter name=submode value={1}/
/map:call
/map:act
map:redirect-to uri={request:contextPath}/login/
/map:match
My problem is that map:parameter name=submode value={1}/ always is
an empty String à “”
This appeared when I applied the authentication to the sitemap.
This is a common mistake :) The {1} refers to values provided by the
parent of the call command, which is the action. But you want to
access the value from the matcher which is one level above, so use
{../1} instead.
There is a nicer way of doing this by giving a the match node a name,
but I don't know the exact syntax out of my head.
Carsten
--
Carsten Ziegeler
[EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [HELP] SitemapEvenListener
) at org.mortbay.jetty.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:206) at org.mortbay.jetty.handler.HandlerCollection.handle(HandlerCollection.java:114) at org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:139) at org.mortbay.jetty.Server.handle(Server.java:324) at org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:505) at org.mortbay.jetty.HttpConnection$RequestHandler.headerComplete(HttpConnection.java:828) at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:514) at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:211) at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:380) at org.mortbay.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java:395) at org.mortbay.thread.BoundedThreadPool$PoolThread.run(BoundedThreadPool.java:450) I have registered the Listener throug a bean definition inside my blocks COB-INF/config/spring/listener.xml: bean id=openSessionInViewInterceptor class=de.ifado.isac.web.OpenSessionInViewInterceptor property name=sessionFactory ref=sessionFactory / /bean The SessionFactory is defined elsewhere (and retrieved after global WebAppCtx is build through Cocoon/Spring. I have no idea why my sessionContext gets lost!? Help appreciated, greetings, Patrick -- Carsten Ziegeler [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [HELP] SitemapEvenListener
Patrick Heiden wrote: Hello Carsten! I have no knowledge about this spring/hibernate stuff, but if your hibernate code is correct, it should work (ok, I know this doesn't help you). So, my question is if you're sure that your code in leftSitemap() should really get to the session created in enteredSitemap?. Could you be more pricise on what you mean, I don't understand exactly. Do you want to explain, that my hibernate-cleanup code shouldn't be placed inside leftSitemap() ? No, that's the correct place. Actually I have no idea why this is not working for you. As the place is correct and as the listener is called on enter and exit, I assume that the problem is somewhere in your code. Carsten -- Carsten Ziegeler [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [2.2] Missing org/apache/commons/collections/map/MultiValueMap
Grzegorz Kossakowski wrote: Kamal pisze: Grzegorz Kossakowski wrote: Kamal pisze: I tried to check out the dependencies (using mvn dependency:list) to work out where the conflict is happening, and maven couldn't find the dependency plugin. Any thoughts? Weird. What about: mvn dependency:list -U Nope. Then, to be honest I have no clue. Are you sure that Maven has no network problems? Try mvn org.apache.maven.plugins:maven-dependency-plugin:2.0:list Carsten -- Carsten Ziegeler [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [2.2] Missing org/apache/commons/collections/map/MultiValueMap
Kamal wrote Thanks. That seems to work. Why do I have to do this extra guff? You didn't have the plugin in your local repo. I have no idea why mvn is not going to the repo to fetch the plugin for you. Anyway, from now on you can invoke the plugin by mvn dependency:list. Carsten -- Carsten Ziegeler [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [2.2] Missing org/apache/commons/collections/map/MultiValueMap
Grzegorz Kossakowski wrote: Kamal pisze: mvn jetty:run -X I will give this a go. I actual fact, I probably should be focussing on the issue of packaged wars. Hope that helps. BTW. What version of Maven do you use? 2.0.4 Ouch, that's old. Maven fixed many nasty bugs in last patch releases and it's really, really good idea to update ASAP. That could explain why Maven failed to download dependency plug-in. PS. I'm using Maven 2.0.8 and I'm very happy about it. I suggest to use 2.0.9 - it seems to be even more stable (if this is possible at all...) than 2.0.8 especially for multi project builds. Carsten -- Carsten Ziegeler [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: SSF
Cocoon-auth is very simple and dates back to the early days of Cocoon. I suggest to have a look at Spring Security (acegi) - it picked up most of the ideas of cocoon auth, but provides much much more in a better way :) Carsten Patrick Heiden wrote: You are right about easyness of ServletFilter, but what if one would like to secure not just the entering, but instead also parts of operations to be in scope for Users with e.g. special Roles? There is also possibility to auth against mod_auth upfront...many many possibilities. I would prefer generic one-stop-shop. Maybe Acegi could be such a solution. Grzegorz: I've just read the AOP-approach. I like the idea, but agree that a generic (configureable) solution would be nice, since such usage-scenarios could be refined to patterns (e.g. special SSF-beans, already proxied or the like). Of course, bloat something up should not be in goal-direction. I am still left on my way to auth so far, best greetings Patrick -- Carsten Ziegeler [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: SSF
Patrick Heiden schrieb: Hi Carsten! I would love to use acegi, but the acegi auth-block sample is not running (got a fresh trunk 5 days ago). Any further references on howto come to grasp with acegi inside cocoon? Hi Patrick, no, sorry, I never used it in real live :) But as Cocoon is Spring based and as spring security has a nice feature list, it seems to be the right fit. I think there are some people here who are using 2.2 with spring security, perhaps they can speak up here? Carsten -- Carsten Ziegeler [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: SSF
Patrick Heiden schrieb: Patrick Heiden schrieb: Hi Carsten! I would love to use acegi, but the acegi auth-block sample is not running (got a fresh trunk 5 days ago). Any further references on howto come to grasp with acegi inside cocoon? Hi Patrick, no, sorry, I never used it in real live :) But as Cocoon is Spring based and as spring security has a nice feature list, it seems to be the right fit. I think there are some people here who are using 2.2 with spring security, perhaps they can speak up here? Yes, this would be nice. But I will keep digging through acegi website-samples. Besides: before users do any work, there must be session-management. What out of cocoon 2.1 is still with 2.2, looking on server-side session-management? Any viable resources, because [1] is somewhat short on that topic and most docs out there refer to cocoon 2.1. No, I don't think we have more docs about it :) But the good part is, that we simply rely on the servlet engine and its session handling; so if you're familiar with the servlet api you know everything :) HTH Carsten -- Carsten Ziegeler [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: SSF
Ralph Goers wrote: Now that I think about it, can't servlet filters be used on servlet services for authorization to them? I know it isn't as granular as would be liked but it would be good to do this. Yepp, I think this is the easiest way and spring security should have everything you need. Carsten Ralph Ralph Goers wrote: Authentication and authorization are two very different things. We never really implemented a proper authorization scheme in the portal, although I always wanted to. From a Cocoon perspective I could definitely see something added to the pipelines to accomplish this, but frankly, I'd prefer to have something like a pipeline filter to do it rather than using actions or some of the other constructs that currently exist. Ralph Patrick Heiden wrote: You are right about easyness of ServletFilter, but what if one would like to secure not just the entering, but instead also parts of operations to be in scope for Users with e.g. special Roles? There is also possibility to auth against mod_auth upfront...many many possibilities. I would prefer generic one-stop-shop. Maybe Acegi could be such a solution. Grzegorz: I've just read the AOP-approach. I like the idea, but agree that a generic (configureable) solution would be nice, since such usage-scenarios could be refined to patterns (e.g. special SSF-beans, already proxied or the like). Of course, bloat something up should not be in goal-direction. I am still left on my way to auth so far, best greetings Patrick - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Carsten Ziegeler [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cocoon-session-fw (deprecated?)
Patrick Heiden wrote: Good Morning ;) Within that blocks src I read that it will be removed in future!? Is it still advisable to use it anyway? No :) The session-fw is a reminder of the old Cocoon days where everything should be xml. It is nice and easy for some things but today with flow, jxtg etc. you can build your app in much better ways. HTH Carsten -- Carsten Ziegeler [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: sleeping components
Jim Brace wrote: Hi, I'm using cocoon 2.1.7 under jdk 1.5. I've written some basic actions, but am puzzled that these actions seem to need a warm up. If I leave the system running overnight, first hit in the morning will be terribly slow. After that, all is ok. My Actions do not implement Threadsafe, so they should be poolable. Still, adding pooling attributes (pool min/max/grow) to the declaration doesn't seem to help. Can anyone give me pointers where to start looking to resolve this, please? I would try to make the actions ThreadSafe :) however, if that's not possible, you need to implement the Poolable interface in order to get the actions pooled. Without any marker interface (ThreadSafe, Poolable), the action objects are created on demand and thrown away after usage. HTH Carsten Thanks in advance Jim -- Carsten Ziegeler [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: getComponent vs. context.getAttribute
Patrick Heiden wrote: Hi, Is there any notable difference in asking for Spring-beans inside flow-scripts wheter using cocoon.getComponent(myBean); // via avalon-bridge!? or var appCtx = cocoon.context.getAttribute(WebApplicationContext.ROOT_WEB_APPLICATION_CONTEXT_ATTRIBUTE); appCtx.getBean(myBean); ?? Yes, there is a difference :) The first one does not use the avalon bridge but uses the context of the current sitemap. This might be a sub context of the root web application context with additional/different beans. So, getComponent() is still the way to go :) Thanks for this one! It might even be the simpler approach. What is confusing for me so far (informations I got from Grzegorz Kossakowski), that the actual implementation (2.2) does not 'really' support different bean-containers. I am able to define beans within blocks A context (META-INF/cocoon/spring/*.xml) and they are visible to other blocks of my webapp as well. How does the future look like for this and how should actual design/configuration of beans (e.g. a service-layer) be done to be prepared? There are different approaches; one of them is the new block concept (which Grzegorz is refering to) and that does not support a hierarchy of containers - but I'm not an expert for blocks, so I have no idea what has been done/will be planned for that. The other approach is the 2.1.x compatible approach: by creating a hierarchy of sitemaps (using map:mount) you create a hierarchy of containers (like it was in 2.1.x). It is possible to define beans on er per sitemap base. However, it seems that current development of Cocoon favours the blocks concept. Carsten -- Carsten Ziegeler [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: getComponent vs. context.getAttribute
Patrick Heiden wrote: Hello together! Is there any notable difference in asking for Spring-beans inside flow-scripts wheter using cocoon.getComponent(myBean); // via avalon-bridge!? or var appCtx = cocoon.context.getAttribute(WebApplicationContext.ROOT_WEB_APPLICATION_CONTEXT_ATTRIBUTE); appCtx.getBean(myBean); ?? Yes, there is a difference :) The first one does not use the avalon bridge but uses the context of the current sitemap. This might be a sub context of the root web application context with additional/different beans. So, getComponent() is still the way to go :) HTH Carsten -- Carsten Ziegeler [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: getComponent vs. context.getAttribute
Grzegorz Kossakowski wrote: Yep, I haven't mentioned these sitemap-specific containers because they are only there for back-compatibility and they are very likely to be deprecated in the future. Moreover, these sitemap-specific containers support only Avalon components and not Spring beans. No, they support both :) Carsten As for now I advise to put beans configurations into META-INF/cocoon/spring/*.xml and declare dependencies between blocks that reflect dependencies between beans. This should be enough for any future invention that will guarantee true isolation between blocks. The other approach is the 2.1.x compatible approach: by creating a hierarchy of sitemaps (using map:mount) you create a hierarchy of containers (like it was in 2.1.x). It is possible to define beans on er per sitemap base. However, it seems that current development of Cocoon favours the blocks concept. Exactly. -- Carsten Ziegeler [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: getComponent vs. context.getAttribute
Grzegorz Kossakowski wrote: Carsten Ziegeler wrote: Grzegorz Kossakowski wrote: Yep, I haven't mentioned these sitemap-specific containers because they are only there for back-compatibility and they are very likely to be deprecated in the future. Moreover, these sitemap-specific containers support only Avalon components and not Spring beans. No, they support both :) Really? I must missed this while removing this stuff in Micro Cocoon. ;-) Just out of curiosity, what's the syntax? You can just put your bean config files under config/spring/*.xml or I think you can use include-beans (or similar) in the sitemap. Carsten -- Carsten Ziegeler [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: jetty
Andre Juffer wrote:
Joerg Heinicke wrote:
On 26.02.2008 04:04, Andre Juffer wrote:
var form = new Form(...);
form.createBinding(...);
var finished = false;
var data = new ...;
while (!finished)
{
try {
form.load(data);
form.showForm(...)
form.save(data);
do_something_with(data);
finished = true;
}
catch (ex)
{
var w = form.lookupWidget(messages);
w.addMessage(ex.message);
}
}
cocoon.sendPage(...);
Is it only me wondering how this can work at all when there is an
exception? In that case finished is NEVER set to true and you always
get into an infinite loop. How can this work with Tomcat? Or am I just
missing something?
If there is an exception, it should be caught by the catch (ex) portion,
which extracts the message and puts it in the message form. finished
remains false (you are entirely right) and the form is being displayed
again to the user as I intended. If there is no exception, finished is
set to true and the while loops ends. The script ends with the
cocoon.sendPage(). This has worked fine with tomcat. Maybe I am too much
of Java programmer such that I miss certain things in Javascript.
Now, I agree with Joerg that this code looks very suspicious; I guess
your intention is to catch an exception while dealing with the data in
do_something_with(data). The problem with the code above is that if an
exception occurs in form.load() or form.showForm() etc. you end up with
an endless loop.
So I would rather catch the exception inside the do_xxx method (or
handle error codes in a more graceful way than just catching exceptions).
Although I suggest to improve the code, I fear that this is not the
cause of your problem. My guess is still a class loader issue: you might
end up with different libs being used in Jetty.
Carsten
--
Carsten Ziegeler
[EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: error Message in the Cocoon Portal user administration!
[EMAIL PROTECTED] wrote: I use Cocoon 2.1.11 Ok, the answer to your problem is simple :) The cocoon portal is using the cocoon-auth block for authentication. The portal tools assume that the old and deprecated authentication-fw is used instead. Changing the tools from the authentication-fw to cocoon-auth however is not that simple :( So if you need the tools, I would suggest to switch back to the authentication-fw for authentication. There is a sitemap-auth.xmap which *should be* a dropin replacement for the sitemap.xmap (but I fear that this hasn't been tested for a long time, so there might be problems). I think a better solution is to create your own user administration. And to fix the tools in Cocoon, we might probably remove them for a future release. Carsten -- Carsten Ziegeler [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: jetty
Hmm, from this description I can only guess what the problem might be. I
guess that you have different libs and/or different class loading
behaviour between Jetty and Tomcat. So it might be that you end up with
a different Rhino version used or something similar.
In any case, you should see an exception somewhere (being it in the
browser or in the logs); your description also seems to imply that in
the case of Jetty an endless loop is reached. So what happens if you set
finished to true before the loop but leave the try/catch in?
Carsten
Andre Juffer wrote:
Carsten Ziegeler wrote:
Which xml files are you refering to?
Just my own files (required for a pipeline). If I make a simple typing
error in one of these files, jetty simply hangs up and I need to
manually kill the process. I would have expected to see an error message
plus a trace stack to see where an error occurs.
I have an example from flow, which goes like (out of my head):
...
var form = new Form(...);
form.createBinding(...);
var finished = false;
var data = new ...;
while (!finished)
{
try {
form.load(data);
form.showForm(...)
form.save(data);
do_something_with(data);
finished = true;
}
catch (ex)
{
var w = form.lookupWidget(messages);
w.addMessage(ex.message);
}
}
cocoon.sendPage(...);
So, in this case, there are no errors in any XML file. Jetty apparently
cannot 'handle' the 'catch(ex)' part whether or not an exception takes
place (the exception is for instance occurring in
do_something_with(data) as result of the handling of the data in the
domain layer). The catch portion simply ensures that if there is an
exception, the error message is displayed to the user. Jetty simply
freezes here. If I remove the while, try and catch portion (but keep the
lines from 'form.load()' to 'finished=true', everything is fine. If I
make a war file and deploy the above to tomcat, there are absolutely no
problems. The flow portion above was taken from an application that runs
fine with all versions of cocoon+tomcat. I must assume that there is
problem caused by Jetty, but I cannot see why that should be. I am
running this all on a Linux box (AMD64) with Java 6.
Carsten
Andre Juffer wrote:
Hi All,
I am testing a cocoon-based webapp. For this, I use the 'mvn
jetty:run'. This all works fine, unless there is an error in any of
the underlying XML files. For instance, if there is a minor error
like missing an '' (implying invalid XML), which is just a typing
error, jetty just hangs up completely and ultimately gives an out of
memory error exception. If that is not the case, the only way to stop
jetty is to manually kill the process (on a Linux box). Is there a
way to get rid of or change this behavior. With cocoon 2.1.* (and
tomcat), decent error message and stack trace were returned so that
could figure out the problem. This would be the preferred behavior.
Thanks,
Andre
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Carsten Ziegeler
[EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Cocoon 2.2 - CocoonServlet?
Alexander Daniel wrote: On 25.02.2008, at 16:58, Edward S wrote: is there any documentation for this request / servlet filter? e.g. http://java.sun.com/products/servlet/Filters.html I have not understood the difference between request and servlet filter though. Or are these the same thing? Servlet filters are tied to a specific servlet and have to be defined for each servlet you want to filter. A request listener is invoked for each request. Carsten -- Carsten Ziegeler [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: jetty
Which xml files are you refering to? Carsten Andre Juffer wrote: Hi All, I am testing a cocoon-based webapp. For this, I use the 'mvn jetty:run'. This all works fine, unless there is an error in any of the underlying XML files. For instance, if there is a minor error like missing an '' (implying invalid XML), which is just a typing error, jetty just hangs up completely and ultimately gives an out of memory error exception. If that is not the case, the only way to stop jetty is to manually kill the process (on a Linux box). Is there a way to get rid of or change this behavior. With cocoon 2.1.* (and tomcat), decent error message and stack trace were returned so that could figure out the problem. This would be the preferred behavior. Thanks, Andre - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Carsten Ziegeler [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: error Message in the Cocoon Portal user administration!
Not sure if I can help you, but what cocoon version are you using? Carsten [EMAIL PROTECTED] wrote: When I call the Cocoon Portal user administration, I get the error message: org.mozilla.javascript.EcmaError: TypeError: Cannot call method getHandler of null (file:///C:/Programme/Apache Software Foundation/Tomcat 5.5/webapps/cocoon/samples/blocks/portal/tools/plugins/userManagement/flow.js#29)/ TypeError/ - file:///C:/Programme/Apache Software Foundation/Tomcat 5.5/webapps/cocoon/samples/blocks/portal/tools/plugins/userManagement/flow.js - 29:0 Cocoon stacktrace[hide] *TypeError: Cannot call method getHandler of null (file:///C:/Programme/Apache Software Foundation/Tomcat 5.5/webapps/cocoon/samples/blocks/portal/tools/plugins/userManagement/flow.js#29)* file:///C:/Programme/Apache Software Foundation/Tomcat 5.5/webapps/cocoon/samples/blocks/portal/tools/plugins/userManagement/flow.js - 29:0 /TypeError/ * Error calling flowscript function showUser* file:///C:/Programme/Apache Software Foundation/Tomcat 5.5/webapps/cocoon/samples/blocks/portal/tools/plugins/userManagement/flow.js - 29:0 /[EcmaError]/ file:///C:/Programme/Apache Software Foundation/Tomcat 5.5/webapps/cocoon/samples/blocks/portal/tools/plugins/userManagement/flow.js - 29:-1 file:///C:/Programme/Apache Software Foundation/Tomcat 5.5/webapps/cocoon/samples/blocks/portal/tools/plugins/userManagement/flow.js - 47:-1 file:///C:/Programme/Apache%20Software%20Foundation/Tomcat%205.5/webapps/cocoon/samples/blocks/portal/tools/plugins/userManagement/sitemap.xmap - 48:30 /map:call/ file:///C:/Programme/Apache%20Software%20Foundation/Tomcat%205.5/webapps/cocoon/samples/blocks/portal/tools/sitemap.xmap - 119:112 /map:mount/ file:///C:/Programme/Apache%20Software%20Foundation/Tomcat%205.5/webapps/cocoon/samples/blocks/portal/sitemap.xmap - 326:78 /map:mount/ file:///C:/Programme/Apache%20Software%20Foundation/Tomcat%205.5/webapps/cocoon/samples/blocks/sitemap.xmap - 67:68 /map:mount/ file:///C:/Programme/Apache%20Software%20Foundation/Tomcat%205.5/webapps/cocoon/samples/sitemap.xmap - 198:66 /map:mount/ file:///C:/Programme/Apache%20Software%20Foundation/Tomcat%205.5/webapps/cocoon/sitemap.xmap - 1034:92 /map:mount/ Someone knows how I can correct the problem? Thanks in advance Norbert -- Carsten Ziegeler [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Psuedo protocol as a action parameter causing problems
Hi,
this should work - the redirector has a built-in handling for cocoon: urls.
Are there any errors when you try it or what is going wrong?
Carsten
Alec Bickerton wrote:
Hi,
I have simple action that takes 3 parameter and does a simple redirect
based on the value of param1.
e.g.,
map:match pattern=blah
map:act type=SimpleAction
map:parameter name=ua value={useragent}/
map:parameter name=one value=http://somehost/someurl/
map:parameter name=two value=http://somehost/someotherURL/
/map:act
/map:match
Works perfectly, however the application I'm working on requires the use
of cocoon:// as parameters.
The following fails as the cocoon://url cannot be properly resolved by
the action.
map:match pattern=blah
map:act type=SimpleAction
map:parameter name=ua value={useragent}/
map:parameter name=one value=cocoon://someurl/
map:parameter name=two value=cocoon://someotherURL/
/map:act
/map:match
SimpleAction.java (Simplified for clarity)
public class SimpleAction extends AbstractAction {
public final Map act( final Redirector redirector, final SourceResolver
resolver, final Map objectModel, final String source,final Parameters
params) throws Exception {
String ua = example;
String oneURL = www.example.example/pass/;
String twoURL = www.example.example/fail/;
if( params.isParameter( ua ) )
ua = params.getParameter( ua );
if( params.isParameter( one ) )
oneURL = params.getParameter( one );
if( params.isParameter( two ) )
twoURL = params.getParameter( two );
if( ua.equals(something))
redirector.redirect( false, oneURL );
else
redirector.redirect( false, twoURL );
return null;
}
Any ideas. Is there a mechanism that I can retrieve the absolute URL
from the cocoon:// protocol from within an action.
Or am I missing some magic incantation on the redirector, that would let
me use this type of URL.
Any help would be most appreciated.
Alec
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Carsten Ziegeler
[EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Psuedo protocol as a action parameter causing problems
Alec Bickerton schrieb:
Carsten,
That is what I'm expecting, but for some reason. The redirect is not a
the url does become the new url.
There are no errors on the console, what is going wrong occurs in
somewhere in the pipeline. Here's a more concrete example.
For example.
If I make a request to http://myserver/blah I would expect to be
redirected to the http://myserver/someotherUrl and the request object in
the action to show the correct URL. This it does.
where there is a matcher
map:match pattern=**/someotherUrl
map:act type=SimpleAction
map:parameter name=ua value={useragent}/
map:parameter name=two value=cocoon://{1}/tools/somecheck.jsp /
/map:act
/map:match
Once the matches and the request gets to the jsp the
request.getRequestURI reads myserver/someotherUrl and not
myserver/tools/somecheck.jsp as I would be expecting.
As I wrote earlier, if a real http:// url is used, the url appears
correctly in the request to the jsp.
Btw, The cocoon version being used is 2.1.9.
Ok, there are two problems :)
The first one is that if you use the cocoon: protocol, the redirect is
handled internally, so the browser is not redirecting and is never
notified that a redirect took place. If you want the browser to redirect
you have to use the fully qualified url (using http). I'm not sure, but
it could be that we have some input modules generating the full url for
you, so you might not have to hard code the server name etc. in your
sitemap. You can check the existing input modules for this. If it's not
available I would suggest that you either write an input module for this
or do this inside your action.
The second problem is that jsp access does not work for internal
redirects. And this is a bug.
HTH
Carsten
--
Carsten Ziegeler
[EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: outputBufferSize doesn't work on Cocoon 2.1.9?
Jens Reufsteck wrote: Hi all, I need to process a large file and used a noncaching-pipeline with outputBufferSize=0 on Cocoon 2.1.7. Worked fine - apart from multithreading problems, which made me change to a newer version of Cocoon. On 2.1.9 outputBufferSize doesn't seem to have any effect. Output is always buffered to the end. I've also tried setting this on a pipe-level, didn't help. The only hint I found in the mail archives is a similar post some time ago - unfortunately without answer. Any hint would be welcome! I briefly looked at the code of 2.1.9 and it seems that there is a potential problem. Could you please debug and see how often org.apache.cocoon.environment.AbstractEnvironment#getOutputStream(int) is called during the request processing and with which int values? Second question: I used to use non-caching=true. Now, it seems to be type=noncaching. Has this changed? Is it still the same mechanism? Where did you use this non-caching=true? Afaik the correct way has always been type=noncaching :) Carsten -- Carsten Ziegeler [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cocoon.context.getRealPath cocoon 2.2
Reinhard Poetz wrote: anil wrote: Hi - Just to update this posting with my investigations - I've managed to extract the file contents within my spring bean. The basic problem was the way I was creating the file object - the path returned by the cocoon.context.getRealPath() method was a URI when instantiating my File object I needed to create a URI object first. Therefore it was: URI fileURI = new URI(output of cocoon.context.getRealPath); File file = new File(fileURI); rather than just new File(output of cocoon.context.getRealPath); Sorry - I should have noticed this - I assumed that I should be able to pass the abstract path into File object directly - I blame it on the late nights! One thing I still don't really understand though is that I'm still unable to get a path to the resource that I want to access through my spring bean as cocoon.context.getRealPath(xqy/test.xqy) still returns null. In order to get round this I do: var fullPath = cocoon.context.getRealPath(/) + xqy/test.xqy; If anyone could clear up that confusion I'd be very grateful. Just wondering: Why can't you use the source resolver? getRealPath() on the context is mapped to the getRealPath of the servlet context. The method is described as follows: Returns aString containing the real path for a given virtual path. For example, the path “/index.html” returns the absolute file path on the server’s file-system would be served by a request for “http://host/contextPath/index.html”, where contextPath is the context path of this ServletContext. Now I guess that you want to get the resource so if you would use the servlet context, the getResource() method would be the right choice. In Cocoon it's, as Reinhard suggested, the source resolver you should use. Carsten -- Carsten Ziegeler [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: 2.2 cocoon-cli
Martin Heiden wrote: Reinhard, Reinhard Poetz schrieb: Will the release of cocoon 2.2 include the cocoon-cli? I noticed that this module currently isn't included in the core's pom and istn't part of RC2. no, 2.2.0 will most probably not ship containing a CLI. I'm sorry. Will it be included in a later release or will the support be dropped starting with 2.2? Well, I hope not, because there are several projects like forrest or daisy which heavily rely on this feature. We discussed this some time ago. The outcome at that time was that the cli is not really needed and a webapp with a crawling client (wget etc.) is sufficient. Now of course, if there is need for a cli and people are willing to work on this, that's more than welcome then. Carsten -- Carsten Ziegeler [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[ANN] Apache Cocoon 2.1.11 Released
Apache Cocoon 2.1.11 Released
-
The Apache Cocoon Community is proud to announce the new release
of Apache Cocoon.
Apache Cocoon is a web development framework built around the concept
of separation of concerns (that is: allowing people to do their job
without having to step on each other toes) and component-oriented web
RAD.
The latest version is downloadable from
http://cocoon.apache.org/mirror.cgi
(Please use the mirrors to download the release - it might take
a little bit more time until the latest release is available on
all mirrors, so give the mirrors some time - approx. 24h to update.)
This release includes many bug fixes and smaller enhancements.
For more information about Apache Cocoon 2.1.10, please go to
http://cocoon.apache.org. You'll find the whole list of changes at
http://cocoon.apache.org/2.1/changes.html.
The Apache Cocoon Project
--
Carsten Ziegeler
[EMAIL PROTECTED]
For more information about Apache Cocoon 2.1.11, please go to
http://cocoon.apache.org
Changes with Apache Cocoon 2.1.11
*) Created XPathXMLFileModule to address issus with XMLFileModule.
XPathXMLFileModule supports variable replacement and caching of documents in
ehcache and expressions as soft references. [RG]
*) Forms: Allow Ajax submission of forms with empty upload field. [AG]
*) Portal: New SiteProfileManager providing the same profile to several users
based on a configured key. [CZ]
*) Portal: Some memory consumption improvements for the user profiles. [CZ]
*) Core: Update xalan to 2.7.1. [AG]
*) Sitemap: Redirect to cocoon:/foo did not work in sub-sitemap when it is in
same directory as the root sitemap. [AN]
*) Core: Update xercesImpl to 2.9.1. [AG]
*) Event Cache Block: Restore serializability of persistent cache when using
event-aware cache. [JH]
*) Mail Block: Fix setting of URL message body. [VG]
*) map:serialize status-code={}/ supports variable resolution. [JH]
*) XMLDB Block: Fix collection URLs in XMLDBSource. Fixes URL resolution and
'Mount DB' sample. [VG]
*) XMLDB Block: Update Xindice to 1.1 release. [VG]
*) POI Block: Color string normalization. [AG]
*) build.sh: Allow for quoted shell arguments containing spaces. [AN]
*) CForms: Handling of empty responses in AJAX Forms with IFrame transport. [AG]
*) Ajax: ajax/common.js makes use of deprecated dojo.animation.Timer [AG]
*) XSP block: Upgrade Eclipse compiler to version 3.1.0 to allow the use of
Java5 syntax in XSPs. (Latest released Eclipse version is 3.2.2 but use 3.1.0
to be consistent with the version picked up by the Maven build in trunk). [AN]
*) Core, QDox: Fixed getInputStream() in XModuleSource and QDoxSource: Set up
XMLSerializer in a component way, i.e. retrieve it from ServiceManager. [JH]
*) Dojo toolkit upgraded to 0.4.3 version. It contains fix for security bug.
See http://dojotoolkit.org/releaseNotes/0.4.3. [GK]
*) I18n (ParamSaxBuffer): when substitution params like {0} are split over
multiple character events, do not write out extra garbage characters. [JJ]
*) Portal: Marked PreparePortalAction, CopletSetDataAction, and
ObjectModelAction ThreadSafe [RG]
*) Core: Update log4j to 1.2.14, commons-io to 1.3.1, commons-lang to 2.3 and
jakarta-regexp to 1.5. [AG]
*) CForms: MultivalueEditorWithSuggestion doesn't add values to the listbox on
Internet Explorer. [AG]
*) CForms: Submit widget now inherits validate attribute value from the
ancestor widget, if it is specified. [VG]
*) Serializers block: Correctly handle content of script and style tag as cdata
for html. [CZ]
*) CForms: MultivalueEditorWithSuggestion, extended multivalueeditor widget
with suggestion list. [AG]
*) CForms: CFormsSuggest widget does not implement the onValueChanged event.
[AG]
*) Core: EHCache now uses the configured cache directory instead of using the
default of java.io.tempdir. [CZ]
*) Core: Update ehcache to 1.2.3. [CZ]
*) Template block: Add missing toString implementation to
TemplateObjectModelHelper.ParametersMap. [CZ]
*) Portal block: CocoonPortlet needs to allow overriding servlet-path parameter
with preferences. [CZ]
*) CForms: Fix Serialization parameter {indent} must have the value yes or no
error in Form.prototype.saveXML() when using Saxon. [JJ]
*) Core: Exipres caching pipeline can now cache the content forever (by setting
cache-expires to a negative value). [CZ]
*) Core: In store janitor, add an option to cleanup all stores on each janitor
run. Default behavior is to cleanup one store at a time. [VG]
*) Core: Fix deadlock in caching pipeline when used in combination with include
transformer. [AN]
*) CForms: introduce a new dojo-based popup-picker for dates, times and
datetimes. For correct localization, supply a dojo-locale parameter to the
forms styling XSLT (see samples). [BRD]
*) CForms: add support for a timeStyle attribute on the formatting date
convertor, so that the time style can (optionally) be specified
Re: best wishes for 2008: 2.1 vs. 2.2
Before we continue to discuss the pros and cons of maven (which I'm really really tired of) a very important clarification: Cocoon 2.2 does not require Maven. Period. and The Cocoon project uses Maven for developing Cocoon itself. While there might be advantages in using Maven for building own applications with Cocoon like the archetypes, it's not a requirement. I think we took great care to allow users to use their favorite build system. I built Cocoon 2.2 web based applications without maven by using a simple ant script copying jars into the WEB-INF/lib folder. All you need are the binary artifacts of Cocoon (and the required third party jars). Now, I agree that we currently fail in providing a convenient download for these use cases - but that's a totally different thing and has nothing to do with maven. I hope that this will change with a final 2.2 release - which is hopefully coming in the near future... Carsten -- Carsten Ziegeler [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Cocoon and clustering
Alec Bickerton wrote: Having spent most of today going through a mountain of .xsl, I have found the cause. It appears that if a transformation does this... session:createcontext name=mysession/ session:setxml context=mysession path=/sessionua /session:setxml Then the session context hangs around and causes the Not serializable exception. Am I missing something? Does any mechanism exist to ensure this is removed at the end of the pipeline. Ok, by this you create a *session* context, so the scope/lifetime of this context is the session. Therefore it's not destroyed at the end of the request. Depending on your application and what you're doing there is the temporary context (lifetime is a single request). So changing the first line to session:createcontext name=temporary/ might solve your problem. HTH Carsten -- Carsten Ziegeler [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: How to convert global sitemap variables to properties in 2.2
Alter wrote:
Hi All,
I am trying to migrate a cocoon site to 2.2. My old sitemap used global
variables defined in the sitemap and addressed as {global:varname}.
I already found that global sitemap variables have been deprecated,
and that I should use properties instead.
HOWEVER: after extensive searching I cannot find the correct way to
define such variables in a name.properties file, and what that file's
location should be. I tried to set use-default-location to false and set
my own location, but that didn't work either.
So my questions are:
1. Where to put such a properties file?
You can put it in your block (jar file) under META-INF/cocoon/properties
or in your web application under WEB-INF/classes/cocoon/properties
2. Can the name part of name.properties be anything or should
it be derived from something?
It can be anything, but it should be a valid filename of course :) Keep
in mind that property files are processed in alphabetical order.
3. What is the correct prefix to use to specify such a global variable?
Should each line read %varname=value, or should there be a
prefix referring to a specific block? If so, which block?
You can use any name, so no prefix required - all properties
used/defined by Cocoon itself will have the prefix org.apache.cocoon
so there shouldn't be any name clashes.
HTH
Carsten
--
Carsten Ziegeler
[EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Filter transformer - default block size?
Derek Hohls wrote:
Carsten
Thank you for clarifying that. I do not wish to implement a special version
only for my own purposes (I can find a work-a-round for now) . Would it
be possible that such an amendment be considered for future versions?
(It does seem like a potentially useful option).
Yes, I think that this addition makes sense, too. If you come up with a
patch
(and add it to Jira) I'm more than happy to apply it.
Thanks
Carsten
Thanks
Derek
Carsten Ziegeler [EMAIL PROTECTED] 2007/12/01 02:48 AM
Derek Hohls wrote:
I am using the filter transformer - which works just fine -
as follows:
map:transform type=filter
map:parameter name=element-name value=row/
use-request-parameterstrue/use-request-parameters
map:parameter name=count value={request-param:c}/
map:parameter name=blocknr value={request-param:b}/
/map:transform
In the case where *no* values are passed for the parameters,
it seems the count value defaults to 10. Is there a way to change
what this default is without passing an actual parameter value to the
filter transformer (I was thinking perhaps a setting in cocoon.xconf)?
Hi,
no, the current implementation does not provide a way to change the
default for count.
You can extend the transformer and make it implement either Configurable
or Parameterizable to change the default values. An example for this is
the EncodeURLTransformer which reads default information in the
configure method and then uses these as defaults in the setup method.
HTH
Carsten
--
Carsten Ziegeler
[EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
This message is subject to the CSIR's copyright terms and conditions,
e-mail legal notice, and implemented Open Document Format (ODF) standard.
The full disclaimer details can be found at
http://www.csir.co.za/disclaimer.html.
This message has been scanned for viruses and dangerous content by
*MailScanner* http://www.mailscanner.info/,
and is believed to be clean. MailScanner thanks Transtec Computers
http://www.transtec.co.uk/ for their support.
--
Carsten Ziegeler
[EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Filter transformer - default block size?
Derek Hohls wrote:
I am using the filter transformer - which works just fine -
as follows:
map:transform type=filter
map:parameter name=element-name value=row/
use-request-parameterstrue/use-request-parameters
map:parameter name=count value={request-param:c}/
map:parameter name=blocknr value={request-param:b}/
/map:transform
In the case where *no* values are passed for the parameters,
it seems the count value defaults to 10. Is there a way to change
what this default is without passing an actual parameter value to the
filter transformer (I was thinking perhaps a setting in cocoon.xconf)?
Hi,
no, the current implementation does not provide a way to change the
default for count.
You can extend the transformer and make it implement either Configurable
or Parameterizable to change the default values. An example for this is
the EncodeURLTransformer which reads default information in the
configure method and then uses these as defaults in the setup method.
HTH
Carsten
--
Carsten Ziegeler
[EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Flowscripts - are they cached?
Hmm, apart from the setting mentioned in the cocoon.xconf there is afaik no other setting. Cocoon checks the last modification date against the current date. So if the actual file system reports the correct date and you have ended your user session, the file should be reloaded. Btw, what version of Cocoon are you using? Carsten Derek Hohls wrote: Yeah, I noticed that the server is running behind by about 90 minutes. Mentioned that to the sysadmin and they said something about synchronizing to the time server but if my files are supposedly *newer* than those on the server, that should not make a difference in this case. Tobia Conforto [EMAIL PROTECTED] 2007/11/12 02:12 PM Another thing: sometimes I run into missing reloads caused by differences in the system time on servers or workstations. That is, a newer file is not reloaded if Cocoon doesn't see it as newer, based on the system clock. Depending on your setup, you might want to investigate that. Tobia - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- This message is subject to the CSIR's copyright terms and conditions, e-mail legal notice, and implemented Open Document Format (ODF) standard. The full disclaimer details can be found at http://www.csir.co.za/disclaimer.html. This message has been scanned for viruses and dangerous content by *MailScanner* http://www.mailscanner.info/, and is believed to be clean. MailScanner thanks Transtec Computers http://www.transtec.co.uk/ for their support. -- Carsten Ziegeler [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Flowscripts - are they cached?
Grzegorz Kossakowski wrote: Derek Hohls pisze: Working with Cocoon 2.1.8 and Tomcat 5 on a Linux box. It appears that changes to flowscript files are not reflected in Cocoon which continues to work with a previous version. How do I ensure that the new version/s are used - without restarting Tomcat? (I do not see the same effect on my local machine... but there I am running Jetty). I don't know how flowscipt management works exactly but a quick guess: have you tried to touch a sitemap referencing modified flowscript? I don't remember the details, but for some reason the flowscripts are linked to the current user session. So if you have a session and change the flowscript, logging out of the session and logging in again should load the new flow script. Carsten -- Carsten Ziegeler [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: authfw auth-logout action delete session contexts
Alberto Brosich wrote: Well, I already have a login form able to show possible exceptions of the authentication phase (intercepted and stored in a session context), so I would simply reuse this functionality to display validation errors catched in the flowscript (form has only listboxes therefore a validation error occur only converting fields to text inputs with tools like web developer addon; really rare). I'll change the approach. No logout and reloading of the form showing the exception. In any case which are other places to store this kind of information? Ah, ok, I see - now, I think there are basically two solutions. Either you store the exception information in the session and take care that there is no logout. Or you add this information as hidden parameters to the login form so they are submitted each time a new login is tried. There are basically two variations for this, either you store all information as request parameters there or you just store a pointer there and on the server you store the information in some global store (simple map would do). HTH Carsten -- Carsten Ziegeler [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: authfw auth-logout action delete session contexts
Alberto Brosich wrote:
I'm fighting with session contexts.
I write a new session context (named exceptions) in a flowscript.
If I call a pipeline that contains an auth-logout action that context is
deleted.
As sample:
map:match pattern=do-logout
map:act type=auth-protect
map:parameter name=handler value=ldaphandler/
map:act type=auth-logout/
/map:act
map:redirect-to uri=test-session session=true/
/map:match
If I commented out the auth-logout action works all fine otherwise
{session-context:exceptions/...} is empty.
It seems auth-logout action deletes all the session contexts. Is it true?
Yes, that's true - in fact auth-logout terminates the session and therefore
the contexts are deleted as well.
I'm wondering what your use case is? If a user logs out there shouldn't
be any user data left on the server. If you want to store data globally
(not bound to a specific user session), the session contexts are not the
right place to store. Session contexts are always bound to a user session.
HTH
Carsten
--
Carsten Ziegeler
[EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: cocoon and jdk 1.5
Yes this is possible. Many are using 2.2 with Java 5 - 1.4.2 or above includes all versions higher than 1.4 which are currently Java 5 and Java 6. Carsten [EMAIL PROTECTED] wrote: I’m interested in using cocoon 2.2 in a Java 5 project. Is this possible? On the site under the deployment section it mentions jdk1.4.2 or above – but no explicit mention of 1.5? Thanks Richard Richard Whalley *Concept Labs *CIO - Global Application Delivery Services Radbroke Hall Knutsford WA16 9EU, Mail Van M c/w 7 2000 4257 external 01565 614257 This e-mail and any attachments are confidential and intended solely for the addressee and may also be privileged or exempt from disclosure under applicable law. If you are not the addressee, or have received this e-mail in error, please notify the sender immediately, delete it from your system and do not copy, disclose or otherwise act upon any part of this e-mail or its attachments. Internet communications are not guaranteed to be secure or virus-free. The Barclays Group does not accept responsibility for any loss arising from unauthorised access to, or interference with, any Internet communications by any third party, or from the transmission of any viruses. Replies to this e-mail may be monitored by the Barclays Group for operational or business reasons. Any opinion or other information in this e-mail or its attachments that does not relate to the business of the Barclays Group is personal to the sender and is not given or endorsed by the Barclays Group. Barclays Bank PLC.Registered in England and Wales (registered no. 1026167). Registered Office: 1 Churchill Place, London, E14 5HP, United Kingdom. Barclays Bank PLC is authorised and regulated by the Financial Services Authority. -- Carsten Ziegeler [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: jsr 168 portlet file download
vtysh schrieb: I am new in Cocoon Portal. Is where a way to use technique described http://www.unicon.net/node/596 here in Cocoon? I tried to define new custom-window-state in portlet.xml file but my portlet doesn't see it. Or is where another way to get exclusive access to response output for file download purposes? Any help will be appreciated Hi, the Cocoon portal does not support such a custom window state. Please note that this window state is not part of the spec and a custom extension of uPortal. If you need this feature you have to enhance the Cocoon portal to support this window state as well. Currently there is no way I know of to achieve what you want. The only thing I can think of is using a servlet inside your portlet application to serve resources. But in this case you don't have access to the portlet information and you have to code every information into the url of the resource. (With 2.0 of the portlet spec things will change as the portlet then supports resource streaming for exactly these purposes). Carsten -- Carsten Ziegeler [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: fullscreen portlet bug...
Hi,
current svn for 2.1.x contains a fix for the case if
cocoon-portal-action is missing. I think the portal block contains
some more bug fixes in current svn.
So you might want to try that version - perhaps it solves your problems
or at least reduces them :)
Carsten
newsted wrote:
I think I have found something...
The problem is in the NewEventLinkTransformer::startTransformingElement()
method,
in the formSpecialTreatment case. First the following code ...
int begin = eventLink.indexOf(cocoon-portal-action=)
+ cocoon-portal-action=.length();
int end = eventLink.indexOf('', begin);
if (end == -1) {
end = eventLink.length();
}
... always assumes that the 'cocoon-portal-action' parameter is present
which is not the case! second, it forgets the 'cocoon-portal-fs' parameter
and this is why I'm loosing fullscreen aspect in an application copplet.
I've supposed that cocoon-portal-action is deprecated and replaced by
cocoon-portal-fs (is it really?). I have replaced it in the above code and
now the fullscreen aspect works... I need to add code to behave correctly
when cocoon-portal-fs parameter is not there.
But I still have the problem with fullscreen portlet when I swicth page in
the tab menu.
newsted wrote:
Hi,
I am using the last version of cocoon portal engine and I'm facing
problems
with the fullscreen feature.
It seems like the fullscreen feature is quite unstable.
For example, I have a full screen sized portlet on one page, when I
navigate
to another page through the tab menu, the second page remains empty.
I have to go back to the previous page, mimimize the portlet (that was
full
screen) to see the portlets on the second page.
Another example: I have an application copplet fullscreen sized again,
when
I interact with the application it losts the fullscreen aspect.
I would like to have the fullscreen aspect working perfectly. What do I
have
to do?
What is the difference betwwen fullscreen-uri, maximize-uri and
maxpage-uri?
thanks a lot
--
Carsten Ziegeler
[EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: How to limit number of instances of component?
Grzegorz Kossakowski wrote: [EMAIL PROTECTED] pisze: I'm trying to use the imageop block, but its rather resource intensive. I get out of memory errors. This happens because I generate a number of thumbnails on a page and the browser requests all images from the server at once. Then cocoon creates a pipeline for each request in parallell and out of memory occurs. I hope that you use caching so every thumbnail is generated only once. Do you? How can I limit the number of parallell instance of a pipeline? I tried pool-max on the resizer like this: map:reader logger=imageop name=image-op-resize-pool-max src=org.apache.cocoon.reading.imageop.ImageOpReader pool-max=2 but it appears that pool-max only limits the number of instances in the pool, not the total number of instances. when the pool is filled, new instances are created outside the pool. Yes, pool-max will not help you in this case, it's not hard limit by any means. I could maybe set session-max on the container, but that would affect the entire system. I could also maybe do some client side javascript hackery to request the images in sequence, but I'd rather not. I want something like a queue rather than a pool. I suspect that you use Cocoon 2.1, right? Your question is quite interesting and I don't have any simple solution off the top of my head. Not so simple but most elegant would be to implement processing queue for particular pipeline in o.a.c.components.pipeline.AbstractProcessingPipeline#process() method. After quite simple implementation you could use something like: map:pipeline map:parameter name=processInQueue value=true/ map:parameter name=maxSimultaneousProcessings value=5/ [put your reader here] /map:pipeline I think it's worth to wait for other ideas before implementing this. It depends on the exact use case and the requirements, but limiting the pipeline might create a real bottleneck. Imagine several clients with each one requesting several images at the same time. I would rather try to do some offline generation of the images and store them in the cache and deliver them from cache only. But of course this depends on the nature of the images like if they change very often or if the representation various depending on the client etc. Carsten -- Carsten Ziegeler [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Cocoon 2.2 and the SourceResolver
Olivier Billard wrote: Hi Cocooners, I read here and there (COCOON-1995 for example), that using Cocoon 2.2, the SourceResolver cannot be used in Spring Beans. If true, this is very annoying, because this feature is really usefull, to have components really independant in the way sources URI are passed to them : cocoon: (yeah costfull, I know, this is just an example :)), context:, blob:, etc... Those services are not tied to an absolute path or whatever. What are the solutions to use this ? Only to develop services using the old Avalon framework ? Is it work in progress ? I post this question in the users list, because this is really a Cocoon 2.2 usability issue. Afaik, you can use the SourceResolver in your spring beans (when running inside Cocoon); the bean name is the full name of the source resolver interface. However, there might be protocol implementations (like cocoon:) which do not work outside of a Cocoon request as the environment for this has not been setup then. But I think this could be fixed by using the stuff which is currently used in the cron block for the background stuff. HTH Carsten -- Carsten Ziegeler [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: tab (including space) in cocoon portal
Ludovic Desforges wrote: tab.xsl, portal-page.xsl, inside \portal\skins\common\styles ? Yes, you have to change tab.xsl - just make sure that the item name is not wrapped. Carsten -- Carsten Ziegeler [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: jsr 168 portlets in cocoon
Conoly, Brett wrote: I’ve been trying to implement a jsr 168 portlet in cocoon and I’ve had a hard time following the wiki at http://wiki.apache.org/cocoon/JSR168Portlet?highlight=%28copletdata%2Fportal.xml%29 I’m using cocoon v 2.1.9, tomcat v 5.5.23 and I’ve followed the wiki as much as I could so far. The problem I seem to be having is that cocoon cannot find my portlet. In the wiki it says: To integrate the portlet into the Cocoon sample site: · **copletdata/portal.xml**: oAfter the CocoonPortlet definition add: code coplet-data id=RssPortlet name=standard titleRssPortlet/title coplet-base-dataPortlet/coplet-base-data attribute nameportlet/name value xsi:type=java:java.lang.String xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;RssPortlet.RssPortlet/value /attribute attribute namebuffer/name value xsi:type=java:java.lang.Boolean xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;true/value /attribute /coplet-data /code If someone can I’d like more of an explination of what the portlet attribute actually is and what it’s looking for. I think I’ve narrowed the problem down to this for now and I’m stuck. The portlet attribute is pointing to your portlet, it is the webapp name of your portlet (in this case RssPortlet) followed by a dot followed by the portlet id (which happens to be RssPortelt as well). Apart from this configuration you need to propertly deploy the portlet into tomcat as mentioned on the page. Usually the most common problem are classpath problems. You have to put the portlet-api and pluto jars into the tomcat common directory and delete it from the cocoon/web-inf/lib dir. The best approach to test things is to follow these instructions (taken from the cocoon portal sampe page) - Get the Pluto project (1.0.x) and install it into Tomcat (Test Pluto now) - Install Cocoon as a web application in Tomcat and remove the Pluto webapp. Please note, that it is currently not possible to start Cocoon directly from a war file; it has to be expanded. - Remove the pluto-*.jar and the portlet-api-*.jar from the Cocoon WEB-INF/lib directory. If you now start the cocoon portal sample, you should see the pluto sample jsr portlets on the jsr tab (after login) Carsten -- Carsten Ziegeler [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: re-design of sitemaps
Stephen Winnall wrote: On 6 Jun 2007, at 18:49, Geert Josten wrote: 3) definition of a sitemap schema http://cocoon.apache.org/schema/sitemap/cocoon-sitemap-1.0.xsd rvlet-service framework? Have you tried validating your own sitemaps to this XSD yet? It contains constructs that allow entry of unknown elements.. I tried a couple of sitemaps before I posted the original comment. One of them was based on the sitemap delivered with Cocoon 2.1.9. Both threw up errors (mainly unknown attributes). I am aware that schemas can be written using the any element for undefined or unknown content, but that seems a bit of a cop-out to me. I don't know what the official adjective is for the class of XML documents for which a complete and correct XML schema can be written: let's use x-able as a place-holder. To the best of my knowledge, the Cocoon sitemap is not x-able, and I think that inhibits the development of useful tools for making Cocoon easier to use. (Perhaps the SunBow or Lepido people could comment on that?) The current schema is a first version which has been tested against all sitemaps of Cocoon 2.2. And they validate against it :) But of course this doesn't guarantee that it's perfect. Now, a schema can only validate the structure (more or less at least), so it can't detect any logical errors one might have in the sitemap like a missing generator or something like that. Custom tags are actually only allowed for component configuration. We could also ignore all elements in other namespaces that might occur throughout the sitemap, but I'm not sure if this is a good idea. I would like to have the schema as strict as possible. If you have a sitemap which does not validate against the schema, it would be great if you could file a bug, so we can enhance the schema. One could think of additional validation tools on top of the schema which try to analyze the logic of the sitemap. Carsten - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Custom Cocoon 2.2 projects: Alternatives to Maven 2
Reinhard Haller schrieb: Is there a design decision to use maven as a base or not? If so then go ahead and use it. If you want to get a new design decision, wait until the next version is in the design phase. The decision was to use maven for developing cocoon itself and to not require maven for cocoon based projects. Carsten - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Custom Cocoon 2.2 projects: Alternatives to Maven 2
Ralph Goers wrote: Carsten Ziegeler wrote: Reinhard Haller schrieb: Is there a design decision to use maven as a base or not? If so then go ahead and use it. If you want to get a new design decision, wait until the next version is in the design phase. The decision was to use maven for developing cocoon itself and to not require maven for cocoon based projects. Maybe, but I'd push Cocoon 2.2 out the door before worrying about this. It's been in the oven long enough. Oh, yes - definitly; it is possible to use 2.2 without maven; you just have to figure out how...when it's released we can update the docs and give help. Carsten - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Custom Cocoon 2.2 projects: Alternatives to Maven 2
Reinhard Poetz wrote: Joerg Heinicke wrote: On 22.05.2007 13:55, Reinhard Poetz wrote: Compared with JSF and Struts Cocoon is very different. This means that you have to learn to think in Cocoon (btw, the same is true for frameworks like Tapestry or Wicket). Without good documentation it is very difficult to learn this way of thinking and hence my reasoning that we need better docs. The annoying in the original post [1] is that the main reason for his frustration seems to be Maven and not necessarily Cocoon itself. yes, Maven 2 is IMHO an even more complex beast than Cocoon (and I mean 2.1 here!). Since I've been involved in two big projects (Cocoon 2.2 and one commercial project) that migrated to Maven 2, I've learnt to appreciate the power of Maven 2 but I remember how difficult it was to learn how Maven 2 works and how to solve real-world problems. How can we help our upcoming 2.2 users? IMO there are two approaches which should be followed in parallel: 1) make the usage of Maven 2 as simple as possible - the tutorials take this into account - we provide different archetypes 2) offer an alternative to Maven 2 Option one is clear and is nearly finsihed. My question is regarding to option 2: What do you expect, when you download Cocoon 2.2 in order to get your new Cocoon 2.2 project started? Keep in mind that Cocoon 2.2 is split into a core and several blocks (template, forms, etc.). All of them are separate release artifacts and in contrast to Cocoon 2.1 they can and will be shipped as binaries again. (Note that I'm not talking about samples, that's something different.) Just some unstructured thoughts: What about creating a zip containing the result of the cocoon archetype run? People could use this as a starting point for own projects without maven. Adding blocks should then just be adding the jar which is available for download. The final step would be a document how to build your own block without maven, perhaps someone could come up with an ant script doing this stuff. Carsten - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Custom Cocoon 2.2 projects: Alternatives to Maven 2
Reinhard Poetz schrieb: What about creating a zip containing the result of the cocoon archetype run? People could use this as a starting point for own projects without maven. I guess that you mean the result in ./target/webapp which is created by mvn install, don't you? Ah, yes, you're right. Yepp. Adding blocks should then just be adding the jar which is available for download. yep The final step would be a document how to build your own block without maven, perhaps someone could come up with an ant script doing this stuff. good idea, shouldn't be that difficult. If someone can document the steps (which we should do anyway) I can try and come up with the ant script. Carsten - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Custom Cocoon 2.2 projects: Alternatives to Maven 2
Grzegorz Kossakowski wrote: Reinhard Poetz pisze: 2) offer an alternative to Maven 2 Option one is clear and is nearly finsihed. My question is regarding to option 2: What do you expect, when you download Cocoon 2.2 in order to get your new Cocoon 2.2 project started? Keep in mind that Cocoon 2.2 is split into a core and several blocks (template, forms, etc.). All of them are separate release artifacts and in contrast to Cocoon 2.1 they can and will be shipped as binaries again. (Note that I'm not talking about samples, that's something different.) To be honest I would not like to see option 2 implemented. I believe that diversity is important but we must also be aware of the costs that come along with more options. First, I really think that we should focus on the other things like documenting, testing, polishing and releasing stuff we already have. Of course, if someone wants to put his effort into developing Ant scripts I won't stop him, it's always better than not doing anything. The second argument is stronger in my opinion. Even though introducing more options is usually not so difficult, we must remember that it's our (as community) responsibility to maintain these more options for a long time. More options means that possible refactorings and serious changes are much more difficult to carry out and providing migration guides is also much more troublesome because you hardly can assume something about readers setup. I would not really like to see situation like I can't help someone on the list only because I don't want to dig through his very own Ant-driven setup. Now I really like situation with Cocoon 2.2 where I can say this: mate, use archetypes for your blocks and for assembling your webapp and if you encounter some problems/bugs just extract bits related to the problem and send us an ad-hoc created block showing the problem. Then, I can just write mvn cocoon:rcl and start helping this person being sure that we both talk about the same thing and problem. Sounds encouraging, doesn't it? :-) To sum up, if you really want to put effort into it could it be assumed as only temporary solution that aims to make it easier to migrate? Hmm, no I don't think so :) Personally, I really love maven 2 and it works very well for a lot of our projects. It makes sense to use it for developing cocoon itself, but we should not force everyone who wants to do a cocoon project to use maven 2. This ain't gonna work. You're right that we should not maintain all possible different ways, but we spend a lot of energy into 2.2 to make it independent from m2. For example that's the reason why we extract blocks at runtime through cocoon itself and not at build time. So if someone wants to use something different than m2, all he has to do is to create a block. A block is just a jar with a special format. We have to document this format anyway and that's all we have to do for other build systems. Nothing more but also nothing less. But as a proof that the docs are correct and our ideas work, we should just come up with one additional solution like an ant script. My idea is to put this script into the documentation and not into our svn. The script would act as a starting point. Carsten - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Cocoon Productivity [was Re: Sitemap patterns dead?]
Derek Hohls wrote: Grzegorz Do you think this a valid criticism - are WebObjects (whatever those are) or Struts (Java coded framework) really that more productive and easy to use than Cocoon?? Just for reference, imho WebObjects (http://www.apple.com/webobjects/) is one of the best frameworks for web applications. Unfortunately it wasn't able to attract the masses over a longer time. (Hmm, sounds somehow familiar?) Carsten - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Portal] How to have user and group information in styles/window.xsl ?
Am 20.04.2007 um 09:51 schrieb Jean-Christophe Kermagoret: Thanks for your help, I'm migrating our portal application on cocoon 2.2 trunk. Are there any things to know that should avoid problems ? I haven't looked at trunk and the portal for a long time nowI think most stuff should work; I'm not sure but I think there are some problems with the ajax stuff and there where some problems with using forms in the portal due to the changes in cforms over time. THe portal in 2.2 has partially migrated to Spring, so configurating might look a little bit different, but I think/hope that the portal itself should work... Carsten - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: XHTML Serializer block/Ajax: Bug
Jason Johnston wrote: Carsten Ziegeler wrote: Actually I was too fast in answering :( Yes, I only fixed the html serializer and that fix is not appropriate for the xhtml. In html, the contents of the script tag is defined as a cdata section, therefore there should be no encoding inside the script. And that's what I fixed. With xhtml the contents of script is defined as pcdata, so the solution would be to create a block like this: script type=text/javascript /* ![CDATA[ */ THE REAL JAVA SCRIPT /* ]] */ /script I definitly think that we should fix this in the serializer by adding a /* ![CDATA[ */ when a script tag opens and a /* ]] */ before the script tag closes. Additionally no encoding inside the script tag (as with the html serializer). Carsten are you working on implementing this? I was going to give it a shot but if you're doing it I won't bother. :-) No, I'm not working on it yet - I would do it by the end of next week. So if you want, just do it :) Carsten -- Carsten Ziegeler http://www.osoco.org/weblogs/rael/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: XHTML Serializer block/Ajax: Bug
Actually I was too fast in answering :( Yes, I only fixed the html serializer and that fix is not appropriate for the xhtml. In html, the contents of the script tag is defined as a cdata section, therefore there should be no encoding inside the script. And that's what I fixed. With xhtml the contents of script is defined as pcdata, so the solution would be to create a block like this: script type=text/javascript /* ![CDATA[ */ THE REAL JAVA SCRIPT /* ]] */ /script I definitly think that we should fix this in the serializer by adding a /* ![CDATA[ */ when a script tag opens and a /* ]] */ before the script tag closes. Additionally no encoding inside the script tag (as with the html serializer). Does this make sense? Carsten Andrew Madu wrote: Hi Jörg, Carsten fixed something in the HTMLSerializer, but changed nothing in the XHTMLSerialzer: Yes, I have seen the changes made by Carsten in HTMLSerializer: @version CVS $Id: HTMLSerializer.java 515096 2007-03-06 12:11:29Z cziegeler Changes to the XHTMLSerializer were made last by Crossley: @version CVS $Id: XHTMLSerializer.java 433543 2006-08-22 06:22:54Z crossley I have no idea (and no time to investigate) if the XHTMLSerializer needs to be updated as well. Ok. Could someone direct me to the where bugs are flagged? -- Regards Andrew -- Carsten Ziegeler http://www.osoco.org/weblogs/rael/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: XHTML Serializer block/Ajax: Bug
Yes, this is a bug in 2.1.10 - I have fixed it last week. You could either use the current xhtml serializer from svn or wait for the next release :) Carsten Andrew Madu wrote: Hi, I would like to bring this to the attention of the cocoon membership. Utilising the serializer block as seralizer of choice in an ajax-request block breaks the ajax process: map:serializer name=xhtml src= org.apache.cocoon.components.serializers.XHTMLSerializer mime-type=text/html map:select type=ajax-request map:when test=true map:serialize type=xml/ /map:when map:otherwise map:serialize type=xhtml/ /map:otherwise /map:select Output from browser view: !DOCTYPE html PUBLIC -//W3C//DTD XHTML 1.0 Transitional//EN http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd; html xmlns =http://www.w3.org/1999/xhtml;headscript type=text/javascript src=resources/dojo/dojo.js/script script type=text/javascript src= resources/ajax/cocoon.js/scriptscript type=text/javascript src=resources/forms/js/forms-lib.js/scriptscript type=text/javascript dojo.addOnLoad(forms_onload); dojo.require(quot;cocoon.forms.*quot;); /script link href=resources/forms/css/forms.css type= text/css rel=stylesheet / script type=text/javascript src=resources/forms/mattkruse-lib/AnchorPosition.js /scriptscript type=text/javascript src=resources/forms/mattkruse-lib/PopupWindow.js/scriptscript type=text/javascript src=resources/forms/mattkruse-lib/OptionTransfer.js/ scriptscript type=text/javascript src =resources/forms/mattkruse-lib/selectbox.js/scriptscript type =text/javascript src=resources/forms/mattkruse-lib/CalendarPopup.js/ scriptscript type=text/javascript src= resources/forms/mattkruse-lib/date.js/scriptscript type=text/javascript // Setup calendar var forms_calendar = CalendarPopup(); forms_calendar.setWeekStartDay(1); forms_calendar.showYearNavigation(); forms_calendar.showYearNavigationInput(); forms_calendar.setCssPrefix(quot;forms_quot;); /scriptlink href= resources/forms/css/forms-calendar.css type=text/css rel= stylesheet /script type=text/javascript _editor_url = quot;resources/forms/htmlarea/quot;; _editor_lang = quot;enquot;; /scriptscript src=resources/forms/htmlarea/htmlarea.js type=text/javascript /script Alert message generated on each ajax page: 'WARNING:_editor_url is not set! You should set this variable to the editor files path; it should preferably be an absolute path, like in '/htmlarea', but it can be relative if you prefer. Further we will try to load the editor files correctly but we'll probably fail.' Form action: Submitting an ajaxed page will cause a whole page reload when none of the required fields are filled in. System: WinXP/SP2 - Java 1.6, Jboss 4.0.3 AS -- Regards Andrew -- Carsten Ziegeler http://www.osoco.org/weblogs/rael/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: CONTEXT_WORK_DIR from flowscript
Tobia wrote:
Jeroen Reijn wrote:
after listing all the AttributeNames attached to the context you could
try to use the following line:
print(workDir: +
cocoon.context.getAttribute(javax.servlet.context.tempdir));
Thank you.
It turns out CONTEXT_WORK_DIR in the Avalon context is equivalent to:
cocoon.context.getAttribute('javax.servlet.context.tempdir') +
'/cocoon-files'
And that's where the various Lucene components create and look for
indices by default.
This is only true if you use the default configuration for the working
directory. However, it's possible to store the directory somewhere else.
The only way to get the Avalon Context in Flow is to write a Java class
that implements Contextualizable. You can now instantiate an object of
this class from flow through cocoon.createObject(CLASSNAME);
Cocoon calls the contextualize methods and passes in the Context object.
Store this in an instance variable and add a getter method to the
object, for example getAvalonContext(), then you get the context like
cocoon.createObject(CLASSNAME).getAvalonContext().
Now, this is rather complicated, I admit, but it should always work.
Carsten
--
Carsten Ziegeler
http://www.osoco.org/weblogs/rael/
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: CONTEXT_WORK_DIR from flowscript
The context returned by cocoon.context is not the Avalon context it's the environment context which is mapped to the servlet context. Carsten Jeroen Reijn wrote: Hi Tobia, after a bit of exploring I can confirm your experience with the null value. I'm not sure yet why this happens, but after listing all the AttributeNames attached to the context you could try to use the following line: print(workDir: + cocoon.context.getAttribute(javax.servlet.context.tempdir)); Kind regards, Jeroen Reijn Tobia wrote: Ard Schrijvers wrote: How can I obtain the following object from flowscript? (java.io.File) context.get(Constants.CONTEXT_WORK_DIR) cocoon.context.getAttribute(Constants.CONTEXT_WORK_DIR) should do the trick Actually: cocoon.context.getAttribute(org.apache.cocoon.Constants.CONTEXT_WORK_DIR) but it's not working, it returns null. Tobia - 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] -- Carsten Ziegeler http://www.osoco.org/weblogs/rael/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: CONTEXT_WORK_DIR from flowscript
Ard Schrijvers wrote: The context returned by cocoon.context is not the Avalon context it's the environment context which is mapped to the servlet context. So cocoon.context.getAttribute(org.apache.cocoon.Constants.CONTEXT_WORK_DIR) works or does not work according the above? I thought it just should work the way I mailed it [cocoon.context.getAttribute(Constants.CONTEXT_WORK_DIR)] (though the org.apache.cocoon i meant implicitely because you might have equally well imported the class and use Constants.CONTEXT_WORK_DIR) Sorry for my brief answer: it does not work. The constants defined in the Constants class starting with CONTEXT all refer to the Avalon component context. cocoon.context is the o.a.c.environment.Context class; it has no pre defined attributes, but as it is mapped to the servlet context, it has all attributes from the servlet context. To add more confusion, there is a constant in the Constants class which points to the o.a.c.environment.Context object in the Avalon context (something like CONTEXT_ENVIRONMENT_CONTEXT). Now, this is all a little bit..ehm...messy, but it's the way it has been defined years ago. Carsten -- Carsten Ziegeler http://www.osoco.org/weblogs/rael/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: redir in auth-fw
tks got the resource, but the resource is like http://localhost:8080/...?p=1 how to get the parameter p in resource You have to pass the url, the best way is propably writing an Action which you can place in your sitemap. HTH Carsten -- Carsten Ziegeler http://www.osoco.org/weblogs/rael/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: redir in auth-fw
Hi,
if you just specify
redirect-to uri=cocoon:/login/
the authentication-fw will automatically call
cocoon:/login?resource={original uri}
So you can get the original uri using the resource request parameter
in your login pipeline.
HTH
Carsten
johnson wrote:
Hi!
In the auth-fw(flow) sitemap, there is a authentication-manager
component like below.
map:component-configurations
authentication-manager
handlers
handler name=flowdemohandler
redirect-to uri=cocoon:/login/
authentication uri=cocoon:raw:/authenticate/
/handler
/handlers
/authentication-manager
/map:component-configurations
I want to use some request param like
redirect-to uri=cocoon:/login?p={request-param:p}/
how to set the parameter like {request-param:p}
Best Regards
johnson
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Carsten Ziegeler - Chief Architect
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Cocoon 2.2, portal and cauth problem
The portal in trunk is now working for me again (well, parts of it are working). I disabled the database authentication (reverting to the pipeline based auth), disabled the automatic cforms transformation (the recent changes to cforms seem to cause problems) and disabled the ajax support. HTH Carsten -- Carsten Ziegeler - Chief Architect http://www.s-und-n.de http://www.osoco.org/weblogs/rael/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Cocoon 2.2, portal and cauth problem
Jean-Christophe KERMAGORET wrote: Are you using another portal, like jetspeed ? No :) I'm using intensively Cocoon Portal, and I'll be happy to help you to make Cocoon portal workgin again with 2.2 Great! I'm available tomorrow to make this job, maybe I'll ask you for help I'm not sure when I will have time for this, perhaps on saturday or early next week. I'll keep you posted. Carsten - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Cocoon 2.2, portal and cauth problem
Jean-Christophe Kermagoret wrote: Hi, I don't want DB auth, so I comment in cocoon-portal-sample/src/main/resources/COB-INF/config/avalon/auth-cauth.conf the part about DBSecurityHandler and uncomment the one with PipelineSecurityHandler. But even if I change the file (and remove the target directory in cocoon-portal-sample and cocoon-webapp with 'mvn -o clean' in each directory), I finally have the original file with DBSecurityHandler in my cocoon-webapp when I try 'mvn -o install jetty:run' in my webapp directory !!! What's wrong ? Dump question just to be sure: you did a mvn -o install in the cocoon-portal-sample directory before the mvn -o install in the cocoon-webapp directory? Usually when I test changes I clean the block I want to test, do then an install there and then do a clean/install/jetty run in the webapp directory. Carsten - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: How to pass {ID} into protected, mounted sitemap?
Stan Dyck wrote:
I've got an authenticating pipeline something like this:
map:match pattern=*
map:act type=auth-protect
map:parameter name=handler value=myhandler/
map:match pattern=protected
map:generate src=resource1.xml/
map:transform src=resource2html.xsl
map:parameter name=uid value={ID}/
/map:transform
map:serialize/
/map:match
map:match pattern=subdir/**
map:mount uri-prefix=subdir check-reload=yes
src=subdir/sitemap.xmap/
/map:match
/map:act
/map:match
The idea is to protect a resource in a root directory and all the
resources in a mounted subdirectory. This works fine except for one
thing. If the sitemap in the subdir directory has something like this:
map:match pattern=subprotect
map:generate src=subresource.xml/
map:transform src=subresource2html.xsl
map:parameter name=uid value={ID}/
/map:transform
map:serialize/
/map:match
I can't get the uid parameter to inject the login id into the
subresource2html.xsl stylesheet. Can someone help me out with this? What
do I need to do to pass the user id into a protected, mounted sitemap?
The {ID} is only available within the auth-protect action in the
sitemap. The easiest way for you is to just repeat the action inside
your subsitemap to make the {ID} available:
map:match pattern=subprotect
map:act type=auth-protect
map:parameter name=handler value=myhandler/
map:generate src=subresource.xml/
map:transform src=subresource2html.xsl
map:parameter name=uid value={ID}/
/map:transform
map:serialize/
/map:act
/map:match
HTH
Carsten
--
Carsten Ziegeler - Chief Architect
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Cocoon 2.2, portal and cauth problem
I haven't tested the portal block for a long time. In the meantime we changed several things in the core regarding configuration. So it could be that the current portal sample needs some updates before it works again. I'm currently working on the hsqldb block and hope to get it finished tonight. Next would be the OJB block, followed by the portal block. So I hope everything will work again very soon. Carsten Jean-Christophe Kermagoret wrote: Hi, I don't want DB auth, so I comment in cocoon-portal-sample/src/main/resources/COB-INF/config/avalon/auth-cauth.conf the part about DBSecurityHandler and uncomment the one with PipelineSecurityHandler. But even if I change the file (and remove the target directory in cocoon-portal-sample and cocoon-webapp with 'mvn -o clean' in each directory), I finally have the original file with DBSecurityHandler in my cocoon-webapp when I try 'mvn -o install jetty:run' in my webapp directory !!! What's wrong ? Thanks for the help -- Carsten Ziegeler - Chief Architect http://www.s-und-n.de http://www.osoco.org/weblogs/rael/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Which one to use Cocoon 2.1 or 2.2?
Personally I've found 2.2 works just fine already, as long as you're not concerned about API/configuration stability. There will be a new milestone release of 2.2 very soon; we are very confident that this one is the last milestone release before a final 2.2 release which means that there should be no API changes anymore (or only minor ones). At least that's our hope :) Carsten -- Carsten Ziegeler - Chief Architect http://www.s-und-n.de http://www.osoco.org/weblogs/rael/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: The authentication resource - auth and authentication-fw
Alessandro Vincelli wrote: Hy, I'm writing my authentication method for new webapp. From 2.1.10 the authentication-fw is deprecated see the release notes: ... Deprecate session-fw and authentication-fw block. These blocks will be removed in further releases. Committed by CZ. ... I'm reading in cocoon documentation how build authentication at http://cocoon.apache.org/2.1/developing/webapps/authentication/authenticating_user.html and I writing a class that implements the /Authenticator/ interface. But in 2.1.10 the /Authenticator/ interface is also depreacted ;-) Now, I see the new package org.apache.cocoon.auth and relatives interfaces, and I found some api references, but no documentications and samples. In shortly how work org.apache.cocoon.auth? This package org.apache.cocoon.auth work similar to org.apache.cocoon.webapps.authentication? Any samples? We deprecated the session-fw and authentication-fw because today there are better ways of doing the same stuff. But although these blocks are deprecated, they will be supported for a long time. So it's safe to use them :) The authentication-fw will be replaced by the auth stuff you mention above. There is currently not that much documentation (apart from the javadocs), but you can have a look at http://osoco.sourceforge.net/cowarp/) The CoWarp framework has been donated to Cocoon and that's the base of the auth block. Both authentication-fw and c-auth work very similar with the difference that c-auth is pojo based while the authentication-fw uses pipelines (we added the authenticator interface later on, but that's more a workaround). You can find a sample for c-auth in the portal block. HTH Carsten -- Carsten Ziegeler - Chief Architect http://www.s-und-n.de http://www.osoco.org/weblogs/rael/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[ANN] Apache Cocoon 2.1.10 Released
Apache Cocoon 2.1.10 Released - The Apache Cocoon Community is proud to announce the new release of Apache Cocoon. Apache Cocoon is a web development framework built around the concept of separation of concerns (that is: allowing people to do their job without having to step on each other toes) and component-oriented web RAD. The latest version is downloadable from http://cocoon.apache.org/mirror.cgi (Please use the mirrors to download the release - it might take a little bit more time until the latest release is available on all mirrors, so give the mirrors some time - approx. 24h to update.) This release includes many bug fixes and smaller enhancements. For more information about Apache Cocoon 2.1.10, please go to http://cocoon.apache.org. You'll find the whole list of changes at http://cocoon.apache.org/2.1/changes.html. The Apache Cocoon Project -- Carsten Ziegeler - Chief Architect http://www.s-und-n.de http://www.osoco.org/weblogs/rael/ Changes with Apache Cocoon 2.1.10 *) Core: Allow dynamic loading of JavaScript objects even when scope is locked. [JH] *) CForms: Always set viewData for flow script functions (if it's not available set it to null). [CZ] *) Javaflow OJB Sample: Fix No method 'showEmployee' found. [CZ] *) The JavaFlow OJB sample overwrote the first entry on insert instead of adding a new entry. This has been fixed. [CZ] *) Core: Removed the buggy WildhardHelper. Use the new improved WildcardMatcherHelper. [CZ] *) Profiler block: Add statistics component. [CZ] *) Databases block: Add support for iBatis to use configured Excalibur data sources in iBatis. [CZ] *) CForms: The filterfield widget was not defined for the forms manager. [AS] *) CForms: Numeric based suggestion list should initialzate to the corresponding suggested text. [AG] *) Updated Rhino (Javascript engine) to version 1.6R5. This version is licensed under MPL, while previous versions were licensed under NPL, which was a problem since software licensed under NPL cannot be included in Apache products. The new version should be compatible with the previous version, though it does not support the constructs catch (continue|break|return) which were available in Cocoon's Rhino fork. [BRD] *) Updated xercesImpl to 2.9.0 and xml-apis to 1.3.04. [AG] *) Ajax: upload progress bar widget. A new dojo widget to display file upload progress for forms (and cforms). Ajax-enabled cforms can now submit file-upload fields in the background. New system pipelines for Blocks (/_cocoon/system/[blockname]/**). Sitemaps can now call flowscripts written in a static namespaced style. Added JSON Serialization utilities for flowscript. You can now get i18n translations from Stings in flowscript. [JQ] *) Core: Add ability to pre-load i18n catalogues in I18nTransformer. Removed references to defunct cache-on-startup configuration. [VG] *) CForms: Added @whitespace attribute to fd:field widget, to control how leading and trailing whitespace characters are handled when reading submitted values. Accepted values are: trim (default), trim-start, trim-end, and preserve. [JJ] *) Mail: Improve MailSender interface: added setBody(Object), setBodyURL methods, deprecated setCharset, setBody(String), setBodyFromSrc, setBodyFromSrcMimeType methods. Support byte[], InputStream as body and attachment objects. [VG] *) Mail: Log exceptions from mail attachments - JavaMail does not preserve cause exception. [VG] *) Lucene: Add analyzer parameter to SearchGenerator as stated by the docs. [JH] *) Databases: Added support for the SQL:XML tag in SQLTransformer. [AG] *) Validation: Replaced references to constant declarations in javax.xml.XMLConstants, which are not in the official API. [JH] *) CForms: Tree widget not handling on-selection-change events correctly. [AG] *) XSP: SOAPHelper does no longer accept only replies with an XML declaration. [JH] *) Updated commons-lang to 2.2 and bsf to 2.4.0. [AG] *) CForms: Add a name attribute to a booleanfield in output mode to make it easily accessible in JavaScript. [JH] *) CForms: BeanConvertor uses a WeakHashMap in the wrong way. [AG] *) AJAX: Fix cocoon suggest sample. [AG] *) Deprecate method org.apache.cocoon.components.flow.FlowHelper.unwrap(Object). This method will be removed in 2.2 release. Use org.apache.cocoon.components.flow.util.PipelineUtil.unwrap(Object) instead. [AG] *) XSP: Use namespace-uri and not the namespace-prefix to select parameters in logicsheet-util.xsl. [JH] *) Databases: Check for null LOBs. [VG] *) JXTemplate: Fix an ArrrayIndexOutOfBoundsException with jx:comment. [JH] *) Apply patch to handle malformed recipient address exception correctly. [AS] *) CForms: Apply patch to disambiguate toSAX method call. [VG] *) Core: Move BackgroundEnvironment from Cron block into the Core. [VG] *) Core: i18n transformer was loosing whitespaces in i18n:text, i18n:translate, i18n:param
Looking for help in upcoming release
Hi community, the Cocoon project is working very hard to release 2.1.10 by Monday, December 18th. To meet this goal -- which clearly will benefit all users -- we need some *specific* QA (quality assurance) input from the user community. While we believe that the current development version of 2.1.10 is stable, we would like to prove this by our users. To help, here's what you need to do: 1. Update your local subversion repository to the *latest* 2.1.10 branch version from subversion. (http://svn.apache.org/repos/asf/cocoon/branches/BRANCH_2_1-X) 2. ./build.[sh|bat] clean 3. ./build.[sh\bat] 4. Assure that you use the same JDK for running Cocoon that you also used for building and start Cocoon by ./cocoon.[sh|bat] 5. Test *all* samples. Hit each and every sample page from links beginning at http://localhost:/samples/ 6. Report back on the Cocoon dev list on your findings, good or bad. 7. Make sure you describe your test environment: Platform and JVM, including version numbers. 8. If you find problems, be specific about the problem description: what page, what error, etc. 9. If you can provide a patch/info to fix the problem, even better. You can also test your Cocoon 2.1.9 applications with the latest version to check if everything is still working fine. What we do *not* need: Please do not submit requests for XYZ features, dreams, etc. Please save these ideas for future versions. Of course, you are welcome to start an own thread for this on the dev list as well. Thanks. The Cocoon Team Carsten -- Carsten Ziegeler - Chief Architect http://www.s-und-n.de http://www.osoco.org/weblogs/rael/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Looking for help in upcoming release
Florian wrote: Sorry, was too dumb to send an eMail only to one person... :) No problem Ok, here's the translation 'cause it could be interesting for other people, too: - The URL is correct: http://svn.apache.org/repos/asf/cocoon/branches/BRANCH_2_1_X Yepp, thanks - see, I'm too dumb to copy/paste a url :( - Which is the SVN-address/-Command to checkout the new baby? A simple svn co http://svn.apache.org/repos/asf/cocoon/branches/BRANCH_2_1_X; does the work Carsten -- Carsten Ziegeler - Chief Architect http://www.s-und-n.de http://www.osoco.org/weblogs/rael/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Looking for help in upcoming release
Joseph Toman wrote: I tried checking out this branch but I met with the following error: svn: REPORT request failed on '/repos/asf/!svn/vcc/default' svn: The REPORT request returned invalid XML in the response: XML parse error at line 48309: no element found (/repos/asf/!svn/vcc/default) I am using subversion 1.2.3 on a SUSE 10.0 system . A cursory googling found references to this problem on other mailing lists, but no definitive solution or diagnosis was mentioned. FYI. I have no real solution for this problem, but did you try it again? From time to time I get those errors when it is required to checkout a lot. So retrying with an svn up . inside the main directory until it succeeds usually solves the problem for me. Carsten -- Carsten Ziegeler - Chief Architect http://www.s-und-n.de http://www.osoco.org/weblogs/rael/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: environment abstraction in Cocoon 2.2
Joerg Heinicke schrieb: 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 ?) Yes, we still use the environment abstraction - mainly for compatibility. We had some discussion in the past to switch to the servlet req/response interfaces etc. While this is the right move, it creates big incompatibilities. So we either have to support two apis in parallel or wait until 3.0. There are several problems with our abstraction; one of them is that we use our own apis (we can create wrappers for this to directly use the http servlet api) - but the other problem is that we are not using the request attributes to store additional request information. Unfortunately everything is stored in the objectModel map, e.g. the flow context etc. And even more: the request is an object stored in the objectModel. I think we have to change this as well and add all request relevant information as attributes of the request object. This would then allow to easily use other techniques/frameworks - like you could then just forward your request from Cocoon flow to a JSP doing the rendering. But just adding all this stuff to request attributes is not that easy as unfortunately sub request are sharing the attributes with the main request. So whenever you use the cocoon protocol the main request and the sub request use the same set of attributes. I hoped to solve these problems for 2.2 but I never had a good idea - but it's something we should definitly work on for the next releases. Carsten -- Carsten Ziegeler - Open Source Group, SN AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: portal question - custom classloaders
Filip Defoort wrote: Hi, I'm working with the cocoon portal, and I'm starting cocoon via a custom classloader ( classloader class=... / in cocoon.xconf ) to make a number of dynamically assembled classes and a back-end service available to cocoon. So far so good, all works. My app starts; cocoon starts after that, and the portal works. The problem I have is that I need to make my portlets (JSR-168 based; implementation in classes loaded by my custom classloader) available to the cocoon portal. I've put them in cocoon/WEB-INF/portlet.xml, but nothing happens. It seems that I also need to put them as separate servlets in cocoon/WEB-INF/web.xml, but if I do that, they're using the regular classloader, which doesn't have the implementation and I'm getting NPE's (and looking at the sources, it's on the class resolution). I've tried to have the classloader that starts the cocoon webapp be swapped out by my custom classloader, but that seems to create all kinds of conflicts when starting cocoon. Anybody any ideas on how to accomplish this ? I guess it's not easy to do :) Now, putting your jsr-168 based portals into the cocoon webapp is a proprietary way and not standard conform. Usually, you should put your portlets into an own webapp (which has an own classloader). So perhaps this might help you. In the case, that you need/want to run those portlets in the cocoon webapp, you could try to create a wrapper for the portlet servlets. The Cocoon portal uses Pluto and Pluto requires a servlet for the deployed portlets; so you could write a wrapper for this servlet which gets the classloader from Cocoon and uses this classloader. You could share the classloader between the portlets by putting it into the servlet context. I'm not sure if this really works, but it sounds doable. HTH Carsten -- Carsten Ziegeler - Open Source Group, SN AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Portal] How to integrate PDF producing pipeline?
[EMAIL PROTECTED] schrieb: Hello @all, sorry for repeating the question, but I still can't get it working. I have a cocoon application which I added to portal. HTML-links were transformed to portal events. One of the links calls the pipeline which produces a PDF file. Everything works fine outside of the portal. If I click the link in the portal, an empty page is displayed. I've attached both logs. Please could someone help me or point me to some docs?! Mark the link for the pdf with external='true' and perhaps with a target, like: a href=yourpdfpipeline target=_blank external=truePDF/a If you specify a link with external=true, the link is not rewritten by the portal. Carsten -- Carsten Ziegeler - Open Source Group, SN AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Portal] VerifyError with portal on cocon trunk 2.2
Jean-Christophe Kermagoret wrote: Hi, I have the following error in portal sample with cocoon trunk (2.2) : I installed all the portal related packages, then deployed and run in non OSGi mode. Did I forget something ? Did you try a mvn clean install? You only need to clean the whole portal block with all sub projects and then just reinvoke the cocoon deploy plugin. HTH Carsten -- Carsten Ziegeler - Open Source Group, SN AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Cocoon Portal / Roles
Wadim Kruse wrote: Hi, I have the same issue, as in: http://marc.theaimsgroup.com/?l=xml-cocoon-usersm=115319517009528w=2 Does the role based view work in the new portal block ? (Cocoon 2.1.10-dev, OS: Ubuntu 6.06, Java: 1.5.0_06 ) If so, how ? If I define copletdata, copletinstancedata and layout per user, it works. The role based approach should work :) However, the approach might be a little different than you expect: *if* the user has an own profil this one is used and *only if* the user does not have an own profil, the profil of the user's role is used (and if that one is not present, the global one is used). So there is no merging between profiles yet. HTH Carsten -- Carsten Ziegeler - Open Source Group, SN AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [GT2006] Update! Cocoon GetTogether 2006 (Oct 2-4,Amsterdam)
Andrew Savory wrote: Sounds like a good option. I'm wondering if there'd be any interest in a business-oriented track, in a separate room. Not sure if that's to protect the geeks from the suits, or the suits from the geeks ... ;-) :) I think we should definitly have some kind of a business track; don't know if the number of possible attendees is enough to have two tracks or if it could be just one track with tech stuff and business things. Carsten -- Carsten Ziegeler - Open Source Group, SN AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Cocoon 2.1.x v WebObjects 5.x
Marc Driftmeyer wrote: To clarify seeing as I used to support WOF at NeXT and Apple. WebObjects lost its elegance when it switched from Objective-C to Java. Definitly, yes. With Leopard I'd expect some major changes with WebObjects. I know several people who are involved and they are more than skilled to bring it up to speed, where it once lead the industry. Sounds interesting, so this means WO is still developed? Carsten -- Carsten Ziegeler - Open Source Group, SN AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Cocoon 2.1.x v WebObjects 5.x
Gavin Carothers schrieb: Yes, oddly enough I have used both. ... now... compare them... WebObjects: hasn't been updated in 4 years or so, and has anemic XML support, but has excellent tools for doing MVC style applications. There is honestly nothing like Direct To Web and the rules framework in any modern web application framework java or otherwise. Rails pretends to be able to do what DTW does, Zope likely can do most of what Direct To Web can but the learning curve there is... cliff like. Also, EO while nice and reasonably easy to get started with isn't nearly as flexible as hibernate or OJB. WebObjects, even in 5.X, still shows a great deal of it's Objective-C roots. NSXML!? Come on, this is 2006. Cocoon: has been updated, is open source. Lives breaths and churns XML. However no direct integration with any model framework. Flowscript or Javaflow is a dramatic departure from the widget and page based model that webobjects and most older web frameworks use. As mentioned before, there isn't anything like Direct To Web. The template block acts something like .wo's do, but since all of the flow, URI space and bizlogic is _really_ separated in cocoon there isn't a good way to compare how they both work. In short Cocoon is modern, and doesn't have much in the way of tools and WebObjects is honestly ancient but has some awesome tools (So long as your running Mac OS X and don't mind XCode for Java... unless wo-lips has gotten a great deal better). If you want more, feel free to follow up off list as I'm not sure how much use this is to the rest of the community. I worked several years with WebObjects before I was forced to use Cocoon (by switching my employee) :) I think the comparison above summarizes it very good. I personally still think that WO is one of the best web frameworks, but if it isn't really maintained I would rather not use it. The tools are great, Objective-C is imho a far better language than Java and EOF and DTW are fantastic. But the learning curve imho is even higher than learning Cocoon as there are so many classes and libs. The way of modelling the flow through your application is imho nicer as in Cocoon with FlowScript. Carsten -- Carsten Ziegeler - Open Source Group, SN AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: portal and forms - no script / styling
Hi, the head section of the html page is created by the portal, so basically all head sections of the portlets (your cforms app) are ignored and not added to the output page. So, the easiest way is to add the head section to the portal-page.xsl of the portal, so the portal loads all required resources for your portlets. If you do this you might have to add some matchers to the sitemap of your portal for these resources. HTH Carsten christian bindeballe wrote: Hi there, since there has been no answer yet, maybe some more details would help you help me. I looked into the xsl-scripts for forms for quite a while now and I compared the output of the forms page outside the portal with the output of the same forms page when inside the portal. it looks as if the URIs to all the xsl are properly resolved, as some elements in the included stylesheets are put in the data that is sent. what is not included, are these references: script src=resources/ajax/cocoon.js type=text/javascript/ script src=resources/forms/js/forms-lib.js type=text/javascript/ script type=text/javascript dojo.addOnLoad(forms_onload); dojo.require(cocoon.forms.*); /script link rel=stylesheet type=text/css href=resources/forms/css/forms.css/ script src=resources/forms/mattkruse-lib/AnchorPosition.js type=text/javascript/ script src=resources/forms/mattkruse-lib/PopupWindow.js type=text/javascript/ script src=resources/forms/mattkruse-lib/OptionTransfer.js type=text/javascript/ script src=resources/forms/mattkruse-lib/selectbox.js type=text/javascript/ script src=resources/forms/mattkruse-lib/CalendarPopup.js type=text/javascript/ script src=resources/forms/mattkruse-lib/date.js type=text/javascript/ script type=text/javascript // Setup calendar var forms_calendar = CalendarPopup(); forms_calendar.setWeekStartDay(1); forms_calendar.showYearNavigation(); forms_calendar.showYearNavigationInput(); forms_calendar.setCssPrefix(forms_); /script link rel=stylesheet type=text/css href=resources/forms/css/forms-calendar.css/ script type=text/javascript _editor_url = resources/forms/htmlarea/; _editor_lang = en; /script script type=text/javascript src=resources/forms/htmlarea/htmlarea.js/ I stripped the output of some namespace declarations, it is just to show, what elements I mean. these are in template-matchers that have the mode set to forms-field. obviously, none of these templates are called or matched, although in the forms-styling.xsl they are referenced: xsl:template match=head head xsl:apply-templates select=. mode=forms-page/ xsl:apply-templates select=. mode=forms-field/ xsl:apply-templates/ /head /xsl:template xsl:template match=body body !--+ !!! If template with mode 'forms-page' adds text or elements |template with mode 'forms-field' can no longer add attributes!!! +-- xsl:apply-templates select=. mode=forms-page/ xsl:apply-templates select=. mode=forms-field/ xsl:apply-templates/ /body /xsl:template I don't know if the comment that is in the second template also applies to the head-template, but still I am confused, why, when I call the URI to my forms outside the portal, they all are properly styled and the JavaScript is included, and when I call them inside a coplet, the forms have no styling and no JavaScript is included. I hope, I am not the only one with this kind of problem and that someone can help me out here. thanks in advance, christian - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Carsten Ziegeler - Open Source Group, SN AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: portal and forms - no script / styling
christian bindeballe wrote:
Hi, Carsten,
that was a very good hint, indeed it made it work as to styling :) thank
you very much for taking the time to look into it.
now, the only thing is, when I have entered data into the form, after
submitting, I get the message the coplet spmt-1 is currently not
available. how, or where can I find out, what caused this error? there
is nothing in the cocoon.log or portal.log that matches the time the
error occurred. could it have to do with wrapping continuations in an
action like this one?
map:match pattern=*.continue
map:act type=auth-loggedIn !-- check authentication --
map:parameter name=handler value=managehandler/
map:act type=auth-protect !-- give access to the context --
map:parameter name=handler value=managehandler/
map:call continuation={1}/
/map:act
/map:act
map:redirect-to uri=login/
/map:match
Ah, yes, this is wrong :) With {1} you refer to values provided directly
by the surrounding action. If you want to refer to the value of the
matcher, you have to use {../../1}. Or you can use named nodes:
map:match pattern=*.continue name=contmatch
...
map:call continuation={#contmatch:1}/
(I'm writing this just using my memory, so there might be a mistake/typo
in it).
I would prefer using named nodes as this is independent of the structure
of your pipeline. It still works if you add/remove some actions inbetween.
By the way, is the caching URI coplet the right way to go for using
CForms in the portal, or should I switch to an application-coplet?
The caching URI is the right coplet to use. The difference between those two
is basically if the app you're integrating is local or remote, so for
local ones you use caching uri while you use application-coplet for
remote ones.
Carsten
--
Carsten Ziegeler - Open Source Group, SN AG
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[ANN] Apache Cocoon 2.1.9 Released
Apache Cocoon 2.1.9 Released The Apache Cocoon Community is proud to announce the new release of Apache Cocoon. Apache Cocoon is a web development framework built around the concept of separation of concerns (that is: allowing people to do their job without having to step on each other toes) and component-oriented web RAD. The latest version is downloadable from http://cocoon.apache.org/mirror.cgi (Please use the mirrors to download the release - it might take a little bit more time until the latest release is available on all mirrors, so give the mirrors some time - approx. 24h to update.) This release includes many bug fixes and smaller enhancements. For more information about Apache Cocoon 2.1.9, please go to http://cocoon.apache.org. You'll find the whole list of changes at http://cocoon.apache.org/2.1/changes.html. The Apache Cocoon Project -- Carsten Ziegeler - Open Source Group, SN AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Cocoon Portal and browser back button problems
philguillard wrote: Hi Angelo, I had this trouble too. But i didn't solve it definitely. My opinion : - portal is not 100% ready for internet web site production because of this, since 99% of internet users use intensively using back and refresh buttons! (if you really insist on back and mostly refresh buttons i bet you'll find an exception quickly) - It seems all the concept of events cause problem since the browser back button is not informing portal we want event no 4 on the last page we had, and thinks we need the event no 4 on the actual page. - But this is open source, so up to us to arrange this problem, but i didn't feel competent for this. It's correct that using the event id in the urls is actually one of the worst parts of the portal which definitly needs some more work. The version in the current development branch for 2.2 is far better in this aspect as it only creates event ids in some rare cases by default. In additions each page uses it's own number range for the ids. This, in combination to expire the portal page and forcing the browser to reload the page when using the back button should solve all these issues. I think the expiring/reloading mechanism should be used in a portal anyway; otherwise you'll end up with inconsistent state very soon. Imagine a user removing a portlet and then hitting the back button. Unfortunately, 2.2 is under going currently some heavy changes in the build system, so you are even not able to have a look at the new version :( Btw, the portal can and is used in several production sites without problems :) Carsten -- Carsten Ziegeler - Open Source Group, SN AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[ANN] Apache Cocoon 2.1.8 Released
Apache Cocoon 2.1.8 Released The Apache Cocoon Community is proud to announce the new release of Apache Cocoon. Apache Cocoon is a web development framework built around the concept of separation of concerns (that is: allowing people to do their job without having to step on each other toes) and component-oriented web RAD. The latest version is downloadable from http://cocoon.apache.org/mirror.cgi (Please use the mirrors to download the release - it might take a little bit more time until the latest release is available on all mirrors, so give the mirrors some time - approx. 24h to update.) This release includes many bug fixes and smaller enhancements. Most notable additions are: * Many enhancements to the forms block including AJAX support for partial updates to a form, a new tree widget, some experimental code for reusable form libraries (coded as a part of the Google Summer of Code project) and a sample showing how to create forms using relational databases with zero java code. * Cocoon Stack Traces: Ever felt overwhelmed when presented with a huge java stack trace when something goes wrong in Cocoon? Well, now you will instead see a Cocoon related stack trace, showing you precisely where the error occurred and in which Cocoon source files * Many enhancements to the portal block, including improved caching mechanisms, support for the Web Services For Remote Portlets (WSRP) standard, and provided components for database access using OJB. * Some small simplifications to the build process (can now exclude all blocks, then include just the ones you need) * Substantial reworking of the Cocoon documentation system. Documentation is now managed using Daisy (cocoondev.org/daisy). Because of this, the documentation is now not included within the main Cocoon release, but is available as a separate download as zipped HTML. * A new JCR block allowing access to JCR repositories such as JackRabbit (Java Content Repository specification was designed as a part of JSR170) * A new validation block providing the ability to validate XML in a pipeline chosing from a range of schema languages (DTD, XSD, RNG) * The ability to use Cocoon pipelines to render JSF pages (using the JSF controller) For more information about Apache Cocoon 2.1.8, please go to http://cocoon.apache.org. You'll find the whole list of changes at http://cocoon.apache.org/2.1/changes.html. The Apache Cocoon Project -- Carsten Ziegeler - Open Source Group, SN AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Is the cocoon portal redirection mandatory ?
Jean-Christophe Kermagoret wrote: I think I solve partly my problem. To tell Tomcat not to use cookies, I just put a cookies attribute to false in my context definition : Context docBase=/home/jck/Project/repons/core/web path=/repons cookies=false I still have my portal redirection problem Any ideas ? It's hard to tell without seeing your sitemap :) Now, I guess, you have a redirect-to url=SOMETHING/ somewhere in the case if the user is not logged in. Try replacing it with redirect-to url=cocoon:/SOMETHING/. HTH Carsten -- Carsten Ziegeler - Open Source Group, SN AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Where is the frame.xsl for the cocoon portal ?
Jean-Christophe Kermagoret wrote: Hi, I've seen there is a frame renderer in the portal. Does it permit to build frameset where each frame corresponds to a coplet ? No :) It's just a place holder for something - if you use a frame layout in the portal you can specify a uri which is than included at this place. For example, this can be used to include a static header or footer or something like that. There is no configured xsl for this renderer. HTH Carsten -- Carsten Ziegeler - Open Source Group, SN AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Where is the frame.xsl for the cocoon portal ?
Jean-Christophe Kermagoret wrote: Waohh Thanks for this quick reply :-) I'm interested to try this layout to compare the costs between (one coplet update) and (one coplet update + reload of the rest of the portal). Do you think it's worth the case ? Do you know if somebody already worked on this ? The idea is to build a AJAX layout to minimize reloading if it permits to spare cpu cycles and networkbandwith WDYT ? Have a look at the portal in Cocoon trunk :) Especially at the Gallery demo - for minimizing/maximizing and some updates of coplets, the refresh is done using ajax and only the affected coplet is transfered from the server to the client. The work is not finished yet which means there are still cases where Ajax is not used but could be used. But in general I think it's worth to think about this. Carsten -- Carsten Ziegeler - Open Source Group, SN AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Where is the frame.xsl for the cocoon portal ?
Jean-Christophe Kermagoret wrote: It sounds very interesting I'm using 2.1.8-dev, are the modifications related to AJAX are compatible with the 2.1.8 version ? No, unfortunately not - I had to restructure/refactor some parts of the portal to get things working. Therefore the portal changed in several parts, but most of your portal developed with 2.1.x should work with 2.2 - the xml is still the same and so on. Currently, there is no documentation about the changes... Carsten -- Carsten Ziegeler - Open Source Group, SN AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Increasing Cocoon Portal speed at stat-up
Angelo Immediata schrieb: Hi. My site is a service oriented portal; i have several application developed by using cocoon and integrated under the cocoon-portal block. Every application is a page (a named-item in the portal-user-anonymous.xml). Moreover i have a double navigator. I attach to this mail all my profiles directory in order you can see the structure (it's a .rar file, you need winrar in order to decompress it). Your profiles are really hugh. Are you using some filtering? Or does each and every user gets all coplets? My question, now, is... why to convert layout into object and not to use SAX in order to read the xml files?. Once you have the objects, streaming them as sax events is the fastest possible approach. No XML parsing etc. anymore. As you need the objects for each request from a user, you can see the objects as an in-memory cache of the XML (though it's actually much more). Carsten -- Carsten Ziegeler - Open Source Group, SN AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Increasing Cocoon Portal speed at stat-up
Ralph Goers wrote: Carsten actually mentioned something like this to me at the GetTogether. I suspect that this is due to using castor to convert your layout into objects. This happens each time a user logs in. With such a large site I could imagine that that could be a problem. This currently cannot be avoided, but with some more details about how your site is laid out I'm sure we could come with a solution. I would recommend opening a defect in jira (when it is available). If you also want to discuss this on the dev list that would be ok too. Cocoon 2.1.8(dev) uses a slightly improved version for the Castor part, so this should be a little bit faster. But as Ralph noted it would be good to have some more information about your site to see what's going wrong. Carsten -- Carsten Ziegeler - Open Source Group, SN AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Log4j - logging request uri
Jorg Heymans wrote: Leszek Gawron wrote: That's useful! And should be wikified IMO :) Can I implement a OpenSessionInView pattern with this? I remember you asking this before on dev@, when Carsten announced this interface. I don't think he ever answered actually, ehrm Carsten ? Not sure... :) Can you please repost the question? Carsten -- Carsten Ziegeler - Open Source Group, SN AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
