On Sat, 28 Jun 2003, Nicola Ken Barozzi wrote:
Christopher Oliver wrote, On 28/06/2003 19.19:
Nicola Ken Barozzi wrote:
...
I'm really confused about this SWT thing. On my computer Eclipse feels
slower than JBuilder. And I still have to understand what makes SWT so
compelling
difficulties with replacing dtd's and applying schemas, etc. Is there
any good open source endeavor in the area of editing XML? I like Bruno's
pollo for the namespaces it is designed for. What I would like to see is a
good client WYSIWYG editing system that works thru Cocoon services for
multiple authors
good open source endeavor in the area of editing XML? I like Bruno's
pollo for the namespaces it is designed for. What I would like to see is a
good client WYSIWYG editing system that works thru Cocoon services for
multiple authors(with permissions and say corporate associations) from
different
on 6/28/03 4:43 PM Nicola Ken Barozzi wrote:
The fact is that SWT is crap. Total crap.
Pff, SWT is a thin layer on top of the operating system, everything else
is native, therefore optimized and normally hardware accelerated
(today's GPUs are gigaflop machines with gigabyte/sec video mem2mem
Stefano Mazzocchi wrote, On 29/06/2003 19.09:
on 6/28/03 4:43 PM Nicola Ken Barozzi wrote:
The fact is that SWT is crap. Total crap.
This is a bit too much taken out of context I reckon ;-)
It was made to try and show that saying that something is crap or not,
things don't go far.
Pff, SWT is
Christopher Oliver wrote, On 28/06/2003 19.19:
Nicola Ken Barozzi wrote:
...
I'm really confused about this SWT thing. On my computer Eclipse feels
slower than JBuilder. And I still have to understand what makes SWT so
compelling and AWT so dreaded.
Check out JGoodies' fake eclipse LF using
copying the cocoon folks since we are getting pretty serious with
continuations overthere (we implement them using a modified version of
Mozilla Rhino, a javascript engine written in java)
on 6/26/03 3:15 PM Ask Bjoern Hansen wrote:
On Thu, 26 Jun 2003, Santiago Gala wrote:
[...]
I still
On Fri, 27 Jun 2003, Stefano Mazzocchi wrote:
Question: do you think it would be possible to compile java source code
into parrot bytecode? how would the limited Perl typing capabilities
would impact that?
http://www.astray.com/java/
--
!-- Matt --
:-get a SMart net/:-
Spam trap - do not
Stefano Mazzocchi escribió:
(...)
Wow, a VM with native continuations, very interesting.
Question: do you think it would be possible to compile java source code
into parrot bytecode? how would the limited Perl typing capabilities
would impact that?
The key piece is the validator. The Java VM uses
Stefano Mazzocchi wrote:
on 6/26/03 12:01 PM Christopher Oliver wrote:
Another aspect not always noticed is the speed of the compiler. Because
Java compilers don't perform any compile-time optimizations, they are
significantly faster than C++ compilers. This is very important when
dealing
Bruno Dumon wrote:
If you have some time, could you compare the current behaviour with
that of xalan 2.5 and 2.4.1, to see if this got worse recently?
Hello Bruno,
back to these bugs - we stumbled over them in our company, where we use
Cocoon 2.0.4 and updated Xalan to 2.4.1.
The pipe:
a sin to have something OS-specific.
Again, the culture difference between java and python, for example, is
that python has OS-specific features, java does not and will never.
java is based on a common denominator. Python is based on giving access
to what you have.
note how apple provides OS
On Mon, 23 Jun 2003, Ted Leung wrote:
..cut..
- Organisationally xml and java are still lagging behind;
but have been catching up (though the catch up has slowed down
somewhat due to a much larger influx from the old school
side; and that influx is by average younger than
filtered and therefore highly focused on what it means to be a member.
Stefano's insightful post got me carried away to run some stats on
members projects: http://blogs.cocoondev.org/stevenn/archives/001008.html
Please comment if you care, but keep the thread on community (or
cocoon-dev). I'd love
On Mon, 23 Jun 2003, Steven Noels wrote:
Stefano's insightful post got me carried away to run some stats on
members projects: http://blogs.cocoondev.org/stevenn/archives/001008.html
I've always stopped short of doing just this; and more kept things limited
to a pie diagram and postings/#of
Dirk-Willem van Gulik wrote:
On Mon, 23 Jun 2003, Steven Noels wrote:
Stefano's insightful post got me carried away to run some stats on
members projects: http://blogs.cocoondev.org/stevenn/archives/001008.html
I've always stopped short of doing just this; and more kept things limited
On 23/06/2003 21:30 Stefano Mazzocchi wrote:
Dirk is right pointing out how a specific frame in time tells you the
'position' but not the 'speed'. Luckily, social dynamics don't exhibit
the Heinsenberg principle.
To amuse the easily bored, here's 2002, 2001 and 2000:
Steven Noels wrote:
BTW: does anyone know some good Python charting library for this kind
of charts? I've looked at PIL but it seems pretty low-level.
Why not use python to generate xml files suitable for FINS, using cocoon
to generate theese graphs?
http://cocoondev.org/projects/fins.html
On Sat, 21 Jun 2003, Stefano Mazzocchi wrote:
NOTE: copying members@ and community@ since this might be helpful to
many people.
WoW! - Excelent summary. Can we put this up somewhere on one of the
foundation pages please, if need be as 'Stefano's excelent and balanced
view' :-)
Dw.
on the
process and what it means for me.
Note: there is current a debate happening inside the members of the ASF
on the value and meaning of ASF membership so, please, don't take my
words as the ASF truth (if there is one), but just as my personal
opinion on this matter.
Now, for the objective things
On Sun, 2003-06-08 at 10:38, Joerg Heinicke wrote:
[...]
Not remembering the LogTransformer I did the logging in the
HTMLSerializer, but I get the same output using LogTransformer.
And I saw XSLTC does not use any prefix mapping, but as you can see it
does neither use URIs. How is it
Hello Bruno,
Bruno Dumon wrote:
startElement[
uri: '', localName:'xhtml:div', raw:'xhtml:div']
endElement[
uri:'http://www.w3.org/1999/xhtml', localName:'div', raw:'xhtml:div']
if these are corresponding start and end element events, then this is
obviously wrong.
Yes, these are :-(
And using
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20508
Hello Thorsten,
I applied your patch on my system and tested it. But it's even worse
than without the patch :-( It's not your problem, it's because of
extreme hacks I guess.
My test stylesheet:
xsl:template match=/
html
head
The SAX events startElement, endElement, startPrefixMapping,
endPrefixMapping in Xalan:
startPrefix [prefix: '', uri: ''
startElement[uri: '', localName: 'html', raw: 'html'
startPrefix [prefix: '', uri: ''
startElement[uri: '', localName: 'head', raw: 'head'
startPrefix [prefix: '', uri: ''
On Fri, 2003-06-06 at 00:09, Joerg Heinicke wrote:
[...]
Logging of element sax events:
startElement[
uri: '', localName:'xhtml:div', raw:'xhtml:div']
endElement[
uri:'http://www.w3.org/1999/xhtml', localName:'div', raw:'xhtml:div']
if these are corresponding start and end element
Hi all,
The flow PetStore demo uses a yoshi object to hold a couple of utility
objects such as a DateFormat.
So far so good, but what does Yoshi mean ? I guess it's a Japanese
word, but Google gives some funny results :
- Yoshi the pig : http://www.slip.net/~atombee/yoshi2.html
- Yoshi
such as a DateFormat.
So far so good, but what does Yoshi mean ? I guess it's a Japanese
word, but Google gives some funny results :
- Yoshi the pig : http://www.slip.net/~atombee/yoshi2.html
- Yoshi the iguana : http://users.erols.com/ziring/yoshi.htm
- or is it the Nintendo game ? http
Hi:
I currently downloaded the lastest CVS from cocoon-2.1. I am using Tomcat
4.1.18. After a sucessfull compile of the sources. I noted the following:
1-If I install the cocoon.war into Tomcat, after this I shutdown it using
./shutdown.sh
Please note that I already can see the working
On Fri, Mar 14, 2003 at 05:09:16AM -0600, Antonio Gallardo wrote:
Hi:
I currently downloaded the lastest CVS from cocoon-2.1. I am using Tomcat
4.1.18. After a sucessfull compile of the sources. I noted the following:
1-If I install the cocoon.war into Tomcat, after this I shutdown it
Hi Jeff!
Thanks for the answer. I was going crazy with this. Also I was trying the
new 4.1.21 BETA for development purpose when the problrm starts.
This is why I changed all back and trying to resolve this issue. Well, I
looks like I have not Good luck when did the change. :-D
Best Regards,
I have introduced one line patch over a month ago (
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16695 ) and it still has not
been neither accepted nor rejected
ouzo
--
__
| / \ |Leszek Gawron// \\
\_\\ //_/ [EMAIL PROTECTED]
Hello,
When you run a Cocoon application, what is the very first servlet that is loaded?
Thanks
Sylvain
Am Die, 2003-03-04 um 15.00 schrieb [EMAIL PROTECTED]:
Hello,
When you run a Cocoon application, what is the very first servlet that is loaded?
Cocoon gets lauched via the CocoonServlet.
take a look at org.apache.cocooon.servlet.CocoonServlet.
That is the only servlet that is exportet via
I just want to keep on the tradition of writing mails
that explain what cocoon is doing wrong :(
We really should avoid action fast when this has a great impact
on all developers and all users of cocoon, like renaming cvs repositories
etc. Reverting things like these is more than a pita.
So, we
you stop sitting on your ass and send out a patch to the mailing
list, how can you do the same when what you wanted to propose is the CVS
repository itself?
My vision is pretty simple, you do it, and you keep it backward compatible,
exactly as I did. All the old repositories, with all the old
new repositores as part of your proposal?
What will happen if I now check-in something only into the old rep?
What will happen if I now check-in something only into the new rep?
I don't see that it helps to create a repository to discuss how it
should be named.
So can we then simply start a proposal
Pier Fumagalli wrote:
My vision is pretty simple, you do it, and you keep it backward compatible,
exactly as I did. All the old repositories, with all the old branches, with
all the old names, are _still_ there (the only unrevertable change is the
fact that now they're owned by the cocoon group,
On 27/2/03 10:30 am, Gianugo Rabellino [EMAIL PROTECTED] wrote:
Now, call me fascist if you want, but to avoid people to commit back
to the old repository names, I've removed YOU ALL karma to the old
repositories...
(which, BTW, makes perfectly sense from a sysadm POV). Not to mention
Carsten Ziegeler wrote:
I just want to keep on the tradition of writing mails
that explain what cocoon is doing wrong :(
We really should avoid action fast when this has a great impact
on all developers and all users of cocoon, like renaming cvs repositories
etc. Reverting things like
PROTECTED]
Subject: Re: What Cocoon is really doing wrong [was: CVS repository
changes... (and what's left to do)]
Carsten Ziegeler wrote:
I just want to keep on the tradition of writing mails
that explain what cocoon is doing wrong :(
We really should avoid action fast when this has
On 27/2/03 11:15, Carsten Ziegeler [EMAIL PROTECTED] wrote:
Ok, Stefano, Pier, all others, I guess we can simply
stop this thread and go on with the proposal discussion.
I had the perception that it wasn't revertable and that because
all karma to the old repos was removed that is had already
J.Pietschmann wrote:
Leo Simons wrote:
the alternative is to only depend on
http://www.apache.org/dist/avalon/excalibur/latest/
What worries me is that excalibur depends on a class
distributed with Xalan.
which package are you referring to, and why is it worrying it depends on
Xalan? Something
Leo Simons wrote:
which package are you referring to,
IIRC org.apache.xml.utils.PrefixResolver
and why is it worrying it depends on Xalan?
I'd like to rip out the Xalan jar, put in Saxon, and start
Cocoon without being surprised by a ClassDefNotFound exception.
J.Pietschmann
.
And what does released mean? One could argue that an alpha version
is a released version ;)
I would like to relax the policy a little bit to:
Never release a stable version that depends on non-released stuff (where
released version has to be at least stable in API).
If I followed the policy
have all the same source
that I discribed in two emails last year (about our community being
healthy), but until today noone even commented my emails. So, it will be
interesting to see what this RT will do.
I would like to a add one more point: Most of us do not care about
releasing new versions. We
not put code in HEAD that depends on a
unreleased software that *NEVER* made a 1.0 release. This will keep the
contracts shaped up.
Good point.
Moving the SourceFactory to Avalon made a mess. This is what I'm mostly
concerned at the moment. What is the status of this?
I personally don't see
Carsten Ziegeler wrote:
First, Stefano, relax - I didn't want to attack you directly.
Don't assume that all my comments were hinting at something you did!
Sorry but it looked pretty personal to me.
Apologies if it was not the case.
Moving the SourceFactory to Avalon made a mess. This is what I'm
ON DEPRECATED SHOULD GO AWAY --
!--path location=${deprecated.src}/--
path location=${build.src}/
path location=${java}/
and recompile.
You'll see what I consider a mess.
Yes, I know.
I don't necessarely blame the Source refactoring since it could well be
that some
I want to know if somebody feels like I'm doing this but remains silent
because of any reason.
Perhaps because you are Stefano? Think about it :-).
Matthew
--
Open Source Group Cocoon { Consulting, Training, Projects }
=
Jeff Turner wrote:
What would removal of the Scratchpad force on the community?
* More controlled innovation. Instead of anybody using it as their
personal playground, it would force the development to be more in
the face of the community.
Hence schecoon would have been shot down in flames
dictator, no matter what great technical vision one is leading to.
I hope this is clear enough.
--
Stefano Mazzocchi [EMAIL PROTECTED]
Pluralitas non est ponenda sine necessitate [William of Ockham]
ours.
I don't really care who's to blame, there's just an issue needing
fixing...though I support the search for the right policy :D
If people that know both cocoon and avalon well can figure out what
stuff in avalon it is that cocoon _really_ needs atm, and we can figure
out what it takes to get
Leo Simons wrote:
Stefano Mazzocchi wrote:
(AltRMI is no longer part of avalon though; that's in incubator now)
Of this list, if it is possible and sensible to remove the cocoon deps on
cli,
Easy enough.
collections,
concurrent,
Both done--all that is required is a new ECM
IO,
I don't think
Stefano Mazzocchi wrote:
Recently on avalon-dev I expressed my concerns about their habit of
moving stuff around for elegance-sake, but I'm starting to think that
Cocoon is abusing avalon and this places too much pressure on their
shoulders.
Example: the instrumentation. The Cocoon core
Stefano Mazzocchi wrote:
ah, the load, the load! I can't take it anymore
action type=jump-of-cliff entity=avalon/
Aaa a a a ah!
:D:D Just kiddin' :D
LOL :)
Anyone know the album cocoon crash by K's Choice? Sounds a bit
different :D
I have to be honest with you: I find the
missing modules and install
missing packages. Read the data definition material
(http://jakarta.apache.org/gump/overview.html) on the gump site.
Hmmm, I have 500Mb left on my harddisk :/ but I'll see what I can do. [I
know, I know, I should buy a new laptop, but Apple is delaying shipping
/avalon/logkit/latest/ which
currently points to LogKit 1.2.
Hmmm, I have 500Mb left on my harddisk :/ but I'll see what I can do. [I
know, I know, I should buy a new laptop, but Apple is delaying shipping
the titaniums... I smell hardware upgrade on the 15 line]
Only 15 ? Those 17 laptops look
Leo Simons wrote:
the alternative is to only depend on
...
http://www.apache.org/dist/avalon/excalibur/latest/
What worries me is that excalibur depends on a class
distributed with Xalan.
J.Pietschmann
Stefano Mazzocchi wrote:
I'm slowly working at finding out the internal dependencies of Cocoon
core myself. Let's not step on each other toes.
I wouldn't worry 'bout that. Me not cocoon committer, nor intending to
become one :D
cheers,
- Leo
it on the head. It's called 'continous integration'. No, dude, I won't
make it easier for you, I want it to make it harder so that everybody
sees what you're doing and can improve on it.
I repeat my proposal to kill the scratchpad
enough for now. i need food.
--
Stefano Mazzocchi
JVM. The Avalon team is
also looking into this dependency ourselves. It is somewhat messy to
require AltRMI for instrument (which we are looking to officially
release RSN).
why we depend on cornerstone-excalibur-thread*?
That's what I asked a while ago.
Scratchpad considered harmful
Stefano Mazzocchi wrote:
I repeat my proposal to kill the scratchpad
Totally +1, since it will hopefully also motivate people to start a
project next to and depending on Cocoon rather than inside it.
enough for now. i need food.
Bon appétit ;-)
/Steven
--
Steven Noels
Steven Noels wrote:
Stefano Mazzocchi wrote:
I repeat my proposal to kill the scratchpad
Totally +1, since it will hopefully also motivate people to start a
project next to and depending on Cocoon rather than inside it.
Actually, I have a need to do this, and I wonder what the best
approach
things around with core stuff, I *WANT* you to do
it on the head. It's called 'continous integration'. No, dude, I won't
make it easier for you, I want it to make it harder so that everybody
sees what you're doing and can improve on it.
I repeat my proposal to kill the scratchpad
Hmmm... how
called 'continous integration'. No, dude, I
won't make it easier for you, I want it to make it harder so that
everybody sees what you're doing and can improve on it.
I repeat my proposal to kill the scratchpad
Hmmm... how could we have done the flow without the scratchpad?
Do you really think
-blocks dir, and that will automatically solve many
of these problems and clear the scratchpad.
Let's KISS. Let's start with the obvious. Move the scratchpad into
scratchpad-blocks and see what's left. We may be surprised.
+1
...
What would removal of the Scratchpad force on the community
On Tuesday, Feb 25, 2003, at 20:57 US/Pacific, Jeff Turner wrote:
What would removal of the Scratchpad force on the community?
* More controlled innovation. Instead of anybody using it as their
personal playground, it would force the development to be more in
the face of the community
source
that I discribed in two emails last year (about our community being
healthy), but until today noone even commented my emails. So, it will be
interesting to see what this RT will do.
I would like to a add one more point: Most of us do not care about
releasing new versions. We *must* come back
Carsten Ziegeler wrote:
What do you mean with tagging that file? I assume, you mean
copying the file from head to the branch, so that it's in 2.0.5 as well,
right?
I don't know if a simple copy is sufficient, perhaps someone else can
help in here?
Gimme one or two days and I'll do
I was going to ask a commiter to tag AbstracMultiAction.java
with the cocoon_2_0_5 branch tag but there doesn't seem to be one.
I thought cocoon_2_0_4 was released, what's going on?
Thanks,
Artur...
-
To unsubscribe,
AbstractMultiAction with the
2_0_... what the ...
There is no cocoon_2_0_5_branch.
When we decided to split the development of 2.1 and 2.0.x we created
a branch for 2.0.x that was unfortunately named cocoon_2_0_3_branch.
This branchs contains 2.0.3, 2.0.4 and 2.0.5 etc.
The versions
What do you mean with tagging that file? I assume, you mean
copying the file from head to the branch, so that it's in 2.0.5 as well,
right?
I don't know if a simple copy is sufficient, perhaps someone else can
help in here?
Carsten
-Original Message-
From: Artur Bialecki [mailto
that they won't
change, but once you remove Component interface from, say, Generator,
it means user's code won't compile anymore without change.
What do you mean it won't compile anymore without change?
Berin,
Please see example sent in response to Ken's question:
Generator g;
Component c = g
should argue on this point instead
of me! But if you want to go down the road of academic and practical
backward compatibility, then I rest my case.
IOW, what does it buy you to perform the bad code snippet above?
For all practical and real requirements, it is safe to remove the
Component
Stefano Mazzocchi wrote:
...
PS As JDK1.2 Poll goes, nobody reported to be using Cocoon with JDK
1.2 so far... Let's wait till the end of the week.
Shouldn't we ask *users* instead of developers?
We did, they are already replying.
Only one IIUC is still using 1.2 till now.
--
Nicola Ken
Leo Simons wrote:
Berin Loritsch wrote:
_It has already been taken care of_
just because it is possible and advisable for cocoon to remove the
reference to Component from their sources doesn't mean we should push
them or our other users into doing so. What about picking a current
cocoon
Stefano Mazzocchi wrote:
Vadim Gritsenko wrote:
PS As JDK1.2 Poll goes, nobody reported to be using Cocoon with JDK
1.2 so far... Let's wait till the end of the week.
Shouldn't we ask *users* instead of developers?
We've asked on cocoon-users. :)
Who else shall we ask?
Vadim
, but once you remove Component interface from, say, Generator, it
means user's code won't compile anymore without change.
What do you mean it won't compile anymore without change?
Of course it will. You can remove interfaces at will. If the class
still implements all the methods that are part
with assumption that they won't
change, but once you remove Component interface from, say, Generator,
it means user's code won't compile anymore without change.
What do you mean it won't compile anymore without change?
Berin,
Please see example sent in response to Ken's question:
Generator
the
Component interface.
All expected uses of the Component interface have been accounted
for.
Yes we should try to keep backwards compatibility. You can go crazy
trying to think of every bastardization of the accepted use and corner
yourself into ineffectualness.
IOW, what does it buy you
Nicola Ken Barozzi wrote:
Peter Donald wrote:
On Thu, 30 Jan 2003 08:05, Leo Sutic wrote:
I'd just like to see what you in Avalon-dev have to say about this:
Update Cocoon to latest Avalon code and remove Component from the
Cocoon codebase (A 30 min job?) and the deprecation warnings
Berin Loritsch wrote:
#3 We can safely remove the Component interface (the source for most
deprecation warnings).
I'm trying to be cautious about removing it from public well-known
interfaces. Users are writing code with assumption that they won't
change, but once you remove Component
Vadim Gritsenko wrote:
Berin Loritsch wrote:
Jeff Turner wrote:
Does this seem like a viable solution? We are trying to get a feel
for the best action from this point forward.
Why deprecating this interface in the first place? I don't see how
presence of (non-deprecated) Component
to Serviceable'ize the codebase.
If none come forward before beta, use a recompiled Framework without
the @deprecated
Given the fact that we have to provide full backward compatibility in
2.x series, which means that all Components and Composables must be
honored, what is the reason moving
Vadim Gritsenko wrote:
Avalon gurus out there - should we fork framework? ...
oh, god, I knew it was coming, I was counting the days.
please don't, let's try to work a solution with them instead.
--
Stefano Mazzocchi [EMAIL PROTECTED]
Stefano Mazzocchi wrote:
Vadim Gritsenko wrote:
Correction:
flamebait
Avalon gurus out there - should we fork framework? ...
/flamebait
oh, god, I knew it was coming, I was counting the days.
please don't, let's try to work a solution with them instead.
I was trying to provoke
these deprecation warnings are annoying, and furthermore
destroy the usefulness of deprecating some classes in Cocoon since we
remove all deprecation warnings.
But instead of forking, what about a tool that automatically removes the
deprecation flag on thoses Avalon classes that aren't
Jeff Turner wrote:
On Mon, Jan 27, 2003 at 07:19:05PM +0100, Ugo Cei wrote:
You should get back a JaxpParser instance, which is a Component, so the
cast is valid. I'd imagine the compiler doesn't realise this at
compile-time, and you'd get a ClassCastException if it wasn't a
Component.
Berin Loritsch wrote:
Jeff Turner wrote:
...
Yes, those deprecation warnings are annoying and misleading, because
Component is deprecated for Avalon, not Cocoon. Perhaps Cocoon should
have a special avalon-framework-nodepr-4.1.3.jar , without the
@deprecated?
The current version of the
of influence is not a component. That is unreastic and irratrional.
This means that the hunreds of standard compoents (refer OMG work) are
nbot realy components. This means that unless I incorporatye this
particular interface I cannot interoperate in a Avalon framework.
That's what is wrong
framework. That's what is wrong with Componet - it locks you into
Avalon. The truth (and the reason for the Service4 package) is that
you don't need lock in - you need liberty.
Cheers, Steve.
I kind of understand this part about bringing non-avalon components
into Avalon, and also I don't
interoperate in a
Avalon framework. That's what is wrong with Componet - it locks you
into Avalon. The truth (and the reason for the Service4 package) is
that you don't need lock in - you need liberty.
Cheers, Steve.
I kind of understand this part about bringing non-avalon components
standards - and guess what - they don't declare standard
components via org.apache.avalon.framework.component.Component. This is
nothing more that an artificial limitation on your developers. If you
want to introduce a JDBC driver as a component - you cannot because it
does not implement
Hi Steve!
Your name was familiar to me. But I dont remember from where after I put
my sight up to the books that are in a bookshelf up my monitor. I have two
books of you:
Software Prject Survival Guide and After the Gold Rush.
I am glad to meet you again here in the Cocoon developer community.
Jeff Turner wrote:
Looking in excalibur-xmlutil-20030122.jar, I found this class:
org.apache.excalibur.xml.sax.Parser.
I guess you mean o.a.e.xml.sax.SAXParser (to complement
o.a.e.xml.dom.DOMParser).
Oh yes, but I'm still using excalibur-xmlutil-20030115.jar instead of
Jeff Turner wrote:
On Mon, Jan 27, 2003 at 07:19:05PM +0100, Ugo Cei wrote:
...
if (saxParser != null) manager.release((Component) saxParser);
(cripes.. I've been happily nulling it in my code.. I'd better go fix:)
:)
I guess you are prepared for Avalon 5 where (going by rumors)
Once upon a time there was a org.apache.cocoon.components.parser.Parser,
but now it's deprecated. OK, so I think I should use the Excalibur
parser component, which has recently been split into a SAX parser and a
DOM parser.
Looking in excalibur-xmlutil-20030122.jar, I found this class:
On Mon, Jan 27, 2003 at 07:19:05PM +0100, Ugo Cei wrote:
Once upon a time there was a org.apache.cocoon.components.parser.Parser,
but now it's deprecated. OK, so I think I should use the Excalibur
parser component, which has recently been split into a SAX parser and a
DOM parser.
Looking
In the block refactoring, I've come across Servlet Generator. Whatever
the name tells you, it seems to have nothing to do with Servlets.
Probably it's due to the includion of the environment abstraction.
Why not simply move these methods in ComposerGenerator and make classes
using this use
Geoff Howard wrote:
I have a sub sitemap mounted under a sub directory,
and within an action called from that sitemap I am
calling context.getRealPath(dir-name).
I expected it to resolve dir-name relative to the
mounted directory, returning
1 - 100 of 185 matches
Mail list logo
