+1 and welcome!
Joerg
On 28.05.12 10:26, Thorsten Scherler wrote:
He is an ASF committer in Apache Droids and I think he would make a
great addition to our team. He contributes now on a regular base and
lately as well started to dig into many issues that are critical for the
c3 release.
+1
Joerg
On 19.09.2011 23:03, Nathaniel, Alfred wrote:
Hi all,
A few weeks ago we had a discussion [1] whether to increase for Cocoon3 the
minimum Java version from 1.5 to 1.6.
There were a number of advantages identified to be gained by using Java6, which
I don't want to repeat here
You can switch off caching per pipeline. There is a non-caching
pipeline. Please don't ask me for details though - too long ago :-)
Joerg
On 17.02.2011 14:42, Robby Pelssers wrote:
I would like to check out the performance without any caching and check if I
can live with it... if so
On 14.12.2009 09:33, Reinhard Pötz wrote:
On Sun, Dec 13, 2009 at 3:59 PM, Joerg Heinickejoerg.heini...@gmx.de wrote:
A long time ago I argued for renaming the FileGenerator to XMLGenerator
since the generators are usually named after the input they accept (Midi,
HTML, Directory, JSP
On 13.12.2009 14:58, Reinhard Pötz wrote:
I propose Simone Tripodi as a new Cocoon committer and PMC member.
+1
Joerg
time ago I argued for renaming the FileGenerator to XMLGenerator
since the generators are usually named after the input they accept
(Midi, HTML, Directory, JSP, JXTemplate, etc.). I'm not sure
SAXGenerator reflects that exactly but it's good enough I guess.
Joerg
Oh, you're right :-) I only read your mail on the mailing list, not the
complete issue text.
Joerg
On 05.12.2009 11:04, Jos Snellings wrote:
That is what I did.
On Sat, 2009-12-05 at 09:50 +, Jörg Heinicke (JIRA) wrote:
[ https://issues.apache.org/jira/browse/COCOON3-46?page
) of a specific servlet or pipeline component.
this may sound a bit confusing to everyone not that much involved in
this subproject.
I agree :) The bigger picture is needed - or a concrete example.
Joerg
implementation and ideas behind it.
I don't have the time to actually look into your implementation. I'm
just wondering if all the insight views couldn't be used to improve the
Java implementation rather than starting something in a different language.
Joerg
Original Message
Subject: [Travel Assistance] Applications for ApacheCon EU 2009 - Now Open
Date: Fri, 23 Jan 2009 13:28:19 +
From: Tony Stevenson pct...@apache.org
Reply-To: commun...@apache.org
To: travel-assista...@apache.org
The Travel Assistance Committee is now
exactly can ForrestBot fail? The only thing I get from the
report is that there are a broken link and some links with file:
somewhere in the middle of the name.
Joerg
major version of Spring is
released, community maintenance updates will be issued for three months
to address initial stability issues. They wouldn't talk about initial
stability issues anymore if it were n+1.
Joerg
from one major
release to the next one (which is actually minor) without a lots of
intermediate patch releases.
Joerg
] is the wrong context in a
different interpreter and so sitemap. Links wouldn't be resolved
correctly anymore.
Joerg
[1] http://svn.apache.org/viewvc?view=revrevision=106089
[2] http://marc.info/?l=xml-cocoon-devm=110268944032541w=4
.
The last sentence above is purely a joke. At the end the new maintenance
policy is a means to push people into the enterprise support program.
They are absolutely free to do so, but they should admit it not talk crap.
Joerg
[1] http://www.springsource.com/products/enterprise/maintenancepolicy
at ContinuationsManagerImpl.lookupWebContinuation(..),
around line 240, where it checks the continuation against the stored
interpreter ID. That's where you should run through if you access a
continuation from another sitemap than the one it was created in if I'm
not mistaken.
Joerg
to the issue.
Thanks,
Joerg
[1] https://issues.apache.org/jira/browse/COCOON
Hey guys,
I'm considering to go to New Orleans. I justed wanted to ask who is
planning to go as well and if anybody wants to share a room.
Cheers,
Joerg
On 03.09.2008 23:37, Joerg Heinicke wrote:
just discovered an exception inside our freshly migrated cocoon 2.2
migration, thrown by the ContinuationManagerImpl:
Exception in thread Timer-0 java.util.ConcurrentModificationException
at java.util.HashMap$HashIterator.nextEntry(Unknown
optimized some code. :-) It's around line 390 [2]. I'll
have a look on how to fix it. Sorry for the inconveniences.
Joerg
[1] http://svn.apache.org/viewvc?view=revrevision=643752
[2]
http://svn.apache.org/viewvc/cocoon/trunk/core/cocoon-sitemap/cocoon-sitemap-impl/src/main/java/org/apache
On 03.09.2008 23:37, Joerg Heinicke wrote:
Exception in thread Timer-0 java.util.ConcurrentModificationException
at java.util.HashMap$HashIterator.nextEntry(Unknown Source)
at java.util.HashMap$ValueIterator.next(Unknown Source
implementation and
configuration?
If I knew how to do this ... Log4j isn't really well documented.
I don't know either. I just felt wrong. Somebody else might know how
to do it or implement his own formatter.
I saw you already removed it. Thanks :)
Joerg
the first 5 lines.
Shouldn't these kind of things be left to the logging implementation and
configuration?
Joerg
last mail.
IMO versioned XSDs are all you need to signal additional functionality
or incompatibilities.
I agree. So +1 one for your proposal.
Joerg
to pipeline content in a selector. Transformer (with access to
SAX events) and flowscript (splitting the pipeline into 2) are the 2
already mentioned alternatives.
Joerg
On 23.07.2008 09:04, Richard McKenzie wrote:
Cheers Peter
Thanks for the advice, we are trying to avoid using flow script
.
CI
---
Apache Infrastructure offers a managed Hudson instance. I propose to
setup a Cocoon 3 project there.
I'd like to see continuous integration, be it Continuum, Hudson or Gump.
Joerg
Reinhard Pötz reinhard at apache.org writes:
Following the result of our recent discussion about the future of
Corona, I propose Corona to become Cocoon 3.
+1
Joerg
Grzegorz Kossakowski grek at tuffmail.com writes:
switching to Java 1.5 as minimal required version
+1
Joerg
Grzegorz Kossakowski grek at tuffmail.com writes:
I would like to propose David Legg as a new Cocoon committer and PMC Member.
+1
Joerg
would be good but it seems we can't agree on calling it Cocoon
3.0 right now. So I prefer to leave it as it is (or just change it to the
official name Apache Cocoon Corona).
Joerg
(last mail in mentioned thread).
Joerg
[1] http://marc.info/?t=11096654551r=1w=4
You need to retrieve a component from the ServiceManager, just
instantiating doesn't work.
Joerg
On 21.07.2008 22:59, Gary Larsen wrote:
I'm sorry for my impatient developer posting.
Still not grasping Avalon and Excalibur stuff in 2.1, but it would seem like
it's possible to create a class
it Cocoon 3.0 at all?
Joerg
is if it needs to be part of the API at all.
Joerg
since there is startDocument() and
endDocument() but in general?
It's not an objection, just some thoughts ...
Joerg
and
useful than these examples to outline the concepts.
Joerg
That's why I just wrapped the stuff in comments rather than taking it
out completely :)
Joerg
On 12.06.2008 02:51, Ralph Goers wrote:
Until we need to take advantage of some Java 1.5 feature ;-)
[EMAIL PROTECTED] wrote:
URL: http://svn.apache.org/viewvc?rev=666946view=rev
Log:
With minimum
problems.
Sorry for the inconveniences.
Joerg
On 09.06.2008 22:40, [EMAIL PROTECTED] wrote:
Author: joerg
Date: Mon Jun 9 19:40:16 2008
New Revision: 665954
URL: http://svn.apache.org/viewvc?rev=665954view=rev
Log:
as a follow-up of COCOON-2168 (http://marc.info/?t=12089986853r=1w=4):
Cocoon's pipeline buffer increases from
for not releasing
XSP block. Yes, somebody has to do the actual work. But why blocking it
when somebody puts in the effort? You can estimate the maintenance costs
by looking at the changes in the last years in the 2.1 branch.
Joerg
[1] http://marc.info/?t=12124988641r=1w=4
On 07.06.2008 03:13, Andy Stevens wrote:
Out of interest, have you raised an enhancement request and/or a patch
with the OpenJDK project[1]? It seems to me this increasing buffer
behaviour would be useful more generally...
Done.
Joerg
to be aware of
multi-threading.
Is the multi-threading processing a feature one has to switch on
intentionally?
Joerg
if CocoonRunnable mentioned by Grek is another point for
potential changes.
Joerg
[1]
http://java.sun.com/j2se/1.4.2/docs/api/java/lang/InheritableThreadLocal.html
On 05.06.2008 09:21, Imran Pariyani wrote:
Hello,
we have come across this issue .. i posted it on user mailing list and
some one from
buffering. Only thing that is going to change
is in case of not endless buffering: The full buffer is not allocated
immediately but step by step.
Joerg
[1] https://issues.apache.org/jira/browse/COCOON-2168
to set the content
length header.
Joerg
[1] https://issues.apache.org/jira/browse/COCOON-2168
Reinhard Pötz reinhard at apache.org writes:
Is my understanding right that the content length header can only be set
as long as you haven't written into the underlying output stream?
Yes, it is. That's why the buffering has to be big enough, i.e. nothing must
have been flushed yet.
Joerg
On 29.05.2008 00:06, Joerg Heinicke wrote:
Only issue I want to solve before the release is the
BufferedOutputStream issue. I planned to do it this weekend.
Done. Please review the file attached. It's still completely untested.
At the moment I need some sleep ;) I will write junit tests
such a release
(signed PGP key or things like that).
Only issue I want to solve before the release is the
BufferedOutputStream issue. I planned to do it this weekend.
Joerg
getOutputStream() without any parameter and deprecating the other one.
Many questions, yet another one: What do you think? :)
Joerg
? I can see the point of a
native lookfeel, but beyond that ...
Joerg
.
Joerg
of the resources.
For the flush buffer size we already talked about 1MB as default value
[1]. This size should be nearly never hit.
Joerg
[1] http://marc.info/?t=12047341133r=1w=4
On 27.04.2008 23:43, Joerg Heinicke wrote:
2. Does the full amount of the buffer automatically get allocated for
each request, or does it grow gradually based on the xml stream size?
I have a lot of steps in the pipeline, so I am worried about the
impact of creating too many buffers even
On 30.03.2008 02:50, Joerg Heinicke wrote:
Author: antonio
Date: Tue Feb 19 22:42:45 2008
New Revision: 629374
URL: http://svn.apache.org/viewvc?rev=629374view=rev
Log:
Faster implementation.
Saw this one only now ... I'm a bit concerned about the approach.
First, do you really think
of annoying issues but there is
at least consistency and usually there is a solution for everything.
Do you guys all switch to Linux when it comes to Java development? :)
Nh. I'm very happy with my Mac :-)
If I could just say the same ;)
Joerg
and ConcreteCallProcessor. Perhaps things were
different in the 2.1.9 release?
No serious changes since 2.1.9 which is rev 392241 [2].
Joerg
[1] https://issues.apache.org/jira/browse/COCOON-2168
[2]
http://svn.apache.org/viewvc/cocoon/branches/BRANCH_2_1_X/src/java/org/apache/cocoon/components
please also take care of this error? We have that one
since a few days.
Thanks,
Joerg
/flow/java/test/FlowTest.java
cocoon/branches/BRANCH_2_1_X/src/blocks/javaflow/test/org/apache/cocoon/components/flow/java/test/InheritanceFlowTest.java
Sorry for the oversight and thanks for the fix.
Joerg
On 18.04.2008 11:36, Grzegorz Kossakowski wrote:
[EMAIL PROTECTED] pisze:
Author: joerg
Date: Wed Apr 16 20:32:57 2008
New Revision: 648942
URL: http://svn.apache.org/viewvc?rev=648942view=rev
Log:
fix inconsistencies between inline parts and file parts when multiple
fields of the same name
:
cocoon/subprojects/
Is there a reason for that? When I want to check out Cocoon trunk I
don't want to have all the subprojects of it, do I?
Joerg
]. With AspectJ the behavior might be different because
there is no longer a target object and a proxy.
Joerg
[1]
http://static.springframework.org/spring/docs/2.5.x/reference/beans.html#beans-factory-lifecycle-initializingbean
[2] http://jira.springframework.org/browse/SPR-2740
solution that's fine.
Joerg
-cvsm=120840325524262w=4
Please test the new code in SVN. Thanks for your report.
Joerg
release them sometime in the next weeks though.
Joerg
to do it but haven't made it
... and in few hours I'm leaving for 1 week of American culture shock:
Orlando, Florida :)
Joerg
development? :)
Joerg
On 01.04.2008 02:21, [EMAIL PROTECTED] wrote:
Author: joerg
Date: Mon Mar 31 23:21:53 2008
New Revision: 643295
URL: http://svn.apache.org/viewvc?rev=643295view=rev
Log:
Fix synchronization issues in ContinuationsManager implementation.
Refactored version for 2.2 will follow this week
(wc.getLastAccessTime()));
+}
}
The better fix is to use FastDateFormat which features thread safe
formatting.
All these nice little gems hidden in Apache Commons libs :)
Applied.
Thanks,
Joerg
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
it when
AbstractContinuable.sendPageAndWait(..) was actually hit twice.
I guess this handling is different in 2.2. There a clean
ContinuationContext is created on both callFunction(..) and
handleContinuation(..).
Joerg
[1] http://svn.apache.org/viewvc?rev=642694view=rev
easy to debug. I have never tried
it before but now I like it better than flowscript.
Joerg
are not yet available. Could somebody please add
them or do we have to go via Infrastructure for that?
Thanks,
Joerg
On 30.03.2008 22:19, [EMAIL PROTECTED] wrote:
Author: joerg
Date: Sun Mar 30 19:19:41 2008
New Revision: 642855
URL: http://svn.apache.org/viewvc?rev=642855view=rev
Log:
fix synchronization
Can you please review this [1]? It's too easy to mess this up ... I hope
I did not introduce any
API and found only this one reference to the
source resolve package.
Joerg
[1] http://marc.info/?l=xml-cocoon-devm=120649777119480w=4
the original. It gives the object
relationships in the memory. BufferedOutputStream takes 50% and is hold
in HttpEnvironment which is hold in TreeProcessorRedirector which is
hold in ContinuationContext. I wondered why it is there.
Joerg
of org.apache.cocoon.components.flow.WebContinuation
Joerg
[1] http://marc.info/?l=xml-cocoon-usersm=120582409910104w=4
the ContinuationContext there as well. You might
know more about it.
Joerg
that represent sources?
Isn't that what components are there for? Encapsulating commonly used
functionality? Why should I extract that to the pipeline *instance*
level? So writing pipelines is becoming a mess!
Joerg
concern.
I really wonder if I miss something. All this seems to be too obvious to
me ...
Joerg
[1] http://marc.info/?l=xml-cocoon-devm=120646488429681w=4
. If your name isn't Ard ( ;-) ) you
usually don't need to know more details. And that's what it is as Vadim
pointed out: implementation details.
Joerg
interface which should then also be decoupled from uri resolving (which
seems to point to Peter's approach [3]).
Joerg
[1]
http://cocoon.apache.org/2.1/apidocs/org/apache/cocoon/components/pipeline/ProcessingPipeline.html
[2]
http://cocoon.apache.org/2.1/apidocs/org/apache/cocoon/components
fancy about it, plain Java. Since this code compiles, you must
have an older commons-lang.jar (Cocoon uses 2.3) on your classpath
during runtime.
Joerg
the environment? Do we get anything useful out of it after
continueing the continuation?
Joerg
why do I need to care about Urls or Sources at
all? Why should it be different then map:generate with its src
attribtue? And when I read CacheableFileGenerator something tells me
this approach is wrong.
Joerg
mare - Loading... and Ottimizzato per Mozilla Firefox 2.0 e Microsoft
Internet Explorer 7. Additionally it shows a dolphin and a spinning
circle. ;-)
Joerg
or the other (complete stop of JavaScript processing or just ignoring
that particular function?). Usually these functions should really not be
used - and I don't think that's the source of the problem.
Joerg
PS: We might better do this off-list if you have more questions.
don't quite agree with it, Javascript does not necessarily prevent
accessibility. I'm not too familiar with all the accessibility
requirements but for example the tabs we have in Forms should be fine,
aren't they?
Joerg
.).
I guess the confusion resulted from your unconditional statement in the
answer to Rice. This just did not make sense to me - and apparently Vadim.
Joerg
it used to work out of the box.
Joerg
[1] http://marc.info/?l=xml-cocoon-devm=120473398413381w=4
better than an OOME in
the default setup. And people can still change it to -1 and endless
buffering if they really need. But at least they are aware of the
effects then.
Joerg
)
at
org.apache.cocoon.components.flow.javascript.fom.FOM_JavaScriptInterpreter.setupContext(FOM_JavaScriptInterpreter.java:429)
at
org.apache.cocoon.components.flow.javascript.fom.FOM_JavaScriptInterpreter.callFunction(FOM_JavaScriptInterpreter.java:575)
Joerg
On 10.03.2008 08:20, rossputin wrote:
I ran an svn up this morning on my Cocoon 2.2
On 05.03.2008 23:06, Joerg Heinicke wrote:
From what I see from the code (AbstractProcessingPipeline) it is
possible to configure and setup/parameterize a pipeline with
outputBufferSize. This means on both map:pipe and map:pipeline it
should be possible to set an actual buffer size. Only
to
send an error response in case of an error. If your buffer is too small,
a first part of the actual content might already have been flushed when
the error occurs and the error content is appended. Looks weird at the
client's browser ;)
Joerg
On 08.03.2008 15:28, Felix Knecht wrote:
Felix, have you tried outputBufferSize?
Not yet. I didn't even knew how to configure it :-(
Both map:pipe and map:pipeline should work as mentioned here:
http://marc.info/?l=xml-cocoon-devm=120477640924395w=4
Joerg
either way.
Joerg
On 05.03.2008 23:06, Joerg Heinicke wrote:
We could argue about another default value than -1 though. Something
like 1024^2.
What do others think? Shall we change the default value from buffer
everything (which lead to the OutOfMemoryError [1]) to something more
secure in the sense
map:parameter name=outputBufferSize value=8192/
...
/map:pipeline
We could argue about another default value than -1 though. Something
like 1024^2.
WDYT?
Joerg
seems to be COCOON-1266 [4] but
the provided and applied patch is older than Vadim's change. I guess we
should review this code.
The revisions for trunk are 155099 [5] and 410113 [6].
Joerg
[1] http://svn.apache.org/viewvc?view=revrevision=155087
[2] http://svn.apache.org/viewvc?view
Eventually ...
Joerg
Original Message
Subject: [jira] Closed: (MNG-2339) ${project.*} are interpreted in the
wrong place
Date: Wed, 27 Feb 2008 18:56:28 -0600 (CST)
[http://jira.codehaus.org/browse/MNG-2339?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
On 20.02.2008 12:47, Reinhard Poetz wrote:
mvn cocoon:load jetty:run
after reading all the mails again, here are my two favorits:
mvn cocoon:load jetty:run
mvn cocoon:prepare jetty:run
Considering your explanation [1] I slightly prefer cocoon:prepare.
Joerg
[1] http://marc.info/?l=xml
1 - 100 of 1679 matches
Mail list logo
