Lars Trieloff (JIRA) wrote:
[ http://issues.apache.org/jira/browse/COCOON-1906?page=comments#action_12437870 ]
Lars Trieloff commented on COCOON-1906:
---
Jean Baptiste,
the main problem is that there is no casting in Javascript and for any
[
http://issues.apache.org/jira/browse/COCOON-1906?page=comments#action_12437932
]
Vadim Gritsenko commented on COCOON-1906:
-
See: http://www.mozilla.org/js/liveconnect/lc3_method_overloading.html (chapter
4).
Form.js can be modified
Arje Cahn wrote:
Hi Lezek,
Is there any chance to record the presentations on camera?
If someone (you?) would be able to do that, that would be awesome...!
I very much enjoyed Jack Ivers' podcasts from last year, but he hasn't signed
up yet (although Vadim did). So, anyone volunteering to
[EMAIL PROTECTED] wrote:
+public class CopyUtils {
+public static void copy( InputStream is, OutputStream os ) throws
IOException {
+if ( !(is instanceof BufferedInputStream) ) {
+is = new BufferedInputStream( is );
+}
+if ( !(os instanceof
repository.
That was it. org/apache/maven/plugins/maven-clean-plugin had single pom file in
it, no jars or anything else.
Thanks,
Vadim
Cheers,
Brett
On 26/08/2006, at 10:42 AM, Vadim Gritsenko wrote:
Hi All,
Anybody knows a way to perform 'clean' with maven? Freshly installed
maven 2.0.4
Nathaniel Alfred wrote:
Hi Hussayn,
thanks for sharing your patch.
I'll have a look at it.
IIUC, the problem with this patch is that it drops usage of Source and replaces
it with jaxp API. Which means, if bug description is correct, that Source still
is not using entity resolver as one
Hi All,
Anybody knows a way to perform 'clean' with maven? Freshly installed maven 2.0.4
with recently (~2 days ago) nuked repository very consistently fails on 'mvn
clean' command:
[INFO]
[INFO] Building Apache
Hi,
What's the correct groupId for servlet-api? javax.servlet seems to work, but I
found in one place it is set to 'servlet-api'.
Vadim
Jorg Heymans wrote:
On 24 Aug 2006, at 03:26, [EMAIL PROTECTED] wrote:
+!-- HTTP ERROR: 404
pluginRepository
idmortbay-repo/id
namemortbay-repo/name
urlhttp://www.mortbay.org/maven2/release/url
/pluginRepository
+--
That repo works fine from here, can
Carsten Ziegeler wrote:
The question now is, what do we use for logging in an avalon free
environment? Spring itself directly uses commons logging.
Please note, that I don't want to change all components we have to the
new mechanism now; but I would like to have our standard way of logging
for
Leszek Gawron wrote:
Reinhard Poetz wrote:
Giacomo Pati wrote:
Do you need more modes?
Actually I've hit that wall now as well as I have to deliver lots of
different testing scenarios and the property mechanism of Cocoon is
more comfortable than using Maven profiles to filter property
Carsten Ziegeler wrote:
Vadim Gritsenko wrote:
Carsten Ziegeler wrote:
The question now is, what do we use for logging in an avalon free
environment? Spring itself directly uses commons logging.
Please note, that I don't want to change all components we have to the
new mechanism now; but I
Hi All,
I only just now realized that BackgroundEnvironment is located in the Cron
block. But, it can be used with any Runnable (managed by RunnableManager) to run
background tasks, and RunnableManager is part of the core.
So if no one objects, I'd like to move BackgroundEnvironment into the
Carsten Ziegeler wrote:
Vadim Gritsenko wrote:
Well in this case it does not have to shield anything, it only have to be
present :)
I'm also somewhat skeptical about shielding ClassLoader - I've not thought all
the ramifications of it myself, and not sure it will work in all deployment
Peter Hunsberger wrote:
On 8/14/06, Joerg Heinicke [EMAIL PROTECTED] wrote:
On 14.08.2006 22:19, Daniel Fagerstrom wrote:
snip/
This remains my main point though: losing some of our user base. You may
never have been working for a bank, but there such changes in the
requirements take years
Reinhard Poetz wrote:
I will start a vote on the JDK and the servlet API versions as we need a
formal agreement about this IMO.
We used to poll user list last time we changed JDK requirements. It may make
sense to do same now.
Vadim
Reinhard Poetz wrote:
Vadim Gritsenko wrote:
Reinhard Poetz wrote:
I will start a vote on the JDK and the servlet API versions as we
need a formal agreement about this IMO.
We used to poll user list last time we changed JDK requirements. It
may make sense to do same now.
Your mail arrived
Reinhard Poetz wrote:
I propose switching to servlet API 2.4 in *trunk*. This shouldn't cause
any problems as a stable version of Tomcat (5.0.16), the reference
implementation for servlet containers, is available since Dec, 4th 2003.
+1
Vadim
Reinhard Poetz wrote:
Reinhard Poetz wrote:
Every block got 5 positive binding votes and no negative one.
Therefore I will release the four blocks today.
I've released the 4 blocks and the blocks archetype.
Speaking of releases, where those can be downloaded? The latest download present
Jorg Heymans wrote:
On 8/1/06 2:49 PM, in article [EMAIL PROTECTED], Reinhard Poetz
I also think that we should wait with an official announcement as long as we
have at least some minimal docs available at http://cocoon.apache.org/2.2-M1/.
-1 on location specified above. I don't see no sense
Reinhard Poetz wrote:
Vadim Gritsenko wrote:
Jorg Heymans wrote:
On 8/1/06 2:49 PM, in article [EMAIL PROTECTED], Reinhard
Poetz
I also think that we should wait with an official announcement as
long as we
have at least some minimal docs available at
http://cocoon.apache.org/2.2-M1/.
-1
Reinhard Poetz wrote:
The idea is that finally each block gets its own documentation. The
problem now is that we will split up our documentation in smaller chunks
(soon) but we aren't that far. This will cause a lot of broken URL in
the future.
Not if you keep docs in Daisy. If docs are kept
Leszek Gawron wrote:
Torsten Curdt wrote:
IMO the only way to solve this transparently is to more accressively
expire and limit the number of continuations. It would make sense to
come up with a LRU list of continuations per session. This list has a
maximum size that can defined. So the
Reinhard Poetz wrote:
I want to propose Ard Schrijvers as a new Cocoon committer.
+1
Vadim
Simone Gianni wrote:
The third option aims to solve the common situation of having a flow
that initializes some variables, sends a form or a page (creating a
continuation) and then waits for the user to click on a button, that 90%
of time never gets pushed. This is quite common in aggregated
Torsten Curdt wrote:
IMO the only way to solve this transparently is to more accressively
expire and limit the number of continuations. It would make sense to
come up with a LRU list of continuations per session. This list has a
maximum size that can defined. So the required maximum can is
Antonio Gallardo wrote:
Vadim Gritsenko escribió:
Ard Schrijvers wrote:
Now, suppose, the JVM is low on memory. Now, I am used to have 3
stores in my apps, namely defaultTransientStore,
eventAwareTransientStore and the EHDefaultStore. I am not sure how
about projects of other people
Ard Schrijvers wrote:
the StoreJanitorImpl is capable of deleting the entire memory part of the
EHCache when JVM is low on memory: The StoreJanitorImpl counts the number of
keys in cache, and multiplies this with the percent_to_free, to calculate the
number of items to delete from
Ard Schrijvers wrote:
Now, suppose, the JVM is low on memory. Now, I am used to have 3 stores in my
apps, namely defaultTransientStore, eventAwareTransientStore and the
EHDefaultStore. I am not sure how about projects of other people/companies,
(we don't use EHDefaultStore in production.
Mark Lundquist wrote:
OK, so @unique-row-id and @unique-path are deprecated. Got that. In
favor of... what? fb:unique-row? Or fb:identity? Or either,
depending on... something?
I'll be happy to edit this section to make it comprehensible, once I
achieve some understanding of it myself
Ard Schrijvers wrote:
Ard Schrijvers wrote:
I can suggest you two easy enhancements to improve the situation.
1. Stores should have configuration which specifies whether
store should
register itself with the StoreJanitor or not. Default
transient store can be
configured to *not* register
Giacomo Pati wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Fri, 23 Jun 2006, Ard Schrijvers wrote:
From: Ard Schrijvers [EMAIL PROTECTED]
Ard Schrijvers escribió:
We are using many continuations in our projects, implying
have load on memory use (apparantly continuations can be
Carsten Ziegeler wrote:
Vadim Gritsenko wrote:
So you are saying it is still possible to log to LogKit, but it won't be feature
complete / backwards compatible with 2.1? Hm...
Yepp, if people think it's worth having this, I would suggest to add an
own module just for the logkit stuff
Antonio Gallardo wrote:
Joerg Heinicke escribió:
Hello,
I'd like to introduce some people of our community and invite them for
becoming committers of the Cocoon project. Three people do I have in
mind: Andreas Hochsteger, Peter Hunsberger and Jason Johnston.
+3! :-)
+3 here as well.
Reinhard Poetz wrote:
AFAICT there is not much work left to get a first beta release out of
the door.
As far as naming goes, since 2.1m1 we adopted 'milestone' naming, so it should
be 2.2m1.
Vadim
[ http://issues.apache.org/jira/browse/COCOON-1247?page=all ]
Vadim Gritsenko closed COCOON-1247:
---
Fix Version: 2.2-dev (Current SVN)
2.1.10-dev (current SVN)
Resolution: Fixed
added support for multiple results - please try
[ http://issues.apache.org/jira/browse/COCOON-1552?page=all ]
Vadim Gritsenko closed COCOON-1552:
---
Fix Version: 2.2-dev (Current SVN)
2.1.10-dev (current SVN)
Resolution: Fixed
fixed
NullPointerException from
Antonio Gallardo wrote:
Hi Vadim,
It's nice to see you around. :-)
Thanks...
Would you review this issues [1] and close the ones you fixed (if any)?
No, those were not on the list... There is no much folks doing stored
procedures ;-)
Vadim
@@ -47,6 +47,7 @@
*
* @author a href=mailto:[EMAIL PROTECTED]Sylvain Wallez/a
* @author a href=mailto:[EMAIL PROTECTED]Vadim Gritsenko/a
+ * @deprecated This class will be removed in 2.2
* @version $Id$
*/
public class CocoonLogFormatter extends ExtensiblePatternFormatter
What
Jorg Heymans wrote:
[EMAIL PROTECTED] wrote:
+
+You may need anywhere from 5 minutes to 4 hours for this step to
+complete.
+
Unless you want absolutely nobody to try the new build I suggest you
remove this witty comment.
It's not witty, it's factual. Giacomo recently reported that it can
Reinhard Poetz wrote:
Vadim Gritsenko wrote:
Reinhard Poetz wrote:
Vadim Gritsenko wrote:
Hi y'all,
By now, subject isn't news to anyone here, but I have a better twist
on usual maven failures: trunk fails to *clean*. And given that
README suggests performing clean first, nobody
Carsten Ziegeler wrote:
Vadim Gritsenko wrote:
+ * @deprecated This class will be removed in 2.2
* @version $Id$
*/
public class CocoonLogFormatter extends ExtensiblePatternFormatter
What is the replacement?
There is no replacement as we have dropped our own logkit support in 2.2
Hi y'all,
By now, subject isn't news to anyone here, but I have a better twist on usual
maven failures: trunk fails to *clean*. And given that README suggests
performing clean first, nobody following README will be able to build trunk...
Here is the error:
$ mvn clean
[INFO] Scanning for
Carsten Ziegeler wrote:
Carsten Ziegeler schrieb:
I think we should remove the concept of sitemap configurable components
from 2.2 completly.
Today, it is possible that a component implements the
SitemapConfigurable interface and then one can additionally configure
this component on a per
Reinhard Poetz wrote:
Vadim Gritsenko wrote:
Hi y'all,
By now, subject isn't news to anyone here, but I have a better twist
on usual maven failures: trunk fails to *clean*. And given that README
suggests performing clean first, nobody following README will be able
to build trunk... Here
Jorg Heymans wrote:
Vadim Gritsenko wrote:
Well... I already went through 20 mvn install cycles and 3 mvn clean
install... I'd hate to start everything all over! :)
Did you change settings.xml in $M2_HOME/conf to use an alternative
primary mirror ?
No, it is (was) absolutely stock maven
Peter Hunsberger wrote:
On 4/17/06, Adrien Guillon [EMAIL PROTECTED] wrote:
XSLT will be more extensible for site-specific configurations, and more
maintainable than the existing Java code.
I don't see that you'd necessarily have to mark the existing
implementation deprecated. Having the
Jorg Heymans wrote:
Can someone confirm the origin of this dependency to me ? It's not
http://xmldb.sourceforge.net/, i'm suspecting xindice but would like to
be sure.
XML:DB API now located at http://xmldb-org.sourceforge.net/
Vadim
[
http://issues.apache.org/jira/browse/COCOON-1839?page=comments#action_12376530
]
Vadim Gritsenko commented on COCOON-1839:
-
Eric,
Above serializer declaration (oacs-xhtml11) is not valid, even if it works. It
is not either HTML nor XHTML
[
http://issues.apache.org/jira/browse/COCOON-1839?page=comments#action_12376532
]
Vadim Gritsenko commented on COCOON-1839:
-
PS Serializers from org.apache.cocoon.serialization package are standard,
core Cocoon serializers. Those from
Reinhard Poetz wrote:
First, this mail is rather long but everybody who works with trunk (or
wants to work with it again) should read it!!!
What about branch? We supposed to have a svn freeze tomorrow, but branch can't
be checked out at the moment due to (at least) template block being in
Daniel Fagerstrom wrote:
I'd like to propose Niclas Hedhman as a new Cocoon committer.
+1
Vadim
Sylvain Wallez wrote:
It's spring time, new committers are blossoming! I'd like to propose
Simone Gianni for Cocoon committership.
+1
Vadim
Antonio Gallardo wrote:
WDYT?
I agree with all points, but personally I'd prefer to release 2.2 (defined as:
2.1 + new core + mvn monolithic build) and stop maintenance of 2.1 branch. Don't
you think this will be a better alternative? :)
Vadim
Antonio Gallardo wrote:
Vadim Gritsenko escribió:
Antonio Gallardo wrote:
WDYT?
I agree with all points, but personally I'd prefer to release 2.2
(defined as: 2.1 + new core + mvn monolithic build) and stop
maintenance of 2.1 branch. Don't you think this will be a better
alternative
Antonio Gallardo wrote:
Vadim Gritsenko escribió:
Antonio Gallardo wrote:
WDYT?
I agree with all points, but personally I'd prefer to release 2.2
(defined as: 2.1 + new core + mvn monolithic build) and stop
maintenance of 2.1 branch. Don't you think this will be a better
alternative
Jean-Baptiste Quenot wrote:
* Vadim Gritsenko:
http://marc.theaimsgroup.com/?l=xml-cocoon-devw=2r=1s=Cocoon-2.1.X+Tests+Failureq=b
So IIUC you setup automated tests that were stopped since more
than one year? I don't remember the decision to stop them.
Since it generated no interest
Jeremy Quinn wrote:
Many thanks for the links Vadim !!
You *are* welcome, you know. No need for double exclamation marks ;-P
Vadim
regards Jeremy
On 20 Mar 2006, at 18:01, Vadim Gritsenko wrote:
Jeremy Quinn wrote:
On 20 Mar 2006, at 12:41, Bruno Dumon wrote:
On Mon, 2006-03-20 at 12
Carsten Ziegeler wrote:
So the proposed plan to release 2.1.9 is:
- Start code freeze on the 31st of March
- Release on the 6th of April (if nothing bad happens)
+1
Vadim
Jeremy Quinn wrote:
On 20 Mar 2006, at 12:41, Bruno Dumon wrote:
On Mon, 2006-03-20 at 12:00 +, Jeremy Quinn wrote:
Lets say the aggregation part that is in error, is a cocoon://
pipeline, it is possible that the called pipeline has it's own local
error-handler . if this is the
Carsten Ziegeler wrote:
Reinhard Poetz schrieb:
If a testcase gets broken *locally* by a developer, the developer should discuss
the change on [EMAIL PROTECTED] and then people can decide together how to proceed.
That should be the standard procedure in every development project, may it be
Carsten Ziegeler wrote:
Vadim Gritsenko wrote:
http://marc.theaimsgroup.com/?l=xml-cocoon-devw=2r=1s=Cocoon-2.1.X+Tests+Failureq=b
Nice statistics :) I was talking about the tests in trunk.
Well if tests are/were ignored in stable branch, why trunk would be any better?
Vadim
Ralph Goers wrote:
The forms block is now marked stable. I believe legal has given the OK
for us to use the JCR api. To the best of my recollection I believe
those were the only two items standing in the way of a 2.1.9 release.
So please vote.
+1
Vadim
Jean-Baptiste Quenot wrote:
* Antonio Fiol (JIRA):
Three possible approaches:
- Investigate further on the meaning of name;something other than
name;lang-something and try to map that into meaningful XML attributes.
e.g. description;lang-en -- ldap:description xml:lang=en
- Split the
Joerg Heinicke wrote:
On 03.02.2006 14:08, Vadim Gritsenko wrote:
[ http://issues.apache.org/jira/browse/COCOON-1558?page=all ]
Jean-Baptiste Quenot updated COCOON-1558:
-
Bugzilla Id: (was: 35673)
Why bugzilla id is lost here
Leszek Gawron wrote:
Carsten Ziegeler wrote:
So what do people think?
I haven't read any other replies yet but my small brain tells me to be
+100 on this one.
I don't have any objections either - especially since it is backward compatible
both from component and configuration POV.
Vadim
[EMAIL PROTECTED] wrote:
Replace jakarta regexp with java.util.regexp on jdk 1.4 builds for better
reliability and improved performance.
So question is, is it faster now? How much faster and on what regexp/data?
Vadim
Jean-Baptiste Quenot (JIRA) wrote:
[ http://issues.apache.org/jira/browse/COCOON-1558?page=all ]
Jean-Baptiste Quenot updated COCOON-1558:
-
Bugzilla Id: (was: 35673)
Why bugzilla id is lost here, and in many other issues? Is it Jira bug (or
Ralph Goers wrote:
So this is one way to get us motivated to get 2.2 out.
Do you think it's still feasible to release 2.2 with only ECM+ and maven build?
Probably trunk already passed 2.2 release point...
Vadim
David Crossley wrote:
David Crossley wrote:
Vadim, Helma, ... does anyone still have a list of the
filenames from when we investigated this. We will need
to set up re-directs now.
Here are files I used - attached
Vadim
/692.html
/bylaws-addendum.html
/developing/concepts/avalon.html
Reinhard Poetz wrote:
Daniel Fagerstrom wrote:
Agree about not using Castor for the blocks framework. On the same
time it would be better to have a common model, but I don't know how
to best achieve that.
Yes, I was also thinking about this. The best (or even better)
alternative
Bertrand Delacretaz wrote:
Le 13 janv. 06, à 00:24, Ralph Goers a écrit :
I would like to propose a 2.1.9 release...
+1
+1
I also thought about releasing a publishing edition, a binary with
blocks which are useful for basic XML to HTML/PDF/SVG publishing enabled.
As a start, you can
Sylvain Wallez wrote:
[ ] move template block to 2.1 and keep the old implementation
Nitpicking... 'Move' implies it will be removed from 2.2... So:
[X] add template block to 2.1 and keep the old jxtg implementation
Vadim
Sylvain Wallez wrote:
Carsten Ziegeler wrote:
As soon as forms is really called and *treated* as stable: +1
As I said previously, the number of CForms users is such that any change
will have to be backwards compatible.
I removed v2 and v3 as the (unnamed) v1 should be the official API,
Joerg Heinicke wrote:
On 13.01.2006 17:37, Ralph Goers wrote:
I don't see a corresponding email for trunk. Was this also
applied there?
Not yet. Is it urgently needed in 2.2?
I have no idea. It is good practice to apply patches to both branches
just
so it doesn't get forgotten.
Hi All,
Noticed that SVN trunk is broken:
$ svn proplist .
Properties on '.':
subversion/libsvn_subr/subst.c:643: (apr_err=135000)
svn: Inconsistent line ending style
All commands - proplist, propset, propget - fail with same message. Examining
contents of .svn/dir-props shows mixed line
[EMAIL PROTECTED] wrote:
Modified:
cocoon/branches/BRANCH_2_1_X/src/java/org/apache/cocoon/bean/CocoonBean.java
URL:
http://svn.apache.org/viewcvs/cocoon/branches/BRANCH_2_1_X/src/java/org/apache/cocoon/bean/CocoonBean.java?rev=366702r1=366701r2=366702view=diff
Daniel Fagerstrom wrote:
Maven has some cool features!
Do you know - does it support IDEA?
Vadim
$ mvn -Declipse.downloadSources=true eclipse:eclipse
snip/
Berin Loritsch wrote:
Daniel Fagerstrom wrote:
Decomponentization could start right away. Do you have any concrete
examples of components that shouldn't be components?
Pipeline (sure we have two implementations, but that doesn't mean it has
to be a component)
Five implementations. And I
Daniel Fagerstrom wrote:
Carsten Ziegeler wrote:
Daniel Fagerstrom wrote:
Decomponentization could start right away. Do you have any concrete
examples of components that shouldn't be components?
The XMLSerializer/XMLDeserializer combo is one of the best examples, I
think. These
Jorg Heymans wrote:
[ +1 ] flatten the structure and pave the way for a 2.2 release
Minor point: does it have to be 'cocoon-core', 'cocoon-webapp',
'cocoon-blockname'; could it be 'core', 'webapp', 'block-blockname'? Not
sure it will be easy to navigate among all those 'cocoon-foo's :)
Berin Loritsch wrote:
Vadim Gritsenko wrote:
Berin Loritsch wrote:
Pipeline (sure we have two implementations, but that doesn't mean it
has to be a component)
Five implementations. And I imagine after interface cleanup and for
pipeline API, pipeline should stay component
Antonio Gallardo wrote:
Jorg Heymans wrote:
Vadim Gritsenko wrote:
Jorg Heymans wrote:
[ +1 ] flatten the structure and pave the way for a 2.2 release
Minor point: does it have to be 'cocoon-core', 'cocoon-webapp',
'cocoon-blockname'; could it be 'core', 'webapp', 'block-blockname
Carsten Ziegeler wrote:
So I'm coming back to my idea, is anyone against adding constructor
injection to ECM++ or at least make it pluggable so I can add it for my
own projects? The change adds only a feature while maintaining 100%
compatibility.
Why not setter injection?
Vadim
Carsten Ziegeler wrote:
Gianugo Rabellino wrote:
I'm definitely not a fan of constructor injection, exp. when we
consider how (way too) often we resorted to inheritance in Cocoon
components. Now, while interface injection is clearly out of fashion,
sticking with Avalon/Excalibur also means that
Giacomo Pati wrote:
On Fri, 30 Dec 2005, Vadim Gritsenko wrote:
Carsten Ziegeler wrote:
Gianugo Rabellino wrote:
I'm definitely not a fan of constructor injection, exp. when we
consider how (way too) often we resorted to inheritance in Cocoon
components. Now, while interface injection
Ralph Goers wrote:
...
when
bind-xml auto-naming=deriveByClass
is used, Castor starts making up names and trying to load them.
...
I expect, when the resource pool is exceeded the
class loader is completely overstressed and the system comes to a
grinding halt. It doesn't actually stop, but
On Dec 23, 2005, at 9:13 AM, hepabolu wrote:
Nathaniel Alfred wrote:
Please cast your votes!
+1
And here's mine: +1
late, +1
Vadim
On Dec 24, 2005, at 12:16 PM, Ralph Goers wrote:
Has anyone had problems with ehcache? I suspect that our problems
are being caused by problems with data being returned from the
cache when the cache starts writing to disk.
Do you really need persistence store? If not, replace store with
On Dec 25, 2005, at 8:49 AM, Leszek Gawron wrote:
Joerg Heinicke wrote:
On 24.12.2005 20:22, hepabolu wrote:
Merry Christmas everyone.
Thanks and Merry Christmas to you and all others.
I'm also joining the wishes.
Merry Christmas and A Happy New Year
Time to change subject. Happy New
the scope can be reduced so that it doesn't hold a lock while
invoking the pipeline. This may be dumb, but I'm also wondering why the
inner class DocumentHelper is static when it always seems to be created
in getDocumentHelper with new.
Ralph
Vadim Gritsenko wrote:
Looks like you've got
with
cocoon:// protocol, might be a bit ... inefficient.
Usage of DelayedValidity is prescribed here. Do you want to make a stab at
implementing delay: protocol? :)
As far as pools go, I feel like a complete idiot. See my comments below.
Vadim Gritsenko wrote:
Ralph Goers wrote:
Thanks Vadim. I'm
Ralph Goers wrote:
Also, Do you know why Document helper is declared static?
DocumentHelper *class* is static. Why it should not be?
Vadim
Berin Loritsch wrote:
Vadim Gritsenko wrote:
Ralph Goers wrote:
My guess is that the requests are simply coming in faster than
XMLFileModule is taking to release the lock.
That's not important, IMHO. Problem is in pool's lock, not
XMLFileModule's lock.
Are you sure?
90% sure. Have
Vadim Gritsenko wrote:
http-8080-Processor17 daemon prio=1 tid=0x2e3d58c8 nid=0x19eb waiting
for monitor entry [2d7f3000..2d7f587c]
at
org.apache.avalon.excalibur.pool.ResourceLimitingPool.get(ResourceLimitingPool.java:262)
- waiting to lock 0x60088180 (a java.lang.Object)
...
The only
out to L.A. I'll happily buy you a beer! :-)
:)
Vadim
Ralph
Vadim Gritsenko wrote:
Vadim Gritsenko wrote:
http-8080-Processor17 daemon prio=1 tid=0x2e3d58c8 nid=0x19eb
waiting for monitor entry [2d7f3000..2d7f587c]
at
org.apache.avalon.excalibur.pool.ResourceLimitingPool.get
Sylvain Wallez wrote:
So my opinion about ditching our abstraction is that, as we say in
France, it is urgent to wait. Along with the backwards compatibility
problems that ditching the abstraction in 2.2 may lead to, we should see
if that common abstraction comes to life and then consider
Niclas Hedhman wrote:
On Wednesday 14 December 2005 01:26, Carsten Ziegeler wrote:
For the versioning, we could for example release a 2.2 soon, change the
environment abstract after that and then release a 2.3 later this year.
Two more releases this year, YEAH!!!
That's a remarkable spirit
Upayavira wrote:
I would also ask whether we should consider replacing the serializers in
core with those in the serializer block.
Why would you replace single class which works in 99% of cases with 4Mb of code?
Vadim
Sylvain Wallez wrote:
In the meantime, what about simply CoNG, for Cocoon New Generation.
This name isn't that nice, which will make us want to find something
else, but solves the immediate need of having a word to designate this
new thing without fighting about version numbers, separate
501 - 600 of 2061 matches
Mail list logo
