[
https://issues.apache.org/jira/browse/COCOON-1574?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ralph Goers reassigned COCOON-1574:
---
Assignee: (was: Ralph Goers)
Memory Leak with XMLFileModule
[
https://issues.apache.org/jira/browse/COCOON-1329?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ralph Goers reassigned COCOON-1329:
---
Assignee: (was: Ralph Goers)
[PATCH] Fix for cocoon.jar bundled in ear common
[
https://issues.apache.org/jira/browse/COCOON-2288?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12853992#action_12853992
]
Ralph Goers commented on COCOON-2288:
-
Not that there is anything wrong with your code
On Dec 13, 2009, at 5:58 AM, Reinhard Pötz wrote:
I propose Simone Tripodi as a new Cocoon committer and PMC member.
Simone has been participating on our mailing lists since Sept 2008.
Recently he provided an extensive patch that adds XInclude support to
Cocoon 3. Additionally he
It has been quite a while since I last worked on Cocoon, but since I
wrote XPathXMLFileModule I suppose I am best qualified to answer the
question.
XPathXMLFileModule is a replacement for XMLFileModule but it is not
completely compatible - which is why it is a new module and not just
an
On May 1, 2009, at 4:45 AM, Sylvain Wallez wrote:
dynnamitt wrote:
Thanks man, I didn't know about that Phone-home feat.
I did not however see GPL as an issue since the JVM(7) itself soon
becomes a member.
Does this mean that all apache apps will be stuck in JVM6 land ??
The GPL is
I think it makes sense to evolve Cocoon to have a central portion of
it revolve around pipeline processing and various ways of doing it.
It would make sense to just come to one place rather than to have to
go to two.
On Apr 7, 2009, at 3:32 AM, Juan José Vázquez Delgado wrote:
Hi all,
Just in case you didn't see it, Jukka has set up a project at https://svn.apache.org/repos/asf/commons/sandbox/xml
.
Ralph
Begin forwarded message:
From: Henri Yandell flame...@gmail.com
Date: February 5, 2009 10:27:51 PM PST
To: Commons Developers List d...@commons.apache.org
Subject: Re:
is completely
independent of your employer it is never really quite that simple.
Reinhard Pötz wrote:
Ralph Goers wrote:
Thorsten Scherler wrote:
On Wed, 2008-09-24 at 09:10 -0600, Antonio Gallardo wrote:
Hi,
There is a worst case scenario now: What if they don't collect
Thorsten Scherler wrote:
On Wed, 2008-09-24 at 09:10 -0600, Antonio Gallardo wrote:
Hi,
There is a worst case scenario now: What if they don't collect enough
money from subscriptions and do the next step: remove the 3 months
window or worse go full closed source?
How people feel to
I will be there arriving on Sunday and leaving Saturday morning. I
prefer not to share a room.
Ralph
Joerg Heinicke wrote:
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
+1
Reinhard Pötz wrote:
After having already discussed the details, let's make a formal decision
about versioning, SVN, Maven, namespaces issue tracking and CI for Cocoon 3.
Versioning
---
Cocoon 3 will follow the alpha/beta/rc release scheme (like Mozilla,
Maven,
Sylvain Wallez wrote:
By chronic disease, I was referring to Maven. And it's not specific
to Cocoon, but to many other projects. Maven has brought one new
brillant idea to the Java world, which is artifact repositories (note
though that Linux repositories have existed for a very long
David Legg wrote:
Once again, I'd like to thank the community for accepting me as a
Cocoon committer.
Finally, it is a good tradition that a new committer introduces
himself on this list.
I'm an English web developer, married with a child and working in
Bracknell, England. I've been
Reinhard Pötz wrote:
.
Versioning
---
For Cocoon 2 there have been proposals that all odd versions are
development/alpha versions and all even versions are stable releases.
I like this idea and propose that we follow this versioning schema in
Cocoon 3: All 3.0.x
Carsten Ziegeler wrote:
Ralph Goers wrote:
It uses the relative path so you will need the parent also.
Hmm, I'm not sure if this is a good idea :) as it permits building a
module standalone.
For Cocoon we have the dream (tm) to have separate
buildable/deployable modules one day.
Carsten
Carsten Ziegeler wrote:
Ralph Goers wrote:
Carsten Ziegeler wrote:
Ralph Goers wrote:
It uses the relative path so you will need the parent also.
Hmm, I'm not sure if this is a good idea :) as it permits building a
module standalone.
For Cocoon we have the dream (tm) to have separate
Ralph Goers wrote:
Carsten Ziegeler wrote:
Ralph Goers wrote:
Carsten Ziegeler wrote:
Ralph Goers wrote:
It uses the relative path so you will need the parent also.
Hmm, I'm not sure if this is a good idea :) as it permits building
a module standalone.
For Cocoon we have the dream (tm
+1
Reinhard Pötz wrote:
Following the result of our recent discussion about the future of
Corona, I propose Corona to become Cocoon 3.
This means that any reference on Corona in source files, package
names, artifact ids, group ids or anywhere else will be dropped and
the standard Cocoon
Reinhard Pötz wrote:
Grzegorz Kossakowski wrote:
[EMAIL PROTECTED] pisze:
Author: reinhard
Date: Tue Aug 5 12:42:45 2008
New Revision: 682901
URL: http://svn.apache.org/viewvc?rev=682901view=rev
Log:
back in snapshot mode
Modified:
cocoon/trunk/tools/pom.xml
Modified:
It uses the relative path so you will need the parent also.
Carsten Ziegeler wrote:
Ralph Goers wrote
I'm actually working on a fix to maven for this at the moment. It
would allow you to put versionMAVEN_PARENT_VERSION/version in the
pom instead of an actual version number. Don't get your
+1
Grzegorz Kossakowski wrote:
Hello,
As discussed in thread Cocoon-jms-sample requires Java = 1.5[1]
there are more and more problems with keeping Java 1.4 compatibility
in trunk.
After a while it turned out that everybody agrees on the need for
dropping Java 1.4 compatibility and in
that Merenque is an improper spelling in
English. Of course, that isn't necessarily a problem.
Ralph
Reinhard Pötz wrote:
Ralph Goers wrote:
Reinhard Pötz wrote:
Corona currently consists of 4 functional modules:
cocoon-corona-pipeline, cocoon-corona-sitemap,
cocoon-corona-controller and cocoon
Reinhard Pötz wrote:
Ralph Goers wrote:
Reinhard Pötz wrote:
Let's summarize the proposed names (alphabetical order):
Cocoon Chasse
Cocoon Merenque
Cocoon Morus
Cocoon Weedle
Could others please check these names too?
Any general comments? Any other suggestions?
I would agree except
+1
Grzegorz Kossakowski wrote:
Dear community,
I would like to propose David Legg as a new Cocoon committer and PMC
Member.
David is around Cocoon community since 2005 and lately become more
active. He provided nice patche migrating us to Maven Archetype 2.0
plug-in and paid lots of
Vadim Gritsenko wrote:
On Aug 4, 2008, at 3:49 AM, Ralph Goers wrote:
I've never really liked the word pipeline because I tend to think
of surfing when I hear it. That isn't altogether bad I suppose, but
it isn't altogether accurate either. I tend to think of what Cocoon
does more
of
likelihood of confusion, a standard that does not easily enable
binary and final determinations short of litigation.
TESS http://tess2.uspto.gov/bin/gate.exe?f=tessstate=879qc0.1.1 may
be used to search for registered trademarks.
- Sam Ruby
On Sat, Aug 2, 2008 at 9:10 AM, Ralph Goers [EMAIL PROTECTED
Reinhard Pötz wrote:
Corona currently consists of 4 functional modules:
cocoon-corona-pipeline, cocoon-corona-sitemap,
cocoon-corona-controller and cocoon-corona-servlet. Using functional
names isn't an appropriate solution for our problem. This would lead
to a lot of confusion because we
Reinhard Pötz wrote:
Borland hasn't trademarked silk but only some variants of it. See
http://tinyurl.com/5bkw9d
Silk was trademarked by a company called mentis:
http://tess2.uspto.gov/bin/showfield?f=docstate=pgshps.20.117
The name that we would use is Cocoon Silk. So I tend to think
Reinhard Pötz wrote:
What would be the options that we vote on?
a) keep the name Apache Cocoon Corona
b) rename to Apache Cocoon Silk
c) we need to find some other name
Any other options?
I sent a message to legal internal to get their opinion on options a and
b. I suggest waiting for
Sorry, I didn't do reply-all. I usually just do reply on all my Apache
email.
Reinhard Pötz wrote:
Ralph Goers wrote:
Reinhard Pötz wrote:
What would be the options that we vote on?
a) keep the name Apache Cocoon Corona
b) rename to Apache Cocoon Silk
c) we need to find some other
Thorsten Scherler wrote:
Just to say another name: ;)
Apache Kokon
which is cocoon in German.
jeje this one is for Antonio:
Apache Capullo
which is cocoon in Spanish (but in Spain it has a slightly double
meaning).
salu2
Should I ask?
I actually like both those names -
Silk is the shorthand name for SilkTest and SilkPerformer.
http://www.borland.com/us/products/silk/index.html.
Carsten Ziegeler wrote:
Reinhard Pötz wrote:
. Apache Cocoon Fiber
. Apache Cocoon Silk
. Apache Fiber
. Apache Silk
Any other suggestions?
I agree with the others that we
+1
Ralph
Reinhard Pötz wrote:
Dear community,
it's a great honor for me to propose Steven Dolg as a committer.
In February Steven, Grzegorz and I invested three days in refactoring
Cocoon so that we get a clean Java Pipeline API and a comprehensible
sitemap/environment handling
+1
Ralph
David Crossley wrote:
I would like to propose Luca Morandini as a new Cocoon committer
and PMC member.
Luca participates at the Cocoon dev and users mail lists
since 2001, being more active again recently.
http://cocoon.markmail.org/search/?q=morandini
shows that there are many
+1
Ralph
David Crossley wrote:
I propose Andreas Hartmann as a new Cocoon committer
and PMC member.
Andreas already has commit access to Cocoon by virtue
of being a committer at Apache Lenya.
This will formalise his status at Cocoon and enable
him to be a PMC member.
Andreas has been
+1
Ralph
David Crossley wrote:
I propose Thorsten Scherler as a new Cocoon committer
and PMC member.
Thorsten already has commit access to Cocoon by virtue
of being a committer at Apache Lenya and Apache Forrest.
This will formalise his status at Cocoon and enable
him to be a PMC member.
+1
Ralph
Andrew Savory wrote:
Hi,
It's my pleasure to propose Jasha Joachimsthal as a new committer on
the Apache Cocoon project.
Jasha has been active on the Cocoon mailing lists since the start of
2006 (http://cocoon.markmail.org/search/?q=Joachimsthal). He has
contributed extensively on
Carsten Ziegeler wrote:
Now all these examples assume that the calling code knows the components.
For my use case - and it's the same with the Cocoon sitemap - I've a
description of a pipeline (think of the sitemap) which has just the name
of the pipeline components to chain. A generic code
Carsten Ziegeler wrote:
Ok, this all depends on what you consider configuration vs execution
information. If you look at the current Cocoon sitemap components
they've only a little configuration (everything that can be configured
in the components section of the sitemap). Most information is
Carsten Ziegeler wrote:
Now I was very brief as I'm not 100% sure how the final solution in
jetspeed looks like.
Ok, our spring configurator includes all files located at a specific
location and adds all bean definitions found there.
The jetspeed guys enhanced the spring bean configuration
Maybe this won't strike you as strange but it did me. I ran a mvn
install on a project using 2.0.9. In the course of that
maven-project-2.0, maven-project-2.0.6, maven-2.0.7, and
maven-project-2.0.9 were downloaded, installed into the local repo and
then used in the build. As you would expect
Rats. Please ignore. Wrong list.
Ralph Goers wrote:
Maybe this won't strike you as strange but it did me. I ran a mvn
install on a project using 2.0.9. In the course of that
maven-project-2.0, maven-project-2.0.6, maven-2.0.7, and
maven-project-2.0.9 were downloaded, installed into the local
Reinhard,
I'm really looking forward to the documentation on this. To be honest, I
am not sure I will ever be using Cocoon as a whole again but I can think
of many cases where just using the pipeline would be valuable.
I would suggest that if Corona is really as independent as it sounds
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 Java raised to 1.4.2 it is no longer necessary to have
JDK-specific source directories.
I sure am glad we decided to go with Java 1.4 for 2.2. See the nice
bulletin at http://java.sun.com/j2se/1.4.2/download.html. At least now
I'm certain we won't be supporting 1.4 until 2010.
Ralph Goers wrote:
Carsten Ziegeler said:
Although I guess everyone understood what I meant above
I would suggest that the wording be changed slightly to remove the word
FINAL.
The title should be Apache Cocoon 2.2.0 Released. Released is correct
because it is the verb in the sentence.
The first sentence should also be The Apache Cocoon Community is proud
to announce the release of
You going to the happiest place on earth? Isn't that Carsten's favorite
place? Never having been (Disneyland is only 1 hr from here) I can't
whether Orlando is much of a culture shock but I somehow doubt it. Try
New York, San Francisco or Hollywood for that.
Joerg Heinicke wrote:
On
Consider this:
URL baseUrl = new URL(file:///C:/temp/);
Pipeline pipeline = new NonCachingPipeline();
pipeline.addComponent(new FileGenerator(new URL(baseUrl, xyz.xml));
pipeline.addComponent(new XSLTTransformer(new URL(baseUrl, xyz.xslt));
pipeline.addComponent(new XMLSerializer());
Carsten Ziegeler wrote:
Hmm, I don't think so. Imagine a pipeline java api just taking a uri
for the sources used in the pipeline. That's simple and easy.
Now, you can use the source resolver on top of that, resolve your
sources and you get a uri from your source that you can put into the
Reinhard Poetz wrote:
Pipeline API + java.net.URL + XML-SAX components
A more advanced scenario could consist of
Pipeline API + Sourceresolve + XML-SAX components + Sitemap
Engine
or maybe you need the full stack that corresponds to Cocoon Core 2.2 -
here you are:
Steven Dolg wrote:
Ralph Goers schrieb:
Appealing? yes. Actually implementable in Java so that it isn;t even
more complicated than what we have? I don't know.
Just curious - do you have doubts, that this is achievable
specifically with Java, or generally with any language?
Taking 5
I had to create a class at work for handling some files. I started with
an input stream. What I needed, though, required caching and being able
to check whether the file was still valid. In this case I soon realized
that I would have to reinvent the Excalibur Source interface since I had
to
I think you are out of your mind. (Not seriously).
I have to tell you, Cocoon without caching pipelines would suck so bad
with performance problems you would give it the boot in very short
order. Even without Cocoon, as soon as you start doing anything
serious caching will become necessary.
I have no problem with merging the PMCs. I am not in favor of merging
the source code.
Carsten Ziegeler wrote:
Grzegorz Kossakowski wrote:
Ralph Goers pisze:
I'm not sure what JNet actually is, but the part I was referring to
was where Carsten was talking about Excalibur being dead
As a user of sourceresolve independent of Cocoon I would be -1 on moving
it into Cocoon. If it goes anywhere I'd prefer commons.
Carsten Ziegeler wrote:
Now, I think that this will be over time the best solution *if* we can
keep the excalibur package names - but I think that should be
I'm not sure what JNet actually is, but the part I was referring to was
where Carsten was talking about Excalibur being dead and pulling out the
few pieces we use.
Grzegorz Kossakowski wrote:
Ralph Goers pisze:
As a user of sourceresolve independent of Cocoon I would be -1 on
moving
+1
Carsten Ziegeler wrote:
Hi,
I had the thought of doing 2 or 3 maintenance releases of 2.1.x (if
there are changes) per year.
Following this spirit I would like to cut a 2.1.12 sometime during April.
Carsten
Could you post the stack trace?
Thorsten Scherler wrote:
Hi all,
we have build a webapp based on cocoon 2.2. Everything is working fine
if a single person is using the app, but as soon as we have concurrent
user the code fails with NPE in different lines of the code.
My questions are:
Every
Yes, I fixed 2108. If you are happy that the fix hasn't caused any other
problems then I will close it.
Grzegorz Kossakowski wrote:
Carsten Ziegeler pisze:
Hi,
did you know that I bought one of those Grumpy shirts last time I
visited WDW? So, I *have* to ask what the current plans for the
Grzegorz Kossakowski wrote:
In contrast to CTemplates or CForms, no developer is using XSP actively at the
moment.
How could you possibly know that?
Thanks Carsten.
I don't get the last paragraph though. Why would we provide more
information about 2.1.10 when the announcement is for 2.1.11? The
changes.html link has almost nothing under 2.1.11 so I assume the
reference to 2.1.10 is correct?
Ralph
Carsten Ziegeler wrote:
Apache Cocoon
Rats. Sorry. I was trying to squeeze that in when I had free time and I
just get so used to skipping the tests since every time I've tried to
run them my build has failed. I shouldn't have assumed they were still
not working.
To be honest when I was working on this I was just very frustrated
? It should only be for developers after all.
Ralph Goers wrote:
Rats. Sorry. I was trying to squeeze that in when I had free time and
I just get so used to skipping the tests since every time I've tried
to run them my build has failed. I shouldn't have assumed they were
still not working
OK. So using PreparedVariableResolver fixes the problems with the
dependencies. I've committed the change. But I am still getting 1 unit
test failure in cocoon core - CachingSourceTestCase is failing on line
88. How could this possibly have anything to do with what I changed?
Ralph Goers
of SitemapComponentTestCase years ago to provide support for unit
testing input modules. I'll have to dig that back up I guess.
Joerg Heinicke wrote:
On 08.01.2008 22:59, Ralph Goers wrote:
But I am still getting 1 unit test failure in cocoon core -
CachingSourceTestCase is failing on line 88. How
I put slashdot.org in my browser on that machine and it took quite a
while to display but it did. I notice that the unit tests pause for
quite a while on that test. I'm not sure why.
Anyway, I changed the 5 to 30 and it still fails. Should unit tests
really be going to external resources?
Maybe we are on the same page, but I'm unclear what you mean by
include. A cocoon release should consist of nothing more than
deploying artifacts to the maven repository. End users should be getting
the release by specifying the version number of the release in the
archetypeVersion. To create
:
On 09.01.2008 00:11, Ralph Goers wrote:
Maybe we are on the same page, but I'm unclear what you mean by
include. A cocoon release should consist of nothing more than
deploying artifacts to the maven repository. End users should be
getting the release by specifying the version number
to just up it to 10.
Ralph
Ralph Goers wrote:
I put slashdot.org in my browser on that machine and it took quite a
while to display but it did. I notice that the unit tests pause for
quite a while on that test. I'm not sure why.
Anyway, I changed the 5 to 30 and it still fails. Should unit
that and b) know what samples exist
that they can add.
Ralph
Vadim Gritsenko wrote:
On Jan 7, 2008, at 2:32 AM, Ralph Goers wrote:
But if they want to build the sample site and run it what would they do?
Create pom.xml inheriting from core/cocoon-webapp and add dependencies
to all
[
https://issues.apache.org/jira/browse/COCOON-1574?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ralph Goers closed COCOON-1574.
---
Resolution: Fixed
Fix Version/s: 2.1.11
Affects version
[
https://issues.apache.org/jira/browse/COCOON-2064?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ralph Goers closed COCOON-2064.
---
Resolution: Fixed
The javadoc has been updated.
PropertySettings does not support run-mode
I didn't know about the plugin, but yes I knew I should have put the
issue number in the commit. I just forgot to do it.
Joerg Heinicke wrote:
On 06.01.2008 04:35, [EMAIL PROTECTED] wrote:
Author: rgoers
Date: Sun Jan 6 01:35:48 2008
New Revision: 609282
URL:
I know how to build the sample site in trunk from the source. However,
this isn't the way a typical end user would like to do it. The online
doc says to do
mvn archetype:create
-DarchetypeGroupId=org.apache.cocoon
-DarchetypeArtifactId=cocoon-22-archetype-block
-DarchetypeVersion=1.0.0-RC2
So the context protocol is pretty much useless in trunk. I replaced it
with blockcontext:/cocoon-core-main-sample/ and it works fine. It would
be a lot nicer to do blockcontext:// and get the current block context
but I'm not seeing anything keeping track of that.
Ralph
Ralph Goers wrote
I'm trying to test the change to JXPathHelper and have run into problems
on the RequestModule sample. It fails in JXPath trying to process the
attributeNames. The problem occurs because the attributeNames member of
ReqeustWrapper is represented by an IndexedPropertyDescriptor instead of
a
Does the context protocol work in trunk? In the XMLFileModule sample it
is resolving to the wrong location.
Ralph Goers wrote:
I'm trying to get XPathXMLFileModule working in trunk. However, before
I can even get that far it doesn't look like XMLFileModule works. It
fails saying it can't find
the scope on getAttributeNames was confusing the heck out
of it.
Ralph
Ralph Goers wrote:
I'm trying to test the change to JXPathHelper and have run into
problems on the RequestModule sample. It fails in JXPath trying to
process the attributeNames. The problem occurs because the
attributeNames
/trunk/core/cocoon-webapp/target/work/blocks/cocoon-core-main-sample/modules/forrestconf.xml.
Grzegorz Kossakowski wrote:
Ralph Goers pisze:
Does the context protocol work in trunk? In the XMLFileModule sample it
is resolving to the wrong location.
To what location does it resolve?
I'm trying to get XPathXMLFileModule working in trunk. However, before I
can even get that far it doesn't look like XMLFileModule works. It fails
saying it can't find forrestconf.xml. The full path is listed in the
exception and indeed the file does not exist there. Instead, it is in a
work
Use the whiteboard. The only areas of concern I have is with regard to
sub-sitemaps and resources. But I reserve judgment on that until I see
what you come up with.
Ralph
Reinhard Poetz wrote:
We at Indoqa have started to think about working on a slimmed down
version of Cocoon 2.2
[EMAIL PROTECTED] wrote:
Creating the jira posted to the Cocoon Dev ML in June. Nobody
commented. Should we consider that as no interest or no objections? I
did not receive notification that nobody looked at the jira. What is
the proper channel for more review?
This list. If you want to
I committed the changes to 2.1.x. I'll try to get trunk done on 1/1/08
Ralph Goers wrote:
If I can't get it done in the next 24 hrs go ahead and do that.
However, I'd really like my changes in 2.1.11 also. It has been an
outstanding defect for several years.
Grzegorz Kossakowski wrote
[
https://issues.apache.org/jira/browse/COCOON-1574?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12554656
]
Ralph Goers commented on COCOON-1574:
-
I have checked in XPathXMLFileModule which can be used as a replacement
Thanks for the explanation, except I'm still not clear what a
connection name is. See below for my 2 cents.
Grzegorz Kossakowski wrote:
The only problem is that we have no way to check if given URI contains
connection name or servlet
ID. Therefore the idea to add special sign that would
[EMAIL PROTECTED] wrote:
I committed/closed my Cocoon jiras as soon as I learned a Cocoon
release was planned. This may be the final release of Cocoon-2.1 so
every change must be committed or discarded.
I wouldn't get your hopes up on this one. 2.2 is sufficiently different
enough that I
In case you didn't know, people.apache.org/~jim lists solprovider as
Paul Ercolino, a committer from Lenya. He opened Cocoon-2074 in June and
listed the change then. No one ever commented on it.
I'm not clear on what you are saying. Does your question I am
wondering if a simple filtering=on
I am going to have to revert the change below to JXPathHelper as it has
broken XMLFileModule. The sample site no longer works correctly.
Subject: svn commit: r575808 -
/cocoon/branches/BRANCH_2_1_X/src/java/org/apache/cocoon/components/modules/input/JXPathHelper.java
Date: Fri, 14 Sep 2007
[
https://issues.apache.org/jira/browse/COCOON-2108?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ralph Goers reopened COCOON-2108:
-
This patch causes XMLFileModule and anything based on AbstractJXPathModule or
JXPathMetaModule
fix this, but I'll have to add it to everything that uses
JXPathHelper.getAttribute, which doesn't seem quite right either. But
I'm testing this right now to see if it fixes this.
Ralph
Grzegorz Kossakowski wrote:
Ralph Goers pisze:
I am going to have to revert the change below
to use JXPathHelper for their own purposes would also have
problems.
Ralph
Ralph Goers wrote:
As far as I know the old implement wasn't buggy,it just always
returned text. It looks like it could have returned null and the code
might not handle that properly, but that isn't a problem
So you have no problem breaking API contracts with end users on minor
point releases?
Grzegorz Kossakowski wrote:
Ralph Goers pisze:
I have verified that the code below gets my new XPathXMLFileModule
working again. However, I'm still not sure that is the correct thing to
do as the change
http://marc.info/?l=xml-cocoon-devm=108266407019215w=2
Ralph Goers wrote:
So you have no problem breaking API contracts with end users on minor
point releases?
Grzegorz Kossakowski wrote:
Ralph Goers pisze:
I have verified that the code below gets my new XPathXMLFileModule
working again
reasons.
I'll add the new method and fix the other classes as part of checking in
XPathXMLFileModule (ironically, I made a new class because this version
is not quite compatible with XMLFileModule).
Ralph
Grzegorz Kossakowski wrote:
Ralph Goers pisze:
So you have no problem breaking API
Back to the topic at hand. I'd like to check in XPathXMLFileModule
before the release. I'll try to do that in the next few days.
Carsten Ziegeler wrote:
LOL - wow, that's really interesting to see - thanks for the information
and I think this is a proof that even with a simple typo in the
You can tell I'm from Los Angeles. When I first started to read this I
couldn't figure it out because here it just doesn't take that long to
fix a flat tire on a car. Of course, I then realized you meant you have
to move to a new apartment. :-D
Ralph
Grzegorz Kossakowski wrote:
Quick
2.1.1? How many years ago was that?
Carsten Ziegeler wrote:
Hi,
I'm planning to release 2.1.1 in the near future.
So, are the any outstanding issues?
Carsten
I can't believe you went to the trouble to list all those Antonio - I
was just trying to make a joke! I'm sure Carsten must have meant 2.1.11.
Ralph
Antonio Gallardo wrote:
Ralph Goers escribió:
2.1.1? How many years ago was that?
4 years ago.
Here is the full 2.1 series release dates
Reinhard Poetz said:
I agree with you but let me give you some reasoning that has lead to this
misture:
The problem is that developing really RESTful applications isn't entirely
possible with current web browsers, e.g. you can't use other methods than
POST
and GET in your forms.
1 - 100 of 1276 matches
Mail list logo
