On 7/25/07, Al Maw <[EMAIL PROTECTED]> wrote:
Hi folks,
Although some people don't really care what their URLs look like, lots
of people do.
If you use UrlCompressingWebCodingStrategy you can get the actual
parameter values for interface/behaviour/etc. URLs looking pretty small
and inoffensive.
Component comp = new Component(new MyChainingModel(new HibernateModel(new
Pojo(;
IModel model = comp.getInnerMostModel()
Naively, just looking at the code, I would expect the HibernateModel to return.
Eelco
we also have IChainingModel shouldn't we also test for that?
because çurrently the behavior is that we only test for WramModels to get to
the innermost model
but what is then the big difference with IChainingModel?
Hey, didn't you code that stuff? :)
Eelco
On 7/19/07, Matej Knopp <[EMAIL PROTECTED]> wrote:
Well, actually, there is none. The reference is filtered only by URL.
You can submit a feature request for adding an ID to it.
Yeah, we should take a look at it.
Eelco
On 7/17/07, Bruno Borges <[EMAIL PROTECTED]> wrote:
Sure Eelco... :) As soon I get something "showable"... I'll show you... lol
Cool :)
Eelco
On 7/17/07, Johan Compagner <[EMAIL PROTECTED]> wrote:
wicket is a framework for dynamic webpages, so 99% of the time you don't
want to cache
and you want to make sure that the browser does query again for the page.
Also the none bookmarkable pages are like wicket:interface= and that xxx
can
Surely you can just register it like that, but also put the name of the
Wicket application (getName()) in the attribute key?
Of course, that requires you to pass in the name of the Wicket app to
your Seam stuff somehow, but if you want to support running multiple
apps in a single context then you
On 7/16/07, Jean-Baptiste Quenot <[EMAIL PROTECTED]> wrote:
* [EMAIL PROTECTED]:
> Author: ehillenius
> Date: Sun Jul 15 13:20:59 2007
> New Revision: 556443
>
> URL: http://svn.apache.org/viewvc?view=rev&rev=556443
> Log:
> register the web application instance with the servlet context so that
On 7/15/07, Juergen Donnerstag <[EMAIL PROTECTED]> wrote:
no big plus, just playing a bit and having the option if some realy
realy needs it.It should not go into the core project for sure. I'm
just looking for the right place to drop it. If extension is not the
right place either, due to the dep
I opened an issue here http://issues.apache.org/jira/browse/WICKET-746
Eelco
this is not really solveable by wicket itself.
We don't know where such a reference is comming from, so this should be
documented i guess
that if you use session data from the session object itself. You should
always use an extra
indiretion to get it
new Model()
{
getObject() {Session.get().getL
1. Automatically insert an attribute value that's the same as the name
(which I think it always should be), for things like disabled.
2. Prevent people adding null values to the map in the first place. To
do this, we'd need to wrap the IValueMap in XmlTag with some magic
on the
On 7/8/07, Sven Meier <[EMAIL PROTECTED]> wrote:
See:
label.add(new AttributeModifier("onclick", true, new
Model("someFancyJavascript(\"fancy\")")));
... will result in something like:
For Firefox the value of onclick is now "someFancyJavascript(\", this is
the problem I'm experiencing.
either
[ x ] remove the affected FormComponent constructors with the type parameter
or
[ x ] deprecate the affected FormComponent constructors with the type parameter
Eelco
On 7/10/07, Juergen Donnerstag <[EMAIL PROTECTED]> wrote:
Today I've committed the new Border to 1.3 trunk. I would appreciate
if you could do a quick check of your applications using Borders to
make sure everthing is working as expected. Thanks.
Hi Juergen. We are experiencing some problems wi
instead of removing it completely can you make it hidden by default and add
a link that will show it? i agree that it is not useful, i have never really
used it myself for anything at least. if it was our treetable it would be
easier to understand imho, but even then its usefulness can be argued.
Hi,
Our first part of the ExceptionErrorPage works fine. It's
straightforward and displays useful information.
I'm not happy with the PageView part though. Tbh, I don't think I ever
read anything from tree that helped me. What's worse, the size bit in
the PageView can be a serious hog sometimes.
Good. Makes the review easier ;-), and you've only the one to remove.
I've opened an issue for it http://issues.apache.org/jira/browse/WICKET-730
Eelco
Not only should you not need to add a finalizer, but most importantly,
review your codebase and *remove* all finalizers.
It's the only one in there.
Eelco
* provide link to switch it on on exception page
Nice idea!
Eelco
> Anyway, Al, what's your take on this?
Do I have to have one? ;-)
I've fixed the bug I was having, haven't had time to compare the two
divergent branches since, sorry.
I meant Noel's remarks, specifically:
"So you do have an old version of the FileCleaner, albeit prior to
enhancements that h
[ x ] disable this feature by default, put instructions on how to enable it
into component-not-found related exception messages
[ ] leave it enabled by default
I've argued before that if it were up to me, deployment would be our
default. Lost that argument and that is fine, but I feel that debug
On 7/6/07, Johan Compagner <[EMAIL PROTECTED]> wrote:
and if i remember correctly, back then it looked if the FileUpload project
was really in suspend stage.
there wasn't much happening on it, so i am talking abou the time we added it
to the core of wicket
Yeah, that's one of the reasons why we
I understand "we just took what little pieces we needed instead of adding a
dependency on the entire thing", but what is meant by "the code grew in a
different direction due to various reasons"?
We started using commons-io as just a dependency, but after a while we
needed some tweaks to better l
For that matter, why aren't you using Commons? The very problem (file
uploading) you are dickering with is precisely one that we addressed in
Commons years ago. The core code is in Commons I/O:
http://svn.apache.org/viewvc/jakarta/commons/proper/io/trunk/src/java/org/ap
ache/commons/io/
We ha
Thanks for adding the 'INullAcceptingValidator'. This solves our problem in a
clean way.
Just a small suggestion: I've seen that the CompoundValidator does not
implement this interface. Would it not be correct to assure that the
CompoundValidator is called always, and that the same logic of check
I have found the following classes in Wicket 1.3.0-beta2:
1) SecondLevelCacheSessionStore
2) SecondLevelCachePageMap
3) SecondLevelCachePageVersionManager
4) FilePageStore
Not really other than the Javadocs. But the short variant:
SecondLevelCacheSessionStore and FilePageStore are the on
On 6/30/07, Juergen Donnerstag <[EMAIL PROTECTED]> wrote:
BoxBorderTest_7 currently fails with Bamboo but it is working fine
with me. The Bamboo online information from the test doesn't give me a
hint either. And idea? I guess Bamboo is running on Linux?
I found and fixed an issue in MarkupPars
Changing the case of Java files tends to cause pain on Windows systems,
because they're case-insensitive. We're almost guaranteed to have people
with strange ClassNotFoundExceptions if we go and do this.
It's yet another API change just before we release 1.3.0.
If we fix the class names, we shou
On 6/30/07, Juergen Donnerstag <[EMAIL PROTECTED]> wrote:
BoxBorderTest_7 currently fails with Bamboo but it is working fine
with me. The Bamboo online information from the test doesn't give me a
hint either. And idea? I guess Bamboo is running on Linux?
Fails on my machine as well. It says the
I'm proposing to move things a bit around.
Sounds good to me, +1
Eelco
[ x ] I have checked the distribution and +1 its release
[ ] I haven't checked the distribution and +0 its release
[ ] I have checked the distribution and -1 its release because...
Eelco
[ ] I checked the distribution, and I +1 the release of them
[ x ] I didn't check the distribution, but I want to release them
regardless (+0)
[ ] I don't want to release the distribution, because ...
Eelco
On 6/25/07, Matej Knopp <[EMAIL PROTECTED]> wrote:
I think reasonable behavior would be to generate markup id when
invoked from constructor (instead of failing getting one from markup).
However, I'm affraid the complications you have are caused by the fact
the the component hasn't been rendered a
may I ask for commit rights for sourceforgeuser "svenmeier" on wicket-stuff?
He is massive help on gmap2, commit rights for him would help its
develoment a lot.
Done. Thanks for helping out!
Eelco
i can think of one, getMarkupId() can't really be called in the constructor
phase (as we could do in 2.0)
(it now can but then you really have to make sure how you construct your
objects you have to setup the hierachy up until the page as soon as
possible)
Yeah, even now the component has to be
On 6/25/07, Martijn Dashorst <[EMAIL PROTECTED]> wrote:
What are the side effects?
Jonathan had problems:
http://www.nabble.com/Unable-to-find-the-markup-for-the-component-tf3976741.html
and
the project I'm working on got some exceptions from the test site this
morning as well. For instance:
o
at this time I have no idea on how to fix it.
Eelco
On 6/24/07, Eelco Hillenius <[EMAIL PROTECTED]> wrote:
> I believe the current behavior is intentional. Igor seemed to feel
> quite strongly about not using markup id specified in template. The
> reason is that it's not un
I believe the current behavior is intentional. Igor seemed to feel
quite strongly about not using markup id specified in template. The
reason is that it's not unique and it behaves wrongly in repeaters or
when you put the component to page twice.
I remember having this discussion a very long tim
On 6/24/07, Martijn Dashorst <[EMAIL PROTECTED]> wrote:
I think everyone ran into it at one time... I know I did. Last time I
think Igor threw some issues with repeaters into the mix, and then the
discussion went dead.
For all I know, it worked in 2.0. I remember testing it specifically.
I'm ju
Yep, you read that right. I just found out that if you explicitly
define an id attribute on your component, getMarkupId still just
returns a generated one. This suprises me; I'm pretty sure we always
agreed that if an explicit id is provided in the markup, that should
be used. See the date picker
https://issues.apache.org/jira/browse/WICKET-689 is very related to this.
Yep, that and working on Wicket In Action, triggered sending this email.
I can't see if there will be any unwanted consequences by doing this
Don't think so. If people for whatever reason want more indirection
they can
IRequestCycleFactory and ISessionFactory annoy the hell out of me. We
simplified how they are used a bit in 1.3, but imho, I think we should
just ditch them all together in favor of simply two factory methods in
application. Factory method newSession already exists in
WebApplication (as that class
On 6/22/07, Martin Funk <[EMAIL PROTECTED]> wrote:
That's were 'ctrl' + 'r' comes into play.
Figure it out once and your history never forgets:-)
And if it does beefing up 'export HISTSIZE=5000' might help.
Indeed :) I also keep a document around with my favorite tricks.
Though I'll never be u
And the best thing about these unix commands is that they are so obvious :)
Eelco
On 6/21/07, Martin Funk <[EMAIL PROTECTED]> wrote:
Martijn Dashorst schrieb:
> The benefits of unix:
>
> find jdk-1.4/wicket -name "*.js" | xargs grep -E "rag|rop"
>
> delivers
> jdk-1.4/wicket/src/main/java/org/
Janne, are you reading with us?
Eelco
On 6/21/07, manunabble <[EMAIL PROTECTED]> wrote:
Hi,
I am on testing my recently-"old"-webapp, now migrated
without-code-compilation-errors to a portlet-application, and my
custom-session implementation forces me to implement
new-PortletRequestCycle, and
How does an application developer use Wicket.Drag?Will there be a
DraggableBehavior (IBehavior) object?
It is used for the Ajax debug panel. Not sure if Wicket.Drag is used
for anything besides that. But there are multiple Wicket-stuff
projects that have support for drag and drop. See
http:/
See how confused we are? :)
Seriously, if we can't agree on it, we should just pick the shortest names ;)
Eelco
On 6/21/07, Johan Compagner <[EMAIL PROTECTED]> wrote:
AjaxSubmitButton is a right name because its only purpose is that it
submits a form right?
But i don't mind that it is renamed
Hi,
I just came across this:
http://cwiki.apache.org/WICKET/using-gwt-widgets-as-wicket-components-tutorial.html
Did someone ever did that? Is it a good idea to have such integration
rather than just running GWT as an applet? And if this is a good idea,
how about putting this in a Wicket-stuff p
maybe the exception display page should just hide all the extra details
using a javascript
triggered fold-out instead of trying to programmatically remove it?
That would be nice.
Eelco
I've given this thread a little bit thought, and besides the
objections Martijn and me have regarding the book, I don't think I
like SubmitButton better than Button. To me, a Button is more generic
and SubmitButton makes me think about 'just' the
tag while it can be used for more than that (which
[ x ] Yes, rename AjaxSubmitButton to AjaxButton, leaving behind a
@deprecated subclass for backwards-compatibility.
[ ] No, that's a crazy idea. We're frozen for 1.3.0 and this sort of
stuff shouldn't change this late in the day.
Eelco
bah, i'd rather have the rename. I have absolutly no problem with a
rename as long as it is announced on the mailing list.
That's fine. But I have :). And I have been bitten by it enough to
know that without such a deprecation realease, people *will* forget/
not notice.
Eelco
On 6/20/07, Maurice Marrink <[EMAIL PROTECTED]> wrote:
Whatever makes you happy :)
I see Johan as has already made the change of putting callDestroyers
in internalDestroy.
However if you are going to rename that method (not sure if Martijn is
going to like that this late in the game). Please let
Done.
Eelco
On 6/19/07, Igor Vaynberg <[EMAIL PROTECTED]> wrote:
go for it
-igor
On 6/19/07, Eelco Hillenius <[EMAIL PROTECTED]> wrote:
>
> AbstractBehavior#isEnabled(Component component) currently returns true
> by default. Wouldn't it be better if it
AbstractBehavior#isEnabled(Component component) currently returns true
by default. Wouldn't it be better if it was implemented like this?
public boolean isEnabled(Component component)
{
return component.isEnabled();
}
Behaviors should be ignored when a com
Ok. I set it to 100. Is that reasonable?
Eelco
On 6/19/07, Sean Sullivan <[EMAIL PROTECTED]> wrote:
Short.MAX_VALUE is definitely too high.
I'd love to see a lower value.
Sean
On 6/18/07, Eelco Hillenius <[EMAIL PROTECTED]> wrote:
>
> max int is actually a prett
On 6/19/07, Eelco Hillenius <[EMAIL PROTECTED]> wrote:
Maybe a bit OT, but how exactly do you implement this Jan?
The project I'm working on has:
public final class ValidationListener implements
IComponentOnBeforeRenderListener {
public void onBeforeRender(Component componen
Maybe a bit OT, but how exactly do you implement this Jan?
The project I'm working on has:
public final class ValidationListener implements
IComponentOnBeforeRenderListener {
public void onBeforeRender(Component component) {
if (component instanceof FormComponent && !component.hasBeenRender
Someone has had any problems with loading resources in OSGI ?
I have no experience with it, but I know that plenty of people are
using Wicket + OSGi. Hope they are reading with us?
Eelco
Hi folks,
The wicket-spring project currently has some generic injection and proxy
classes with no Spring dependencies.
If we want to provide support for Guice, these should go and live
somewhere else, otherwise wicket-guice will need to depend on
wicket-spring, which seems silly. ;-)
There are
max int is actually a pretty rediculous default in itself. How about
setting it to 1,000 or even 100 or such?
Eelco
On 6/18/07, Eelco Hillenius <[EMAIL PROTECTED]> wrote:
Why would you want to do that? Sure, we can put a setter in there, but
it is really only meant to detect cycles.
Why would you want to do that? Sure, we can put a setter in there, but
it is really only meant to detect cycles.
Eelco
On 6/18/07, Sean Sullivan <[EMAIL PROTECTED]> wrote:
In RequestCycle.java, the steps() method has this code:
* final* *int* maxSteps = Short.MAX_VALUE;
Is there any way for
-1 on the streamline. I'm not going to go through and rewrite my
chapters of the book yet *again*.
Can we just agree to keep the API stable?
Yeah, +1 on that. You guys scare the hell out of me if I have to think
about how long *any* book will be valueable on any version :-) It's
time to settle
In the case I was wanting to work with markup inheritance didn't really work
right as I wanted to change the used border on the fly, in the end I just
used object inheritance having the subclassed pages to call "border.add()"
rather than add() directory (with the border defined/added by the base c
On 6/8/07, Mark Derricutt <[EMAIL PROTECTED]> wrote:
Hey all,
Hey Mark,
Just catching up on my wicket-foo and noticed that the wiki page on using
borders is invalid for 1.3 as the add/removeAll/replace/autoAdd methods are
all final.
http://cwiki.apache.org/WICKET/consistent-page-layout-usin
That is exactly what i am doing right now. And i have no problem if it
has to stay that way. However I thought i might be helpful for
everyone extending CompoundPropertyModel, and given the fact that none
of the methods in AttachedCompoundPropertyModel are final or otherwise
protected against over
isAncestorOf" is deprecated now
(oh no, my chance to patch THE Component) ;)
Eelco Hillenius wrote:
>
> People,
>
> We could use everyone's help. I just came across some stale
> documentation, particularly RequestCycle, which stated in large
> caption that it is no
Can't you just create your own version of
AttachedCompoundPropertyModel (you are after all thinking about
extending it, and there isn't so much going on in that class) and
overriding wrapOnInheritance and return an instance of your class?
Eelco
On 6/17/07, Maurice Marrink <[EMAIL PROTECTED]> wr
Great news Ate!
It would be interesting to read the experiences of those who have been
playing with it in this thread. Is anyone considering using this for
their projects yet?
Cheers,
Eelco
On 6/14/07, Ate Douma <[EMAIL PROTECTED]> wrote:
As promised a few weeks ago, I've created a separate
Hi Juergen,
The changes sound good to me. As it's mostly internal, I'd be +1 for
you committing them.
The threadtest project is made to facilitate tests like this.
Cheers!
Eelco
On 6/16/07, Juergen Donnerstag <[EMAIL PROTECTED]> wrote:
I've backported the IMarkupLoader change which removes
I've updated confluencene:
http://wicketstuff.org/confluence/display/STUFFWIKI/wicket-contrib-gmap
So what more should I do to make the world know that we have a stable
build of the wicket-contrib-gmap?
Should I write to the user list and should anything else be done ?
Cool Nino. Thanks. I thi
On 6/14/07, Johan Compagner <[EMAIL PROTECTED]> wrote:
ahh i see, shouldn't bind() call just dirty() then?
Currently dirty doesn't result in bind being called. If we would fix
(?) it so that it does, dirty would work fine, tough it would be done
at the end of the request rather than immediately
On 6/14/07, Francisco Diaz Trepat - gmail
<[EMAIL PROTECTED]> wrote:
Man, you know I'm gona preach it. So bring it. And I'll deliver the
message...
That's good to hear. We're gonna need all the publicity we can get
when we start MEAP[1] in a few weeks. :)
Eelco
[1] http://www.manning.com/abou
But maybe we should remove the "This method should not typically be
called by clients" line from bind() javadoc then?
Yeah. Just did.
Eelco
On 6/14/07, Francisco Diaz Trepat - gmail
<[EMAIL PROTECTED]> wrote:
Come on guys
We're working, we're working.
God I can't wait to get my hands on the new generics for wicket.
And I can't wait to ship Wicket In Action ;)
Eelco
Nope. We found some licensing issues and will soon propose a new release.
Eelco
On 6/14/07, Sean Sullivan <[EMAIL PROTECTED]> wrote:
Did the vote pass?
On 6/12/07, Sean Sullivan <[EMAIL PROTECTED]> wrote:
>
>
> Have the votes been counted? Is beta2 coming soon?
>
>
>
On 6/14/07, Maurice Marrink <[EMAIL PROTECTED]> wrote:
Then i must be missing something here :s. The api doc clearly states:
Yeah, you're talking about bind(), I'm talking about dirty() :)
Eelco
On 6/14/07, Johan Compagner <[EMAIL PROTECTED]> wrote:
he just has to call dirty() when he alters a session and wants to store it
That currently (in 1.3) doesn't trigger binding.
Eelco
I'm wondering whether it still is a good idea to automatically mark
pages as stateless if there are no 'statefull' components/ callbacks
on it. It's not so much a problem that the page isn't stored - it
isn't as there aren't any non-bookmarkable callbacks to it - but it
can be a problem that a ses
Cheers Grégory :)
Eelco
On 6/11/07, Jean-Baptiste Quenot <[EMAIL PROTECTED]> wrote:
Dear developers,
Please welcome Grégory Maes among the WicketStuff developers.
Grégory has filed [1]several patches on WicketStuff Dojo, and has
shown a long-term interest in this project. He now dese
People,
We could use everyone's help. I just came across some stale
documentation, particularly RequestCycle, which stated in large
caption that it is not meant for being subclassed (which is nonsense
of course). I'm a bit afraid that the API docs may be stale in more
places.
If you (including u
Well, if I remember correctly the outcome of the discussion was
DataView into core, DataTable stays in extensions.
Yeah, it was. But not because I wanted that :)
Although I wouldn't mind DataTable in core.
I think a Tree (the new one :) ) belongs to the core. But the
TreeTable really can live
a) remove the old (kinda unsupported) tree from extensions (is
anyone even use it?)
+1
b) move the current Tree and TreeTable* from core to extensions
(sight, i know we moved it into core just recently)
Don't know yet.
c) move the new Tree into core.
So the 'new new' tree is inc
besides the fix you've implemented by clearing this metadata
as soon as you can, you could also make the inspector temporarily
null it out while it computes the size of things. then the inspector
would give you results more in line with production sizes.
The results should be good now for every
I already implemented it.
Cheers!
Eelco
On 6/7/07, Martijn Dashorst <[EMAIL PROTECTED]> wrote:
On 6/7/07, Eelco Hillenius <[EMAIL PROTECTED]> wrote:
> > Until we find a usecase for the creation of the stack elements at a
> > later stage, I'm fine with killing the
Until we find a usecase for the creation of the stack elements at a
later stage, I'm fine with killing the metadata for now. We have the
ability for keeping it, so it is easily re-instated.
That sounds good to me. Do you want to implement it?
Eelco
mented.
Possibly we could also profile the construction of the stack elements,
to see how it can be improved. Currently I create stacks for both the
construction *and* the addition to the component hierarchy. Maybe that
is overkill?
Martijn
On 6/7/07, Eelco Hillenius <[EMAIL PROTECTED]> wrote:
&
Hi,
I'd like to discuss the recent introduced functionality of line
precise error reporting - this time specifically in it's own thread.
It is a new facility that records the stack trace when a component is
created and when it is added to a container. A relevant representation
of the stack trace
On 6/7/07, Johan Compagner <[EMAIL PROTECTED]> wrote:
can't we do an RC at the moment we graduate? (a bit more fuss then?)
Also we can try to have only 1 or 2 release candidates so that the release
is a bit earlier..
I think we need as many release candidates as it takes to get it free
of (ser
On 6/6/07, Martijn Dashorst <[EMAIL PROTECTED]> wrote:
All,
I'm not sure the usecase is general, but in our application we have a
couple of classes that implement IDetachable, but not IModel, and
these are put into a CompoundPropertyModel
The thing is that the CompoundPropertyModel does an inst
Yeah, that sounds right.
Eelco
On 6/5/07, Al Maw <[EMAIL PROTECTED]> wrote:
Hi folks,
I'm pretty sure our slf4j dependencies are very wrong.
I see the root pom.xml in trunk has a dependencies section that doesn't
actually include slf4j-api (it's only in the dependenciesManagement).
Instead,
Ok, let's go for it then. Who's taking it up?
Eelco
On 6/5/07, Matej Knopp <[EMAIL PROTECTED]> wrote:
I'm definitely +1 for metadata. The thread locals are clumsy and
extremely dangerous.
-Matej
On 6/5/07, Johan Compagner <[EMAIL PROTECTED]> wrote:
> >
> > > But i also need it for other stuff
Hi,
Some people were complaining that the wicketstuff.org server was down
quite a bit. Anyone (Johan, Jan) has an idea why? Could it be bamboo?
Or do we do hot deploys of the examples project everytime it is
rebuild?
Eelco
But i also need it for other stuff that are specific to specific
implementations of certain things
for example the AccessStackStore doesn't need such a thread locale but SLC
does..
Fair enough. So you would use such a 'bag' in request cycle to store
stuff like dirtyObjects (session)? Aren't you
ers as parsed in the first step of request cycle processing in
the request.
Eelco
On 6/4/07, Martijn Dashorst <[EMAIL PROTECTED]> wrote:
On 6/4/07, Eelco Hillenius <[EMAIL PROTECTED]> wrote:
> > i am getting a bit tired of all those threadlocals that have to be
> > cleaned.
i am getting a bit tired of all those threadlocals that have to be
cleaned... I already discussed this with matej and i thing we should
give the RequestCycle metadata... then we can store any thing we want
and it is auto cleanup
Agreed. RequestCycle currently doesn't have metadata though. What's
On 6/4/07, Johan Compagner <[EMAIL PROTECTED]> wrote:
it is harder now to specify converters on the session. (which we always had
as far as i remember)
because now you by pass that.
Well, it's one of these things that probably started with a good idea
at some point in the past, but after a few
On 6/4/07, Jean-Baptiste Quenot <[EMAIL PROTECTED]> wrote:
* [EMAIL PROTECTED]:
> Author: ehillenius
> Date: Sun Jun 3 17:13:59 2007
> New Revision: 544015
>
> URL: http://svn.apache.org/viewvc?view=rev&rev=544015
> Log:
> simplified converterlocators by removing
IConverterLocatorFactoryLocator
But the component resolver is too eager. Look at the failing unit test
for an example.
Eelco
On 6/2/07, Juergen Donnerstag <[EMAIL PROTECTED]> wrote:
You can: MarkupParser.appendMarkupFilter(final IMarkupFilter filter,
final Class beforeFilter)
Juergen
On 5/24/07, Al Maw <[EMAIL PROTECTED]>
1 - 100 of 956 matches
Mail list logo
