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.
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/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
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/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
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
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()
I opened an issue here http://issues.apache.org/jira/browse/WICKET-746
Eelco
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
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
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
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
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
[ 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
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
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
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 let
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
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 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
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
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
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
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 unique and it behaves wrongly in repeaters
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:
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
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
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
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
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
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
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
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
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
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
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
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
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
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
[ 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
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 input type=submit
tag while it can be used for
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
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
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
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
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 component
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 pretty rediculous default in itself. How
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
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 was implemented like this?
public
-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
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
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
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]
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 not meant for being subclassed (which is nonsense
of course). I'm a bit afraid
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
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.
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
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
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
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
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, 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
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:
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]
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
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
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
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
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
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
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
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
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
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
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
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 that
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,
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=revrev=544015
Log:
simplified converterlocators by removing
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
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.
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 already discussed this with matej and i thing
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
Who are the admins currently?
Eelco
On 6/2/07, Jean-Baptiste Quenot [EMAIL PROTECTED] wrote:
I'd like to edit this page:
http://wicketstuff.org/confluence/display/STUFFWIKI/Wiki
This is restricted to group wicket-stuff-admin and I am in
confluence-users only.
Thanks,
--
Jean-Baptiste
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]
private static final String RESOURCE_KEY = EmailAddressValidator;
but AlMaw also mentioned using Classes.simpleName(...).
That sounds like a better idea to me.
Eelco
Where is it used and what does it look like Martijn? Also, could you
open and resolve a JIRA issue for this so that it is part of the
change log?
Cheers,
Eelco
On 5/9/07, Martijn Dashorst [EMAIL PROTECTED] wrote:
OK, I am now committing this feature. It is in!
Martijn
On 5/1/07, Al Maw
+1... But just to make sure: is the DEPLOYMENT configuration going to be
default?
Nope, DEVELOPMENT is the default (see one of the other threads this week).
Eelco
Yeah, good idea. Too bad we can't use blink ;)
Eelco
On 5/31/07, Al Maw [EMAIL PROTECTED] wrote:
Eelco Hillenius wrote:
+1... But just to make sure: is the DEPLOYMENT configuration going to be
default?
Nope, DEVELOPMENT is the default (see one of the other threads this week).
But I'll
List,
I'm still worried about the fact that development mode is our default
setting. Imho, this is a mistake as the development setting is a
dangerous setting for production systems: it uses more memory (for
precise line reporting), is less efficient (render check) and can
potentially bring down
my 2 cent would be to force the setting to be present, else the startup
would fail - so the developer *has* to set it manually in any way
but your and Martijn's idea sounds very nice to me. An idea would to extend
the logo/ link and bring up a console where the current page is displayed
together
And we have that component: the inspector bug... We moved it to
wicket-examples because it was a security risk.
Sure. But if it would be part of the 'development dashboard' it
wouldn't be a security risk as we don't want people to run in
develpment mode in the first place, right?
Eelco
Wow, that was a long mail. It's a bit unfortunate that many of the
abstractions in Wicket actually came from the idea of separating the
servlet and portlet environments, and that we won't need those now,
but I guess that's the way it goes. Most of those abstractions proved
to be useful anyway.
I
Ah, yes. I missed that one. Just came back from a vacation :)
Eelco
On 5/28/07, Johan Compagner [EMAIL PROTECTED] wrote:
AlMaw also already looked at it:
http://www.nabble.com/Chaining-IComponentResolvers-tf3803758.html#a10763056
is juergen around?
johan
On 5/28/07, Eelco Hillenius [EMAIL
This is soon to be picked up by Ate and possibly some others. He plans
on submitting a proposal on this list early this week.
Do you plan to work with this Michal? Or have you already been working
on it? We definitively need a couple of people testing and
contributing this time; it'll be the
two or three weeks a go I had a look on the current source for the
portlet integration. They are currently stored at the wicket stuff
project. This source do not compile with the wicket 1.3 release (this
was two or three week ago). I play around with the source and get some
examples of the normal
Look, having a failing unit test only works when it is indeed fixed
ASAP. This is a known issue for a least a few days now, and there
isn't even any serious discussion on how this might be fixed, so atm a
quick fix seems unlikely. Also, though the problem can be anoying,
it's not a show stopper
When you comment such a failing test, then at the very least add the
class and method to the issue. Otherwise it will be HELL to find the
test again. Also, ensure that the method is commented with the JIRA
issue number.
The test was already mentioned in the JIRA issue and of course I added
a
1 - 100 of 667 matches
Mail list logo
