Re: svn commit: r629374 - /cocoon/trunk/core/cocoon-core/src/main/java/org/apache/cocoon/xml/StringXMLizable.java
On 20.02.2008 01:42, [EMAIL PROTECTED] wrote:
Author: antonio
Date: Tue Feb 19 22:42:45 2008
New Revision: 629374
URL: http://svn.apache.org/viewvc?rev=629374&view=rev
Log:
Faster implementation.
Saw this one only now ... I'm a bit concerned about the approach.
First, do you really think this implementation is significantly faster?
Your implementation only "caches" the parser instance, you replace the
instantiation with ThreadLocal handling. Parsing itself should still be
the slowest part. How many Strings do you convert to SAX per thread?
Second, who cleans up the thread before it goes back to the thread pool?
At the end is it really worth the "ugly" implementation?
IMO it's a much better approach to make it a "real" Cocoon component
(Serializeable) instead and look up the SAXParser.
Joerg
Modified:
cocoon/trunk/core/cocoon-core/src/main/java/org/apache/cocoon/xml/StringXMLizable.java
Modified:
cocoon/trunk/core/cocoon-core/src/main/java/org/apache/cocoon/xml/StringXMLizable.java
URL:
http://svn.apache.org/viewvc/cocoon/trunk/core/cocoon-core/src/main/java/org/apache/cocoon/xml/StringXMLizable.java?rev=629374&r1=629373&r2=629374&view=diff
==
---
cocoon/trunk/core/cocoon-core/src/main/java/org/apache/cocoon/xml/StringXMLizable.java
(original)
+++
cocoon/trunk/core/cocoon-core/src/main/java/org/apache/cocoon/xml/StringXMLizable.java
Tue Feb 19 22:42:45 2008
@@ -5,9 +5,9 @@
* The ASF licenses this file to You under the Apache License, Version 2.0
* (the "License"); you may not use this file except in compliance with
* the License. You may obtain a copy of the License at
- *
+ *
* http://www.apache.org/licenses/LICENSE-2.0
- *
+ *
* Unless required by applicable law or agreed to in writing, software
* distributed under the License is distributed on an "AS IS" BASIS,
* WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
@@ -29,25 +29,40 @@
/**
* XMLizable a String
- *
+ *
* @since 2.1.7
*/
public class StringXMLizable implements XMLizable {
+private static class Context {
+SAXParser parser;
+Context() throws SAXException {
+SAXParserFactory parserFactory = SAXParserFactory.newInstance();
+parserFactory.setNamespaceAware(true);
+parser = null;
+try {
+parser = parserFactory.newSAXParser();
+} catch (ParserConfigurationException e) {
+throw new SAXException("Error creating SAX parser.", e);
+}
+}
+}
+
+private static final ThreadLocal context = new ThreadLocal();
private String data;
-public StringXMLizable(String data) {
+public StringXMLizable(final String data) {
this.data = data;
}
-public void toSAX(ContentHandler contentHandler) throws SAXException {
-SAXParserFactory parserFactory = SAXParserFactory.newInstance();
-parserFactory.setNamespaceAware(true);
-SAXParser parser = null;
-try {
-parser = parserFactory.newSAXParser();
-} catch (ParserConfigurationException e) {
-throw new SAXException("Error creating SAX parser.", e);
+private Context getContext() throws SAXException {
+if (context.get() == null) {
+context.set(new Context());
}
+return (Context) context.get();
+}
+
+public void toSAX(ContentHandler contentHandler) throws SAXException {
+final SAXParser parser = getContext().parser;
parser.getXMLReader().setContentHandler(contentHandler);
InputSource is = new InputSource(new StringReader(data));
try {
Re: [jira] Created: (COCOON-2189) Dojo drag and drop reordering does not work
On 3/29/08, Hugh Sparks (JIRA) <[EMAIL PROTECTED]> wrote: > Dojo drag and drop reordering does not work > --- > > Key: COCOON-2189 > URL: https://issues.apache.org/jira/browse/COCOON-2189 > Project: Cocoon > Issue Type: Bug > Components: Blocks: Forms > Affects Versions: 2.2-dev (Current SVN) > Reporter: Hugh Sparks > Priority: Minor > > > On the "CForms block samples" page in the "Advanced Ajax samples using Dojo > widgets" > section, the drag and and drop reordering examples do not work. > > When a field is moved using drag and drop, this error is reported: > > DEBUG: [Error: Unspecified error.] when calling > onMouseMove$joinpoint$method on [object Object] with arguments [object > Object] > FATAL exception raised: Unspecified error. > > > > > -- > This message is automatically generated by JIRA. > - > You can reply to this email to add a comment to the issue online. > > -- Sent from Gmail for mobile | mobile.google.com Bye, hepabolu
Re: Meeting in Amsterdam
On Mar 29, 2008, at 21:04, Bertrand Delacretaz wrote: On Fri, Mar 28, 2008 at 12:08 PM, Torsten Curdt <[EMAIL PROTECTED]> wrote: Bertrand Delacretaz wrote: how about having dinner together somewhere on Monday night? ...keep in mind there is also the BarCamp on Monday night Right, forgot about that. I don't have precise info but it's planned at the end of the Hackathon day on Monday, time and place will be announced on site I guess. See Message-ID: <[EMAIL PROTECTED]> on [EMAIL PROTECTED] for more info. I suggest meeting at that BarCode event then, and we can still have dinner after if needed. +1 -- Torsten
Re: Meeting in Amsterdam
On Fri, Mar 28, 2008 at 12:08 PM, Torsten Curdt <[EMAIL PROTECTED]> wrote: > > > Bertrand Delacretaz wrote: > >> how about having > >> dinner together somewhere on Monday night? > ...keep in mind there is also the BarCamp on Monday night Right, forgot about that. I don't have precise info but it's planned at the end of the Hackathon day on Monday, time and place will be announced on site I guess. See Message-ID: <[EMAIL PROTECTED]> on [EMAIL PROTECTED] for more info. I suggest meeting at that BarCode event then, and we can still have dinner after if needed. -Bertrand
[jira] Created: (COCOON-2189) Dojo drag and drop reordering does not work
Dojo drag and drop reordering does not work --- Key: COCOON-2189 URL: https://issues.apache.org/jira/browse/COCOON-2189 Project: Cocoon Issue Type: Bug Components: Blocks: Forms Affects Versions: 2.2-dev (Current SVN) Reporter: Hugh Sparks Priority: Minor On the "CForms block samples" page in the "Advanced Ajax samples using Dojo widgets" section, the drag and and drop reordering examples do not work. When a field is moved using drag and drop, this error is reported: DEBUG: [Error: Unspecified error.] when calling onMouseMove$joinpoint$method on [object Object] with arguments [object Object] FATAL exception raised: Unspecified error. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Meeting in Amsterdam
Reinhard Poetz wrote: Is there anybody who is going to attend the ApacheCon in Amsterdam? I'll be there at the two Hackathon days (Mon full day, Tue till 3pm) and would love to have some discussions about Corona. What about a meeting on Monday 2pm at the official Hackathon room? (Though I don't know if this conflicts with other community events Sling/Jackrabbit/Wicket/... Could people involved with these communities clearify?) I'll arrive on tuesday evening and thus will miss the hackaton. But I'll be happy to discuss with those who were there about this interesting subject! Sylvain -- Sylvain Wallez - http://bluxte.net
Re: [GSoC_2008] Project ideas
Grzegorz Kossakowski pisze: Vadim, you forgot about FIXME marks ;) find core/cocoon-servlet-service/cocoon-servlet-service-impl -name "*.java" | xargs grep -E "TODO|FIXME" | wc -l 27 I've been considering participation in GSoC for some time due to my tottering planes for summer. Now I'm pretty sure I'll be able to do some Cocoon-related work again this year. I would like to focus on fixing bugs, implementing lacking features and general polishing SSF. My goals would be: * get rid of most FIXME/TODO marks in SSF code * implement SAX buffering for service calls * fix COCOON-1964: Redirects inside a block called via the servlet protocol fail * fix COCOON-2096: Servlet source's exists() method always returns true * provide samples of SSF usage for both situations: - servlets managed by SSF are pure servlets that have nothing to do with Cocoon itself - servlets are both pure servlets or SitemapServlets For samples I would like to prepare examples how to connect, call servlets. How to make service calls, make use of polymorphism, etc. --- o0o --- Apart from that I have an idea of making Cocoon blocks/servlets distributed and enabling SSF to transparently handle such set up. I think it would be very interesting to have a possibility to deploy different servlets to different physical machines and let them talk to eacher other using HTTP. Actually, current implementation of servlet-to-servlet connections exploits only standard HTTP API so this should be quite easy to implement. That would enable completely new-brand SSF usage patterns like: * setting up load balancer between blocks (servlets) provided there are few machines with the same block deployed * setting up fail-over handling (if one of machines goes down, rest takes the processing) * exceptional scalability: if one of blocks is being used extensively, you can add another machine with this block deployed and make load balancer aware of it * even block (servlets) calls through the Internet! :-) This should be considered as an optional deliverable for my GSoC activity as it would demand lots of discussing, researching and implementing in the end. Nevertheless, if time permits I would like to start experiment with this idea during the summer. WDOT? Argh, I forgot about very important issue: Who is going to be my mentor? Any volunteers on board? :-) -- Grzegorz Kossakowski
Re: [GSoC_2008] Project ideas
Vadim Gritsenko pisze: On Mar 17, 2008, at 11:30 AM, Grzegorz Kossakowski wrote: Reinhard Poetz pisze: My statement was meant to be more general (SSF + Spring migration + Schema support). For an SSF project only, I don't see enough work (I only know about SAX buffering and support for redirects as missing features) ... but maybe I'm wrong here. There is not that much work left in "pure" SSF (cocoon-servlet-service-impl module) but there is still a room for improvement in module containing components integrating SSF and Cocoon (cocoon-servlet-service-components). Mentioned SAX buffer support involves modifications in impl and components modules. I would add to the list of nice-to-have-in-SSF servlet discovery feature based on some conditions (e.g. returning 200 status code as response to certain request path). This way one could discover blocks providing certain services (e.g. skinning). Nothing more comes to my mind right now. $ find cocoon/core/cocoon-servlet-service/cocoon-servlet-service-impl -name "*.java" | xargs grep TODO | wc -l 18 I'm not so sure that this is "not much" :) Vadim, you forgot about FIXME marks ;) find core/cocoon-servlet-service/cocoon-servlet-service-impl -name "*.java" | xargs grep -E "TODO|FIXME" | wc -l 27 I've been considering participation in GSoC for some time due to my tottering planes for summer. Now I'm pretty sure I'll be able to do some Cocoon-related work again this year. I would like to focus on fixing bugs, implementing lacking features and general polishing SSF. My goals would be: * get rid of most FIXME/TODO marks in SSF code * implement SAX buffering for service calls * fix COCOON-1964: Redirects inside a block called via the servlet protocol fail * fix COCOON-2096: Servlet source's exists() method always returns true * provide samples of SSF usage for both situations: - servlets managed by SSF are pure servlets that have nothing to do with Cocoon itself - servlets are both pure servlets or SitemapServlets For samples I would like to prepare examples how to connect, call servlets. How to make service calls, make use of polymorphism, etc. --- o0o --- Apart from that I have an idea of making Cocoon blocks/servlets distributed and enabling SSF to transparently handle such set up. I think it would be very interesting to have a possibility to deploy different servlets to different physical machines and let them talk to eacher other using HTTP. Actually, current implementation of servlet-to-servlet connections exploits only standard HTTP API so this should be quite easy to implement. That would enable completely new-brand SSF usage patterns like: * setting up load balancer between blocks (servlets) provided there are few machines with the same block deployed * setting up fail-over handling (if one of machines goes down, rest takes the processing) * exceptional scalability: if one of blocks is being used extensively, you can add another machine with this block deployed and make load balancer aware of it * even block (servlets) calls through the Internet! :-) This should be considered as an optional deliverable for my GSoC activity as it would demand lots of discussing, researching and implementing in the end. Nevertheless, if time permits I would like to start experiment with this idea during the summer. WDOT? -- Respects, Grzegorz Kossakowski
Re: [GSoC_2008] Project ideas
hey, I've participated in GSoC last year and I'll be happy to help you with whatever problem you encounter. thanks for your dedication! i already noticed that there are great and ambitious activities going on. What about cocoon-linkrewriter block? It's very small but yet very important block that should be migrated to Spring. i'm not sure about including further blocks into my summer activities, but obviously linkrewriter is not that much. Looks good. I would add one more thing: - writing general migration guide from Avalon to Spring that's an awesome idea! i will add it to my application immediately. You could just dump your experiences gained during GSoC and as result there should be one long tutorial discussing different aspects of Avalon -> Spring migration. This is a very desired thing for existing Cocoon users. i already had the idea of filing my experiences blog-shaped, but i don't mind if it's written more impartially to achieve more approval ,-) @Vadim: order changed @Reinhard: documentation added regards, lukas
Re: [GSoC_2008] Project ideas
Lukas Lang pisze: hey everybody, Hi Lukas, i'm the student, who's interested in participating in a GSoC cocoon-project. I've participated in GSoC last year and I'll be happy to help you with whatever problem you encounter. two days ago i had a conversation with Reinhard and as i read on the list, he told me raising CForms from Dojo 0.4 upto Dojo 1.1 as a GSoC project would not be the best way to do so, due to Jeremy's work on this. he pointed out that several blocks and related examples yet don't work in cocoon-2.2 and a great part of cocoon's users would take advantage of porting frequently used, cohesive blocks to version 2.2. migrating the following blocks could be a realistic aim: - cocoon-eventcache - cocoon-jms - cocoon-webdav - cocoon-repository What about cocoon-linkrewriter block? It's very small but yet very important block that should be migrated to Spring. my suggestion would consist of: - creating a test-environment - writing integration tests - replacing avalon by spring - making existing samples work - developing new samples Looks good. I would add one more thing: - writing general migration guide from Avalon to Spring You could just dump your experiences gained during GSoC and as result there should be one long tutorial discussing different aspects of Avalon -> Spring migration. This is a very desired thing for existing Cocoon users. -- Grzegorz Kossakowski
Re: [GSoC_2008] Project ideas
Vadim Gritsenko pisze: I'd change the order a bit. First I'd suggest to make sure (and fix if necessary) existing samples. Once this is done, the block should be released. After that, you could start (as necessary) avalon to spring migration, and development of new samples. +1 for this proposal provided it's not too much work to get Avalon-based samples to work. -- Grzegorz
[jira] Updated: (COCOON-2188) "mvn install -P allblocks" fails
[
https://issues.apache.org/jira/browse/COCOON-2188?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andreas Kuckartz updated COCOON-2188:
-
Component/s: Blocks: Ajax
> "mvn install -P allblocks" fails
>
>
> Key: COCOON-2188
> URL: https://issues.apache.org/jira/browse/COCOON-2188
> Project: Cocoon
> Issue Type: Bug
> Components: - Build System: Maven, Blocks: Ajax
>Affects Versions: 2.2-dev (Current SVN)
>Reporter: Andreas Kuckartz
>Priority: Blocker
> Fix For: 2.2-dev (Current SVN)
>
>
> [INFO] Building Cocoon Ajax Block Implementation
> [INFO]task-segment: [install]
> [INFO]
>
> [INFO] [enforcer:enforce-once {execution: enforce-maven}]
> [INFO] [resources:resources]
> [INFO] Using default encoding to copy filtered resources.
> [INFO] snapshot
> org.apache.cocoon:cocoon-servlet-service-components:1.0.0-RC2-SNAPSHOT:
> checking for updates from apache.snapshots
> Downloading:
> http://people.apache.org/repo/m2-snapshot-repository/org/apache/cocoon/cocoon-servlet-service-components/1.0.0-RC2-SNAPSHOT/cocoon-servlet-service-components-1.0.0-RC2-SNAPSHOT.pom
> Downloading:
> http://people.apache.org/repo/m2-snapshot-repository/org/apache/cocoon/cocoon-servlet-service-components/1.0.0-RC2-SNAPSHOT/cocoon-servlet-service-components-1.0.0-RC2-SNAPSHOT.jar
> [INFO]
>
> [ERROR] BUILD ERROR
> [INFO]
>
> [INFO] Failed to resolve artifact.
> Missing:
> --
> 1) org.apache.cocoon:cocoon-servlet-service-components:jar:1.0.0-RC2-SNAPSHOT
> Try downloading the file manually from the project website.
> Then, install it using the command:
> mvn install:install-file -DgroupId=org.apache.cocoon
> -DartifactId=cocoon-servlet-service-components -Dversion=1.0.0-RC2-SNAPSHOT
> -Dpackaging=jar -Dfile=/path/to/file
> Alternatively, if you host your own repository you can deploy the file
> there:
> mvn deploy:deploy-file -DgroupId=org.apache.cocoon
> -DartifactId=cocoon-servlet-service-components -Dversion=1.0.0-RC2-SNAPSHOT
> -Dpackaging=jar -Dfile=/path/to/file -Durl=[url] -DrepositoryId=[id]
> Path to dependency:
> 1) org.apache.cocoon:cocoon-ajax-impl:jar:1.1.0-SNAPSHOT
> 2)
> org.apache.cocoon:cocoon-servlet-service-components:jar:1.0.0-RC2-SNAPSHOT
> --
> 1 required artifact is missing.
> for artifact:
> org.apache.cocoon:cocoon-ajax-impl:jar:1.1.0-SNAPSHOT
> from the specified remote repositories:
> apache.snapshots (http://people.apache.org/repo/m2-snapshot-repository),
> central (http://repo1.maven.org/maven2)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: Meeting in Amsterdam
Reinhard Poetz pisze: Is there anybody who is going to attend the ApacheCon in Amsterdam? I'll be there at the two Hackathon days (Mon full day, Tue till 3pm) and would love to have some discussions about Corona. What about a meeting on Monday 2pm at the official Hackathon room? (Though I don't know if this conflicts with other community events Sling/Jackrabbit/Wicket/... Could people involved with these communities clearify?) Standard question: Is there any chance to set up some audio/video recording? I would be very, very interested in hearing/watching such a record. -- Grzegorz
[jira] Created: (COCOON-2188) "mvn install -P allblocks" fails
"mvn install -P allblocks" fails
Key: COCOON-2188
URL: https://issues.apache.org/jira/browse/COCOON-2188
Project: Cocoon
Issue Type: Bug
Components: - Build System: Maven
Affects Versions: 2.2-dev (Current SVN)
Reporter: Andreas Kuckartz
Priority: Blocker
Fix For: 2.2-dev (Current SVN)
[INFO] Building Cocoon Ajax Block Implementation
[INFO]task-segment: [install]
[INFO]
[INFO] [enforcer:enforce-once {execution: enforce-maven}]
[INFO] [resources:resources]
[INFO] Using default encoding to copy filtered resources.
[INFO] snapshot
org.apache.cocoon:cocoon-servlet-service-components:1.0.0-RC2-SNAPSHOT:
checking for updates from apache.snapshots
Downloading:
http://people.apache.org/repo/m2-snapshot-repository/org/apache/cocoon/cocoon-servlet-service-components/1.0.0-RC2-SNAPSHOT/cocoon-servlet-service-components-1.0.0-RC2-SNAPSHOT.pom
Downloading:
http://people.apache.org/repo/m2-snapshot-repository/org/apache/cocoon/cocoon-servlet-service-components/1.0.0-RC2-SNAPSHOT/cocoon-servlet-service-components-1.0.0-RC2-SNAPSHOT.jar
[INFO]
[ERROR] BUILD ERROR
[INFO]
[INFO] Failed to resolve artifact.
Missing:
--
1) org.apache.cocoon:cocoon-servlet-service-components:jar:1.0.0-RC2-SNAPSHOT
Try downloading the file manually from the project website.
Then, install it using the command:
mvn install:install-file -DgroupId=org.apache.cocoon
-DartifactId=cocoon-servlet-service-components -Dversion=1.0.0-RC2-SNAPSHOT
-Dpackaging=jar -Dfile=/path/to/file
Alternatively, if you host your own repository you can deploy the file there:
mvn deploy:deploy-file -DgroupId=org.apache.cocoon
-DartifactId=cocoon-servlet-service-components -Dversion=1.0.0-RC2-SNAPSHOT
-Dpackaging=jar -Dfile=/path/to/file -Durl=[url] -DrepositoryId=[id]
Path to dependency:
1) org.apache.cocoon:cocoon-ajax-impl:jar:1.1.0-SNAPSHOT
2)
org.apache.cocoon:cocoon-servlet-service-components:jar:1.0.0-RC2-SNAPSHOT
--
1 required artifact is missing.
for artifact:
org.apache.cocoon:cocoon-ajax-impl:jar:1.1.0-SNAPSHOT
from the specified remote repositories:
apache.snapshots (http://people.apache.org/repo/m2-snapshot-repository),
central (http://repo1.maven.org/maven2)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: [RT] Do we need URL/Source in SSF?
Rice Yeh pisze: Hi, I have a guts feeling that Spring's Resource and ResourcePatternResolver have similar functions as Source and SourceResolver, hence we could just depend on Spring's Resource to achieve the same functionality in SSF. Hi Rice, I guess you didn't get my point from my previous e-mail. SSF does not need *any* resource Source/URL/Resource functionality. It just needs to calculate base URLs for which Spring's functionality probably won't help much. -- Grzegorz
