Re: Wicket code conventions

[tetsuo]

What existing classes could be substituted by guava classes?
I don't think it would be sensible to replace 3 or 4 classes with a
2-million-byte library :)




“The truth is rarely pure and never simple.” ― Oscar Wilde


On Sun, Jul 13, 2014 at 2:13 PM, Garret Wilson gar...@globalmentor.com wrote:
 On 7/13/2014 8:49 AM, Sven Meier wrote:

 ...

 for null checking we have our own solution, see
 org.apache.wicket.util.lang.Args#notNull().


 Great! I'll start using Args with code I submit.

 Has there been any discussion on including Google Guava as a dependency?

 Years ago I rolled all my own collection utilities and such, but I finally
 came around to using Guava. All that stuff is just so hard to maintain, but
 it's also hard to live without.

  * The Multimap classes (in which each key can have a collection of
values) as just one example is so convenient.
  * And its MapMaker allows for easy creation of concurrent maps with
e.g. weak keys. (The weak hash maps Java offers don't use identity
for keys, which can create some really unexpected behavior and bugs.)
  * Oh, and its ImmutableSet factory methods are so handy...


 Anyway, Guava is hard to live without at this point, and I'm even
 considering (gasp!) including it as a dependency in my own personal code and
 abandoning a lot of the utilities I've created over the years. :) Any
 thoughts on this for Wicket 7.x?

 Garret

Re: the dangers of Wicket's modifying given HTML

[tetsuo]

Almost no Wicket component actually generate/modify the HTML
structure. You just cited 2 of the very few cases (the only others I
can think of are part of the 'extensions' module, which you don't need
to use if you don't want to). Just try to do the same with RichFaces
:)

It can't be expected that the generated markup matches exactly what
your specific CSS framework wants (since every framework expects
something different), but I do agree that there should always be
customization hooks for these kind of customization.

For the specific cases you complained about, there are such hooks,
they just may don't be as obvious and convenient as you may want:

For the disabled links, you may override
AbstractLink.disableLink(ComponentTag) and change it to whatever you
want. Since Java doesn't have mixins, you may have to override this
same method in the various AbstractLink subclasses you use (make it a
static method in an utility class to avoid too much repetition).

For CheckBoxMultipleChoice, you may override the
CheckBoxMultipleChoice.appendOptionHtml() method, and generate exactly
the markup you want. The method is a little longer than the ideal, but
it centralizes the HTML generation for the items, so it's the only one
you have to rewrite. You can also use CheckGroup+Check instead, and
specify the exact HTML you want, if you prefer.

One of the beauties of Wicket is that its code is fairly easy to read,
and has plenty of hooks to customize its behavior. And even if they
are not sufficient (due some final method, for example), the
components usually are simple and decoupled from the core. You can
just copy the component source into your project (with different names
or packages, to avoid classloader hell) and just modify it to your
heart's content.

Again, imagine how much fun it would be to do the same with JSF's
render kits or Swing`s LaFs :)

Tetsuo

“The truth is rarely pure and never simple.” ― Oscar Wilde


On Thu, Jul 10, 2014 at 9:49 PM, John Sarman johnsar...@gmail.com wrote:
 Garrett,
 Since Wicket is open source, why not create the desired patch and submit it
 to the committers instead of ranting about what caveats (in your opinion)
 exist.  Productivity comes from contributions to code, not from complaining
 why it does not do it the way you think it should.  Once you request a
 patch you will have the long time hard working devs scouring over the code
 to produce a better product.  I did this approach and ultimately the long
 time devs rewrote the solution to my issue, and it is beautiful and simple.


 In summary, I'd like you to contribute the changes you desire to the
 codebase making sure that your ideas do not breaks the 1000's of other
 developers usage of the API.

 Thanks,
 John


 On Thu, Jul 10, 2014 at 6:31 PM, Garret Wilson gar...@globalmentor.com
 wrote:

 Everyone,

 Wicket was created in a world in which little was done at display time to
 manipulate the HTML DOM tree, so Wicket felt like it had free reign to muck
 around with the HTML given by the developer. But in today's world in which
 we use JavaScript libraries like jQuery to modify the DOM on a whim, and
 CSS libraries such as Yahoo! Pure to provide styling, Wicket's modification
 of the HTML I give it can wreak havoc with my application.

 1. Let me give you two examples. The first is BookmarkablePageLink. I have
 a simple and semantically useful navigation:

 nav
   ul
lia wicket:id=homePageLink ...

 I throw in a couple of CSS classes from Yahoo! Pure CSS Library, and it
 turns into a beautiful menu with mouseover highlighting, selected items,
 etc. I use a BookmarkablePageLink to wrap each link. But some menu items
 are only available to users with certain permissions, so I want to disable
 some of them. Oops! When I call BookmarkablePageLink.setEnabled(false),
 the HTML changes! Suddenly my a tags are turned into ugly spanem
 tags, completely destroying the look of the menu because Yahoo! Pure CSS
 doesn't recognize spanem tags as menu items.

 Sure, I can call getMarkupSettings().setDefaultBeforeDisabledLink(...)
 and friends, but I shouldn't have to. This is a holdover from the days when
 stylistic changes were made by changing the HTML, not by applying CSS. I
 recommend that by default links should not change the HTML, but instead add
 or remove a particular HTML class value.

 2. The second example is CheckBoxMultipleChoice. I have a nice set up
 checkboxes in the HTML:

   div wicket:id=widgets
 label for=fooinput id=foo type=checkbox/ Foo/label
 label for=barinput id=bar type=checkbox/ Bar/label
   /div

 Without Wicket, those look nice; they are displayed horizontally, and the
 labels are beside the checkboxes:

   X FooX Bar

 But if I use CheckBoxMultipleChoice, it completely screws up the HTML!
 Suddenly my HTML looks like this:

   ...input .../label ...foo/labelbr/input .../label
 ...bar/labelbr/

 Wicket has not only taken my input out of the label.../label, it has
 added an ugly, non

Re: Java 8 lambdas vs serialization

[tetsuo]

It is an Eclipse bug, not a JDK one. javac works fine.

But I haven't submitted it to Eclipse... yet? :)
“The truth is rarely pure and never simple.” ― Oscar Wilde


On Sun, May 25, 2014 at 2:55 PM, Martin Grigorov mgrigo...@apache.org wrote:
 Thanks for sharing your findings!

 What is the id of the bug at Oracle ? Just for reference

 Martin Grigorov
 Wicket Training and Consulting


 On Fri, May 23, 2014 at 11:48 PM, tetsuo ronald.tet...@gmail.com wrote:

 Never mind, Eclipse bug (sigh)
 “The truth is rarely pure and never simple.” ― Oscar Wilde


 On Fri, May 23, 2014 at 4:38 PM, tetsuo ronald.tet...@gmail.com wrote:
  I'm using Java 8 lambdas with Wicket, and they make it really simple
  to have almost 100% type-safe code, without the verbosity of anonymous
  inner classes. With a few adapter classes and interfaces, it was
  relatively easy to integrate them.
 
  But I'm having some non-trivial problems with serialization. I think
  it's a bug in the compiler, but I'm curious if someone else has seen
  this:
 
 
  public class TestClass implements Serializable {
  String   msg = HEY!;
  SerializableRunnable runnable;
  public TestClass() {
  TestClass self = this;
  runnable = () - self.say();  // uses a local copy of 'this'
 // runnable = () - this.say(); // uses 'this' directly
  }
  public void say() {
  System.out.println(msg);
  }
  public static void main(String[] args) throws Exception {
  ByteArrayOutputStream buffer = new ByteArrayOutputStream();
  try (ObjectOutputStream out = new ObjectOutputStream(buffer)) {
  out.writeObject(new TestClass());
  }
  try (ObjectInputStream in = new ObjectInputStream(new
  ByteArrayInputStream(buffer.toByteArray( {
  TestClass s = (TestClass) in.readObject();
  s.say();
  }
  }
  }
  interface SerializableRunnable extends Runnable, Serializable {
  }
 
 
  The above code runs fine, but if I use the commented line to
  initialize the runnable (using 'this' directly instead of a local
  variable), the in.readObject() call throws an excetion
  ('java.lang.IllegalArgumentException: Invalid lambda
  deserialization'). The object is serialized, but can't be
  deserialized.
 
  That is, lambdas are correctly serialized when it only uses the local
  scope, but if it tries to use the enclosing class directly (methods or
  attributes), it fails. I mean, it compiles, it works, it can access
  them, but if serialized, it can't be deserialized.
 
  Obviously, it makes it very inconvenient to use with Wicket, which
  uses serialization extensively.
 
  I already submited a bug to Oracle. Do you agree that it looks like a
 bug?

Java 8 lambdas vs serialization

[tetsuo]

I'm using Java 8 lambdas with Wicket, and they make it really simple
to have almost 100% type-safe code, without the verbosity of anonymous
inner classes. With a few adapter classes and interfaces, it was
relatively easy to integrate them.

But I'm having some non-trivial problems with serialization. I think
it's a bug in the compiler, but I'm curious if someone else has seen
this:


public class TestClass implements Serializable {
String   msg = HEY!;
SerializableRunnable runnable;
public TestClass() {
TestClass self = this;
runnable = () - self.say();  // uses a local copy of 'this'
   // runnable = () - this.say(); // uses 'this' directly
}
public void say() {
System.out.println(msg);
}
public static void main(String[] args) throws Exception {
ByteArrayOutputStream buffer = new ByteArrayOutputStream();
try (ObjectOutputStream out = new ObjectOutputStream(buffer)) {
out.writeObject(new TestClass());
}
try (ObjectInputStream in = new ObjectInputStream(new
ByteArrayInputStream(buffer.toByteArray( {
TestClass s = (TestClass) in.readObject();
s.say();
}
}
}
interface SerializableRunnable extends Runnable, Serializable {
}


The above code runs fine, but if I use the commented line to
initialize the runnable (using 'this' directly instead of a local
variable), the in.readObject() call throws an excetion
('java.lang.IllegalArgumentException: Invalid lambda
deserialization'). The object is serialized, but can't be
deserialized.

That is, lambdas are correctly serialized when it only uses the local
scope, but if it tries to use the enclosing class directly (methods or
attributes), it fails. I mean, it compiles, it works, it can access
them, but if serialized, it can't be deserialized.

Obviously, it makes it very inconvenient to use with Wicket, which
uses serialization extensively.

I already submited a bug to Oracle. Do you agree that it looks like a bug?

Re: Java 8 lambdas vs serialization

[tetsuo]

Never mind, Eclipse bug (sigh)
“The truth is rarely pure and never simple.” ― Oscar Wilde


On Fri, May 23, 2014 at 4:38 PM, tetsuo ronald.tet...@gmail.com wrote:
 I'm using Java 8 lambdas with Wicket, and they make it really simple
 to have almost 100% type-safe code, without the verbosity of anonymous
 inner classes. With a few adapter classes and interfaces, it was
 relatively easy to integrate them.

 But I'm having some non-trivial problems with serialization. I think
 it's a bug in the compiler, but I'm curious if someone else has seen
 this:


 public class TestClass implements Serializable {
 String   msg = HEY!;
 SerializableRunnable runnable;
 public TestClass() {
 TestClass self = this;
 runnable = () - self.say();  // uses a local copy of 'this'
// runnable = () - this.say(); // uses 'this' directly
 }
 public void say() {
 System.out.println(msg);
 }
 public static void main(String[] args) throws Exception {
 ByteArrayOutputStream buffer = new ByteArrayOutputStream();
 try (ObjectOutputStream out = new ObjectOutputStream(buffer)) {
 out.writeObject(new TestClass());
 }
 try (ObjectInputStream in = new ObjectInputStream(new
 ByteArrayInputStream(buffer.toByteArray( {
 TestClass s = (TestClass) in.readObject();
 s.say();
 }
 }
 }
 interface SerializableRunnable extends Runnable, Serializable {
 }


 The above code runs fine, but if I use the commented line to
 initialize the runnable (using 'this' directly instead of a local
 variable), the in.readObject() call throws an excetion
 ('java.lang.IllegalArgumentException: Invalid lambda
 deserialization'). The object is serialized, but can't be
 deserialized.

 That is, lambdas are correctly serialized when it only uses the local
 scope, but if it tries to use the enclosing class directly (methods or
 attributes), it fails. I mean, it compiles, it works, it can access
 them, but if serialized, it can't be deserialized.

 Obviously, it makes it very inconvenient to use with Wicket, which
 uses serialization extensively.

 I already submited a bug to Oracle. Do you agree that it looks like a bug?

Re: refactoring IDataProvider interface

[tetsuo]

Since it's the same request, isn't (or couldn't be) the db connection the
same in size() and iterator() calls? If you created the temporary table in
one, isn't it still available to the other (so you could avoid recreating
it)?

“The truth is rarely pure and never simple.” ― Oscar Wilde


On Tue, May 6, 2014 at 11:15 AM, Leszek Gawron lgaw...@apache.org wrote:

 hello,

 I would like to propose a major change in IDataProvider so I thougt
 this topic is better suited for dev list.

 Currently IDataProvider looks like this:

 public interface IDataProviderT extends IDetachable
 {
 Iterator? extends T iterator(long first, long count);
 long size();
 IModelT model(T object);
 }

 this looks OK but is actuall suboptimal in some cases.


 It would be a lot better (at least for me :)) ) if IDataProvider
 looked somewhat like:

 public interface IDataProviderT extends IDetachable
 {
 PageT getPage(long first, long count);
 IModelT model(T object);
 }

 or similarly to IDataSource from inmethod-grid:

 public interface IDataSourceT extends IDetachable, IClusterable
 {

 public void query(IQuery query, IQueryResultT result);

 public IModelT model(T object);

 public interface IQuery
 {
 public long getFrom();
 public long getCount();

 public static final long UNKNOWN_TOTAL_COUNT = -1L;

 public long getTotalCount();

 public S IGridSortStateS getSortState();
 }

 public interface IQueryResultT
 {
 public static final int MORE_ITEMS = -1;
 public static final int NO_MORE_ITEMS = -2;

 public void setTotalCount(long count);
 public void setItems(Iterator? extends T items);
 };
 }


 Following arguments prove that two latter proposals are better than
 current IDataProvider:

 1. You have your data page generated by one method, not two.

 Something like show me a DataTable of contractors that either me or
 any of my subordinates (tree) has access to is impossible without
 using temporary tables.
 With a temporary table it is as simple as: select * from contractor c
 inner join #temporary_user_contractors_88 t on c.id = t.id

 Temporary tables are usually quite costly to build (in the example you
 execute as many queries as you have nodes in subordinate tree), they
 also required proper cleanup before the connection is released back to
 the pool.
 Having two methods on IDataProvider means you have to:

 - invoke dataProvider.size()
   - create a temporary table
   - query for count
   - release a temporary table
 - invoke dataProvider.iterator(first,count)
   - create a temporary table
   - query for items
   - release temporary table

 being able to compute both data in one pass saves a lot of unnecessary
 queries being made.

 2. Usually select for items and select for count(*) differ only with
 columns fetched:

 select * from some_joined_tables where condition1 and condition2 and
 condition3;
 select count(*) from some_joined_tables where condition1 and
 condition2 and condition3;

 What users usually do is create some template methods for filling in
 the same conditions in both cases.
 Having one method would make the code clearer:

 @Override
 @Transactional(readOnly = true)
 public PageT list( Pageable pageable, F filter, MapString,
 Object context ) {
 ValueListQueryConfigF queryConfig = getQueryConfig(pageable,
 filter,
 context );
 queryConfig.setDialect( dialect );
 SelectRecord resultsQuery = queryConfig.generateResultsQuery();
 ListT results = getJdbcTemplate().query(
  resultsQuery.getSQL(),

 resultsQuery.getBindValues().toArray(),
 getRowMapper() );

 SelectRecord countQuery = queryConfig.generateCountQuery();
 long total = getJdbcTemplate().queryForLong(
  countQuery.getSQL(),

 countQuery.getBindValues().toArray() );

 return new PageImplT( results, pageable, total );
 }


 3. Your code may do some optimizations and not fetch the count from
 data source at all.

 ListT results = fetch( first, pageSize );
 count = ( results.size()  pageSize ) ? first + results.size() :
 calculateSize();

 4. You may choose not to provide total count AT ALL, simply providing
 information if there is a next page (something inmethod-grid's
 IDataSource) already does.


 I tried to wrap this functionality in my own code:
 public abstract class NewValueListDataProviderAdapterT, F extends
 SortableDataProviderT, String {
 public NewValueListDataProviderAdapter( MapString, Object context ) {
 Injector.get().inject( this );
 this.context = context;
 }

 private final MapString, Objectcontext;

 private transient PageTcurrentPage;

 protected abstract ValueListT, F getValueList();

 protected F 

Re: refactoring IDataProvider interface

[tetsuo]

Yeah, you're right. By reflex, I was thinking Hibernate Session (with open
session in view), not JDBC Connection, since I don't work directly with it
very often. And even if it was Hibernate, and the session was still open,
the connection would also be closed anyway.

What methods would the Page interface (with another name, since we already
have a Page class) have? iterator() and size()?



“The truth is rarely pure and never simple.” ― Oscar Wilde


On Tue, May 6, 2014 at 5:41 PM, Leszek Gawron lgaw...@apache.org wrote:

 I replied from wrong email, please excuse me if this reaches the list
 twice.

 On Tue, May 6, 2014 at 8:06 PM, tetsuo ronald.tet...@gmail.com wrote:
  Since it's the same request, isn't (or couldn't be) the db connection the
  same in size() and iterator() calls? If you created the temporary table
 in
  one, isn't it still available to the other (so you could avoid recreating
  it)?
 Well, the connection is being managed by spring transactional resource
 management classes. A transaction is demarcated with
 @Transactional(readOnly=true) on a particular method. All
 transactional resources are bound to thread during transaction
 execution and released when transaction finishes. One transactional
 resource is of course a connection. I have extended this framework to
 register temporary table names which are being automatically deleted
 on transaction finish.

 Each time you invoke a transactional method you perform following steps:
 - acquire a connection from the pool
 - bind connection to thread making all subsequent queries use same
 connection
 - start transaction
 - do some work
 - finish transaction (of course for read only there is nothing to be done)
 - release transactional resources
 - unbind connection from thread
 - release connection to the pool.

 using spring framework without spring managed transactions means you
 end up using different connection for EVERY sql query.

 My IDataProviders usually wrap spring bean with
 @Transactional(readOnly=true) methods.

 Unfortunatelly two method calls: size() and iterator() mean two
 different transaction and two different connections. I am unable to
 wrap any single point of entry with @Transactional - that probably
 would have to be some generic Wicket method call. I cannot bind a
 connection to current request thread preemptively because that would
 mean a huge resource hog - I would have to obtain a connection from
 pool for every request being made.

 Temporary tables have connection scope so not deleting the table on
 connection release means polluting the database server with lots of
 temporary tables as long as connection stays in pool (which could be
 indefinite).
 The temporary tables would be probably stale all the time - any
 ongoing transaction may probably alter what the temporary table should
 contain.

 Anyway any approach still feels like a hack and not resolving the
 problem at source.



 A single point of entry in IDataProvider:
 - allows the user to manage resources more efficiently.
 - gives user the option to resign from providing size() information -
 do you really go from 1st to 15th page that often or do you usually
 click next results?
 - gives user the option to provide has more results information
 without providing actual dataset size.

 Having a single point of entry IDataSource means also you can do:

 new IDataProviderSingleEntryT( oldDataProvider ) {
   public PageT getPage( long first, long count ) {
   return new PageImplT(
  oldDataProvider.interator( first, count ), oldDataProvider.size()
 );
   }
 }

 This trivial decorator means IDataProviderSingleEntry and
 IDataProvider may even coexist in wicket-core and wicket-extensions.
 Some variation of this approach is actually used by inmethod-grid.
 Maybe we could unify the way all pageables access resources.


 --
 Leszek Gawron

Re: Make ListView invisible when list is empty?

[tetsuo]

But I guess most of the time you have an empty list you want to hide not
only the list, but also some markup around it (thus the use of an
enclosure), so just changing the HTML generated by the empty list would not
be enough.

I think the ListView should be invisible when empty. Besides that, the
enclosure could be smarter and render an alternate (static) markup instead
of just becoming invisible. But that would be another topic of discussion :)


“The truth is rarely pure and never simple.” ― Oscar Wilde


On Mon, May 5, 2014 at 10:29 AM, Nick Pratt nbpr...@gmail.com wrote:

 Having some alternate text/markup displayed is commonly what we do since if
 a user expects to see something at a point in the page, and we no longer
 show anything, that becomes confusing for the user.  Our current usage of
 ListView for all customer/public facing pages is:

 div wicket:id=empty-lv
 Text to show in case of empty ListView
 /div
 div wicket:id=listview
 ...
 /div

 We also hide the listview in the empty case using the same mechanism as you
 described.  Since we do this for all ListViews (or nearly all - the only
 exceptions being admin/dev/debug pages) it would be nice to have this
 seemingly common functionality as part of the provided component.

 If that alternate text ('empty-lv') could be produced/contained inside the
 ListView markup, that would be great (since then spacing/styling on the
 page becomes easier) as the ListView dom element position/size/whatever can
 be fixed

 Could we make such a change, and then have a flag on the ListView (or
 simply inferred from the presence of the alternateEmptyText property)
 whether to render the LV repeater or the alternate text?

 N


 On Mon, May 5, 2014 at 9:13 AM, Martijn Dashorst 
 martijn.dasho...@gmail.com
  wrote:

  One of the things I dislike is when I have to implement my own
  visibility logic when a ListView is empty, mostly when using
  enclosures to wrap around surrounding markup.
 
  So for a ListViewAddress I have to implement an onConfigure that
  calls setVisible(!getList().isEmpty()); to tell the enclosure that it
  should not render the enclosed markup.
 
  wicket:enclosure child=addresses
  h2Addresses/h2
  dl
  wicket:container wicket:id=addresses
dtAddress/dt
ddwicket:container wicket:id=address/wicket:container/dd
  /wicket:container
  /dl
  /wicket:enclosure
 
  I figure we can make that the default. There is little point in having
  a visible, empty ListView, is there?
 
  Another option would be to make wicket:enclosure smarter, but that is
  a rabbit hole I'd like leave closed.
 
  Martijn
 

Re: Wicket 7: IChoiceRenderer restore or keep out?

[tetsuo]

+1 for keeping IChoiceRenderer.

I often create Enums with a single value when I want a singleton (the JVM
guarantees the single instance, and it takes less space in memory and when
serialized), and many of my custom choice renderers are like this. I can't
do this if it is not an interface.





On Wed, Feb 26, 2014 at 7:45 AM, Martin Grigorov mgrigo...@apache.orgwrote:

 Hi,

 Igor suggested to remove the interface and I agreed.
 For me there was no real benefit from the interface here.
 Almost everything in Wicket uses ChoiceRenderer.
 By using a class it is easier to add new logic. Otherwise tickets like
 https://issues.apache.org/jira/browse/WICKET-663 will be moved to the next
 major release and then forgotten.

 But I don't expect adding new methods in near future to this class so I am
 not against reverting this.


 Martin Grigorov
 Wicket Training and Consulting


 On Wed, Feb 26, 2014 at 12:36 PM, Sven Meier s...@meiers.net wrote:

  +1 for keeping IChoiceRenderer:
 
  Currently all renderers extend ChoiceRenderer. But EnumChoiceRenderer
  could be implemented on its own:
 
  public T getObject(String id, IModel? extends List? extends T
  choices)
  {
  if (choices.getObject().isEmpty())
  {
  return null;
  }
  else
  {
  return (T)Enum.valueOf(choices.getObject().get(0).getClass(),
  id);
  }
  }
 
  Other implementations could do so too, so why should they extend
  ChoiceRenderer? An interface would be suited much better for this.
 
  Regards
  Sven
 
 
 
  On 02/26/2014 11:23 AM, Martijn Dashorst wrote:
 
  While upgrading our application the biggest time sink for now was going
  through our code base and fixing the issues that came from removing
  IChoiceRenderer. While I don't mind the work (mostly search and
 replace) I
  would like to learn about the reasoning for removing the interface.
 
  In my previous trial Sven noticed that he'd like to see IChoiceRenderer
  restored. I'd like to start the discussion and resolve it before we cut
 a
  7-M1 release-to prevent having to go through the motions of
 re-introducing
  the interface after folks have done work to modify their code base to
 the
  IChoiceRenderer-less situation.
 
  What are the pro's and con's of removing/keeping IChoiceRenderer?
 
  Martijn
 
 
 

Re: Wicket 7: IChoiceRenderer restore or keep out?

[tetsuo]

Guillaume, you're right.

Martin, sorry for the misunderstanding.

Enums can't extend any classes besides Enum. But can implement interfaces.

I use Enums in lots of places, not as enums, but as singletons, because
they won't be serialized, won't carry unintended references, and use
virtually no memory in pages. Converters, Renderers, Validators, Models
(less so of the former, since it almost always needs state). If IBehavior
still existed, and didn't have so many methods, I'd use enums to implement
some of them, too.

But my main complaint is not specific to this issue, however. I'm more
concerned about frequent breaking API changes with no practical advantage.
Javascript/JavaScript, addComponent/add(Component) and the like. I'm at the
point that I'm starting to feel unconfortable recommending Wicket to
people, because I know an year from now they will complain that they
upgraded a library and a thousand compiling errors appeared. 98% of them
are very simple errors, but it's a daunting task neverthless.






On Wed, Feb 26, 2014 at 12:44 PM, Martin Grigorov mgrigo...@apache.orgwrote:

 As Martijn explained all that is needed is:
 - s/implements/extends/
 - remove the leading 'I' from IChoiceRenderer

 If the interface is preserved then all custom impls will have to add
 implementation of the new method introduced with WICKET-663. This IMO will
 lead to more work for the application developers.

 As I said: I am not against restoring the interface, just don't see its
 value.

 Martin Grigorov
 Wicket Training and Consulting


 On Wed, Feb 26, 2014 at 5:37 PM, Guillaume Smet guillaume.s...@gmail.com
 wrote:

  On Wed, Feb 26, 2014 at 4:33 PM, tetsuo ronald.tet...@gmail.com wrote:
   Because... it's an unnecessary breaking change?
 
  From what I understand of your previous post, you implements some of
  your converters in Enums, which you can do because IChoiceRenderer is
  currently an interface. And you won't be able to do it if it's a
  class.
 
  Am I right?
 

Re: Wicket 7: IChoiceRenderer restore or keep out?

[tetsuo]

Sorry for the rant...

The transition from 1.4 to 1.5 was awful (full of such minor breaking
changes), but not so afterwards, I know I'm overreacting. Probably it's
because it happened (a colleague complaining about all the compiling errors
when upgrading from 1.4) last week :/

And well... it's somewhat inevitable to avoid compiling errors when
evolving a framework that is strongly type-safe (which is a great plus).

Sorry again.

But I still like my enums, please keep the interfaces :)






On Wed, Feb 26, 2014 at 1:34 PM, Martin Grigorov mgrigo...@apache.orgwrote:

 On Wed, Feb 26, 2014 at 6:21 PM, tetsuo ronald.tet...@gmail.com wrote:

  Guillaume, you're right.
 
  Martin, sorry for the misunderstanding.
 
  Enums can't extend any classes besides Enum. But can implement
 interfaces.
 

 Thanks! Now it is clear to me.


 
  I use Enums in lots of places, not as enums, but as singletons, because
  they won't be serialized, won't carry unintended references, and use
  virtually no memory in pages. Converters, Renderers, Validators, Models
  (less so of the former, since it almost always needs state). If IBehavior
  still existed, and didn't have so many methods, I'd use enums to
 implement
  some of them, too.
 
  But my main complaint is not specific to this issue, however. I'm more
  concerned about frequent breaking API changes with no practical
 advantage.
  Javascript/JavaScript, addComponent/add(Component) and the like. I'm at
 the
  point that I'm starting to feel unconfortable recommending Wicket to
  people, because I know an year from now they will complain that they
  upgraded a library and a thousand compiling errors appeared. 98% of them
  are very simple errors, but it's a daunting task neverthless.
 
 
 Options:
 1) Wicket devs stop developing Wicket so the API stays stable forever
 2) application developers don't upgrade to next major version of Wicket
 3) find the golden middle.

 I think we all agree that 3) is the best for all and that we (Wicket devs)
 try to follow it:

 - we use SemVer to make it easier for application developers to know when
 to expect API breaks and when to not expect such
 - we discuss most of the API breaks for major versions here in dev@.
   If there are issues identified on time we react! Even this change has
 been discussed before being made




 
 
 
 
  On Wed, Feb 26, 2014 at 12:44 PM, Martin Grigorov mgrigo...@apache.org
  wrote:
 
   As Martijn explained all that is needed is:
   - s/implements/extends/
   - remove the leading 'I' from IChoiceRenderer
  
   If the interface is preserved then all custom impls will have to add
   implementation of the new method introduced with WICKET-663. This IMO
  will
   lead to more work for the application developers.
  
   As I said: I am not against restoring the interface, just don't see its
   value.
  
   Martin Grigorov
   Wicket Training and Consulting
  
  
   On Wed, Feb 26, 2014 at 5:37 PM, Guillaume Smet 
  guillaume.s...@gmail.com
   wrote:
  
On Wed, Feb 26, 2014 at 4:33 PM, tetsuo ronald.tet...@gmail.com
  wrote:
 Because... it's an unnecessary breaking change?
   
From what I understand of your previous post, you implements some of
your converters in Enums, which you can do because IChoiceRenderer is
currently an interface. And you won't be able to do it if it's a
class.
   
Am I right?
   
  
 

Re: Method chaining

[tetsuo]

Making 'void' methods return 'this' doesn't prevent you to write each call
in a new line. But gives others the choice to call it inline.

It could be a problem if Wicket's internal code used chaining extensively,
but I find it very convenient to chain calls, specially when building the
component tree for a page. If you break lines in the right places, Eclipse
indents it beautifully, if configured to not automatically join lines.

I'd love to see this adopted throughout the API, but it will break
compatibility everywhere you override these void methods (not if you just
use them). Which is much less than other kinds of change, but still... I
really like backwards compatibility :)






On Fri, Jan 31, 2014 at 1:15 PM, Nick Pratt nbpr...@gmail.com wrote:

 Which would be perfectly fine if the JVM told you which specific method
 invocation on a source code line with chained methods threw an exception.
  While you can sometimes figure it out, you can't always, and an answer of
 if it happens again, we'll know how to fix it just doesn't fly in certain
 verticals.

 For our production code we don't allow it, and we strongly recommend that
 our clients don't use it either.

 Perhaps I should log a RFE with Oracle.

 N


 On Fri, Jan 31, 2014 at 9:32 AM, Martin Makundi 
 martin.maku...@koodaripalvelut.com wrote:

  Java should natively chain all void instance methods...
 
  **
  Martin
 
 
  2014-01-31 Sven Meier s...@meiers.net
 
   I don't think it makes sense here:
   In all of Wicket's code there's a single place only, where two metaData
   entries are set consecutively.
  
   Sven
  
  
   On 01/31/2014 03:08 PM, Martin Grigorov wrote:
  
   Hi,
  
   What others think about
  https://issues.apache.org/jira/browse/WICKET-5459?
   Should Wicket use return this pattern where makes sense instead of
   'void'
   return type ?
  
   One problem that I see is with:
   MyPage.doSomething() will/may return some base type of MyPage.
   I remember some trink for Java to make this simpler but AFAIR it
  involved
   some longer generics signature for the class that use it.
  
  
  
   Martin Grigorov
   Wicket Training and Consulting
  
  
  
 

Re: Wicket-5353: Wrap feedback messages in a model instead of using Serializable objects

[tetsuo]

I think it isn't even an Wicket issue. I don't think the servlet spec
guarantees the thread-safety of the http session (
http://stackoverflow.com/a/616723/176897). Even if it does, it will be
between request threads. It would be very, very, unlikely that it would
mandate that the session should work with random application-created
threads.

In 2001, I've worked with IBM's Websphere Application Server, and if I
remember correctly, it used to serialize the session to a database at the
end of the request, and de-serialize it at the beginning of the next. It
was a very poor implementation, but I don't think it is unreasonable to
assume some servers still do something like this nowadays, especially if
arranged in a cluster.

In this kind of scenario, the session instance reference you keep and use
in the background thread probably wouldn't work.

I'm not saying it wouldn't work in a single Tomcat instance, it probably
would. But it's not in the spec. Http sessions were made to be manipulated
in a request context, and servers may assume this premise.





On Thu, Sep 19, 2013 at 10:19 AM, Rafael W. rafael@web.de wrote:

 I consider writing an alternative implementation where a thread-safe
 component works as a mediator for feedback messages such that the
 Wicket-thread can poll them from this thread-safe component. It's not the
 most beautiful solution since it generates quite some boilerplate which
 must in addition be explained to every developer, but I guess there is no
 better way?

 By the way, I am not clinging to my solution. I ask all this, because - at
 least for me - the Wicket source code is not always easy to follow. I just
 wanted to know the background for these decisions in order to find a better
 solutions since I was not aware of the exact reasons for the
 synchronization of the method. I read the code and obviously made some
 wrong assumptions over it which were corrected now. I would not know where
 I would get answers to these questions other than from this mailing list,
 this is why I am asking.

 PS: From your answer, I still do not get why it is a difference if Session
 adds a feedback message asynchronously to some third request thread
 compared to if some custom background thread does the same. Wouldn't this
 mean that I could simply keep a temporary reference to the session in a
 custom background thread and call Session.error instead?

Re: RFC-0001: Deprecating PageParameters for Wicket 7 (was Re: [4/4] git commit: WICKET-4997)

[tetsuo]

no magic (or the option of no magic) +1




On Mon, Aug 26, 2013 at 3:41 AM, Michael Mosmann mich...@mosmann.de wrote:

 Am 23.08.13 00:16, schrieb Martijn Dashorst:

 On Thu, Aug 22, 2013 at 11:42 PM, Igor Vaynberg igor.vaynb...@gmail.com
 wrote:

 On Thu, Aug 22, 2013 at 2:04 PM, Martijn Dashorst
 martijn.dasho...@gmail.com wrote:
 still need
 pageparameters to carry those params forward in bookmarkablelink, etc.

 Not necessarily: the API is still under construction. It is the
 intention to remove the need for PageParameters altogether in the API.

 I also prefer removing instead of wrapping it around the now code.. But:
 sometimes you need a functionality where you simply pass unknown page
 parameters some of your bookmarkablelinks. So there is no need to access
 this functionality with the PageParameters-api, but there is a need to have
 such kind of functionality.

 IMHO these page parameter stuff is something like page-external state
 conversion. And is think the JAX-RS way is only one part of the game. (Btw
 i don't like magic:) So i would prefer not to use
 annotation-based-injection-**something.)

 We should reuse the conversion infrastructure we have to convert one
 parameter into one value/attribute of the what-ever-mapped page state. But
 in the end there should be one object/type for an state of an page.

 Michael:)

Re: RFC-0001: Deprecating PageParameters for Wicket 7 (was Re: [4/4] git commit: WICKET-4997)

[tetsuo]

About changing parameters on stateful pages, one comment: one thing that
makes Wicket secure by default is exactly the fact that you get the
parameters when you create a page, and everything after is made by
interacting with components (which don't process values if disabled,
invisible, or invalid). If changing the URL now will re-inject parameters
on already-created stateful pages, it could lead to lots of security issues.

What the original author of the issue 4441 wanted, as I understand it, is
an easy way to get path parameters of the current request (query and post
parameters are already available), which is perfectly fine since you have
to ask for it, not to automatically change the PageParameter object of the
page.

About the setResponsePage() issue, I agree that varargs is not a good
solution at all. The builder is better, but is not better than just using a
PageParameter object. Keeping parameters separated from the base URL gives
you the flexibility of reusing a set or parameters to navigate to various
pages. With the builder, since the target page is the root, you'd have to
execute code to add each parameter to the builder, instead of reusing a
pre-built instance. And, if you add a 'with(parameters)' method, what's the
difference of just using a PageParameter in the first place?

And one more use-case: if I want a page to receive not a fixed set of
parameters, but any parameter that comes from the request? Say, an
intermediary page that must redirect (or forward) to another after some
processing, without having to URL-encode the whole redirect URL beforehand,
or that must accept POST requests. One could, of course, get the request
object and read the parameters directly from it, but would lose the
niceties of PageParameters, like conversion and default values. Is it a too
edge-case scenario?





On Fri, Aug 23, 2013 at 10:40 AM, Martijn Dashorst 
martijn.dasho...@gmail.com wrote:

 On Fri, Aug 23, 2013 at 3:28 PM, Martin Grigorov mgrigo...@apache.org
 wrote:
  I'd like to extend to pages as well: have stateful pages be able to
  respond to updated request parameters.
 
  See https://issues.apache.org/jira/browse/WICKET-4441
  I know of 3 users complained with this problem. Don't ask me to dig the
  mails. Just FYI.

 Yup, this is what triggered the RFC in the first place, when we
 started looking at how we would like to see how page parameters should
 work. Having done largish projects with JAX-RS, we feel that that
 programming model is a vast improvement over the current
 implementation in Wicket.

 It is something I'd like to spec to death in the RFC on how to work
 with existing stateful pages and parameter injection.

 Martijn

Re: Wicket hot reloading - Proof of concept

[tetsuo]

I use JRebel (I've bought it when a perpetual license was still available),
and it works great. If you use Scala, or do non-commercial development,
it's free.

But just using Jetty already saves you lots of time, since restarting the
whole server takes milliseconds. Wicket and Spring are pretty much
instantaneous, the only thing that still takes some time to startup is
Hibernate.





On Thu, Aug 1, 2013 at 4:59 AM, Martin Grigorov mgrigo...@apache.orgwrote:

 On Thu, Aug 1, 2013 at 9:53 AM, Cedric Gatay ced...@gatay.fr wrote:

  No I didn't know the run-jetty-run eclipse plugin, I am an Intellij IDEA
  user ;)
  I think that it could be a good feature if we allow simple hot reloading
  during development.
 

 Yes, the idea is to facilitate the development.
 The hot reloading is one of the main features in PlayFramework. At least
 developers coming from Ruby/Python/... love it. It could be just marketing
 but I doubt.

 If DCEVM gives this for free then there is no reason to support something
 own. But not all users want/can use something different than the official
 Hotspot VM.


 
  __
  Cedric Gatay (@Cedric_Gatay http://twitter.com/Cedric_Gatay)
  http://code-troopers.com | http://www.bloggure.info |
  http://cedric.gatay.fr
 
 
  On Thu, Aug 1, 2013 at 9:48 AM, Michael Mosmann mich...@mosmann.de
  wrote:
 
   Only to be sure.. You know the run-jetty-run eclipse plugin?
  
   Am 31.07.13 17:29, schrieb Cedric Gatay:
  
   Hi all,
  
   today I did a small Proof Of Concept of autocompile and hot reload
   fonctionnality for Wicket. The implementation is inspired by Xavier
   Hanin's
   work on restx (restx.io) (he inspired himself from PlayFramework!).
  
   You can find the implementation on the following github repo :
   https://github.com/code-**troopers/wicket-hot-reload
  https://github.com/code-troopers/wicket-hot-reload
  
   There is a lot of things to do, but with my basic example it works.
 The
   major thing we need to sort out is the actual need to destroy /
 recreate
   the whole application object whenever we want to load new classes.
  
   Any comments are welcome,
  
   Regards,
   __
   Cedric Gatay (@Cedric_Gatay http://twitter.com/Cedric_**Gatay
  http://twitter.com/Cedric_Gatay
   )
  
   http://code-troopers.com | http://www.bloggure.info |
   http://cedric.gatay.fr
  
  
  
 

Re: Deprecating wicket:enclosure

[tetsuo]

What about moving this functionality directly into MarkupContainer, so that
there's no need for an additional 'magic' component? Would it be feasible?



On Tue, Jun 18, 2013 at 9:37 AM, Nick Pratt nbpr...@gmail.com wrote:

 -1 to deprecate.  Same reasons as Igor stated.

 On Mon, Jun 17, 2013 at 5:44 PM, Martin Grigorov mgrigo...@apache.org
 wrote:

  Hi,
 
  We have several issues in Jira related to the same problem  -
  wicket:enclosure hides its children/parents from the other components
  while traversing the tree.
  See https://issues.apache.org/jira/browse/WICKET-5214 and my last
 comment
  for the links to the other tickets.
 
  There is a simple solution to this problem - use EnclosureContainer
  explicitly in Java code.
 
  I'd like to deprecate wicket:enclosure and remove Enclosure,
  InlineEnclosure and the related classes.
  Until now I think we have removed only wicket:component in Wicket 1.5
 but
  it wasn't used so much.
 
  Do you see another solution ?
 

Re: Generified Component

[tetsuo]

This change kind of works (I had to change getPath() too), but then for
every component I use LazyModel this way (every textfield in my case), I
get three exceptions thrown, then ignored (2 at getObjectClass() and 1 at
getPath()).

I guess using exceptions to flow control isn't very efficient, too... :)

Could Generics.getClass(type) be changed to not throw
IllegalArgumentException when it can't resolve the class? Maybe return null
and let callers deal with it?







On Fri, Jun 14, 2013 at 2:52 AM, Sven Meier s...@meiers.net wrote:

 Hi Tetsuo,

 I stand corrected:
 For #getObjectClass() the model had to be bound to something revealing its
 type.

 We cannot hold a reference to the type because this could lead to all
 sorts of class loading problems (see Wicket's IClassResolver). Furthermore
 it would unnecessarily increase the size of LazyModel in most cases (if
 everything is properly typed).

 I improved LazyModel to behave like PropertyModel, i.e. return the result
 object's type as fallback or just return null if everything fails.

 Sven


 On 06/14/2013 02:24 AM, tetsuo wrote:

 I made the changes to make it work, added a test case, and sent a pull
 request on github.
 Now it works when you create an unbound model from a class, and then bind
 it to a plain model.


 On Thu, Jun 13, 2013 at 6:39 PM, tetsuo ronald.tet...@gmail.com wrote:

  Well, you were the one who said that if I created the unbound model
 (from(A.class)) then I could bind it to a plain IModel, without the extra
 type information :)

 I just assumed that it would keep the 'A.class' information passed in the
 beginning and use it at runtime.

 It seems that the Evaluation holds the initial 'from' type, but it isn't
 passed down to LazyModel when it is created (it only receives target and
 stack), so it has to try to discover the type by itself, and fails.

 I'll try to do some experiments here...





 On Thu, Jun 13, 2013 at 6:21 PM, Sven Meier s...@meiers.net wrote:

  Well, here again LazyModel needs the type of the bound target at
 runtime.
 Without any runtime information about the model's object type, LazyModel
 cannot derive the type of the evaluation result.

 Sven


 On 06/13/2013 10:55 PM, tetsuo wrote:

  this test also passes here, but

   assertEquals(B.class, ((IObjectClassAwareModelB)
 model.bind(a)).getObjectClass());

   assertEquals(B.class, ((IObjectClassAwareModelB)
 model.bind(Model.of(a))).getObjectClass());



 While the first assert passes, but the second one doesn't.

 The exception is thrown not when getting the object, but the object
 class
 (the AbstractTextComponent class calls this before rendering and while
 converting input).





 On Thu, Jun 13, 2013 at 5:40 PM, Sven Meier s...@meiers.net wrote:

   Strange, works fine here:

   @Test
   public void bindToModelAndGet() {
   LazyModelB model = model(from(A.class).getB());

   final A a = new A();
   a.b = new B();

   assertEquals(a.b, model.bind(Model.of(a)).**
 getObject());


   }

 Sven


 On 06/13/2013 10:23 PM, tetsuo wrote:

   Thanks for the response!

 If I use an object instance, it works, but if I do as your third
 example
 (create a model from the class, then bind to a
 non-IObjectClassAwareModel-**model),


 it doesn't:

 public class TestPage extends WebPage {

private String text;

public TestPage(final PageParameters parameters) {

super(parameters);

add(new FormVoid(form)

.add(new TextFieldString(text,
 model(from(TestPage.class
 ).getText()).bind(Model.of(**this);



}

public String getText() { return text; }

public void setText(String text) { this.text = text; }

 }


 If I change 'Model.of(this)' to 'this' or an IObjectClassAwareModel
 implementation, it works:


class TestPageModel extends AbstractReadOnlyModel**
 TestPage

implements IObjectClassAwareModel**TestPage {



public TestPage getObject() { return TestPage.this; }

public ClassTestPage getObjectClass() { return
 TestPage.class;
 }

}


 Is this a bug? I could create some wrapper models to make it work,
 but
 if
 this is a bug, I'd prefer to wait for a corrected version.


 Thanks again


 On Thu, Jun 13, 2013 at 4:52 PM, Sven Meier s...@meiers.net wrote:

Hi,

  LazyModel needs to know the type of the model object to return an
 appropriate proxy:

  model(from(a).getB()); // works
  model(from(aModel).getB()); // aModel must be an
 IObjectClassAwareModel
  model(from(A.class).getB()).bind(aModel); // works
 even if

 aModel


 does not reveal its object class

 Sven


 On 06/13/2013 09:35 PM, tetsuo wrote:

wait, wait, do you actually do something like

  new TextFieldString(name, new IModelString(){
 public String getObject() {
 return entity.getName();
 }
 public void setObject

Re: Generified Component

[tetsuo]

I can make the change and send a pull request, but will it have a chance to
be accepted? :)


On Fri, Jun 14, 2013 at 4:18 PM, tetsuo ronald.tet...@gmail.com wrote:

 This change kind of works (I had to change getPath() too), but then for
 every component I use LazyModel this way (every textfield in my case), I
 get three exceptions thrown, then ignored (2 at getObjectClass() and 1 at
 getPath()).

 I guess using exceptions to flow control isn't very efficient, too... :)

 Could Generics.getClass(type) be changed to not throw
 IllegalArgumentException when it can't resolve the class? Maybe return null
 and let callers deal with it?







 On Fri, Jun 14, 2013 at 2:52 AM, Sven Meier s...@meiers.net wrote:

 Hi Tetsuo,

 I stand corrected:
 For #getObjectClass() the model had to be bound to something revealing
 its type.

 We cannot hold a reference to the type because this could lead to all
 sorts of class loading problems (see Wicket's IClassResolver). Furthermore
 it would unnecessarily increase the size of LazyModel in most cases (if
 everything is properly typed).

 I improved LazyModel to behave like PropertyModel, i.e. return the result
 object's type as fallback or just return null if everything fails.

 Sven


 On 06/14/2013 02:24 AM, tetsuo wrote:

 I made the changes to make it work, added a test case, and sent a pull
 request on github.
 Now it works when you create an unbound model from a class, and then bind
 it to a plain model.


 On Thu, Jun 13, 2013 at 6:39 PM, tetsuo ronald.tet...@gmail.com wrote:

  Well, you were the one who said that if I created the unbound model
 (from(A.class)) then I could bind it to a plain IModel, without the
 extra
 type information :)

 I just assumed that it would keep the 'A.class' information passed in
 the
 beginning and use it at runtime.

 It seems that the Evaluation holds the initial 'from' type, but it isn't
 passed down to LazyModel when it is created (it only receives target and
 stack), so it has to try to discover the type by itself, and fails.

 I'll try to do some experiments here...





 On Thu, Jun 13, 2013 at 6:21 PM, Sven Meier s...@meiers.net wrote:

  Well, here again LazyModel needs the type of the bound target at
 runtime.
 Without any runtime information about the model's object type,
 LazyModel
 cannot derive the type of the evaluation result.

 Sven


 On 06/13/2013 10:55 PM, tetsuo wrote:

  this test also passes here, but

   assertEquals(B.class, ((IObjectClassAwareModelB)
 model.bind(a)).getObjectClass());

   assertEquals(B.class, ((IObjectClassAwareModelB)
 model.bind(Model.of(a))).getObjectClass());



 While the first assert passes, but the second one doesn't.

 The exception is thrown not when getting the object, but the object
 class
 (the AbstractTextComponent class calls this before rendering and while
 converting input).





 On Thu, Jun 13, 2013 at 5:40 PM, Sven Meier s...@meiers.net wrote:

   Strange, works fine here:

   @Test
   public void bindToModelAndGet() {
   LazyModelB model = model(from(A.class).getB());

   final A a = new A();
   a.b = new B();

   assertEquals(a.b, model.bind(Model.of(a)).**
 getObject());


   }

 Sven


 On 06/13/2013 10:23 PM, tetsuo wrote:

   Thanks for the response!

 If I use an object instance, it works, but if I do as your third
 example
 (create a model from the class, then bind to a
 non-IObjectClassAwareModel-**model),


 it doesn't:

 public class TestPage extends WebPage {

private String text;

public TestPage(final PageParameters parameters) {

super(parameters);

add(new FormVoid(form)

.add(new TextFieldString(text,
 model(from(TestPage.class
 ).getText()).bind(Model.of(**this);



}

public String getText() { return text; }

public void setText(String text) { this.text = text; }

 }


 If I change 'Model.of(this)' to 'this' or an IObjectClassAwareModel
 implementation, it works:


class TestPageModel extends AbstractReadOnlyModel**
 TestPage

implements IObjectClassAwareModel**TestPage {



public TestPage getObject() { return TestPage.this; }

public ClassTestPage getObjectClass() { return
 TestPage.class;
 }

}


 Is this a bug? I could create some wrapper models to make it work,
 but
 if
 this is a bug, I'd prefer to wait for a corrected version.


 Thanks again


 On Thu, Jun 13, 2013 at 4:52 PM, Sven Meier s...@meiers.net
 wrote:

Hi,

  LazyModel needs to know the type of the model object to return an
 appropriate proxy:

  model(from(a).getB()); // works
  model(from(aModel).getB()); // aModel must be an
 IObjectClassAwareModel
  model(from(A.class).getB()).bind(aModel); // works
 even if

 aModel


 does not reveal its object class

 Sven


 On 06/13/2013 09:35 PM, tetsuo wrote:

wait, wait, do you actually do

Re: Generified Component

[tetsuo]

Thanks for the response!

If I use an object instance, it works, but if I do as your third example
(create a model from the class, then bind to a
non-IObjectClassAwareModel-model),
it doesn't:

public class TestPage extends WebPage {

private String text;

public TestPage(final PageParameters parameters) {

super(parameters);

add(new FormVoid(form)

.add(new TextFieldString(text, model(from(TestPage.class
).getText()).bind(Model.of(this);

}

public String getText() { return text; }

public void setText(String text) { this.text = text; }

}


If I change 'Model.of(this)' to 'this' or an IObjectClassAwareModel
implementation, it works:


class TestPageModel extends AbstractReadOnlyModelTestPage

implements IObjectClassAwareModelTestPage {

public TestPage getObject() { return TestPage.this; }

public ClassTestPage getObjectClass() { return TestPage.class; }

}


Is this a bug? I could create some wrapper models to make it work, but if
this is a bug, I'd prefer to wait for a corrected version.


Thanks again


On Thu, Jun 13, 2013 at 4:52 PM, Sven Meier s...@meiers.net wrote:

 Hi,

 LazyModel needs to know the type of the model object to return an
 appropriate proxy:

   model(from(a).getB()); // works
   model(from(aModel).getB()); // aModel must be an IObjectClassAwareModel
   model(from(A.class).getB()).**bind(aModel); // works even if aModel
 does not reveal its object class

 Sven


 On 06/13/2013 09:35 PM, tetsuo wrote:

 wait, wait, do you actually do something like

 new TextFieldString(name, new IModelString(){
  public String getObject() {
  return entity.getName();
  }
  public void setObject(String value) {
  entity.setName(value);
  }
  public void detach(){}
 });

 for every single field in your system, or you use LazyModel?

 Well, I've been trying to use LazyModel, but with it I have to pass the
 type of every field (the last arg of TextField's constructor) because if I
 don't, this exception is thrown:

 Caused by: java.lang.**IllegalArgumentException: T is not a class or
 parameterizedType

 at org.wicketstuff.lazymodel.**reflect.Generics.getClass(**
 Generics.java:78)

 at org.wicketstuff.lazymodel.**LazyModel.getObjectType(**
 LazyModel.java:139)

 at org.wicketstuff.lazymodel.**LazyModel.getObjectClass(**
 LazyModel.java:124)

 at org.apache.wicket.markup.html.**form.AbstractTextComponent.**
 getModelType(
 AbstractTextComponent.java:**167)

 at org.apache.wicket.markup.html.**form.AbstractTextComponent.**
 resolveType(
 AbstractTextComponent.java:**152)

 at org.apache.wicket.markup.html.**form.AbstractTextComponent.**
 onBeforeRender(
 AbstractTextComponent.java:**142)

 Any thoughts?

 I guess I'll just go back to CompoundPropertyModel... (sigh)


 (and no, I don't spend that much time debugging property models. I usually
 don't rename properties that often, and when I have to do some
 refactoring,
 usually the structure changes, and I have to revise all pages anyway...)




 On Fri, May 31, 2013 at 10:49 AM, Martin Grigorov mgrigo...@apache.org
 wrote:

  On Fri, May 31, 2013 at 4:24 PM, tetsuo ronald.tet...@gmail.com wrote:

  Black magic, or code generation? hard choice... :)
 I think I'll try the black magic, let's see how it goes :)

  I personally prefer writing the boilerplate of custom Model per field.
 It is a boring work but it gives me:
 * type safety
 * the fastest read/write access possible
 * easier debugging

 (who knows - maybe I've spent less time to write such models than you've
 spent to debug your issues with property model after refactoring)




 On Thu, May 30, 2013 at 8:16 PM, Igor Vaynberg igor.vaynb...@gmail.com

 wrote:
 On Thu, May 30, 2013 at 12:37 PM, tetsuo ronald.tet...@gmail.com

 wrote:

 -1000!

 This will be horrible! Even with the current API, most generics I

 have

 to

 declare in my code don't add anything to type safety. For example:

 while i am also not a fan of having component generified i do believe
 the example below is a bit contrived.

 first, i hope most people do not use PropertyModels because they are
 not compile-time-safe. there are plenty of project that implement
 compile-time-safe models, personally i prefer
 https://github.com/42Lines/**metagenhttps://github.com/42Lines/metagento
  using proxy-based solutions.

 further, i hope even less people use compound property models. they
 are even more unsafe then property models and make your code even more
 fragile. i would hate to refactor code that uses CPMs.

  add(new FormPerson(form, new CompoundPropertyModelPerson(**
 new
 PropertyModelPerson(this, person)))
.add(new TextFieldString(name))
.add(new TextFieldInteger(age))
.add(new TextFieldDouble(salary))
.add(new Button(save, new

 PropertyModelPerson(this,**person)){

   public void onSubmit() {

  repository.save((Person)**getForm().**getDefaultModelObject

Re: Generified Component

[tetsuo]

this test also passes here, but

assertEquals(B.class, ((IObjectClassAwareModelB)
model.bind(a)).getObjectClass());

assertEquals(B.class, ((IObjectClassAwareModelB)
model.bind(Model.of(a))).getObjectClass());


While the first assert passes, but the second one doesn't.

The exception is thrown not when getting the object, but the object class
(the AbstractTextComponent class calls this before rendering and while
converting input).





On Thu, Jun 13, 2013 at 5:40 PM, Sven Meier s...@meiers.net wrote:

 Strange, works fine here:

 @Test
 public void bindToModelAndGet() {
 LazyModelB model = model(from(A.class).getB());

 final A a = new A();
 a.b = new B();

 assertEquals(a.b, model.bind(Model.of(a)).**getObject());
 }

 Sven


 On 06/13/2013 10:23 PM, tetsuo wrote:

 Thanks for the response!

 If I use an object instance, it works, but if I do as your third example
 (create a model from the class, then bind to a
 non-IObjectClassAwareModel-**model),
 it doesn't:

 public class TestPage extends WebPage {

  private String text;

  public TestPage(final PageParameters parameters) {

  super(parameters);

  add(new FormVoid(form)

  .add(new TextFieldString(text, model(from(TestPage.class
 ).getText()).bind(Model.of(**this);

  }

  public String getText() { return text; }

  public void setText(String text) { this.text = text; }

 }


 If I change 'Model.of(this)' to 'this' or an IObjectClassAwareModel
 implementation, it works:


  class TestPageModel extends AbstractReadOnlyModel**TestPage

  implements IObjectClassAwareModel**TestPage {

  public TestPage getObject() { return TestPage.this; }

  public ClassTestPage getObjectClass() { return TestPage.class;
 }

  }


 Is this a bug? I could create some wrapper models to make it work, but if
 this is a bug, I'd prefer to wait for a corrected version.


 Thanks again


 On Thu, Jun 13, 2013 at 4:52 PM, Sven Meier s...@meiers.net wrote:

  Hi,

 LazyModel needs to know the type of the model object to return an
 appropriate proxy:

model(from(a).getB()); // works
model(from(aModel).getB()); // aModel must be an
 IObjectClassAwareModel
model(from(A.class).getB()).bind(aModel); // works even if aModel

 does not reveal its object class

 Sven


 On 06/13/2013 09:35 PM, tetsuo wrote:

  wait, wait, do you actually do something like

 new TextFieldString(name, new IModelString(){
   public String getObject() {
   return entity.getName();
   }
   public void setObject(String value) {
   entity.setName(value);
   }
   public void detach(){}
 });

 for every single field in your system, or you use LazyModel?

 Well, I've been trying to use LazyModel, but with it I have to pass the
 type of every field (the last arg of TextField's constructor) because
 if I
 don't, this exception is thrown:

 Caused by: java.lang.IllegalArgumentException: T is not a class or
 parameterizedType

 at org.wicketstuff.lazymodel.reflect.Generics.getClass(**
 Generics.java:78)

 at org.wicketstuff.lazymodel.LazyModel.getObjectType(**
 LazyModel.java:139)

 at org.wicketstuff.lazymodel.LazyModel.getObjectClass(**
 LazyModel.java:124)

 at org.apache.wicket.markup.html.form.AbstractTextComponent.
 getModelType(
 AbstractTextComponent.java:167)

 at org.apache.wicket.markup.html.form.AbstractTextComponent.
 resolveType(
 AbstractTextComponent.java:152)

 at org.apache.wicket.markup.html.form.AbstractTextComponent.
 onBeforeRender(
 AbstractTextComponent.java:142)


 Any thoughts?

 I guess I'll just go back to CompoundPropertyModel... (sigh)


 (and no, I don't spend that much time debugging property models. I
 usually
 don't rename properties that often, and when I have to do some
 refactoring,
 usually the structure changes, and I have to revise all pages anyway...)




 On Fri, May 31, 2013 at 10:49 AM, Martin Grigorov mgrigo...@apache.org

 wrote:

   On Fri, May 31, 2013 at 4:24 PM, tetsuo ronald.tet...@gmail.com
 wrote:

   Black magic, or code generation? hard choice... :)

 I think I'll try the black magic, let's see how it goes :)

   I personally prefer writing the boilerplate of custom Model per
 field.

 It is a boring work but it gives me:
 * type safety
 * the fastest read/write access possible
 * easier debugging

 (who knows - maybe I've spent less time to write such models than
 you've
 spent to debug your issues with property model after refactoring)




  On Thu, May 30, 2013 at 8:16 PM, Igor Vaynberg 
 igor.vaynb...@gmail.com

  wrote:
 On Thu, May 30, 2013 at 12:37 PM, tetsuo ronald.tet...@gmail.com

  wrote:

  -1000!

 This will be horrible! Even with the current API, most generics I

  have

 to

  declare in my code don't add anything to type safety. For example:
 while i am also not a fan of having component generified i

Re: Generified Component

[tetsuo]

I made the changes to make it work, added a test case, and sent a pull
request on github.
Now it works when you create an unbound model from a class, and then bind
it to a plain model.


On Thu, Jun 13, 2013 at 6:39 PM, tetsuo ronald.tet...@gmail.com wrote:

 Well, you were the one who said that if I created the unbound model
 (from(A.class)) then I could bind it to a plain IModel, without the extra
 type information :)

 I just assumed that it would keep the 'A.class' information passed in the
 beginning and use it at runtime.

 It seems that the Evaluation holds the initial 'from' type, but it isn't
 passed down to LazyModel when it is created (it only receives target and
 stack), so it has to try to discover the type by itself, and fails.

 I'll try to do some experiments here...





 On Thu, Jun 13, 2013 at 6:21 PM, Sven Meier s...@meiers.net wrote:

 Well, here again LazyModel needs the type of the bound target at runtime.
 Without any runtime information about the model's object type, LazyModel
 cannot derive the type of the evaluation result.

 Sven


 On 06/13/2013 10:55 PM, tetsuo wrote:

 this test also passes here, but

  assertEquals(B.class, ((IObjectClassAwareModelB)
 model.bind(a)).getObjectClass(**));

  assertEquals(B.class, ((IObjectClassAwareModelB)
 model.bind(Model.of(a))).**getObjectClass());


 While the first assert passes, but the second one doesn't.

 The exception is thrown not when getting the object, but the object class
 (the AbstractTextComponent class calls this before rendering and while
 converting input).





 On Thu, Jun 13, 2013 at 5:40 PM, Sven Meier s...@meiers.net wrote:

  Strange, works fine here:

  @Test
  public void bindToModelAndGet() {
  LazyModelB model = model(from(A.class).getB());

  final A a = new A();
  a.b = new B();

  assertEquals(a.b, model.bind(Model.of(a)).getObject());

  }

 Sven


 On 06/13/2013 10:23 PM, tetsuo wrote:

  Thanks for the response!

 If I use an object instance, it works, but if I do as your third
 example
 (create a model from the class, then bind to a
 non-IObjectClassAwareModel-model),

 it doesn't:

 public class TestPage extends WebPage {

   private String text;

   public TestPage(final PageParameters parameters) {

   super(parameters);

   add(new FormVoid(form)

   .add(new TextFieldString(text,
 model(from(TestPage.class
 ).getText()).bind(Model.of(this);


   }

   public String getText() { return text; }

   public void setText(String text) { this.text = text; }

 }


 If I change 'Model.of(this)' to 'this' or an IObjectClassAwareModel
 implementation, it works:


   class TestPageModel extends AbstractReadOnlyModelTestPage

   implements IObjectClassAwareModelTestPage {


   public TestPage getObject() { return TestPage.this; }

   public ClassTestPage getObjectClass() { return
 TestPage.class;
 }

   }


 Is this a bug? I could create some wrapper models to make it work, but
 if
 this is a bug, I'd prefer to wait for a corrected version.


 Thanks again


 On Thu, Jun 13, 2013 at 4:52 PM, Sven Meier s...@meiers.net wrote:

   Hi,

 LazyModel needs to know the type of the model object to return an
 appropriate proxy:

 model(from(a).getB()); // works
 model(from(aModel).getB()); // aModel must be an
 IObjectClassAwareModel
 model(from(A.class).getB()).**bind(aModel); // works even if
 aModel


 does not reveal its object class

 Sven


 On 06/13/2013 09:35 PM, tetsuo wrote:

   wait, wait, do you actually do something like

 new TextFieldString(name, new IModelString(){
public String getObject() {
return entity.getName();
}
public void setObject(String value) {
entity.setName(value);
}
public void detach(){}
 });

 for every single field in your system, or you use LazyModel?

 Well, I've been trying to use LazyModel, but with it I have to pass
 the
 type of every field (the last arg of TextField's constructor) because
 if I
 don't, this exception is thrown:

 Caused by: java.lang.**IllegalArgumentException: T is not a
 class or
 parameterizedType

 at org.wicketstuff.lazymodel.**reflect.Generics.getClass(**
 Generics.java:78)

 at org.wicketstuff.lazymodel.**LazyModel.getObjectType(**
 LazyModel.java:139)

 at org.wicketstuff.lazymodel.**LazyModel.getObjectClass(**
 LazyModel.java:124)

 at org.apache.wicket.markup.html.**form.**
 AbstractTextComponent.
 getModelType(
 AbstractTextComponent.java:**167)

 at org.apache.wicket.markup.html.**form.**
 AbstractTextComponent.
 resolveType(
 AbstractTextComponent.java:**152)

 at org.apache.wicket.markup.html.**form.**
 AbstractTextComponent.
 onBeforeRender(
 AbstractTextComponent.java:**142)



 Any thoughts?

 I guess I'll just go back to CompoundPropertyModel... (sigh

Re: Generified Component

[tetsuo]

-1000!

This will be horrible! Even with the current API, most generics I have to
declare in my code don't add anything to type safety. For example:

   add(new FormPerson(form, new CompoundPropertyModelPerson(new
PropertyModelPerson(this, person)))
  .add(new TextFieldString(name))
  .add(new TextFieldInteger(age))
  .add(new TextFieldDouble(salary))
  .add(new Button(save, new PropertyModelPerson(this,person)){
 public void onSubmit() {
repository.save((Person)getForm().getDefaultModelObject());
 }
  });

In my experience, this kind of code is fairly common in Wicket
applications. Every form component must be declared with a type, but none
has *any* kind of type safety gain.

- The property model uses reflection, so its type can't be verified by the
compiler (this.person could be anything, not just a Person).
- Generics will guarantee that the form model will be of type Person, but
since it's all declared inline, and the real model isn't verifiable, it
just adds lots of verbosity without any real gain.
- Most form components use the implicit model, that also uses reflection,
and also can't verify the actual type of the underlying property, at
compilation time. Even in runtime, *the type information is lost due erasure
*, so it can't use it to do any additional verification.
*- Worse, you can even declare the name TextField as Integer or
Double (while maintaining the 'text' attribute as String), and since
there is no type information at runtime, it doesn't matter. It won't even
throw an exception (it will just work normally).* In this case, the type
declaration is simply a lie.

Just pain, no gain. In my code, I sometimes just add a @SuppressWarnings(
rawtypes) to the class, and remove all useless generic type declarations.
If everything will be required to declare them, I will have do it more
frequently.

That said, repeater components benefit greatly from generics. So do custom
models, validators, and converters. Or the rare cases that we explicitly
declare the form component model. But forcing everything to be
generic-typed will just make Wicket extremely verbose to use, with very
little benefit.




On Thu, May 30, 2013 at 4:00 AM, Martin Grigorov mgrigo...@apache.orgwrote:

 Hi,

 I just pushed some initial work for [1] and [2] in
 branch generified-component-4930.

 So far it doesn't look nice.

 The added generics break somehow setMetaData/getMetaData methods - you can
 see compilation errors in Component and Page classes. I think it is caused
 by the anonymous instance of MetaDataKey ( new MetaDataKeyT(type) {} ).

 Also the visit*** methods do not compile at the moment, but even if we find
 a way to fix their signature I think writing a visitor will become quite
 cumbersome.
 At the moment we have IVisitor
 and org.apache.wicket.util.iterator.AbstractHierarchyIterator which do the
 same job. The Iterator API is supposed to be simpler to write for the
 users. Maybe we can drop  IVisitor ... ?!

 I'd like to ask for help with this task. It is supposed to be the biggest
 API break for Wicket 7.0. My current feeling is that the end result won't
 be very pleasant for the user-land code.
 For example the application code will have to do something like:

   WebMarkupContainerVoid wmc = new WebMarkupContainer(id)

 It is not that much but we have to decide whether we want it.
 But first let's try to fix the compilation problems.


 1. https://issues.apache.org/jira/browse/WICKET-4930 (Add generics to
 o.a.w.Component)
 2.

 https://cwiki.apache.org/confluence/display/WICKET/Wicket+7.0+Roadmap#Wicket7.0Roadmap-Genericsfororg.apache.wicket.Component

Re: Dynamic decision which version of jQuery to contribute

[tetsuo]

Just not by default, please.


On Mon, May 27, 2013 at 6:32 PM, Sebastien seb...@gmail.com wrote:

 Hi Martin,

 About the dynamic calculation, can't it be made according to an
 IApplicationSettings or an IJavaScriptLibrarySettings flag? Maybe could
 this flag be false by default and the user may set it to true it if its
 application needs to be used by IE6/7/8?

 Thanks  best regards,
 Sebastien


 On Mon, May 27, 2013 at 11:20 PM, Martin Grigorov mgrigo...@apache.org
 wrote:

  Hi,
 
  At https://issues.apache.org/jira/browse/WICKET-5208 you may see a
 simple
  patch that makes JQueryResourceReference more dynamic.
  With this change Wicket can deliver jQuery 2.x to modern browsers and
  jQuery 1.x for IE 6/7/8.
 
  Pros: smaller jQuery
  Cons: dynamic calculation by using the user agent to make the decision.
 
  Do you think this is useful/problematic ?
 
  The user application still can set its own ResourceReference with jQuery
  version that it prefers.
 

Re: Benchmarks with wicket in top 10

[tetsuo]

No, parleys is not free. Some talks are, but most aren't.


On Thu, Apr 4, 2013 at 8:11 AM, Martin Grigorov mgrigo...@apache.orgwrote:

 Am I using parleys.com wrongly or it is not exactly free ?
 It allows me to watch the first N minutes and then asks me to pay an annual
 fee to be able to watch more.


 On Sat, Mar 30, 2013 at 7:49 PM, Cedric Gatay ced...@gatay.fr wrote:

  It's nice to see this anyway. This week at Devoxx France, Matt Raible did
  another round of its Web Framework for the JVM and Wicket is still one of
  the leaders (you can view its slides here :
 
 
 http://fr.slideshare.net/mraible/comparing-jvm-web-frameworks-devoxx-france-2013?utm_source=slideshowutm_medium=ssemailutm_campaign=upload_digest
  )
  and, in a month or two, when it will hit parleys.com, you'll be able to
  watch the entire talk free of charge ! ;)
 
 
  On Fri, Mar 29, 2013 at 9:55 AM, Martijn Dashorst 
  martijn.dasho...@gmail.com wrote:
 
   I'm not sure what they benchmarked and why they used Wicket to render
   JSON, but it is good to see Wicket perform consistently in the top 10,
   and in one place on number 3.
  
   http://www.techempower.com/blog/2013/03/28/framework-benchmarks/
  
   Martijn
  
 



 --
 Martin Grigorov
 jWeekend
 Training, Consulting, Development
 http://jWeekend.com http://jweekend.com/

Re: Benchmarks with wicket in top 10

[tetsuo]

Well, it was the last time I looked into it. Now, the 'pricing' page says
it's free for viewers...


On Thu, Apr 4, 2013 at 8:53 AM, tetsuo ronald.tet...@gmail.com wrote:

 No, parleys is not free. Some talks are, but most aren't.


 On Thu, Apr 4, 2013 at 8:11 AM, Martin Grigorov mgrigo...@apache.orgwrote:

 Am I using parleys.com wrongly or it is not exactly free ?
 It allows me to watch the first N minutes and then asks me to pay an
 annual
 fee to be able to watch more.


 On Sat, Mar 30, 2013 at 7:49 PM, Cedric Gatay ced...@gatay.fr wrote:

  It's nice to see this anyway. This week at Devoxx France, Matt Raible
 did
  another round of its Web Framework for the JVM and Wicket is still one
 of
  the leaders (you can view its slides here :
 
 
 http://fr.slideshare.net/mraible/comparing-jvm-web-frameworks-devoxx-france-2013?utm_source=slideshowutm_medium=ssemailutm_campaign=upload_digest
  )
  and, in a month or two, when it will hit parleys.com, you'll be able to
  watch the entire talk free of charge ! ;)
 
 
  On Fri, Mar 29, 2013 at 9:55 AM, Martijn Dashorst 
  martijn.dasho...@gmail.com wrote:
 
   I'm not sure what they benchmarked and why they used Wicket to render
   JSON, but it is good to see Wicket perform consistently in the top 10,
   and in one place on number 3.
  
   http://www.techempower.com/blog/2013/03/28/framework-benchmarks/
  
   Martijn
  
 



 --
 Martin Grigorov
 jWeekend
 Training, Consulting, Development
 http://jWeekend.com http://jweekend.com/

Re: Problem upgrading from 1.4 to 1.5

[tetsuo]

You don't have a servlet-mapping?

On Mon, Feb 25, 2013 at 9:30 AM, David Torres david.tor...@renuda.com wrote:
 Hello list.

 My name is David, and I started recently to develop tools for Sakai. We
 decided to use Wicket and we are happy with that.

 The problem is that we started from a existent Hello world example (a Maven
 archetype) written for Wicket 1.4.17. However we would like to migrate to
 1.5 (and even 6 when we have 1.5 working) to take advantage of all the new
 functionality (like tree viewers and graphic charts).

 When I started the migration I just changed the name of the version, and of
 course it didn't work. But following this guide: dev@wicket.apache.org, I
 managed to build it (I use Maven)

 However I got an error (please find trace below). I updated my dependencies
 to use Api Servlet 2.5 instead 2.4 but I am still having the same error, and
 the tool worked perfectly with Wicket 1.4

 Could somebody help me, please?

 Please find attached also the web.xml of my tool, where I think the problem
 is.

 Thank you in advance



 org.sakaiproject.portal.api.PortalHandlerException:
 java.lang.IllegalStateException: filter path was not configured
 at
 org.sakaiproject.portal.charon.SkinnableCharonPortal.doGet(SkinnableCharonPortal.java:881)
 caused by: java.lang.IllegalStateException: filter path was not configured
 at
 org.apache.wicket.protocol.http.WicketFilter.processRequest(WicketFilter.java:164)
 at
 org.apache.wicket.protocol.http.WicketServlet.doGet(WicketServlet.java:137)
 at javax.servlet.http.HttpServlet.service(HttpServlet.java:621)
 at javax.servlet.http.HttpServlet.service(HttpServlet.java:728)
 at
 org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:305)
 at
 org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
 at org.sakaiproject.util.RequestFilter.doFilter(RequestFilter.java:634)
 at
 org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:243)
 at
 org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
 at
 org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:749)
 at
 org.apache.catalina.core.ApplicationDispatcher.processRequest(ApplicationDispatcher.java:487)
 at
 org.apache.catalina.core.ApplicationDispatcher.doForward(ApplicationDispatcher.java:379)
 at
 org.apache.catalina.core.ApplicationDispatcher.forward(ApplicationDispatcher.java:339)
 at
 org.sakaiproject.tool.impl.ActiveToolComponent$MyActiveTool.forward(ActiveToolComponent.java:511)
 at
 org.sakaiproject.portal.charon.SkinnableCharonPortal.forwardTool(SkinnableCharonPortal.java:1470)
 at
 org.sakaiproject.portal.charon.handlers.ToolHandler.doTool(ToolHandler.java:213)
 at
 org.sakaiproject.portal.charon.handlers.ToolHandler.doGet(ToolHandler.java:96)
 at
 org.sakaiproject.portal.charon.SkinnableCharonPortal.doGet(SkinnableCharonPortal.java:881)
 at javax.servlet.http.HttpServlet.service(HttpServlet.java:621)
 at javax.servlet.http.HttpServlet.service(HttpServlet.java:728)
 at
 org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:305)
 at
 org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
 at org.sakaiproject.util.RequestFilter.doFilter(RequestFilter.java:695)
 at
 org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:243)
 at
 org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
 at
 org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:222)
 at
 org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:123)
 at
 org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:472)
 at
 org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:171)
 at
 org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:99)
 at
 org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:936)
 at
 org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:118)
 at
 org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:407)
 at
 org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1004)
 at
 org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:589)
 at
 org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:312)
 at
 java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
 at
 java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
 at java.lang.Thread.run(Thread.java:662)





 Best regards,

 David Torres



 Computer Scientist

 Renuda UK



 tel: +44 

Re: Problem upgrading from 1.4 to 1.5

[tetsuo]

Portlet support was dropped in 1.5...

On Mon, Feb 25, 2013 at 1:11 PM, David Torres david.tor...@renuda.com wrote:
 I would like to try that, but then I would need to use url-pattern, and  
 the URL of my tool is this
 http://localhost:8080/portal/site/ac656672-cc87-4b21-be4b-dc3966f67ff8/page/f02e537d-a2de-4331-9e45-7429e0cfe645

 I have try this
 url-pattern/site/ac656672-cc87-4b21-be4b-dc3966f67ff8/page/f02e537d-a2de-4331-9e45-7429e0cfe645/url-pattern
 and this
 url-pattern/site/ac656672-cc87-4b21-be4b-dc3966f67ff8/page/f02e537d-a2de-4331-9e45-7429e0cfe645/*/url-pattern

 also this
 url-pattern/*/url-pattern

 In all cases obtaining the error below.

 Is it necessary to use url-pattern? I have an example without it, using 
 wicket servlet but without servlet-mapping and it is working for version 1.4




 org.sakaiproject.portal.api.PortalHandlerException: 
 java.lang.IllegalArgumentException: Unable to find registered context for 
 tool with ID sakai.wicketArchetype
 at 
 org.sakaiproject.portal.charon.SkinnableCharonPortal.doGet(SkinnableCharonPortal.java:881)
 caused by: java.lang.IllegalArgumentException: Unable to find registered 
 context for tool with ID sakai.wicketArchetype
 at 
 org.sakaiproject.tool.impl.ActiveToolComponent$MyActiveTool.forward(ActiveToolComponent.java:508)
 at 
 org.sakaiproject.portal.charon.SkinnableCharonPortal.forwardTool(SkinnableCharonPortal.java:1470)
 at 
 org.sakaiproject.portal.charon.handlers.ToolHandler.doTool(ToolHandler.java:213)
 at 
 org.sakaiproject.portal.charon.handlers.ToolHandler.doGet(ToolHandler.java:96)
 at 
 org.sakaiproject.portal.charon.SkinnableCharonPortal.doGet(SkinnableCharonPortal.java:881)
 at javax.servlet.http.HttpServlet.service(HttpServlet.java:621)
 at javax.servlet.http.HttpServlet.service(HttpServlet.java:728)
 at 
 org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:305)
 at 
 org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
 at org.sakaiproject.util.RequestFilter.doFilter(RequestFilter.java:695)
 at 
 org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:243)
 at 
 org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
 at 
 org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:222)
 at 
 org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:123)
 at 
 org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:472)
 at 
 org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:171)
 at 
 org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:99)
 at 
 org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:936)
 at 
 org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:118)
 at 
 org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:407)
 at 
 org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1004)
 at 
 org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:589)
 at 
 org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:312)
 at 
 java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
 at 
 java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
 at java.lang.Thread.run(Thread.java:662)


 Best regards,

 David Torres

 Computer Scientist
 Renuda UK

 tel: +44 (0)20 3371 1709
 web: www.renuda.com

 Renuda UK is registered in England and Wales.  Company number 6218863.
 VAT registration number 918 6490 91. Registered office: 35 Charleville Road, 
 London W14 9JJ, UK.

 
 From: Hans Lesmeister 2 [hans.lesmeis...@lessy-software.de]
 Sent: 25 February 2013 12:46
 To: dev@wicket.apache.org
 Subject: Re: Problem upgrading from 1.4 to 1.5

 Hi,

 better use WicketFilter instead of WicketServlet



 -
 --
 Regards,
 Hans

 http://cantaa.de

 --
 View this message in context: 
 http://apache-wicket.1842946.n4.nabble.com/Problem-upgrading-from-1-4-to-1-5-tp4656762p4656763.html
 Sent from the Forum for Wicket Core developers mailing list archive at 
 Nabble.com.

Re: remove javax.servlet from wicket-core

[tetsuo]

Isolating Servlet dependencies could potentially ease portlet support, too.

It won't be an easy task, though. Some of the main classes of the
framework, like WicketFilter, are deeply coupled to the Servlet API.

But I'm not sure if the benefits out-weight the cost of doing the changes
and probably breaking (once more) compatibility with older versions.


On Thu, Jan 17, 2013 at 8:53 PM, Michael Mosmann mich...@mosmann.de wrote:

 What i want to know: Is there any chance, that this can succeed? This will
 change wicket in many places, and i understand, that nobody will accept
 this as an wicket 6.x.y improvment. Maybe this is the wrong direction,
 maybe the right thing to early, not the best thing we could do now...

Re: new wicket extensions

[tetsuo]

Well, I don't think drag-and-drop modal tree tables are essential to
any widget toolkit, but date pickers and modal dialogs are. It's
fairly easy to integrate javascript libraries (like jquery-ui) to
wicket, but it surely demands some work to do it.

I try to sell Wicket to enterprise developers, since it is the market
I work for. We often don't have the requirement of pixel-perfect
design fidelity to a designer's vision, so the pre-built components,
with some style tuning, are more than enough (even the ugly
Wicket-built-in-ModalWindow). And a set of out-of-the-box components
are a nice productivity boost.

And, in this market, being an official (or officially 'blessed')
library is important, and breaks many barriers. Saying to your manager
that it is not maintained by some random guy of the Internet, but by
Apache, makes a huge difference.





On Thu, Dec 13, 2012 at 6:08 PM, Martin Sachs sachs.mar...@gmail.com wrote:
 hi,

 you sell wicket to people, that want to have rich components ?

 We developing an application for an enterprise with wicket and have no
 need for rich component, because we need to create a page in a specific
 design from a design agency. no rich component library has the
 flexibility to meet the need of the customer (i know that from jsf and
 its primefaces or whatever). With wicket its quite easy to create all
 widgets you need, yourself in a very short time.

 People who just create small sites could probably have little need for
 this, but only for at the beginning of a project-lifecycle

 just my 2 cents


 Am 13.12.2012 20:33, schrieb tetsuo:
 What about home-baking or incorporating (if donated, obviously) a
 library that integrates jquery-ui components into an official
 wicket-jqueryui or wicket-widgets project?

 When I'm trying to sell Wicket to people, one thing they always
 complain is that it lacks a rich component library (sf.net and
 googlecode projects don't count).
 Having jquery-ui pre-integrated would be a huge win.




 On Thu, Dec 13, 2012 at 4:34 PM, Burton, Tom F (DOR)
 tom.bur...@alaska.gov wrote:
 +1  I would like to see a Date/Time/Picker remain a part of core as well.

 However, I find myself getting confused are we talking about.

 Are we talking about one of the full blown fields on the Dates example page?
 http://www.wicket-library.com/wicket-examples/dates/
 Or are we just talking about the Datepicker component?

 Tom


 -Original Message-
 From: Nick Pratt [mailto:nbpr...@gmail.com]
 Sent: Thursday, December 13, 2012 5:25 AM
 To: dev@wicket.apache.org
 Subject: Re: new wicket extensions

 Since most data entry forms Ive seen involve dates, a well supported 
 datetime component as part of the core wicket distribution, based on 
 jquery-ui, released in lock-step with the other core wicket JARs, would 
 IMHO, be most beneficial.  It would reduce barriers to entry, provide a 
 common good looking, functional datetime component that would work for 90%+ 
 of the cases, that most people would use, understand, and be able to debug 
 and support.

 It doesn't preclude the use of other date time components, but as a 
 developer using a framework, I prefer common supported out-of-the-box 
 components to other libs.

 N

 On Thu, Dec 13, 2012 at 3:45 AM, Martin Grigorov 
 mgrigo...@apache.orgwrote:

 Hi,

 Here is my opinion on this topic

 Option 5) Deprecate wicket-datetime and move it in WicketStuff when
 Wicket
 7 is released.
 If someone needs a date picker there are several other options:
 - wiquery
 - wicket-jquery-ui
 - wicket-bootstrap



 On Wed, Dec 12, 2012 at 8:04 PM, Ernesto Reinaldo Barreiro 
 reier...@gmail.com wrote:

 Hi,

 In discussion at



 http://apache-wicket.1842946.n4.nabble.com/a-question-on-different-dat
 a-grid-components-available-for-wicket-tt4654273.html
 Martin Grigorov mentioned that maybe it is time to improve
 wicket-datetime.

 I see following possibilities.

 1- Try to upgrade to more resent version of YUI.
 2- Try to rewrite wicket-date.js in terms of jquery, now that
 wicket 6.0.x is jquery based. Similarly to what it has been done
 for inMethod grid. This has the advantage that existing
 functionality will not
 break.
 3- Replace, or provide an alternative to, wicket-date.js rolling out
 a component based on one of the (many) existing jquery based date pickers.
 4- Any other option?

 What would be the most useful thing to do?

 In case of option [3].

 What would be a good  jquery based replacement/alternative for
 wicket-datetime?


 1-http://jqueryui.com/datepicker/? Maybe also
 http://trentrichardson.com/examples/timepicker/
 2-http://www.kelvinluck.com/assets/jquery/datePicker/v2/demo/
 3-http://keith-wood.name/datepick.html
 4-http://www.eyecon.ro/datepicker/
 4-Others?


 Also see
 http://www.tripwiremagazine.com/2012/08/jquery-datepicker.html

 --
 Regards - Ernesto Reinaldo Barreiro
 Antilia Soft
 http://antiliasoft.com/ http://antiliasoft.com/antilia



 --
 Martin Grigorov
 jWeekend
 Training, Consulting

Re: new wicket extensions

[tetsuo]

Wicket already uses jquery for its ajax support. A jquery-ui module
(thus the dependency to jquery-ui.js) would be completely optional, as
is the embedded yui library currently used by wicket-extensions.



On Thu, Dec 13, 2012 at 8:29 PM, Michael Haitz michael.ha...@1und1.de wrote:
 I think wicket should only provide basic components without dependencies to 
 keep clean and simple (and extendable). Libraries like jquery-ui or bootstrap 
 would break this and everyone who wants to use wicket has to use the choosen 
 ui lib too. And there isn't a all in one lib suitable for every purpose.

Re: Component setDefaultModel

[tetsuo]

Couldn't it be solved with a delegate model? It wouldn't be 100%
transparent, because the one who changes the underlying model would
need to know that the container's model is a delegating model, but
works perfectly.

Well, but if you guys are so eager to break things... what about this:
make getDefaultModel() never return the assigned model directly, but a
wrapper, that delegates to the real one (assigned by
setDefaultModel()). That way, any component that calls
getParent().getDefaultModel() will automatically get the new model.

All code out there that relies on 'if (getDefaultModel() instanceof
XXX)' will break (since it will return the wrapper), but this edge
case will work.



On Thu, Sep 27, 2012 at 7:18 PM, Jeremy Thomerson
jer...@wickettraining.com wrote:
 On Thu, Sep 27, 2012 at 3:33 PM, tetsuo ronald.tet...@gmail.com wrote:

 What about calling APanel.setDefaultModelObject(B.getObject()) instead
 of APanel.setDefaultModel(B)?


 That's to replace an object inside a model.  There are very valid usecases
 for actually replacing a model.

 --
 Jeremy Thomerson
 http://wickettraining.com
 *Need a CMS for Wicket?  Use Brix! http://brixcms.org*

Re: Wicket 6: some hanging fruit before final?

[tetsuo]

If the code doesn't require it, why add it artificially?
Is there any planned feature that may potentially require it?



On Wed, Aug 22, 2012 at 5:35 PM, Martijn Dashorst
martijn.dasho...@gmail.com wrote:
 http://s.apache.org/wicket-servlet3-discuss

 It has been proposed a couple of times for the roadmap for 6. There is
 no confusion between Emond and myself (at least for servlet 3, I won't
 comment on any confusion on other topics :-)). We both think that
 servlet 3 is out long enough and supported widely enough to move on
 (or he has changed his opinion since last I've seen him).

 Martijn

 On Wed, Aug 22, 2012 at 10:14 PM, Martin Grigorov mgrigo...@apache.org 
 wrote:
 Hi,

 Requiring Servlet 3.x as minimum version has never been in the scope
 of Wicket 6. It is neither in the roadmap page nor there was any mail
 discussion about this.
 I think this is some confusion in/between you and Emond. He also
 mentioned this few months ago in IRC.

 I see no reason to require Servlet 3.0 at this moment. Atmosphere
 doesn't need it.

 On Wed, Aug 22, 2012 at 10:35 PM, Martijn Dashorst
 martijn.dasho...@gmail.com wrote:
 All,

 As I was preparing to build a final, I noticed that we don't yet have
 moved to servlet 3 in master. I thought that for the web socket stuff
 we needed to at least move to 3.0. I do see a commit in the history
 that adds servlet 3 done by Emond. I also see a commit reverting Jetty
 from jetty 8 to jetty 7 as jetty 8 requires servlet 3, also done by
 Emond.

 I wonder what the status is of our servlet 3 handling, is it still on
 the map for 6? We can't upgrade to 3 in 6.x after 6.0, so I'd rather
 move now than later.

 Martijn

 --
 Become a Wicket expert, learn from the best: http://wicketinaction.com



 --
 Martin Grigorov
 jWeekend
 Training, Consulting, Development
 http://jWeekend.com



 --
 Become a Wicket expert, learn from the best: http://wicketinaction.com

Re: Wicket 6.0.0-beta2 or 6.0.0-RC1 ?

[tetsuo]

-1 RCx should only be used if you are pretty sure it could be released,
since it means *Release* Candidate.



On Fri, May 4, 2012 at 9:53 AM, Martijn Dashorst martijn.dasho...@gmail.com
 wrote:

 I would opt for a beta2. IMO we should not make release candidates
 available for wider use, but really use release candidates as a way to
 push a release to its conclusion. I.E. each drop of a beta2 is a rc.

 Martijn

 On Thu, May 3, 2012 at 11:43 AM, Martijn Dashorst
 martijn.dasho...@gmail.com wrote:
  On Thu, May 3, 2012 at 10:44 AM, Emond Papegaaij
  emond.papega...@topicus.nl wrote:
  I agree, it should be RC1, but first I want to merge my
  sandbox/atmosphere branch back in master and I think we should add
  wicket-cdi as experimental module as well, just as it is now.
 
  +1
 
  Martijn



 --
 Become a Wicket expert, learn from the best: http://wicketinaction.com

Re: Move to servlet-api 3.0 for Wicket 6

[tetsuo]

The new annotations don't add much for framework developers, they just
replace the web.xml file, in a hard-to-maintain fashion.

Asynchronous servlets, in the other hand, are a nice addition to the
platform, but unless the atmosphere module absolutely requires special
support from wicket-core, and cannot be implemented by hooks, I think
it's better to keep core 2.5-compatible, and make the atmosphere
module dependent on 3.0.

At work, we have just upgraded some services to Tomcat 7, and we still
have many JBoss 4.2.3 servers around. I think that is the case for
many, many shops out there. If there's no real need to require servlet
3.0, I don't think it would be a good idea to do it.


On Fri, Apr 13, 2012 at 9:32 AM, Emond Papegaaij
emond.papega...@topicus.nl wrote:
 Hi all,

 It was already mentioned by Martijn some time ago as a suggestion for the
 roadmap for Wicket 6, but it was never decided. The question is: should we
 move to servlet-api 3.0 or stay at 2.5. Servlet 3.0 has been around for over 2
 years now and is supported by most (all?) servlet containers. It allows us to
 use things like the new annotations and asynchronous servlets.

 I'm +1 for moving to servlet 3.0 and already have some work done on the
 sandbox/atmosphere branch to get it working.

 Best regards,
 Emond

Re: Move to servlet-api 3.0 for Wicket 6

[tetsuo]

 Using 3.0 in a module might prove to be quite difficult. The main problem is
 that they changed the artifactId from servlet-api to javax.servlet-api. This
 makes it impossible to simple set a dependency management, you need to exclude
 the dependencies on servlet 2.5.

I think you need to do this only if you will actually develop the
atmosphere module, or will try to access some Servlet 3.0 new methods
directly in the application. Not sure, though.

 But even if you manage to do this in maven,
 Eclipse still screws up your classpath and you will end up with duplicate
 classes.

Not if you exclude servlet-api from jetty's dependencies.

 Personally I dont see why a framework released in 2012 still needs to support
 servlet containers versions of over 5 years old. If you are able to upgrade
 Wicket, you should also be able to upgrade other parts of your deployment.
 IMHO Wicket should move forward with the rest of the world.

Because supporting them costs virtually nothing?

Because many of the framework users are still using 5 years old
servlet containers?

The infrastructure guys will happily deploy a new application with new
jars (they probably don't even know what a jar file is), but won't
take the hassle of upgrading all installed servers (and buying new
licenses, and making new support contracts, and re-training all IT
department) just because I want to use a new version of a third-party
library.

And well, the very first server with Java EE 6 support was Glassfish
v3, in 2010. Tomcat and JBoss added that support only about a year
ago. So, even if you are using a 1 year old server version, chances
are you are still limited to Servlet 2.5!

It's still too early to jump to the newest shiny thing.

Re: wicket 6.0 and automatic model detachment

[tetsuo]

I think it should be an optional add-on (if included in the library at
all), so that core/extensions components won't rely on it, and
application developers may use it if they want the convenience. It is
just a convenience, after all.

If it is enabled by default, it may cause really weird, hard-to-trace
bugs in applications. If so, it will be hard to upgrade from previous
versions (it's much, much worse than a method rename, because the IDE
won't warn you in any way).

And, what will I do if I don't want some IModel attribute to be
detached? I declare an array of one element, just to 'hide' it from
the detacher?

Besides, AFAIK, Wicket's use of reflection has been pretty limited,
and in very predictable forms. If at least you had to annotate these
attributes to enable it, it wouldn't be so bad, but this feels like is
magic. This is the kind of thing that makes Seam and CDI good for
demos and awful for real applications. Convenient, saves two lines of
code, and you never know what is going on.




On Sun, Apr 8, 2012 at 12:51 PM, Igor Vaynberg igor.vaynb...@gmail.com wrote:
 like i said, this only makes sense as a core features. because
 components implemented with this enabled will not work properly in an
 application where this is enabled. this is an all-or-nothing feature.

 -igor

 On Sun, Apr 8, 2012 at 3:15 AM, Johan Compagner jcompag...@gmail.com wrote:
 i think it would be fine to have something like this, and enabled by default
 but only to have an option to turn it off


 On Sat, Apr 7, 2012 at 22:30, Igor Vaynberg igor.vaynb...@gmail.com wrote:

 -1 on adding it if its not enabled by default. its a trivial class
 thats only about 40-50 lines of real code. adding it into extensions
 and not using it will just add to code rot because i doubt many people
 will go out looking for something like this since most of them wont
 even know that its possible to do this.

 -igor

 On Fri, Apr 6, 2012 at 11:28 PM, Sven Meier s...@meiers.net wrote:
  The listener won't be set in IFrameworkSettings by default, right?
  IMHO it's better located in extensions then.
 
  Sven
 
 
  On 04/07/2012 01:37 AM, James Carman wrote:
 
  Add the listener to core and if folks want to use it they can.  You
 could
  have a component instantiation listener add the detach listener to the
  components. Another option would be an aspect.
  On Apr 6, 2012 12:43 PM, Igor Vaynbergigor.vaynb...@gmail.com
  wrote:
 
  i wrote a IDetachListener that automatically detaches any IModel
  fields found on components. is this something we would be interested
  in for core? its been running in production for a while without any
  noticeable overhead and its nice not to have to implemenet onDetach()
  all the time just to forward it to secondary models. the only downside
  is that once we introduce this feature we can never remote it because
  doing so will break code.
 
  thoughts?
 
  -igor
 
 

Re: More experimental code happening at Apache

[tetsuo]

What about one (or more) separate apache-hosted repository for
experimental projects? Maybe completely separate, maybe a clone just
to host the experimental branches. This would

- keep the main repository cleaner
- ease experimentation, since there will be no subconscious fear of
committing junk to the main rep
- make some good use of git's distributed features

Since a git clone holds the whole history of the repository, including
all branches, it makes sense to try to keep it somewhat clean.



On Mon, Apr 2, 2012 at 11:35 AM, Emond Papegaaij
emond.papega...@topicus.nl wrote:
 After a good discussion with Martijn Dashorst, we agreed that Github (or any
 other open repository) probably is a good thing, but not yet. The board needs
 to come up with a way to integrate this into the 'Apache way' of development.
 Until then, it's probably best to always push your code to the Apache server
 first, after which you can also push it to Github (it's open source after
 all). This should keep everone happy. So expect a wicket-atmosphere sandbox
 branch soon :)

 Best regards,
 Emond

 On Monday 02 April 2012 15:11:45 Emond Papegaaij wrote:
 While I do agree with you that we could put experimental code in modules in
 Wicket, I do not agree with you that all development should take place on
 Apache Git servers. We no longer live in a centralized world. With Git,
 development is a decentralized process, taking place on many locations by
 many people at the same time.

 I do understand the need for ip-clearance, but moving all development to a
 central server defeats the purpose of using Git on most points. Git allows
 open development, where everybody can contribute. Not so long ago, the board
 asked if Git changed our community dynamics. I think that's exactly what is
 happening right now. Git is changing our community for the better, and
 forcing all development back to the central servers will kill that process.

 Mainline Wicket develoment will still take place on the central Apache
 repository, because that's where our code lives. Code will have to be
 integrated into our main repository before it can become part of a release.
 If code from non-committers needs to be flaged, you can always aks the
 person to export the commits to mbox with format-patch and attach them to a
 ticket (the good-old email workflow). But IMHO the PMC should come up with
 a way to flag git commits without the need to attach them to a ticket.

 Best regards,
 Emond

 On Monday 02 April 2012 14:49:49 Martijn Dashorst wrote:
  The trend seems to be to do experimental things at wicketstuff or
  personal github accounts with the intention of bringing that back to
  Wicket at a later time. IMO this is the wrong way. The Apache Way
  should be (IMO): also do experimental stuff at Apache, within the
  purview of the PMC.
 
  When things are not mature enough for a 1.0 release, we can either
  mark it @Experimental or @Beta, or deliver the code in a side project
  with a version number of  1.0 until the code is mature enough to be
  included in Wicket proper. In the mean time, the experimental projects
  will be released with the wicket proper releases, but with a release
  version  1.0, marking them as unfinished.
 
  So for example, a Wicket Push/Comet/Atmosphere project would reside in:
 
  wicket/
 
     core/
     extensions/
     .../
     push/
 
  With a pom that specifies the version as 0.1-SNAPSHOT. When released
  it will released as 0.1, and the next version will become
  0.2-SNAPSHOT. Iterate ad nauseam, and when the code base is mature
  enough, reversion to be on par with the proper Wicket release version
  (e.g. 6.1).
 
  The benefits of this are:
   - no need to go project hopping, there is one central place where we
 
  can find Wicket code, proper and experimental
 
   - better visibility of the project within Wicket and the wicket community
   - easier to attract new core developers to Wicket
   - no need for software grants and 'white washing' of code through the
 
  http://incubator.apache.org/ip-clearance/index.html
 
   - clearly defined trajectory for code bases developed by Wicket
 
  committers to go into core
 
   - no need to explain to the board why we have zero commits at
 
  apache's git and everything happening outside the purview of the PMC
  at external servers
 
  Martijn

Re: More experimental code happening at Apache

[tetsuo]

Apache has policies that try to keep legal issues (IP ownership,
copyright, licensing, patents) in check. I don't know the specifics,
but I think any 'big' chunk of contributed code must be checked before
accepted. But, if the incremental development is all done on Apache
infrastructure, by official committers, it's probably considered safe.

The Apache Foundation doesn't exist just to give a big name to random
projects. It exists exactly to handle those legal issues, and shield
users from them.

The process does cause some inconveniences to developers, but it also
protects them from themselves. It is very easy for an individual
developer to accept into his github repo contributed code that is
tainted with patents and copyright. It probably doesn't cause problems
most of the time, because github projects are almost always
non-relevant (it's not worth it to sue a project with a single user),
but don't you think Apache httpd or tomcat could be potential targets
to patent trolls if they didn't have the proper safeguards in place?

The Apache Software Foundation provides organizational, legal, and
financial support for a broad range of open source software projects.
The Foundation provides an established framework for intellectual
property and financial contributions that simultaneously limits
contributors potential legal exposure. --
http://apache.org/foundation/

The iBatis project folks didn't adapt to the process, so they moved
away (the iBatis brand, however, was kept with the Foundation, so they
renamed it to MyBatis). In my opinion, they lost most of their
relevance with this move, and I sincerely don't want Wicket to go the
same route.

So, guys, please don't get too upset with the old geezers from the
board :) They have pretty good reasons to require most of these little
inconveniences. And I'm sure there is some way to use the modern tools
we have at our disposal effectively, in a manner compatible to the
process.





On Mon, Apr 2, 2012 at 3:49 PM, Burton, Tom F (DOR)
tom.bur...@alaska.gov wrote:
 I know I'm not an Apache committer or even a regular on these
 discussions.  But it seems to me this whole conversation is a little
 weird.  It seems your trying to make culture into policy, or more
 directly policy that is potentially counter to the current development
 culture.  If the community is developing experimental code elsewhere and
 then contributing it back, shouldn't that be a Good Thing (tm) and
 encouraged, it seems to me that restricting to Apache Servers would
 stifle creativity  hamper development, which are both anathema to Open
 Source in general. Instead of forcing a private experimental server,
 why not just come up with a procedure to easily incorporate finished
 modules into Wicket.

 Also Maybe I'm missing the point, but what's Wrong with starting code in
 github and/or WicketStuff? Isn't that part of the point of their
 existence?  Is it a loss of history issue once the code is imported
 into Wicket Proper?

 Trying to better understand the discussion,
 Tom Burton

 -Original Message-
 From: Emond Papegaaij [mailto:emond.papega...@topicus.nl]
 Sent: Monday, April 02, 2012 10:25 AM
 To: dev@wicket.apache.org
 Subject: Re: More experimental code happening at Apache

 Martijn and I want to release experimental things in different modules.
 For that, they need to be stable enough to release, and it needs to be
 certain that they will be continue to be supported for some time to
 come, but the code does not need to be finished. For example, the code
 I'm currently working on integrating Atmosphere with Wicket will meet
 these conditions.

 I do understand Martijn's concerns regarding IP-clearance, but I do
 think the current vission of some members of the board is a little short
 minded. I read (most of) a discussion about what should be done when an
 Apache developer develops code at Github and wants to move it to Apache.
 Although they did not seem to agree entirely, the concenses was that
 'large' pieces of code needed to be cleared before moving it to Apache.
 IMHO, this severely limits the freedom of Apache developers. This also
 means, your wicket-cdi project will need to be cleared before moving it
 to the main Wicket repo, even though you and I are the only persons that
 have committed on the project.

 Best regards,
 Emond

 On Monday 02 April 2012 10:03:04 Igor Vaynberg wrote:
 from a couple of replies to this thread i am a little confused. are we

 talking about keeping experimental things in different modules on
 master or different branches?

 obviously the big problem is that not everyone has access to the
 apache git repo, so projects will still pop up on github, etc, if they

 require collaboration from non-committers.

 if, this is directed at committers, there are a couple of issues that
 need to be discussed.

 1) sometimes its not possible to release the code, ie wicket-cdi which

 lacks necessary maven dependencies in central. what do we do in those
 

Re: Wicket 6: Java 6 or Java 7?

[tetsuo]

Well, I still don't see a good reason to require anything beyond Java 5 :)



On Thu, Feb 16, 2012 at 2:12 PM, Johan Compagner jcompag...@gmail.com wrote:
 Stick for now to Java 6

 or does somebody really has good reason (api or feature that he wants to
 use) to go to Java 7?
 I think java 7 almost brought nothing, the all postponed the nice stuff to
 Java 8 (which is postponed to next year i believe)

 i do think that the eol of java 6 is quite fast, i don't think java 7 is
 used a lot at all, i think even the latest ubuntu that i installed
 yesterday does still by default get java 6?
 on the mac its also still java 6 right?

 But i guess for November this could all change,

 a bit offtopic, but i like to rant: i am currently using java 7u4 and i am
 quite annoyed by this bug;
 http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7145592
 so a git repo over https with self signed certificates is not going to work
 for EGit .

 johan


 On Thu, Feb 16, 2012 at 17:06, Martijn Dashorst
 martijn.dasho...@gmail.comwrote:

 With Oracle stopping support for Java 6 this year [1], should we
 target Java 7 instead in Wicket 6? Or leave that for Wicket 7?

 I'm for keeping Java 6 as our current platform for Wicket 6 (so we
 don't add to the confusion with numbering our releases). Wicket 7 can
 then be our Java 7 release, and Wicket 8 our Java 8 release :).
 Intermitted we can release 6.1 and such in accordance with semver and
 provide new functionality in those .y releases.

 Martijn, tossing this in front of the wolves :)

 [1] https://blogs.oracle.com/henrik/entry/updated_java_6_eol_date

Re: Opinion about the change proposed in WICKET-4326 ?

[tetsuo]

No, please not another breaking change just for the sake of it.

It's cheap to rename things that exist in your codebase and you hit
'Ctrl+Shift+R', and Eclipse does it all for you. It's not that cheap
to fix safely (which 'find|grep|wc' is not!) thousands of compiler
errors spread across hundreds of classes, when you just drop a new
version of the library and wait the IDE to scream in anger. And it's
very expensive to fix things inside third-party (or even in-house)
libraries.

I'm all in favor of enhancing the framework and cleaning its
internals, but breaking things just because it will be slightly (and
arguable) more pleasing to the eye, is not something I agree with.

I already had to fix tons of 'Javascript' to 'JavaScript' errors in my
projects, and this is something I rarely use. AjaxRequestTarget is
used extensively.



A suggestion: make AjaxRequestTarget an interface.

Sure, it won't be consistent with the 'ISomething' convention, but
this change probably won't break almost any application code besides
internal hooks someone dares to override in the WebApplication class.

My 2 cents.

Tetsuo


On Tue, Jan 10, 2012 at 7:55 AM, Martin Grigorov mgrigo...@apache.org wrote:
 On Tue, Jan 10, 2012 at 11:22 AM, Martijn Dashorst
 martijn.dasho...@gmail.com wrote:
 -1

 There is no reason other than esthetics for renaming
 AjaxRequestTarget. It is probably after Label and Link the most used
 API in our framework. This breaks all existing applications about a
 million times.

 It is not just renaming ART to ARH.
 Introducing IAjaxRequestHandler actually requires changes in all
 onAction() methods (onClick, onUpdate, ...). This is the bigger
 change. Simple change, but I understand what you mean.


 This is similar to renaming Form to something else, or Label to
 TextRenderingComponent. We can't just go about and willy nilly rename
 stuff because it is somewhat better. This works for minor APIs or
 relatively new APIs. But AjaxRequestTarget is as widely used as Label.

 For example our major 3 applications contain the following component counts:

 find . -name *.java -type f -exec grep AjaxRequestTarget {} \; | grep -v 
 import | wc -l
    2671
 find . -name *.java -type f -exec grep  Label {} \; | grep -v import 
 | wc -l
    6333
 find . -name *.java -type f -exec grep  Form {} \; | grep -v import | 
 wc -l
    3264

 That is: 2671 times a use of AjaxRequestTarget. Every and each use
 must be renamed, but even if the change is just making
 AjaxRequestTarget an interface with existing API still available, this
 warrants 2671 times a check to see if nothing breaks.

 Any advanced editor can replace any occurrence of AjaxRequestTarget
 with IAjaxRequestHandler for a few seconds in a directory recursively.
 Running the tests after that is a normal flow of the development process.


 Please suggest something that doesn't break the living hell out of our
 users' code base.

 Then I suggest to remove the 'final's from the method signatures in
 AjaxRequestTarget.
 If this is not acceptable then I'll close the ticket as Won't fix.


 Martijn


 On Mon, Jan 9, 2012 at 3:14 PM, Martin Grigorov mgrigo...@apache.org wrote:
 Hi,

 In https://issues.apache.org/jira/browse/WICKET-4326 I suggest to
 introduce IAjaxRequestHander which is an interface for
 AjaxRequestTarget.
 It gives the possibility to be able to provide customized ART or
 completely new one. This way it is much easier to use a mock for
 testing too.

 Until now we had
 org.apache.wicket.protocol.http.WebApplication#setAjaxRequestTargetProvider()
 but it was useless because ART is mostly final (i.e. many methods in
 it are final).

 The bad thing is that all onXyz() methods (like onEvent, onClick,
 onUpdate, ...) need to change their signature to receive
 IAjaxRequestHandler instead.
 The fix is easy but depending on how much Ajax you use in your
 application it may be a cumbersome task ...

 --
 Martin Grigorov
 jWeekend
 Training, Consulting, Development
 http://jWeekend.com



 --
 Become a Wicket expert, learn from the best: http://wicketinaction.com



 --
 Martin Grigorov
 jWeekend
 Training, Consulting, Development
 http://jWeekend.com

Re: Opinion about the change proposed in WICKET-4326 ?

[tetsuo]

Oh, or just remove the 'final' from the methods! (I can suggest a
number of other cases it could also be done)

On Wed, Jan 11, 2012 at 8:32 PM, tetsuo ronald.tet...@gmail.com wrote:
 No, please not another breaking change just for the sake of it.

 It's cheap to rename things that exist in your codebase and you hit
 'Ctrl+Shift+R', and Eclipse does it all for you. It's not that cheap
 to fix safely (which 'find|grep|wc' is not!) thousands of compiler
 errors spread across hundreds of classes, when you just drop a new
 version of the library and wait the IDE to scream in anger. And it's
 very expensive to fix things inside third-party (or even in-house)
 libraries.

 I'm all in favor of enhancing the framework and cleaning its
 internals, but breaking things just because it will be slightly (and
 arguable) more pleasing to the eye, is not something I agree with.

 I already had to fix tons of 'Javascript' to 'JavaScript' errors in my
 projects, and this is something I rarely use. AjaxRequestTarget is
 used extensively.



 A suggestion: make AjaxRequestTarget an interface.

 Sure, it won't be consistent with the 'ISomething' convention, but
 this change probably won't break almost any application code besides
 internal hooks someone dares to override in the WebApplication class.

 My 2 cents.

 Tetsuo


 On Tue, Jan 10, 2012 at 7:55 AM, Martin Grigorov mgrigo...@apache.org wrote:
 On Tue, Jan 10, 2012 at 11:22 AM, Martijn Dashorst
 martijn.dasho...@gmail.com wrote:
 -1

 There is no reason other than esthetics for renaming
 AjaxRequestTarget. It is probably after Label and Link the most used
 API in our framework. This breaks all existing applications about a
 million times.

 It is not just renaming ART to ARH.
 Introducing IAjaxRequestHandler actually requires changes in all
 onAction() methods (onClick, onUpdate, ...). This is the bigger
 change. Simple change, but I understand what you mean.


 This is similar to renaming Form to something else, or Label to
 TextRenderingComponent. We can't just go about and willy nilly rename
 stuff because it is somewhat better. This works for minor APIs or
 relatively new APIs. But AjaxRequestTarget is as widely used as Label.

 For example our major 3 applications contain the following component counts:

 find . -name *.java -type f -exec grep AjaxRequestTarget {} \; | grep -v 
 import | wc -l
    2671
 find . -name *.java -type f -exec grep  Label {} \; | grep -v import 
 | wc -l
    6333
 find . -name *.java -type f -exec grep  Form {} \; | grep -v import 
 | wc -l
    3264

 That is: 2671 times a use of AjaxRequestTarget. Every and each use
 must be renamed, but even if the change is just making
 AjaxRequestTarget an interface with existing API still available, this
 warrants 2671 times a check to see if nothing breaks.

 Any advanced editor can replace any occurrence of AjaxRequestTarget
 with IAjaxRequestHandler for a few seconds in a directory recursively.
 Running the tests after that is a normal flow of the development process.


 Please suggest something that doesn't break the living hell out of our
 users' code base.

 Then I suggest to remove the 'final's from the method signatures in
 AjaxRequestTarget.
 If this is not acceptable then I'll close the ticket as Won't fix.


 Martijn


 On Mon, Jan 9, 2012 at 3:14 PM, Martin Grigorov mgrigo...@apache.org 
 wrote:
 Hi,

 In https://issues.apache.org/jira/browse/WICKET-4326 I suggest to
 introduce IAjaxRequestHander which is an interface for
 AjaxRequestTarget.
 It gives the possibility to be able to provide customized ART or
 completely new one. This way it is much easier to use a mock for
 testing too.

 Until now we had
 org.apache.wicket.protocol.http.WebApplication#setAjaxRequestTargetProvider()
 but it was useless because ART is mostly final (i.e. many methods in
 it are final).

 The bad thing is that all onXyz() methods (like onEvent, onClick,
 onUpdate, ...) need to change their signature to receive
 IAjaxRequestHandler instead.
 The fix is easy but depending on how much Ajax you use in your
 application it may be a cumbersome task ...

 --
 Martin Grigorov
 jWeekend
 Training, Consulting, Development
 http://jWeekend.com



 --
 Become a Wicket expert, learn from the best: http://wicketinaction.com



 --
 Martin Grigorov
 jWeekend
 Training, Consulting, Development
 http://jWeekend.com

Re: JSON Ajax responses ?

[tetsuo]

It works well as it is, and reimplementing it could introduce new,
unknown bugs. But if it becomes much cleaner, it may well worth the
risk.

Another issues:
- will this change introduce a new depency on a third-party JSON
library, like jackson or json-lib, or will Wicket roll its own JSON
parser/generator?
- will JSON be more or less readable than XML in the AJAX debug panel?
As it is now, the html and javascript sections are escaped only with
![CDATA[]], leaving the contents intact. As I understand, the JSON
output would be full of backslash escapes for quotes, making it quite
unreadable (unless enhance the panel to display it properly, of
course).

Tetsuo



On Tue, Jan 10, 2012 at 1:47 PM, Bertrand Guay-Paquet
ber...@step.polymtl.ca wrote:

 I don't fully understand the blog post about the security problems. From
 what
 I can see, you need to be able to render a mallicious script tag to be
 able to
 intercept the JSON data. But if you are able to do that, there are much
 bigger
 problems.

 Indeed. If a malicious script can be injected, the DOM can be completely
 controlled and intercepted no matter what kind of encoding is used for the
 ajax response. However, the technique described in the blog means that raw
 components of a JSON response which are not added to the DOM can be
 intercepted by a malicious script by overloading array methods.

 I am unconvinced that using xml responses solves this problem though. Can't
 the javascript functions processing an xml response be overloaded just as
 well to capture it?

Re: JSON Ajax responses ?

[tetsuo]

I don't think JSON would bring any benefit, and it could cause a
number of security issues.

http://directwebremoting.org/blog/joe/2007/03/05/json_is_not_as_safe_as_people_think_it_is.html




On Mon, Jan 9, 2012 at 12:22 PM, Martin Grigorov mgrigo...@apache.org wrote:
 Hi,

 Are we interested in reworking AjaxRequestTarget to produce JSON
 response instead of XML ?
 Do you see any advantages in this except a bit shorter response ?

 Currently wicket-ajax.js uses DOMParser to create the XML document in
 1.5 and jQuery creates the document for us in 6.0.
 I'm not sure whether there is any performance benefit in JSON parsing
 at the client side...

 --
 Martin Grigorov
 jWeekend
 Training, Consulting, Development
 http://jWeekend.com

Re: Nested Forms in 1.4.x - order of calling onSubmit

[tetsuo]

This (nested first) is the behavior for 1.5.

In 1.4, you could override the 'Form.delegateSubmit()' method,
rewriting its logic to execute forms in reverse order, **IF**
'Form.onSubmit()' wasn't protected (thus, you can't call it on nested
forms from your form subclass).

You can, however, use reflection to cheat :)


@SuppressWarnings(rawtypes)
public class HomePage extends WebPage {

public HomePage(final PageParameters parameters) {
class SelfLoggingForm extends Form {
public SelfLoggingForm(String id) {
super(id);
add(new Button(s));
}
@Override
protected void onSubmit() {
System.out.println(this.getId());
}
@Override
protected void delegateSubmit(IFormSubmittingComponent
submittingComponent)
{
// when the given submitting component is not null, it
means that it was the
// submitting component
Form? formToProcess = this;
if (submittingComponent != null)
{
// use the form which the submittingComponent has
submitted for further processing
formToProcess = submittingComponent.getForm();
submittingComponent.onSubmit();
}

// this list will hold the forms for execution in reverse order
final ListForm? forms = new ArrayListForm?();

// Model was successfully updated with valid data
forms.add(formToProcess);

// call onSubmit on nested forms
formToProcess.visitChildren(Form.class, new IVisitorForm?()
{
public Object component(Form? component)
{
Form? form = component;
if (form.isEnabledInHierarchy() 
form.isVisibleInHierarchy())
{
forms.add(form);
return IVisitor.CONTINUE_TRAVERSAL;
}
return IVisitor.CONTINUE_TRAVERSAL_BUT_DONT_GO_DEEPER;
}
});

Collections.reverse(forms);
for (Form? form : forms) {
invokeOnSubmit(form);
}
}

private void invokeOnSubmit(Form? form) {
try {
final Method onSubmitMethod =
Form.class.getDeclaredMethod(onSubmit, new Class[0]);
onSubmitMethod.setAccessible(true);
onSubmitMethod.invoke(form);
} catch (Exception ex) {
throw new IllegalStateException(ex.getMessage(), ex);
}
}
}

add(new SelfLoggingForm(a)
.add(new SelfLoggingForm(b)
.add(new SelfLoggingForm(c;
}
}

html 
xmlns:wicket=http://wicket.apache.org/dtds.data/wicket-xhtml1.4-strict.dtd;
body
  form wicket:id=a
form wicket:id=b
  form wicket:id=c
button type=submit wicket:id=sC/button
  /form
  button type=submit wicket:id=sB/button
/form
button type=submit wicket:id=sA/button
  /form
/body
/html


On Wed, Oct 19, 2011 at 6:30 PM, Bruno Borges bruno.bor...@gmail.com wrote:
 I wrote this message to the Users list but I now I think it would be better
 to ask the devs

 ...

 After playing with Nested Forms in WIcket 1.4.18, I found out that the
 onSubmit method of these forms is called at the end of the process.

 If a parent form has a button and this button is submited, its onSubmit
 method is called before anything.
 Then, parent form's onSubmit method is called.
 Then, it will navigate through all nested forms calling their onSubmit
 method.
 The problem is that I have a nested forms that changes a value in the model
 that is associated with the parent form.

 My usecase has an AddressPanel with a form inside that manipulates the
 person.address object. This panel is created by informing two
 IModelAddress objects.
 One is to be used as the Person's address. The other one is to be used as
 copy of, because of a CheckBox that states Use the same address as of
 account holder.

 On its onSubmit method, is where I clone the account holder address to the
 actual person.address.

 But because of the order of how Wicket calls onSubmit methods, this
 implementation fails.

 Any suggestion?

 Should Wicket call all nested forms' onSubmit methods before calling the
 Button's onSubmit (or the parent form onSubmit) ?

 Thanks,

 *Bruno Borges*
 (21) 7672-7099
 *www.brunoborges.com*

Re: Ajax in Wicket.next

[tetsuo]

 tetsu, ever tried to:

It's tetsu*o*.


 - get an AjaxRequestTarget in a component that was not designed by ajax in
 mind?


Yes, and it works pretty well. I can't really remember a single case that I
couldn't do what I wanted to do. Sometimes I had to do it in a different way
than I tried to do first, but it always ends up working.

- tried to ajaxify a table-row in a dataTable component?

I don't know, probably. I do remember trying to ajax-refreshing treetable (a
third-party, not the built-in one) rows, and it did work. I think I had to
do something like target.add(getParent().getParent()). Not the most
beautiful thing in the world, but it worked.

- tried ajax with repeaters?

Yes, the way it is supposed to be done, refreshing its parent container, or
the items individually.

- tried to interact with a modal window from inside in case you have a pure
 non-ajax page within it?

With iframes? I think it works ok, unless you are trying to do it
cross-domain, which isn't allowed by the browser, not by Wicket.


 of even

 - got tired with the verbose .setOut... .setMark... true?

No, because I use a ComponentInstantiationListener to call
.setOutputMarkupId(true) in all components.

- wondered why my ajaxified component got more lines of code then the rest
 of the page?

Maybe because your ajaxified components are much more complex than mine?
Maybe because you don't know what you are doing? My ajaxified pages are
usually very, very similar to the non-ajaxified ones.



Wicket's ajax support is the best I've ever seen in any framework. It's
simple, it's direct, it's intuitive, it's easy to use. Maybe the internals
are fragile or messy, then it needs some refactoring. Maybe some things
aren't possible (that is what I asked, because I haven't hit any of those
cases), but it has always worked brilliantly for me.

But it's definitely not broken.





 Am 19.09.11 19:20, schrieb tetsuo:

  What is so broken about the current ajax in Wicket, that requires such
 rewrite?

Re: Ajax in Wicket.next

[tetsuo]

What is so broken about the current ajax in Wicket, that requires such
rewrite?



On Mon, Sep 19, 2011 at 1:11 PM, Igor Vaynberg igor.vaynb...@gmail.comwrote:

 staged approach is fine, however its step 2 only that will cause
 migration headaches, so this is just delaying the inevitable...

 -igor


 On Mon, Sep 19, 2011 at 8:29 AM, Martin Grigorov mgrigo...@apache.org
 wrote:
  Hi,
 
  In the recent ticket changes by Igor I mentioned few comments that
  Ajax will be re-written for Wicket.next (1.6, 3.0, 6.0 - whatever we
  call it).
 
  I want to share my experience with trying to re-vive Matej's work at [1],
 [2].
  The changes there are a bit drastic (maybe because the task hasn't
  been finished and the API breaks not cleaned) and knowing how Ajax
  heavy are the applications I've worked on I think it will be quite a
  work to migrate the apps from 1.5 to Wicket.next.
  I also tried to introduce wicket-ajax.jar with the new impl and keep
  the old one for transition but that wasn't easy too.
 
  So I want to propose a two step approach:
  1) introduce some JavaScript library for Wicket.next and improve
  wicket-xyz.js files by using it
  2) improve/reimplement Wicket Ajax for Wicket.next+1
 
 
  martin-g
 
  1.
 http://svn.apache.org/viewvc/wicket/sandbox/knopp/experimental/wicket/src/main/java/org/apache/_wicket/ajax/
  2. https://github.com/martin-g/wicket/tree/ajax2
 

Re: Ajax in Wicket.next

[tetsuo]

Ok. I'd add some kind of 'server-side-push/comet/websocket' support to the
wishlist :)

It certainly will break the javascript side, but do you guys think these
improvements could be implemented without breaking (too much) the Java API?



On Mon, Sep 19, 2011 at 2:49 PM, Igor Vaynberg igor.vaynb...@gmail.comwrote:

 here is my take on the areas that need improvement:

 * there is a potential to significantly reduce the size of our
 wicket-ajax.js by rebuilding it on top of a js library like jquery
 which provides all the basics such as an ajax pipeline and
 replaceOuterHtml() function.
 * currently we use inline attributes, eg adding a behavior to a
 component adds javascript in an onclick attribute. we need to switch
 to using dom events for this. this will solve the long outstanding
 problem of cant add multiple behaviors to the same event
 * server-side customization of callbacks is very difficult. eg it is
 not easy to add a callback variable that clientside js would pass to
 the serverside callback. this essentially requires a
 sql-injection-like attack on the callback url generated by wicket - so
 its a big hack.
 * ajax generates *a lot* of javascript in the source, making the
 document bigger. we can reduce that significantly.
 * better support for ajax channels and blocking behavior. eg right now
 its pretty hard to write an ajax button/link that blocks multiple hits
 or perhaps blocks all other ajax activity on the page.

 -igor


 On Mon, Sep 19, 2011 at 10:20 AM, tetsuo ronald.tet...@gmail.com wrote:
  What is so broken about the current ajax in Wicket, that requires such
  rewrite?
 
 
 
  On Mon, Sep 19, 2011 at 1:11 PM, Igor Vaynberg igor.vaynb...@gmail.com
 wrote:
 
  staged approach is fine, however its step 2 only that will cause
  migration headaches, so this is just delaying the inevitable...
 
  -igor
 
 
  On Mon, Sep 19, 2011 at 8:29 AM, Martin Grigorov mgrigo...@apache.org
  wrote:
   Hi,
  
   In the recent ticket changes by Igor I mentioned few comments that
   Ajax will be re-written for Wicket.next (1.6, 3.0, 6.0 - whatever we
   call it).
  
   I want to share my experience with trying to re-vive Matej's work at
 [1],
  [2].
   The changes there are a bit drastic (maybe because the task hasn't
   been finished and the API breaks not cleaned) and knowing how Ajax
   heavy are the applications I've worked on I think it will be quite a
   work to migrate the apps from 1.5 to Wicket.next.
   I also tried to introduce wicket-ajax.jar with the new impl and keep
   the old one for transition but that wasn't easy too.
  
   So I want to propose a two step approach:
   1) introduce some JavaScript library for Wicket.next and improve
   wicket-xyz.js files by using it
   2) improve/reimplement Wicket Ajax for Wicket.next+1
  
  
   martin-g
  
   1.
 
 http://svn.apache.org/viewvc/wicket/sandbox/knopp/experimental/wicket/src/main/java/org/apache/_wicket/ajax/
   2. https://github.com/martin-g/wicket/tree/ajax2
  
 
 

Re: Make AjaxRequestTarget extendable/mockable

[tetsuo]

 In short term removing final from method signatures would allow to
 mock it for tests and return customized impl from

org.apache.wicket.protocol.http.WebApplication.getAjaxRequestTargetProvider().

setAjaxRequestTargetProvider()?

Re: Adding a new method in abstract class should go in Wicket.next ?

[tetsuo]

write(byte[],int,int) has a concrete implementation even in OutputStream. I
don't think it would be necessary to make it abstract, even in Wicket.next.
Well, the ideal would be to make this method abstract, and write(byte[])
concrete, since it would avoid the arraycopy overhead, but I think it would
be a marginal gain, compared to breaking backwards compatibility.



On Wednesday, September 14, 2011, Martin Grigorov mgrigo...@apache.org
wrote:
 Emond suggested in IRC to add default impl in Response like:

 public void write(byte[] array, int offset, int length) {
  byte[] towrite = new byte[length];
  System.arraycopy(array, offset, towrite, 0, length);
  write(towrite);
 }

 so it will work for 1.5.1.
 For Wicket.next we can make it abstract as all other methods in this
class.

 I like the approach.

 On Wed, Sep 14, 2011 at 1:11 PM, Andrea Del Bene adelb...@ciseonweb.it
wrote:
 Yes, I'm afraid we should wait for a major release to add it.

 Hi,

 I just filed https://issues.apache.org/jira/browse/WICKET-4052: Add
 org.apache.wicket.request.Response.write(byte[], int, int) to make it
 easier to write buffered data to the web response.

 I guess this have to wait for Wicket.next because it is API break ?
 In the patch I added this new method for all implementations of
 o.a.w.request.Response which we deliver but since there could be users
 providing their own impls it is not OK to add it in 1.5.x?

 Please confirm.






 --
 Martin Grigorov
 jWeekend
 Training, Consulting, Development
 http://jWeekend.com

Re: Roadmap for Wicket 6

[tetsuo]

- I echo the .setOutput*() thing. There should be some global setting for
these.

- some preparation for Java 8/closures support (Single-Method Interfaces)

- more/refined debug tools

- revive portlet support



On Wed, Aug 31, 2011 at 9:26 AM, Korbinian Bachl - privat 
korbinian.ba...@whiskyworld.de wrote:

 My wish list:

 1. Java 6

 2. JEE6 where possible like e.g. CDI;

 3. Modularization using OSGI

 4. AJAX overhaul: currently Ajax is a pain in case it gets more complicated
 as one
 - needs to add components to target AND page hierarchy;
 - needs to do .setOutputId(true) all over
 - can't touch invisible containers in e.g.: DataTable

 5. look at side-efforts done by matej, igor and co to bring the nice things
 to wicket and enhance/ or replace the affected counterparts of wicket (e.g.:
 DataTable vs. InMethod Grid; bindgen-wicket etc.)

 6. Not 100% sure: let the HTML templates feed via a single place so one can
 switch to e.g. a JCR implementation - however, I dont know how this could
 work in conjunction with added jars etc. to path. Idea is to allow the
 templates to live outside the java part (e.g.: CMS);

 7. @RequireHTTPS logic overhaul (currently: either must use SSL or mustn't
 use SSL, no may use SSL);



 Am 30.08.11 00:12, schrieb Martijn Dashorst:

  In order to start discussing what will constitute Wicket Next and
 where we want to take our beloved framework, I'll start off with my
 wish list:

 1. Java 6 as a minimum requirement for *all* of wicket
 2. Servlet API 3.0 as a minimum requirement
 3. JavaEE 6 support for at least CDI
 4. Proper OSGi support
 5. Ajax refactoring to use JQuery and provide proper JQuery integration in
 core
 6. Shorter release cycle

 I +1000 #1 in my wish list, since then I'll be able to build releases
 again.

 Regarding #6 I aim to release Wicket 6 final in December.

 Martijn

Re: Roadmap for Wicket 6

[tetsuo]

- Refactor things out of WicketFilter (and removing any direct dependency on
it from the core processing), so that we could tweak the request processing
cycle (more low-level things, that are not possible with
RequestCycleListeners) without having to patch its source code. The way
things are now, it is a big blob of code with lots of private/final methods,
impossible to customize.



On Wed, Aug 31, 2011 at 10:33 AM, tetsuo ronald.tet...@gmail.com wrote:

 - I echo the .setOutput*() thing. There should be some global setting for
 these.

 - some preparation for Java 8/closures support (Single-Method Interfaces)

 - more/refined debug tools

 - revive portlet support



 On Wed, Aug 31, 2011 at 9:26 AM, Korbinian Bachl - privat 
 korbinian.ba...@whiskyworld.de wrote:

 My wish list:

 1. Java 6

 2. JEE6 where possible like e.g. CDI;

 3. Modularization using OSGI

 4. AJAX overhaul: currently Ajax is a pain in case it gets more
 complicated as one
 - needs to add components to target AND page hierarchy;
 - needs to do .setOutputId(true) all over
 - can't touch invisible containers in e.g.: DataTable

 5. look at side-efforts done by matej, igor and co to bring the nice
 things to wicket and enhance/ or replace the affected counterparts of wicket
 (e.g.: DataTable vs. InMethod Grid; bindgen-wicket etc.)

 6. Not 100% sure: let the HTML templates feed via a single place so one
 can switch to e.g. a JCR implementation - however, I dont know how this
 could work in conjunction with added jars etc. to path. Idea is to allow the
 templates to live outside the java part (e.g.: CMS);

 7. @RequireHTTPS logic overhaul (currently: either must use SSL or mustn't
 use SSL, no may use SSL);



 Am 30.08.11 00:12, schrieb Martijn Dashorst:

  In order to start discussing what will constitute Wicket Next and
 where we want to take our beloved framework, I'll start off with my
 wish list:

 1. Java 6 as a minimum requirement for *all* of wicket
 2. Servlet API 3.0 as a minimum requirement
 3. JavaEE 6 support for at least CDI
 4. Proper OSGi support
 5. Ajax refactoring to use JQuery and provide proper JQuery integration
 in core
 6. Shorter release cycle

 I +1000 #1 in my wish list, since then I'll be able to build releases
 again.

 Regarding #6 I aim to release Wicket 6 final in December.

 Martijn

Re: Next wicket versioning and release schedule

[tetsuo]

non-binding

-1 to independent module versioning. I don't want to have a compatibility
matrix like Hibernate's (
http://community.jboss.org/wiki/HibernateCompatibilityMatrix).

+1 to semantic versioning (http://semver.org/)

-1 to jump to 6.0, unless it features some major architectural change like,
make Wicket mostly stateless or something like that. Even with that, I'd
prefer to go with 2.0 instead. Large numbers, for me, indicate bloat (with
the exception of Chrome, because we don't even care about the version number
anymore) and instability. If we look to some very stable projects, they are
still in their 2.x or 3.x versions, even with almost, or more than, a decade
of history (Apache HTTPD, Linux, Spring, Apache Commons). Tomcat only is at
version 7 because it increments every time the specs versions change. But
which quality Java framework has such a high version number?

Tetsuo



On Mon, Aug 29, 2011 at 8:36 PM, Brian Topping topp...@codehaus.org wrote:

 -1

 I propose that Wicket modules be released separately.  Projects that are
 small can be released as a monolithic whole.  Wicket is no longer a small
 project.  With the changes that went into 1.5 to make it easier to program,
 there should be very few changes in the core modules.

 Maven provides very robust facilities for version ranges that can make sure
 modules avoid incompatibilities.  The rules of when to update these version
 ranges is very easy to follow.  I would be very surprised if anyone was
 incapable of doing it well.  Basically, version ranges of dependencies are
 kept open until there is an API change that requires it to be closed at
 some milestone.

 At the end of the day, it doesn't matter really matter how versions are
 named, what matters is that users expectations are met.  I've already
 referenced Wikipedia entries that cover pretty commonly held expectations
 that people have, what is proposed here is not far from them.  Again,
 whatever scheme is chosen just needs to be documented and adhered to.

 Brian

 p.s. I am presuming I am one of the anal retentive folks with versioning
 OCD.  Congrats on keeping it classy!

 On Aug 29, 2011, at 6:15 PM, Martijn Dashorst wrote:

  I think I can speak for everyone here that our current release has
  taken a long time to stabilize, and finalize (and we are not even
  there yet!). Given that we are all volunteers and many of us also try
  to have a family and/or social life, it is what it is.
 
  When we hit RC status, we should be able to pull out a final release
  within weeks, not months. The issue is that none of our users will
  actually test prior to us releasing a RC. I think that 1.5 matured
  considerably during RC phase, especially since several folks dove in
  and started shipping products with it (for better and for worse). It
  is a testament to the quality of the software built mostly by Igor,
  Juergen, Matej and Martin that our systems haven't had any major issue
  with Wicket 1.5 in production use (nothing that couldn't be patched
  locally). Kudos to you guys for all the effort and countless hours you
  put in!
 
  One thing that anal retentive folks are concerned about is that
  breaking API should only be done in major X releases. I've read
  statements of folks claiming we are not enterprise ready because we
  name our major versions X.Y and even break API in X.Y.Z. While I never
  understood the folks with versioning OCD, we can and probably should
  improve our versioning strategy even though it currently works for us,
  and has worked for us in the last 7 years.
 
  So I propose that we call our next major Wicket version: Wicket 6, and
  the major version after that Wicket 7, and the next major version
  Wicket 8, etc. New features that don't break API should go into a X.Y
  release. Bug fixes that don't break API should go into a X.Y.Z
  release.
 
  I propose that we develop breaking API features on trunk until we have
  implemented our proposed and scheduled roadmap features, while
  continuing to support the previous major release. When we have
  finalized our roadmap for the next major release, we create a branch
  for it:
 
 branches/wicket-X.x (substitute capital X with the major version
 number)
 
  From that point on we can continue developing API breaking features on
  trunk for X+1, and start bug fixing on Wicket-X.x branch. This will be
  a release train that starts with Wicket-X.0.0, and continues until we
  deem Wicket-X.0.z stable for general consumption. The Wicket-X.0.z
  release will then be a GA release. This seems to be how Tomcat works
  and other frameworks as well. As long as we don't bless the release
  with GA I suggest we add a classifier beta to the release. This
  results in apache-wicket-X.Y.Z-beta.jar, and
  apache-wicket-X.Y.Z+1-beta.jar. When our GA release comes I suggest
  just dropping the beta-classifier.
 
  If needed we can create feature releases that only add new stuff
  without breaking old code in a Wicket-X.y

Re: Next wicket versioning and release schedule

[tetsuo]

The difference is that we would have had a version 2.0, 3.0, 4.0 and 5.0
before 6.0. Or, more care would be taken to not introduce unnecessary API
incompatibilities (although I can't see any way to avoid it in both 1.3~1.4
and 1.4~1.5 transitions).

Oh well, ok, I just like 2.0 better, and I'm making up arguments. :)

I think I'm more uncomfortable with the rapid release cycle proposed.

It may work well for browsers, because we just don't care about the version,
since it gets updated automatically. But I really wouldn't like to use a
library that breaks its API every year (I've always criticized Tapestry for
that).

Even products like Tomcat, that reached version 7.x (although its first
version was *3.0*, released 12 years ago), take backward compatibility very
seriously (well, also due the fact that the spec itself takes backward
compatibility to the extreme, of course).

If growing an ecosystem is important for the project, this stability is
essential, or else third-party projects won't even have time to mature
before the next (incompatible) release.





On Mon, Aug 29, 2011 at 11:09 PM, Igor Vaynberg igor.vaynb...@gmail.comwrote:

 On Mon, Aug 29, 2011 at 6:28 PM, tetsuo ronald.tet...@gmail.com wrote:
  non-binding
 
  -1 to independent module versioning. I don't want to have a compatibility
  matrix like Hibernate's (
  http://community.jboss.org/wiki/HibernateCompatibilityMatrix).
 
  +1 to semantic versioning (http://semver.org/)
 
  -1 to jump to 6.0, unless it features some major architectural change
 like,
  make Wicket mostly stateless or something like that. Even with that, I'd
  prefer to go with 2.0 instead. Large numbers, for me, indicate bloat
 (with
  the exception of Chrome, because we don't even care about the version
 number
  anymore) and instability.

 if we followed simver from the beginning the next version would be
 6.0.0, so what is the difference?

 -igor

Re: Self type

[tetsuo]

I've used this technique in some projects (internal APIs), with some degree
of success, but I don't think it fits well in this case.
Java's generics doesn't support this very well. It makes the code too
verbose, and in some inheritance cases, it just doesn't work.



One feature I would love to see in Java (although I have no hope to ever
have it) is something like this:

class A {
  public this add(Component c) {
if (c == null)
  return; // 'this' is implicit, just like 'void'
components.add(c);
// 'return this;' is implicit, just like 'void'
  }
}

class B extends A {}

A a = new A().add(comp);
B b = new B().add(comp); //since 'this' is always implicit (so, cannot be
overridden), the compiler would know that the return type is B, not A


method chaining paradise! :)



On Mon, Aug 29, 2011 at 11:11 PM, richard emberson 
richard.ember...@gmail.com wrote:

 For many months the Scala port of Wicket 1.5 has used self type
 return values (this.type) where appropriate; more than 10 methods
 in Component, more than 5 in MarkupContainer, etc. with all
 tests passing and some code simplification (or, at least, the
 removal of some casts). Ought to work in Java also.

 Richard


 On 08/29/2011 06:52 PM, Martin Makundi wrote:

 Hi!

 Is wicket using self type yet for methods like add(cc) {...; return this;
 } ?

 http://calliopesounds.**blogspot.com/2010/11/having-**
 java-generic-class-return-**type.htmlhttp://calliopesounds.blogspot.com/2010/11/having-java-generic-class-return-type.html

 **
 Martin


 --
 Quis custodiet ipsos custodes

Re: Wicket Weld into wicket 1.5?

[tetsuo]

Why does it require java 6?



On Mon, Aug 22, 2011 at 7:38 PM, Igor Vaynberg igor.vaynb...@gmail.comwrote:

 +1 for including it in rc6. we are tweaking poms anyways.

 the release of this is pending on jboss guys getting weld and seam
 artifacts into central, something im working with them on.

 -igor


 On Mon, Aug 22, 2011 at 3:11 PM, Martijn Dashorst
 martijn.dasho...@gmail.com wrote:
  Wicket Weld is a really nice to have for wicket 1.5 and would increase
  the importance of our release pretty considerably. The issue with
  wicket-weld is that it requires java 6, and it is late in the release
  game for 1.5 final.
 
  We have experience with building mixed java releases (see our 1.3
  history), though the build process was not pretty.
 
  In order to enable wicket-weld we need to do the following IMO:
   - create java5 and java6 modules in trunk, each configured with the
  correct java version
   - commit wicket-weld as a submodule for the java 6 module
   - move wicket-examples to java 6 module
   - move all other wicket modules to the java 5 module
   - fix the wicket parent pom to have a java 5 profile and a java 6
 profile
   - fix the build script to run different maven setups utilizing a java
  5 home directory and a java 6 home directory
   - fix the build script to run java 5 compilation first and then only
  java 6 for packaging (without clean) this will keep the java 5
  compiled classes and re-package them during the java 6 run
 
  This is some work, and as I said, we are late in the release game. If
  1.5 final was this week I wouldn't propose to do this, but perhaps do
  it in 1.5.1 or 1.5.2. However, since 1.5-rc6 is still not complete we
  might do this now. I'm open to suggestions on whether to include
  wicket-weld or not.
 
  Martijn
 
  --
  Become a Wicket expert, learn from the best: http://wicketinaction.com
 

Re: Wicket and Java 7

[tetsuo]

It's not a problem to keep supporting 'old' JDKs, if newer ones don't
give you any significant advantage.

When Java 8 comes out with closures, that would be a big reason to
break backwards compatibility (just like Java 5's generics). I don't
see any of this in Java 7.

Breaking compatibility just for the sake of it is not being 'bleeding
edge', it's just begging to lose users.

Tetsuo

On Tue, Jul 5, 2011 at 10:20 AM, Martin Grigorov mgrigo...@apache.org wrote:
 :-)
 The diamond notation is just about the declaration at the right side
 of equals sign. This part is automatically typed for me by my IDE.
 So I'd say it saves me some reading, not writing :-)

 On Tue, Jul 5, 2011 at 3:16 PM, Johan Compagner jcompag...@gmail.com wrote:
 the nice thing is that the diamond notation for generics is working
 out of the box when you can target 1.7 your self in your app.
 Thats can be quite a bit lot less typing of characters in wicket apps.


 On Tue, Jul 5, 2011 at 14:57, Martin Grigorov mgrigo...@apache.org wrote:
 I'm saying only that JDK7 based solutions should be in a separate
 module and pluggable.
 If my application runs on JDK7 then I can replace the default
 functionalityX (based on JDK5/6) with the improved one (based on
 JDK7).

 On Tue, Jul 5, 2011 at 2:52 PM, Andrea Del Bene adelb...@ciseonweb.it 
 wrote:
 Well, I wasn't expecting a rapid or easy adoption of JDK7, but I think that
 is useful starting to explore how to  parallelize some of the stages of
 Wicket's rendering pipeline. This could lead to a strong performance gain 
 in
 the future, with adoption of JDK7 or using a parallel programming library.

 You know that Wicket still uses JDK 1.5 (not even 1.6) because many
 users still use JDK1.5 and cannot upgrade to the newer.
 So any improvements based on JDK7 should be out of wicket-core. They
 can be plugged but the default impl should be 1.5 based.
 For example you can create ModificationWatcher based on NIO2 but it
 will in wicket-jdk7 module (or similar) or in wicketstuff project.

 For Wicket 1.6 we can move to JDK6 but this will be discussed later.
 Usage of JDK7 for frameworks is not very close.

 On Tue, Jul 5, 2011 at 2:11 PM, Bruno Borgesbruno.bor...@gmail.com
  wrote:

 Some internals of Wicket don't use collections. Take for instance
 ResourceNameIterator.

 But certainly there are some things that can be used, like the new File
 watching API.

 *Bruno Borges*
 www.brunoborges.com.br
 +55 21 76727099



 On Tue, Jul 5, 2011 at 9:04 AM, Andrea Del
 Beneadelb...@ciseonweb.itwrote:

 I know it could sound a bit premature, but hasanyone starting to think
 how
 improve Wicket with the new JDK? I think that the new concurrency and
 collections API could help to speed up  Wicket.

 Has anyone run some tests?








 --
 Martin Grigorov
 jWeekend
 Training, Consulting, Development
 http://jWeekend.com





 --
 Martin Grigorov
 jWeekend
 Training, Consulting, Development
 http://jWeekend.com

Re: Wicket and Java 7

[tetsuo]

All this parallelism thing is overrated, and in web apps in
particular, it's pretty irrelevant. Web apps already use parallelism:
requests are handled in parallel. This is the kind of thing that
server vendors must worry about, so that we don't.

The more CPUs/cores you have, the more simultaneous users you'll be
able to handle. And, if you don't have that many users, you won't need
this kind of optimization either.

Some very specific applications need parallel processing, but they
will need parallelism in the backend (parallel search, raytracing,
scientific calculations/simulations), not while generating HTML.

Besides, this kind of fork/join processing has its own overhead, both
in CPU cycles and in code complexity. Not worth it.

Tetsuo



On Tue, Jul 5, 2011 at 12:52 PM, Andrea Del Bene adelb...@ciseonweb.it wrote:
 My fault Martin, I have not explained well myself. I try to summarize what I
 wanted to say:

 -Java 7 introduces some tools to implement Fork/Join parallelism (
 http://en.wikipedia.org/wiki/Fork-join_queue )
 -Should we adopt this pattern? Is Wicket ready for implementing such a
 pattern?

 Render phase is probably the most time-expensive part of Wicket. Do you
 think it could be splitted in subtasks?
 For example it would be nice if a page could apply Fork/Join parallelism to
 render its children components.


 I'm saying only that JDK7 based solutions should be in a separate
 module and pluggable.
 If my application runs on JDK7 then I can replace the default
 functionalityX (based on JDK5/6) with the improved one (based on
 JDK7).

 On Tue, Jul 5, 2011 at 2:52 PM, Andrea Del Beneadelb...@ciseonweb.it
  wrote:

 Well, I wasn't expecting a rapid or easy adoption of JDK7, but I think
 that
 is useful starting to explore how to  parallelize some of the stages of
 Wicket's rendering pipeline. This could lead to a strong performance gain
 in
 the future, with adoption of JDK7 or using a parallel programming
 library.

 You know that Wicket still uses JDK 1.5 (not even 1.6) because many
 users still use JDK1.5 and cannot upgrade to the newer.
 So any improvements based on JDK7 should be out of wicket-core. They
 can be plugged but the default impl should be 1.5 based.
 For example you can create ModificationWatcher based on NIO2 but it
 will in wicket-jdk7 module (or similar) or in wicketstuff project.

 For Wicket 1.6 we can move to JDK6 but this will be discussed later.
 Usage of JDK7 for frameworks is not very close.

 On Tue, Jul 5, 2011 at 2:11 PM, Bruno Borgesbruno.bor...@gmail.com
  wrote:

 Some internals of Wicket don't use collections. Take for instance
 ResourceNameIterator.

 But certainly there are some things that can be used, like the new File
 watching API.

 *Bruno Borges*
 www.brunoborges.com.br
 +55 21 76727099



 On Tue, Jul 5, 2011 at 9:04 AM, Andrea Del
 Beneadelb...@ciseonweb.itwrote:

 I know it could sound a bit premature, but hasanyone starting to think
 how
 improve Wicket with the new JDK? I think that the new concurrency and
 collections API could help to speed up  Wicket.

 Has anyone run some tests?

Re: Rework AttributeModifier to deprecate AttributeAppender and SimpleAttributeModifier

[tetsuo]

I don't like the builder pattern in this case (specially with that
verbose syntax), but I kind of like the idea of method chaining for
additional (optional) configurations, with sensible defaults:

add(new AttributeModifier(class, selected)); // to overwrite the
current value

add(new AttributeModifier(class,
selected).setCreateAttribute(false)); // to not create the attribute
if it does not exists (default is true)

add(new AttributeModifier(class, selected).append( )); // to
append, separated by space

add(new AttributeModifier(class, selected).prepend( )); // to
prepend, separated by space

add(new AttributeModifier(style, width:80%).pattern(width:
*100%)); // to replace the value matched by the pattern (the current
functionality of AttributeModifier)


DSLs are useful, but they must be terse. Haiku, not sonnet.




On Wed, Jun 8, 2011 at 8:03 AM, James Carman
jcar...@carmanconsulting.com wrote:
 I like the idea of the builder pattern much better.  DSLs rock!

 Sent from tablet device.  Please excuse typos and brevity.
 On Jun 8, 2011 6:35 AM, Martin Grigorov mgrigo...@apache.org wrote:
 or builder pattern:

 AttributeModifier.attr(name).model(someModel).create().append()

 On Wed, Jun 8, 2011 at 12:27 PM, Martijn Dashorst
 martijn.dasho...@gmail.com wrote:
 Taken from the user@ list, where it might get snowed under...

 The SimpleAttributeModifier, AttributeAppender and AttributePrepender
 classes are in my opinion stop gap measures to work around issues with
 AttributeModifier's API.

 I think that we could do better API wise with three factory methods (or 6
 if
 we duplicate each method to take an IModel? and a String for
 convenience) on AttributeModifier, and deprecate SimpleAttributeModifier
 and AttributeAppender. I'd also merge the appender/prepender logic into
 attribute modifier, such that user specializations can make use of
 them.

 AttributeModifier.setAttribute(String attribute, IModel? value);
 AttributeModifier.setAttribute(String attribute, String value);
 AttributeModifier.prependAttribute(String attribute, String value);
 AttributeModifier.prependAttribute(String attribute, IModel? value);
 AttributeModifier.appendAttribute(String attribute, String value);
 AttributeModifier.appendAttribute(String attribute, IModel? value);

 Or perhaps:

 AttributeModifier.overwrite(String attribute, IModel? value);
 AttributeModifier.overwrite(String attribute, String value);
 AttributeModifier.prepend(String attribute, IModel? value);
 AttributeModifier.prepend(String attribute, String value);
 AttributeModifier.append(String attribute, IModel? value);
 AttributeModifier.append(String attribute, String value);

 I'd value input on the naming of things.

 Martijn




 --
 Martin Grigorov
 jWeekend
 Training, Consulting, Development
 http://jWeekend.com

Re: Rework AttributeModifier to deprecate AttributeAppender and SimpleAttributeModifier

[tetsuo]

I'd prefer calling the constructor instead of static methods. It makes
it clear that you are creating a new instance, and how you could
extend the class if you needed to.

Oh, and 'for' is a reserved keyword :)

Tetsuo



On Wed, Jun 8, 2011 at 9:02 AM, Martijn Dashorst
martijn.dasho...@gmail.com wrote:
 On Wed, Jun 8, 2011 at 1:02 PM, James Carman
 jcar...@carmanconsulting.com wrote:
 What about the separator?

 I'm thinking of ditching the separator as a constructor parameter, and
 defaulting to ' ' (space). Is there anyone who uses any other value
 for the separator? The attribute modifier will have a setter for the
 separator, so that you can do AttrbuteModifier.append(onclick,
 return false;).setSeparator(;);

 As for the fluent api... we can add that as a bonus. I'd like to keep
 the shorthand for  AttributeModifier.append/prepend/overwrite

 Might I suggest the following fluent api:

 AttributeModifier.for(class).overwrites().value(error);
 AttributeModifier.for(class).appends().value(Model.of(error));
 AttributeModifier.for(onclick).prepends().value(if(!confirm('Sure?'))
 return false;');

 Or perhaps:

 AttributeModifier.for(class).puts(error);
 AttributeModifier.for(class).appends(Model.of(error));
 AttributeModifier.for(onclick).prepends(if(!confirm('Sure?'))
 return false;');

 Martijn

 --
 Become a Wicket expert, learn from the best: http://wicketinaction.com

Re: HEADS UP: A change in web.xml setup is required

[tetsuo]

Well, I was trying to understand the problem before posting random thoghts :)

SegFault commented the issue with this question:

  the only problem I see is that there is no one to clean the static
 org.apache.wicket.page.PersistentPageManager.managers = maybe a stupid 
 question,
 but how does this behave in case of many context reloading (for example in 
 developpement
 mode), is this cleaned up by container ? or this will end up with a PermGen 
 space error ?

I think that, unless you hold references to webapp-specific classes in
server-loaded classes' static fields, or leave zombie threads, PermGen
shouldn't occur, and all classes should be gc'ed. Does the page
manager do anything that prevents it to be gc'ed? Does it need any
extra clean-up, besides being unloaded with the webapp classloader?



On Fri, Mar 18, 2011 at 12:42 PM, Igor Vaynberg igor.vaynb...@gmail.com wrote:
 i would say that the lack of response shows that people dont care
 about a couple more xml lines they have to add to web.xml once and
 forget about.

 -igor

 On Fri, Mar 18, 2011 at 7:47 AM, Martin Grigorov mgrigo...@apache.org wrote:
 On Thu, Mar 17, 2011 at 10:54 PM, Martin Grigorov 
 mgrigo...@apache.orgwrote:

 Hi,

 To solve https://issues.apache.org/jira/browse/WICKET-3470 we need to
 introduce ServletContextListener in Wicket.
 In comment
 https://issues.apache.org/jira/browse/WICKET-3470?focusedCommentId=13008166page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13008166I
  described a proposal how we can change web.xml configuration to make it
 working. The proposal is based on a discussion between me and Igor in IRC.

 This is a rather big change and we need more opinions, so please share if
 you have ideas.


 By big here I mean conceptually, not code wise. Technically it doesn't
 seem to be big or complex.


 --martin-g

 P.S. I'm interested to understand why there is no such problem with Wicket
 1.4?
 I guess sessions in 1.4 are cleared earlier and never persisted between web
 container restarts.

 --
 Martin Grigorov
 jWeekend
 Training, Consulting, Development
 http://jWeekend.com http://jweekend.com/




 --
 Martin Grigorov
 jWeekend
 Training, Consulting, Development
 http://jWeekend.com http://jweekend.com/

Re: HEADS UP: A change in web.xml setup is required

[tetsuo]

Why would it (Igor's proposal) be not correct?


On Fri, Mar 18, 2011 at 2:28 PM, Peter Ertl pe...@gmx.org wrote:
 in general I prefer correctness over convenience ... so if we need a context 
 listener to do everything right so should it be (remember having the same 
 kind of trouble with jetty)

 +0

 Am 18.03.2011 um 17:50 schrieb Igor Vaynberg:

 another possible solution is to serialize the page into SerializedPage
 before sticking it into session...this may introduce some overhead,
 especially for non-clustered apps. however, we can have a special
 pagemanager for non-clustered apps that does not change page instances
 into SerializedPage...kind of like HttpSessionStore works in 1.4
 compared to a store that uses DiskPageStore.

 -igor


 On Fri, Mar 18, 2011 at 9:35 AM, Martin Grigorov mgrigo...@apache.org 
 wrote:
 On Fri, Mar 18, 2011 at 5:04 PM, tetsuo ronald.tet...@gmail.com wrote:

 Well, I was trying to understand the problem before posting random thoghts
 :)

 SegFault commented the issue with this question:

  the only problem I see is that there is no one to clean the static
 org.apache.wicket.page.PersistentPageManager.managers = maybe a stupid
 question,
 but how does this behave in case of many context reloading (for example
 in developpement
 mode), is this cleaned up by container ? or this will end up with a
 PermGen space error ?

 I think that, unless you hold references to webapp-specific classes in
 server-loaded classes' static fields, or leave zombie threads, PermGen
 shouldn't occur, and all classes should be gc'ed. Does the page
 manager do anything that prevents it to be gc'ed? Does it need any
 extra clean-up, besides being unloaded with the webapp classloader?

 The problem is that the web container first destroys WicketFilter and then
 goes to serialize/persist the session.
 Wicket puts Page instances in the session, but before serialization these
 Page instances are transformed to SerializedPage which is a struct of
   int pageId;
   String sessionId;
   byte[] data;  // the page itself

 and to be able to transform them Wicket needs the configured IPageManager.
 With the destroy of WicketFilter all information is removed (null-ified)
 including the PageManager and thus the serialization fails.

 With the new ServletContextListener (SCL) we will move the application start
 and stop from the Filter to SCL and solve this problem.

 Additionally by Servlet specification the container may restart
 servlets/filters at any time without completely stopping the application,
 i.e. w/o
 calling 
 javax.servlet.ServletContextListener.contextDestroyed(ServletContextEvent).
 So the new way will improve the current behavior.



 On Fri, Mar 18, 2011 at 12:42 PM, Igor Vaynberg igor.vaynb...@gmail.com
 wrote:
 i would say that the lack of response shows that people dont care
 about a couple more xml lines they have to add to web.xml once and
 forget about.

 -igor

 On Fri, Mar 18, 2011 at 7:47 AM, Martin Grigorov mgrigo...@apache.org
 wrote:
 On Thu, Mar 17, 2011 at 10:54 PM, Martin Grigorov mgrigo...@apache.org
 wrote:

 Hi,

 To solve https://issues.apache.org/jira/browse/WICKET-3470 we need to
 introduce ServletContextListener in Wicket.
 In comment

 https://issues.apache.org/jira/browse/WICKET-3470?focusedCommentId=13008166page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13008166Idescribed
  a proposal how we can change web.xml configuration to make it
 working. The proposal is based on a discussion between me and Igor in
 IRC.

 This is a rather big change and we need more opinions, so please share
 if
 you have ideas.


 By big here I mean conceptually, not code wise. Technically it doesn't
 seem to be big or complex.


 --martin-g

 P.S. I'm interested to understand why there is no such problem with
 Wicket
 1.4?
 I guess sessions in 1.4 are cleared earlier and never persisted between
 web
 container restarts.

 --
 Martin Grigorov
 jWeekend
 Training, Consulting, Development
 http://jWeekend.com http://jweekend.com/




 --
 Martin Grigorov
 jWeekend
 Training, Consulting, Development
 http://jWeekend.com http://jweekend.com/






 --
 Martin Grigorov
 jWeekend
 Training, Consulting, Development
 http://jWeekend.com http://jweekend.com/

Re: HEADS UP: A change in web.xml setup is required

[tetsuo]

Thus the +0, not -1. Duh, sorry...


On Fri, Mar 18, 2011 at 3:01 PM, James Carman
ja...@carmanconsulting.com wrote:
 I don't think he was saying it was incorrect.  He was saying that he's
 okay with the added inconvenience if it makes everything work
 correctly.

 On Fri, Mar 18, 2011 at 1:51 PM, tetsuo ronald.tet...@gmail.com wrote:
 Why would it (Igor's proposal) be not correct?


 On Fri, Mar 18, 2011 at 2:28 PM, Peter Ertl pe...@gmx.org wrote:
 in general I prefer correctness over convenience ... so if we need a 
 context listener to do everything right so should it be (remember having 
 the same kind of trouble with jetty)

 +0

 Am 18.03.2011 um 17:50 schrieb Igor Vaynberg:

 another possible solution is to serialize the page into SerializedPage
 before sticking it into session...this may introduce some overhead,
 especially for non-clustered apps. however, we can have a special
 pagemanager for non-clustered apps that does not change page instances
 into SerializedPage...kind of like HttpSessionStore works in 1.4
 compared to a store that uses DiskPageStore.

 -igor


 On Fri, Mar 18, 2011 at 9:35 AM, Martin Grigorov mgrigo...@apache.org 
 wrote:
 On Fri, Mar 18, 2011 at 5:04 PM, tetsuo ronald.tet...@gmail.com wrote:

 Well, I was trying to understand the problem before posting random 
 thoghts
 :)

 SegFault commented the issue with this question:

  the only problem I see is that there is no one to clean the static
 org.apache.wicket.page.PersistentPageManager.managers = maybe a stupid
 question,
 but how does this behave in case of many context reloading (for example
 in developpement
 mode), is this cleaned up by container ? or this will end up with a
 PermGen space error ?

 I think that, unless you hold references to webapp-specific classes in
 server-loaded classes' static fields, or leave zombie threads, PermGen
 shouldn't occur, and all classes should be gc'ed. Does the page
 manager do anything that prevents it to be gc'ed? Does it need any
 extra clean-up, besides being unloaded with the webapp classloader?

 The problem is that the web container first destroys WicketFilter and 
 then
 goes to serialize/persist the session.
 Wicket puts Page instances in the session, but before serialization these
 Page instances are transformed to SerializedPage which is a struct of
   int pageId;
   String sessionId;
   byte[] data;  // the page itself

 and to be able to transform them Wicket needs the configured IPageManager.
 With the destroy of WicketFilter all information is removed (null-ified)
 including the PageManager and thus the serialization fails.

 With the new ServletContextListener (SCL) we will move the application 
 start
 and stop from the Filter to SCL and solve this problem.

 Additionally by Servlet specification the container may restart
 servlets/filters at any time without completely stopping the application,
 i.e. w/o
 calling 
 javax.servlet.ServletContextListener.contextDestroyed(ServletContextEvent).
 So the new way will improve the current behavior.



 On Fri, Mar 18, 2011 at 12:42 PM, Igor Vaynberg igor.vaynb...@gmail.com
 wrote:
 i would say that the lack of response shows that people dont care
 about a couple more xml lines they have to add to web.xml once and
 forget about.

 -igor

 On Fri, Mar 18, 2011 at 7:47 AM, Martin Grigorov mgrigo...@apache.org
 wrote:
 On Thu, Mar 17, 2011 at 10:54 PM, Martin Grigorov mgrigo...@apache.org
 wrote:

 Hi,

 To solve https://issues.apache.org/jira/browse/WICKET-3470 we need to
 introduce ServletContextListener in Wicket.
 In comment

 https://issues.apache.org/jira/browse/WICKET-3470?focusedCommentId=13008166page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13008166Idescribed
  a proposal how we can change web.xml configuration to make it
 working. The proposal is based on a discussion between me and Igor in
 IRC.

 This is a rather big change and we need more opinions, so please share
 if
 you have ideas.


 By big here I mean conceptually, not code wise. Technically it 
 doesn't
 seem to be big or complex.


 --martin-g

 P.S. I'm interested to understand why there is no such problem with
 Wicket
 1.4?
 I guess sessions in 1.4 are cleared earlier and never persisted 
 between
 web
 container restarts.

 --
 Martin Grigorov
 jWeekend
 Training, Consulting, Development
 http://jWeekend.com http://jweekend.com/




 --
 Martin Grigorov
 jWeekend
 Training, Consulting, Development
 http://jWeekend.com http://jweekend.com/






 --
 Martin Grigorov
 jWeekend
 Training, Consulting, Development
 http://jWeekend.com http://jweekend.com/

Re: Spring Annotations supoprt for IoC on WebPages

[tetsuo]

Since Spring 3.0, scoped proxies are Serializable. So, it's perfectly
possible to use @Configurable, @Autowired, and lots of AspectJ magic,
for Pages and Components, instead of wicket-spring/@SpringBean.

Provided, of course, that all beans you inject into Components are
scope-proxied (aop:scoped-proxy/ or @Scope(value = singleton,
proxyMode = ScopedProxyMode.INTERFACES)).



On Tue, Feb 22, 2011 at 7:10 PM, Bruno Borges bruno.bor...@gmail.com wrote:
 If enough documentation is supplied, to state that usage of such annotations
 can only be used this way:

 class MyPage extends WebPage {
  @Autowired
  private transient MyService service;
 }

 Annotations like @Configured (at type level of panels, pages and components
 in general) and @Component would be ignored (or reported).

 Is this feature still inviable?

 Bruno Borges
 www.brunoborges.com.br
 +55 21 76727099

 The glory of great men should always be
 measured by the means they have used to
 acquire it.
  - Francois de La Rochefoucauld



 On Tue, Feb 22, 2011 at 6:38 PM, James Carman 
 ja...@carmanconsulting.comwrote:

 The problem with that is that it doesn't address the situation where
 the reference is passed elsewhere (like to a DataProvider).  With the
 proxy-based approach (which wicket-spring does now), it does.

 On Tue, Feb 22, 2011 at 4:34 PM, Bruno Borges bruno.bor...@gmail.com
 wrote:
  Hi everyone,
 
     A friend was playing with Wicket and Spring and suggested that the
  Spring integration could have a injector that could call the
  AutowireCapableFactory of Spring to process Spring-native annotations,
 like
  @Autowired and @Value.
 
       @Override
  public void onInstantiation(Component arg0) {
 
 contextLocator.getSpringContext().getAutowireCapableBeanFactory().autowireBean(arg0);
  }
 
  What do you guys think of this?
 
  Best regards,
 
  Bruno Borges
  www.brunoborges.com.br
  +55 21 76727099
 
  The glory of great men should always be
  measured by the means they have used to
  acquire it.
   - Francois de La Rochefoucauld
 

Re: Spring Annotations supoprt for IoC on WebPages

[tetsuo]

Yes, it is. Just use @SpringBean.


On Wed, Feb 23, 2011 at 4:25 PM, James Carman
ja...@carmanconsulting.com wrote:
 On Wed, Feb 23, 2011 at 8:56 AM, tetsuo ronald.tet...@gmail.com wrote:
 Since Spring 3.0, scoped proxies are Serializable. So, it's perfectly
 possible to use @Configurable, @Autowired, and lots of AspectJ magic,
 for Pages and Components, instead of wicket-spring/@SpringBean.

 Provided, of course, that all beans you inject into Components are
 scope-proxied (aop:scoped-proxy/ or @Scope(value = singleton,
 proxyMode = ScopedProxyMode.INTERFACES)).


 That's a pretty big gotcha, IMHO.

Re: Upgrade spring dependency to 3.0-latest prior to 1.5 final?

[tetsuo]

I think you should keep the dependency on the 2.5 version, unless new
features actually add something *to the wicket-spring module*.

But I'd welcome the change from 'spring' to 'spring-web', since it
actually lowers the library dependency.

I know you guys like to upgrade library versions (like you did with
servlet-api, even if all the tests pass with 2.3), but my preference
is to always minimize requirements on dependencies.

Tetsuo


On Wed, Feb 16, 2011 at 1:11 PM, Martijn Dashorst
martijn.dasho...@gmail.com wrote:
 Currently wicket-spring 1.5 depends on spring 2.5 (specifically
 org.springframework:spring:2.5.x:jar) which collides when folks are
 upgrading to spring 3, since spring 3 doesn't have an aggregate
 library any more.

 If we chose to upgrade to spring 3, should we depend on spring-web or
 spring-core?

 Martijn

 --
 Become a Wicket expert, learn from the best: http://wicketinaction.com

final Page.onInitialize()

[tetsuo]

Overriding onInitialize() on Pages certainly may cause some problems,
if you mix adding components there and in constructors in the same
class hierarchy, but it will work with some care. I'm using
onInitialize() to build Pages, because, in the infrastructure already
built in a project I'm working on, I have to instantiate Pages to
determine if a link to it is enabled or not. I don't use its
'construction', I don't need components. I just instantiate it to call
a method 'hasPermission()' on it.

Well, please don't tell me I shouldn't do it, it works and works well.
The only problem is that in 1.5 the method is final on Pages. Is there
any workaround? Would you consider reverting this change? Or will I
have to stay with 1.4 forever?

Tetsuo

Re: [discuss] How to resolve wicket aggregate classes / sources jar issues

[tetsuo]

What about having the aggregated jar only for the bundle (zip)
download, not to be available in maven central?




On Tue, Jan 25, 2011 at 7:17 AM, Martin Grigorov mgrigo...@apache.org wrote:
 [x] - Just forget about the aggregated wicket.jar and modify the wicket
 module a pom-only module.  This means Maven users can eternally depend on
 wicket only, and not care about how we (re-)structure our code.  Non-maven
 users will have to download all the separate jars, or use Ivy, or whatever.

 On Tue, Jan 25, 2011 at 9:27 AM, Guillaume Smet 
 guillaume.s...@gmail.comwrote:

 Hi Jeremy,

 On Tue, Jan 25, 2011 at 9:18 AM, Jeremy Thomerson
 jer...@wickettraining.com wrote:
  Then, I changed all other modules that were depending on -core to depend
 on
  plain wicket.  But, that didn't work.

 IMHO, it's a bad idea. If the goal is to have cleaner dependencies,
 you should make your modules dependant on the -core/-whatever jars,
 not the aggregated pom dependency. The latter should only be used by
 users to facilitate their migration.

 Guillaume, read the previous mails about the reason to depend on
 o.a.w:wicket:pom.

 Actually this kind of dependency is also recommended in Sonatype's Maven
 book - aggregation over inheritance.
 They have plans to make improvements in that area in Maven 3.1.

 But if you really want to do that, you need to add:
 typepom/type
 to your wicket dependency to make it work.

 Have a nice day.

 I have it working here.
 Commit is coming.


 --
 Guillaume

Re: [discuss] How to resolve wicket aggregate classes / sources jar issues

[tetsuo]

When you don't use maven.

For example, most Ant-based projects I've worked with use spring.jar,
instead of 
spring-core.jar+spring-tx.jar+spring-jdbc.jar+spring-orm.jar+spring-web.jar+spring-webmvc.jar+spring-beans.jar+spring-context.jar+spring-expression.jar+spring-aop.jar+spring-aspects.jar+spring-hibernate3.jar+aopalliance.jar

With maven this is a non-issue, since you'd simply declare
spring-hibernate3 and spring-webmvc, and everything else would come as
transitive dependencies, but to do it by hand is pretty daunting,
especially for beginners trying out the library.

Tetsuo

On Tue, Jan 25, 2011 at 9:11 AM, Max Bowsher m...@f2s.com wrote:
 On 25/01/11 10:44, tetsuo wrote:
 What about having the aggregated jar only for the bundle (zip)
 download, not to be available in maven central?

 In my experience aggregated jars tend to prove more of confusion in the
 end, than a help, with users who misunderstand and end up with multiple
 copies of a classes on their classpath.

 Are there any build/deployment scenarios where adding several jars to a
 classpath isn't just as easy as adding one?

 Max.

Re: [discuss] How to resolve wicket aggregate classes / sources jar issues

[tetsuo]

Which is kinda sad, since I still find too many Ant (and variants)
-based projects out there (which is even more sad).

Spring is becoming increasingly more difficult for beginners. Even the
old MVC tutorial (which were a very good step-by-step script) isn't
available anywhere anymore.

It doesn't really affect me, since I use maven whenever I have the
option, and already know how to do all these, but Well, the good
side is that, beginners will have to learn maven from the start (since
is the only bearable option), and hopefully Ant will become a
forgotten artifact from ancient times... :)

Tetsuo



On Tue, Jan 25, 2011 at 11:27 AM, Pedro Santos pedros...@gmail.com wrote:
 Spring distribution hasn't the spring.jar anymore:
 https://fisheye.springsource.org/browse/spring-framework/trunk/build-spring-framework/resources/readme.txt?r=2858r=2854r=2940r=3872

 On Tue, Jan 25, 2011 at 10:27 AM, tetsuo ronald.tet...@gmail.com wrote:

 When you don't use maven.

 For example, most Ant-based projects I've worked with use spring.jar,
 instead of
 spring-core.jar+spring-tx.jar+spring-jdbc.jar+spring-orm.jar+spring-web.jar+spring-webmvc.jar+spring-beans.jar+spring-context.jar+spring-expression.jar+spring-aop.jar+spring-aspects.jar+spring-hibernate3.jar+aopalliance.jar

 With maven this is a non-issue, since you'd simply declare
 spring-hibernate3 and spring-webmvc, and everything else would come as
 transitive dependencies, but to do it by hand is pretty daunting,
 especially for beginners trying out the library.

 Tetsuo

 On Tue, Jan 25, 2011 at 9:11 AM, Max Bowsher m...@f2s.com wrote:
  On 25/01/11 10:44, tetsuo wrote:
  What about having the aggregated jar only for the bundle (zip)
  download, not to be available in maven central?
 
  In my experience aggregated jars tend to prove more of confusion in the
  end, than a help, with users who misunderstand and end up with multiple
  copies of a classes on their classpath.
 
  Are there any build/deployment scenarios where adding several jars to a
  classpath isn't just as easy as adding one?
 
  Max.
 
 




 --
 Pedro Henrique Oliveira dos Santos

Re: [announce] Wicket 1.5-RC1 is released!

[tetsuo]

Er... why was servlet API dependency version upgraded to 2.5? I can't
remember the discussion. Searched for it, but only found a pre-1.4
discussion, which was settled on 2.4.



On Sat, Jan 22, 2011 at 7:02 PM, Igor Vaynberg igor.vaynb...@gmail.com wrote:
 The Wicket Team is proud to introduce the first Release Candidate in
 Wicket 1.5 series. The 1.5 series provides the following major
 improvements:
 * A more powerful and flexible request processing pipeline
 * Intercomponent event mechanism
 * Improved configuration
 * More flexible markup loading
 * Better proxy support (x-forwarded-for header)

 More detailed migration notes are available on our [Migrate to 1.5
 Wiki Page](https://cwiki.apache.org/WICKET/migration-to-wicket-15.html)

 Release Artifacts:
 * Subversion tag: 
 http://svn.apache.org/repos/asf/wicket/releases/wicket-1.5-RC1
 * Changelog: 
 https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=truepid=12310561fixfor=12315483sorter/field=issuekeysorter/order=DESC
 * To use in Maven:
 dependency
    groupIdorg.apache.wicket/groupId
    artifactIdwicket/artifactId
    version1.5-RC1/version
 /dependency
 * Download the full distribution:
 http://www.apache.org/dyn/closer.cgi/wicket/1.5-RC1 (including source)

 Cheers!

Re: [announce] Wicket 1.5-RC1 is released!

[tetsuo]

No, no... such core dependency wouldn't be changed just because an
example need it. There must be another reason.


On Sat, Jan 22, 2011 at 10:06 PM, Clint Checketts checke...@gmail.com wrote:
 I believe the wicket-examples attached jetty jar was upgraded which
 required the servlet update.

 On Saturday, January 22, 2011, tetsuo ronald.tet...@gmail.com wrote:
 Er... why was servlet API dependency version upgraded to 2.5? I can't
 remember the discussion. Searched for it, but only found a pre-1.4
 discussion, which was settled on 2.4.



 On Sat, Jan 22, 2011 at 7:02 PM, Igor Vaynberg igor.vaynb...@gmail.com 
 wrote:
 The Wicket Team is proud to introduce the first Release Candidate in
 Wicket 1.5 series. The 1.5 series provides the following major
 improvements:
 * A more powerful and flexible request processing pipeline
 * Intercomponent event mechanism
 * Improved configuration
 * More flexible markup loading
 * Better proxy support (x-forwarded-for header)

 More detailed migration notes are available on our [Migrate to 1.5
 Wiki Page](https://cwiki.apache.org/WICKET/migration-to-wicket-15.html)

 Release Artifacts:
 * Subversion tag: 
 http://svn.apache.org/repos/asf/wicket/releases/wicket-1.5-RC1
 * Changelog: 
 https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=truepid=12310561fixfor=12315483sorter/field=issuekeysorter/order=DESC
 * To use in Maven:
 dependency
    groupIdorg.apache.wicket/groupId
    artifactIdwicket/artifactId
    version1.5-RC1/version
 /dependency
 * Download the full distribution:
 http://www.apache.org/dyn/closer.cgi/wicket/1.5-RC1 (including source)

 Cheers!

Re: WICKET-3261

[tetsuo]

+1 I guess

Please say if I've understood it correctly. By this proposal:
- wicket (from the 1.4 perspective) will be split into three modules,
wicket-core, wicket-util, wicket-request;
- a 'new' wicket.jar will be created to aggregate the three (well,
just like the 'old' wicket.jar), easing migration.

That would be nice.

In maven projects, should we add 'wicket' or
'wicket-core'+'wicket-util'+'wicket-request' as dependencies? If we
use 'wicket', will it add only one jar to WEB-INF/lib, or will it just
be a 'dependency alias', and the other three jars will be added as
transitive dependencies?

Tetsuo

On Wed, Dec 22, 2010 at 9:09 AM, Juergen Donnerstag
juergen.donners...@gmail.com wrote:
 +1

 Juergen

 On Wed, Dec 22, 2010 at 11:59 AM, Martin Grigorov mgrigo...@apache.org 
 wrote:
 +1 to rename current wicket to wicket-core

 On Tue, Dec 21, 2010 at 5:58 PM, Igor Vaynberg 
 igor.vaynb...@gmail.comwrote:

 +1 to rename current wicket into wicket-core

 -igor

 On Tue, Dec 21, 2010 at 6:53 PM, Martin Grigorov mgrigo...@apache.org
 wrote:
  Hi,
 
  With https://issues.apache.org/jira/browse/WICKET-3261 I added a new
 Maven
  module to 1.5: wicket-core.
  Its purpose is to create a .jar that contains the classes from
 wicket.jar,
  wicket-util.jar and wicket-request.jar (aka uberjar, jarjar, ...).
 
  We split wicket/ to three modules : wicket/, wicket-util and
 wicket-request
  to make it more modular and easier to maintain, but now (non-Maven) users
  complain about class loading problems because they didn't add -util and
  -request in their classpath.
  The purpose of the new module is to hide the fact that we split the code
  internally and tell all users to use the new uberjar.
  We can even not publish the smaller ones in the Maven repos.
 
  The open question is: should we rename current wicket module to
 wicket-core
  and the new module to become 'wicket' ?
  Pros:
   - all user apps will continue to have dependency to
  org.apache.wicket:wicket
  Cons:
   - merging code from 1.4 to 1.5 can become a bit harder
 
  If we agree on that renaming of the modules then I need a date when other
  devs don't commit anything to do it.
 
  martin-g
 

Re: [DISCUSS 1.5] Rename IHeaderResponse to IResourceResponse (or similar)?

[tetsuo]

Unless you can think of a spectacularly better name, I think you
should just keep IHeaderResponse.

Tetsuo


On Sat, Dec 18, 2010 at 12:25 PM, Jeremy Thomerson
jer...@wickettraining.com wrote:
 On Sat, Dec 18, 2010 at 2:27 AM, Juergen Donnerstag
 juergen.donners...@gmail.com wrote:
 I understand that IHeaderResponse is no longer accurate, but
 IResourceResponse IMO would simply be wrong: it's not a response to a
 resource. It contributes to a specific section of a response such as
 Header or Footer

 Agreed.  I just haven't thought of a great name for it.
 IAmGoingToRenderYourStuffSomewhereResponse seemed a little unwieldy,
 and it was the best I had at the time.  :)

 Perhaps IResourceContributions (to replace IHeaderResponse) and
 IResourceContributor (to replace IHeaderContributor) and
 contributeResources (to replace renderHead of IHeaderContributor)?

 --
 Jeremy Thomerson
 http://wickettraining.com
 Need a CMS for Wicket?  Use Brix! http://brixcms.org

Re: Future hosting of wicket stuff

[tetsuo]

+1 Apache Extras

http://www.apache-extras.org/
https://blogs.apache.org/foundation/entry/the_apache_software_foundation_launches



On Tue, Dec 14, 2010 at 3:22 PM, Stefan Lindner lind...@visionet.de wrote:
 +1 for Apache.
 Let's keep Wicketstuff as close as possible to wicket.

 Stefan

Re: Future hosting of wicket stuff

[tetsuo]

GitHub may be a little better for developers, but I think it's quite
intimidating to users (people who just want to easily download the
binaries and read the documentation).

Google Code (thus, Apache extras) is much more friendly to non-committer-users.

But well, if one is fine with that randomly structured wicketstuff
wiki site, github shouldn't be a problem... (sigh)



On Tue, Dec 14, 2010 at 4:25 PM, Carl-Eric Menzel cmen...@wicketbuch.de wrote:
 Moving to Github

 +1 for github. It makes distributed development so much easier. As for
 staying close to Apache... apache.org is only a link away.

 Carl-Eric
 www.wicketbuch.de

Re: Future hosting of wicket stuff

[tetsuo]

I'm just saying that Google Code's interface is much cleaner and
friendlier, which helps a lot with projects' adoption (you don't get a
.

And it supports Mercurial, which is pretty much the same as git in
terms of cloning and merging changes back.


On Tue, Dec 14, 2010 at 5:17 PM, Martin Grigorov mgrigo...@apache.org wrote:
 On Tue, Dec 14, 2010 at 7:37 PM, tetsuo ronald.tet...@gmail.com wrote:

 GitHub may be a little better for developers, but I think it's quite
 intimidating to users (people who just want to easily download the
 binaries and read the documentation).

 Google Code (thus, Apache extras) is much more friendly to
 non-committer-users.

 But well, if one is fine with that randomly structured wicketstuff
 wiki site, github shouldn't be a problem... (sigh)

 It will not be randomly structured.
 There will be a main page with links to the documentation for each project.
 Just like it was/is in Confluence.




 On Tue, Dec 14, 2010 at 4:25 PM, Carl-Eric Menzel cmen...@wicketbuch.de
 wrote:
  Moving to Github
 
  +1 for github. It makes distributed development so much easier. As for
  staying close to Apache... apache.org is only a link away.
 
  Carl-Eric
  www.wicketbuch.de
 

Re: JRebel and wicket

[tetsuo]

Use DCEVM instead:

http://ssw.jku.at/dcevm/

Won't rerun constructors, though (which would be a horrible idea, BTW)

On Fri, Nov 19, 2010 at 9:25 AM, Peter Ertl pe...@gmx.org wrote:

  The most annoying thing is when you suddenly decide to anonymously
 subclass a component - then you have to restart.

 I do that all the time so this is a showstopper for me...


 Am 19.11.2010 um 12:17 schrieb Leszek Gawron:

  On 2010-11-18 14:25, Martijn Dashorst wrote:
  Relaxing the add() method has been proposed before (by Eelco). It is
  not something new, and if it helps people using jrebel to improve
  their productivity, that would be a great side effect.
 
  The workaround is indeed to go back to a different page and do the
  appropriate clicks again.
 
  It is several times faster to do that instead of booting the whole
 container and doing exacly that again.
 
  JRebel really shines when it comes to building a page from scratch. When
 I didn't have it I tried to come up with the most complete page/panel design
 i could think of at the moment. Now I start with completely empty panel and
 add child components one by one refreshing the browser as I go.
 
  Adding form components or DataTable columns feels like you are coding in
 scripting language (in the good sense).
 
 
  The most annoying thing is when you suddenly decide to anonymously
 subclass a component - then you have to restart.
 
  From my experience there is only a little margin of strange errors.
 Either the code runs as expected or it throws with huge JRebel exception
 telling you to reboot the container.
 
  --
  Leszek Gawron  http://lgawron.blogspot.com

Re: [jira] Updated: (WICKET-3147) Servlet 3 Annotation @WebFilter is not supported

[tetsuo]

Drop Java 5 support just because of one single annotation?


On Fri, Nov 5, 2010 at 3:45 PM, Jeremy Thomerson
jer...@wickettraining.comwrote:

 Since Wicket 1.5 its not yet released, should we make it dependent on Java
 1.6? I don't see that being a big problem.

 Jeremy Thomerson
 http://wickettraining.com
 -- sent from my smart phone, so please excuse spelling, formatting, or
 compiler errors

 On Nov 5, 2010 12:06 PM, Igor Vaynberg (JIRA) j...@apache.org wrote:


 [

 https://issues.apache.org/jira/browse/WICKET-3147?page=com.atlassian.jira.plugin.system.issu
 .
 ..
   Fix Version/s: (was: 1.5-M4)
  1.6.0
  Issue Type: Improvement  (was: Bug)

 since servlet 3.0 requires java 6 and wicket 1.5 requires java 5 we cannot
 properly support this yet. we are moving the relevant code into a helper
 wicket-stuff project.

 i left the necessary code commented out with todo tag JAVA6,SERVLET3.0, we
 can reinstate it when work begins on wicket 1.6


  Servlet 3 Annotation @WebFilter is not supported
  --...
   Issue Type: Improvement

  Components: wicket
  Affects Versions: 1.4.9, 1.4.10, 1.4.13
  Environment: Gl...
  Fix For: 1.6.0

 
  Attachments: wicket.tgz
 
 
  Trying to run my application this way:
  @WebFilter(value=...

Re: Making Wicket Fully Compatible with Google App Engine

[tetsuo]

I think Wicket is listed as semi-compatible because it requires some
customization (override some methods, change some configuration) to make it
work, not because its internals are inherently incompatible to GAE, or
because it has some incompatible visual components.

Such customization are simply disabling resource polling, enabling sessions
and persisting the session store in the HttpSession, and those shouldn't
change, since the defaults shoud target to the plain-old Java web
application, not GAE.

Some things could be done to improve GAE support, such as eliminating
javax.swing dependencies (from the Tree component), but I think nothing one
could do would change the classification from semi-compatible to compatible
in that listing. Unless, of course, GAE turns to be the main target for
Wicket (which I don't think is the case).

my 2c,

Tetsuo


On Mon, Sep 20, 2010 at 9:52 AM, Peter Ertl pe...@gmx.org wrote:

 Why not prefix all issue titles with something like

  [GAE] problem description

 ?

 This should be easy to filter or lookup

 Am 20.09.2010 um 14:43 schrieb Clint Checketts:

  There is a 'Will it play in app engine' page that tracks libraries that
 are
  compatible with Google App Engine (aka GAE):
 
 http://groups.google.com/group/google-appengine-java/web/will-it-play-in-app-engine?pli=1
 
  Correctly, Wicket is listed as Semi-Compatible.
 
  As a project I've been looking through the Wicket codebase locating the
  pieces that need to change to make it fully compatible. Does it make
 sense
  to have a master Jira that tracks the overall 'compatible with GAE' state
  while making individual issues for the specific changes that reference
 back
  to the master issue?
 
  Thanks,
 
  -Clint Checketts

Re: Making Wicket Fully Compatible with Google App Engine

[tetsuo]

An auto-detected GAE-specific mode in Wicket core? I don't think this is a
good idea...




On Mon, Sep 20, 2010 at 3:07 PM, Erik van Oosten e.vanoos...@grons.nlwrote:


  ...and those shouldn't change, since the defaults shoud target...
 ...I think nothing one could do would change the classification from
 semi-compatible to compatible...


 Sure you can, the defaults could change automatically by detecting that GAE
 is the container.

 Regards,
Erik.



 Op 20-09-10 15:05, tetsuo wrote:

 I think Wicket is listed as semi-compatible because it requires some
 customization (override some methods, change some configuration) to make
 it
 work, not because its internals are inherently incompatible to GAE, or
 because it has some incompatible visual components.

 Such customization are simply disabling resource polling, enabling
 sessions
 and persisting the session store in the HttpSession, and those shouldn't
 change, since the defaults shoud target to the plain-old Java web
 application, not GAE.

 Some things could be done to improve GAE support, such as eliminating
 javax.swing dependencies (from the Tree component), but I think nothing
 one
 could do would change the classification from semi-compatible to
 compatible
 in that listing. Unless, of course, GAE turns to be the main target for
 Wicket (which I don't think is the case).

 my 2c,

 Tetsuo



 --
 Sent from my SMTP compliant software
 Erik van Oosten
 http://day-to-day-stuff.blogspot.com/

Re: How to build a Wicket AJAX Portlet in Liferay's Eclipse IDE

[tetsuo]

Wow, I was just looking for instructions about using Wicket in portlets, and
couldn't find much information. I need to make this work for other portlet
containers, but this will help me a lot! There's nothing better than working
code :)

But, I couldn't find the attachment with the sources in the page, where is
it?

Thanks a lot!

Tetsuo



On Tue, Sep 7, 2010 at 9:36 PM, melom me...@intelliware.ca wrote:


 Hi everyone,

 I've posted this on the Liferay forums as well and would like to share it
 here as well:

 Our development team has put together a step-by-step document on how to
 build an AJAX capable Wicket portlet in Liferay's Eclipse IDE. Our travels
 began as most of us here have, by using the wicket examples as a starting
 ground but soon discovering a few caveats along the way. What we've
 attempted to do is put together a cohesive and hopefully complete startup
 guide using (and crediting of course) sources we've found along the way.

 Any feedback, insight, corrections, etc. is greatly appreciated. Please
 feel
 free to comment here or on our page:

 https://i-proving.ca/space/Michael+Melo/blog/2010-09-07_1

 Looking forward to your feedback,

 Michael Melo

 Developer
 Intelliware Development
 http://www.intelliware.com
 http://i-proving.ca
 --
 View this message in context:
 http://apache-wicket.1842946.n4.nabble.com/How-to-build-a-Wicket-AJAX-Portlet-in-Liferay-s-Eclipse-IDE-tp2530621p2530621.html
 Sent from the Wicket - Dev mailing list archive at Nabble.com.

Re: [vote] Revert WICKET-2846

[tetsuo]

It seems that this memory leak happens only once. I guess the first deploy
(the one which will force the creation of the background Java2D thread) will
hang around forever, but subsequent redeploys will be correctly cleaned-up.

Also, what leaks is the classloader. Only static variables and class
definitions will be kept in memory. So, you will only get an
OutOfMemoryError (and it will be a PermGen error) if your container has too
little permgen memory allocated, your application is realy huge (in class
number), or you keep very large objects in static vars, since it must break
with only two instances of the application.

That said... there's nothing like a working (err, breaking) test case to
prove a point!



On Tue, May 25, 2010 at 6:57 PM, Alex Objelean alex.objel...@gmail.comwrote:


 James, thank you very much for such a detailed description. I appreciate
 your
 effort and I'm sure this experience helped me to learn a lot of new things.
 Nevertheless, I would like to clarify few things:

  Here is a definition of memory leak: If a program holds a reference to a
 heap chunk that is not used during the rest of its life, it is considered a
 memory leak because the memory could have been freed and reused. GC won't
 reclaim it due to the reference being held by the program.
 I agree, your example proved that WicketApplication instance is used by
 InheritableThreadLocal (that is exactly what ITL does). Have you managed to
 find it even after the servlet container was stopped? Isn't it important to
 prove that the 'WicketApplication' instance outlives the servlet container
 and holds a reference to a heap chunk?
  To make it simpler to test, I have changed a little bit your quickstart,
 making the WicketApplication intance insanely big, by adding a very large
 object (50MB). My expectation was, in order to prove the memory leak, to
 see
 that the physical memory used by the JVM increases by 50MB after each
 restart, or at least steadily grow. You can check this by monitoring the
 'Local' entry and the memory details from the right pane of the VisualVM
 window.
   But the actual behavior seems to be different: performing several times
 the same flow: start the server-load the home page-stop the server
 doesn't increase the heap memory usage. The memory usage comes back to
 normal after each restart.

  I do not want to draw the conclusion, because I could have a wrong
 understanding of what a 'memory leak' is and how to prove it correctly.
 That
 is why, I'm kindly asking you (or anybody else) to interpret my findings.

 Thank you!
 Regards,
 Alex Objelean

 PS: by the way, I'm using jdk 1.6.0_13-b03 if it does make any difference

 --
 View this message in context:
 http://apache-wicket.1842946.n4.nabble.com/vote-Revert-WICKET-2846-tp2226987p2230796.html
 Sent from the Wicket - Dev mailing list archive at Nabble.com.

Re: [vote] Release Wicket 1.4.9

[tetsuo]

You could use Spring 3's @Async:
http://static.springsource.org/spring/docs/3.0.x/spring-framework-reference/html/scheduling.html#scheduling-annotation-support-async

If you can upgrade to 3.0, that is..


On Thu, May 20, 2010 at 5:17 PM, Alex Objelean alex.objel...@gmail.comwrote:


 I do not agree...
 Maybe you didn't understand completely the use-case:

 public class MyPage extends Page {
  @SpringBean
  private MyService service;
  //perform a polling of long running process triggered by a button click
  onClickButton() {
new Thread() {
  run() {
service.executeLongRunningProcess();
  }
}.start();
  }
 }

 The following example won't work well if the Application is not stored in
 InheritableThreadLocal. The reason why it doesn't work, as I understand
 that, is because @SpringBean lookup depends on Application instance which
 is
 not accessible from within the thread. Having it stored inside of ITL would
 solve the problem.


 --
 View this message in context:
 http://apache-wicket.1842946.n4.nabble.com/vote-Release-Wicket-1-4-9-tp388p2225232.html
 Sent from the Wicket - Dev mailing list archive at Nabble.com.

Re: [vote] Release Wicket 1.4.9

[tetsuo]

You can return a Future from the @Async-annotated method.

http://static.springsource.org/spring/docs/3.0.x/spring-framework-reference/html/scheduling.html#scheduling-annotation-support-async


On Thu, May 20, 2010 at 5:52 PM, Alex Objelean alex.objel...@gmail.comwrote:


 Thanks for the hint. It is good to know about it.
 But how can you get the state of the task when using Async? When creating
 the thread myself, I can get an instance of Future and poll its state
 whenever I need.

 Alex
 --
 View this message in context:
 http://apache-wicket.1842946.n4.nabble.com/vote-Release-Wicket-1-4-9-tp388p2225298.html
 Sent from the Wicket - Dev mailing list archive at Nabble.com.

Re: WICKET-2846 - Store Application in InheritableThreadLocal instead of ThreadLocal

[tetsuo]

JRebel is intended to be used in development, not in production. In
production, you want to undeploy and redeploy your application and,
hopefully, leave no old ClassLoader reference behind.

I'm not sure if InheritableThreadLocal will create memory leaks, but I know
it is something to be very carefully considered.



On Wed, May 19, 2010 at 2:35 PM, James Carman ja...@carmanconsulting.comwrote:

 On Wed, May 19, 2010 at 11:56 AM, Adriano dos Santos Fernandes
 adrian...@gmail.com wrote:
 
  I suggest to not change something in a minor release that breaks things
 that
  is working. I also suggest this shouldn't be done by default in major
  releases as well.
 
  I see no way JRebel or any tool going to remove thread locals knowing
 what
  its being done.

 JRebel won't require totally blowing away your application object.
 It'll just swap out the underlying logic behind it when you restart
 your application.

Re: WICKET-2846 - Store Application in InheritableThreadLocal instead of ThreadLocal

[tetsuo]

If I understand it correctly, the InheritedThreadLocal (ITL) wil hold the
Application reference only if its corresponding thread stays alive. If the
thread dies, the ITL value is eligible for gc, right?

Well, if your application creates a new thread, that is kept alive even
after the webapp is undeployed, the leak is the living thread, not the ITL.
This thread will probably also make some reference to application classes
(if not, why was it created in the first place?), which will cause the same
memory leak.

And, if the thread is taken from a pool managed by some lightweight
container, e.g. Spring, the ITL will not inherit the Application value,
since the 'working' thread is not a child of the request thread.

Well, maybe there is some corner case, for example, if the thread pool
implementation creates new threads on demand, and make them children of the
requesting threads and thus, inheriting the Application instance (this
should probably be considered a bug of the pool implementation). Even then,
it will only be a problem if the pool is managed by something outside the
application, because its threads must survive the web app undeployment to
cause a leak.

Well, I tried to think of some problematic case (since I was worried about
this, too), but couldn't. Do you have any case with potential to trigger the
leak?

Tetsuo


On Wed, May 19, 2010 at 1:15 PM, Adriano dos Santos Fernandes 
adrian...@gmail.com wrote:

 On 19/05/2010 13:06, Alex Objelean wrote:

 Please, correct me if I'm wrong, but the Application won't become the root
 of
 child threads. Using InheritableThreadLocal will only make Application
 available from the threads created during a request cycle. There is
 absolutely no memory related problem with it.


 As I said, some operations may spawn threads, like manipulation images, for
 example.

 If your application call it (during a request cycle), the application
 object will be stored in a system thread.

 Take a look at this:
 http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6489540

 This currently make web-classloader leaks. If you start using
 InheritableThreadLocal's with arbitrary objects, you're going to make even
 more leaks.

 Also note, there is something not good here. AFAIK, Wicket sets the thread
 locals only during the request. But if child threads are spawned, they can't
 be cleaned automatically. IMO, it should be done something that the user
 needs to call to set/clear this, like a specialized WicketThread class.


 Adriano

Re: [vote] Release Wicket 1.4.9

[tetsuo]

On Wed, May 19, 2010 at 4:20 PM, Adriano dos Santos Fernandes 
adrian...@gmail.com wrote:

 I can't, however, do it now. But I would have no reason to do it knowing
 some folks just consider a normal thing restart the container to update the
 application. So if Wicket devs are in this way, I could write no quickstart
 to convince.


Cara, agora você está sendo um grande babacão...

What they are trying to say is that there is no reason to believe that there
is an issue regarding the InheritableThreadLocal and application redeploys,
but your *unproven* doubt, thus submitting a test case would make the issue
clear.


Guice, by its use of thread locals, and considering that Java thread locals
 are not ideal, have the same type of bug. They could solve it with an API to
 close a thing, but they don't. They could ship some fancy classes that may
 work (accordingly to old @crazybob says) in some cases but they also didn't.
 So if you redeploy an app with Guice in Tomcat, it logs about a thread local
 leak.


Is Guice's issue related to child thread creation (thus related to our
issue)? Or is it just some clean-up they don't do (which is not related to
our issue at all)?



 It's going to do the same thing with Wicket.


Only if you leave request-created threads to run indefinitely. But this
would be a bug in *your *code, not in Wicket.

Re: WICKET-2846 - Store Application in InheritableThreadLocal instead of ThreadLocal

[tetsuo]

On Wed, May 19, 2010 at 4:30 PM, Adriano dos Santos Fernandes 
adrian...@gmail.com wrote:

 I do not think the application object is general enough to be passed
 implicitly to threads.


Now, this is a valid argument!

I agree wholeheartedly that Application.get() shouldn't be accessible to
child threads by default. But, it's just my opinion about how to design
applications and deal with thread issues, not some fundamental flaw.

Anyway, the InheritableThreadLocal doesn't seem to cause any memory leak
issue that wouldn't already occur due threads running amok. If the
maintainers don't see a problem with it, I think this is an non-issue.

Re: WICKET-2846 - Store Application in InheritableThreadLocal instead of ThreadLocal

[tetsuo]

onClickOrSomethingSimilar() {
   final Application app = Application.get();
   new Thread(new Runnable() {
   void run() {
   doSomethingWith(app);
   }
   }).start();
}

On Wed, May 19, 2010 at 10:29 PM, Jeremy Thomerson 
jer...@wickettraining.com wrote:

 It solves this problem, which is specifically why it was requested:

 onClickOrSomethingSimilar() {
new Thread(new Runnable() {
void run() {
doSomethingWith(Application.get());
}
}).start();
 }

 --
 Jeremy Thomerson
 http://www.wickettraining.com



 On Wed, May 19, 2010 at 6:28 PM, James Carman ja...@carmanconsulting.com
 wrote:

  Sure this might work, but then again you wouldn't need the
  InheritableThreadLocal for this.  The question is, does the
  InheritableThreadLocal really solve anything?  Is it really addressing
  the problem?  Or, would you have to do code like this to manage it
  properly anyway?  And, if so, then why implement the
  InheritableThreadLocal, especially since we've shown that it will fail
  in more cases than it will work?
 
  On Wed, May 19, 2010 at 6:28 PM, Johan Compagner jcompag...@gmail.com
  wrote:
   If you where using threads in your application
   Then i would do it this way:
  
   Your WebApplication class has a method:
   getExecutor() that returns a ThreadPoolExecutor
  
   That threadpoolexecutor (that you extend) overrides 2 methods
  
   protected void beforeExecute(Thread t, Runnable r) { }
  
   that sets the thread locals (so the application instance that has the
   executor) and
  
 protected void afterExecute(Runnable r, Throwable t) { }
  
   to release all thread locals.
  
   this way you use a pool (way better to control your web application)
 and
  all
   the resources you need are set just before and release right after.
  
   johanm
  
  
  
   On Wed, May 19, 2010 at 23:41, James Carman 
 ja...@carmanconsulting.com
  wrote:
  
   Will the inheritance of the application really work correctly?  For
  pooled
   threads that are created at application startup, the threadlocal will
 be
   null, because the parent thread is the thread that starts the
 container.
   For threads that are created within the context of the request thread,
  they
   will get the current application object, which would be fine if that
  thread
   executes and finishes.  But, for threads that are going to be reused
   (executor threads in a pool), they will see the original application
  object
   because the value is set at thread creation time.  If you have
 multiple
   wicket filters in the same context, that could be incorrect, meaning a
   request thread for a different application submitted a task to be
  executed.
  
   On May 19, 2010 4:13 PM, Adriano dos Santos Fernandes 
   adrian...@gmail.com
   wrote:
  
   On 19/05/2010 17:03, Jeremy Thomerson wrote:
   
   
To clarify this, I use Application.set and App...
   Well, forgetting to unset it would not leak any more than have it
   implicitly
   set like it's going to be. And I do think forgetting this is developer
   fault.
  
   What you all do not want to understand is what I said about Java
 library
   spawning its own threads, and that is not documented, as its for
 cleanup
  in
   the case I shown.
  
  
   Adriano
  
  
 

Re: spring cleaning wicket?

[tetsuo]

Taking specifically your example, 'foo == false' is too similar to 'foo =
false', which also compiles, and is probably an error (not just checking the
value, but changing it. '!foo' or 'false == foo' ('false = foo' doesn't
compile) may be better choices.

But yes, most of these warnings are just about taste or rules without
context, and I don't think they should even be cosidered 'fixes'.



On Tue, Mar 23, 2010 at 10:14 AM, Jeremy Thomerson 
jer...@wickettraining.com wrote:

 I would reject patchs to fix some of those.  Some of those so-called
 violations are just their coding style not being the same as ours.

 For instance, they say there are 218 violations where we have 'if (foo ==
 false)' - which they say should be simplified, I'm assuming to be 'if
 (!foo)'.  Personally, I write mine as foo == false because it is much
 harder to miss that than it is to miss ! as you're reading through the
 code.

 Another example: empty method in abstract class should be abstract.  No,
 it shouldn't.  It's a method designed to be overridden for additional
 functionality if you so desire.

 There might be some that are worth fixing.  But as I mention, there are
 some
 that are better left alone.

 --
 Jeremy Thomerson
 http://www.wickettraining.com



 On Tue, Mar 23, 2010 at 6:39 AM, nino martinez wael 
 nino.martinez.w...@gmail.com wrote:

  Hi I wondered
 
  if it would be interesting if I started to make wicket more in
  compliance with the rules defined here:
  http://nemo.sonarsource.org/drilldown/violations/44196?priority=MAJOR
  ?
 
  I'd of course start by submitting patches..
 
  So are it interesting?
 
  regards Nino
 

Re: IComponentInheritedModel rule exception

[tetsuo]

 2 - here I have an simple consideration: framework should respect my
 component design.


My view is different: we should respect the framework design. Don't fight
your tools, learn how to use them properly.

That said, I think that the model is the place where lazy instantiations
should occur. I mean, create your components with models that create their
'backend' on demand, like LoadableDetachableModel (without the 'detach'
stuff, maybe). Such model object should be pretty small in byte size, so it
shouldn't be a problem for memory consumption.

Well, I'm not an expert in Wicket's internals, so it's just a guess. :)

Re: taking the I out of Interface

[tetsuo]

 I agree, names like IThing and ThingImpl can be a sign of not thinking too
 hard about naming things (and even a rush to get coding without enough
 thought put into design -  but that's a long story).

I* is just a convention, which some like, others dislike, and *Impl are
perfectly fine when used in private inner classes (the only case I've found
in a quick search of Wicket's code).

Good naming is nice, but is not the ultimate goal of good design, for god's
sake! Backward compatibility (a pragmatic one, not a religious one like
Java's) is much higher in my priorities.


 For me, dropping those
 I prefixes and any  Impl suffixes will make the project code-base look
 even more credible.

... and breaking everything every release will make the project less
credible.

Will you rename PropertyModel to PropertyLocator? ListModel to ListLocator?
BreadCrumbModel to BreadCrumbLocator? For the sake of consistency, of course
:)

Re: taking the I out of Interface

[tetsuo]

 What if I have
 a class for the iPlayer (a BBC service for watching already broadcast TV
 programs online). If I call my class IPlayer do I need to worry that half
 the world is going to think it's an interface.


Oh, Apple will have a lot of trouble if they try to use Wicket :)



 Again, having such a naming convention in the code is certainly not the end
 of the world


Exactly!



 but to my mind it's a convention that does more harm than good


But how does this harm compare to the harm caused by the cure? You only take
Chemotherapy when you die otherwise.

I think you guys are underestimating the cost of renaming such central part
of the framework.

Do whatever you want with *Impl, because it just doesn't occur in public
classes.

Abstract* and Default* are useful, if they have a consistent meaning. For
example, I'm not sure, but I think Default* are ready-to-use complex
components, with all style needed out-of-the-box. Abstract* are partial
implementations of interfaces, what are very useful. If they are not that
consistent, and you can think of really better names (StyledDataTable is *
not* better than DefaultDataTable), it may be worth renaming.

If you only take the 'I' out of interfaces, you'll break every component,
tutorial, documentation, and code sample out there, but at least the concept
remains intact.

If you also rename IModel to Locator, you'll break either the naming
consistency (half *Model, half *Locator), or the already established
vocabulary of the framework (if everything changes to *Locator), which is,
by far, the worst option.

But I still think that both changes are completely unnecessary, and a fruit
of pure purism. And it's not a question of skill. In fact, this kind of
purism manifests precisely in very skilled developers. I also do this
sometimes, but fortunately I always have someone who pulls me back to Earth.

And about 'breaking compatibility each release', well, it does happen, and
if comes without a very good reason, it becomes harder and harder to sell
Wicket to my employee :)

Re: taking the I out of Interface

[tetsuo]

-1

It breaks compatibility for absolutely no reason.



On Fri, Oct 2, 2009 at 7:45 PM, Johan Edstrom seij...@gmail.com wrote:

 +1


 On Oct 2, 2009, at 17:28, Igor Vaynberg igor.vaynb...@gmail.com wrote:

  is it perhaps time to take the I out of our interface names? wicket
 has been the only project i have ever worked on/used that follows this
 convention, is it time for a change?

 this is not meant as a flamewar about which convention is teh
 aw3s0m3st, simply a discussion of whether or not we should switch.

 -igor

Re: Tim Boudreau doesn't like getModel() - getDefaultModel()

[tetsuo]

I've just read the explanation in a Tim's blog post comment. Oh, well,
generics definitely isn't easy to grasp...

I myself have observed that my (wicket) code is so much readable without
most generics declarations. Even when using components that do have models
(Textfield, for example) I didn't gain anything for adding the angle
brackets, since the models in general use reflection (PropertyModel,
CompoundPropertyModel, etc.), and don't make any use of the build-time
validation at all.

sigh...

Tetsuo



On Mon, Jul 6, 2009 at 3:35 PM, tetsuo ronald.tet...@gmail.com wrote:

 I understand the getModelObject() thing, but I not about the
 getDefaultModel(). Why is that?

 I've found an e-mail (
 http://mail-archives.apache.org/mod_mbox/wicket-dev/200806.mbox/%3c23eb48360806190903y27f3baeaua2db57e392497...@mail.gmail.com%3e)
 that states that it may be removed in 1.5.

 Why rename getModel to getDefaultModel just to take it out later?

 Not a critic, just trying to understand.

 Tetsuo




 On Mon, Jul 6, 2009 at 11:18 AM, Jeremy Thomerson 
 jer...@wickettraining.com wrote:

 A good overall read, but he also seemed to miss the reason we have
 getModel**Object**.  He doesn't think that's necessary, but misses
 that there is also getModel (without object) and the word does clarify
 the difference.

 Anyway, a good read on overall API design, though.  I'd recommend it
 to others with the caveat that I also disagree with his last part
 about the rename.

 --
 Jeremy Thomerson
 http://www.wickettraining.com




 On Mon, Jul 6, 2009 at 8:22 AM, Martijn
 Dashorstmartijn.dasho...@gmail.com wrote:
 
 http://weblogs.java.net/blog/timboudreau/archive/2009/07/api_design_vs_a_1.html
 
  I guess he doesn't get why we did the rename. This reminds me that we
  *really* should improve our release docs before we finalize 1.4!!!
 
  Martijn
 
  --
  Become a Wicket expert, learn from the best: http://wicketinaction.com
  Apache Wicket 1.3.5 is released
  Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.
 

Re: Tim Boudreau doesn't like getModel() - getDefaultModel()

[tetsuo]

What if Component was not generified, and had an 'Object getModel()' method
instead of 'Object getDefaultModel()', and the components that do benefit
from generics, simply override the method to return 'T' (then the component
class would have a T type parameter)? The compiler accepts this just fine.

Tetsuo



On Mon, Jul 6, 2009 at 3:48 PM, tetsuo ronald.tet...@gmail.com wrote:

 I've just read the explanation in a Tim's blog post comment. Oh, well,
 generics definitely isn't easy to grasp...

 I myself have observed that my (wicket) code is so much readable without
 most generics declarations. Even when using components that do have models
 (Textfield, for example) I didn't gain anything for adding the angle
 brackets, since the models in general use reflection (PropertyModel,
 CompoundPropertyModel, etc.), and don't make any use of the build-time
 validation at all.

 sigh...

 Tetsuo




 On Mon, Jul 6, 2009 at 3:35 PM, tetsuo ronald.tet...@gmail.com wrote:

 I understand the getModelObject() thing, but I not about the
 getDefaultModel(). Why is that?

 I've found an e-mail (
 http://mail-archives.apache.org/mod_mbox/wicket-dev/200806.mbox/%3c23eb48360806190903y27f3baeaua2db57e392497...@mail.gmail.com%3e)
 that states that it may be removed in 1.5.

 Why rename getModel to getDefaultModel just to take it out later?

 Not a critic, just trying to understand.

 Tetsuo




 On Mon, Jul 6, 2009 at 11:18 AM, Jeremy Thomerson 
 jer...@wickettraining.com wrote:

 A good overall read, but he also seemed to miss the reason we have
 getModel**Object**.  He doesn't think that's necessary, but misses
 that there is also getModel (without object) and the word does clarify
 the difference.

 Anyway, a good read on overall API design, though.  I'd recommend it
 to others with the caveat that I also disagree with his last part
 about the rename.

 --
 Jeremy Thomerson
 http://www.wickettraining.com




 On Mon, Jul 6, 2009 at 8:22 AM, Martijn
 Dashorstmartijn.dasho...@gmail.com wrote:
 
 http://weblogs.java.net/blog/timboudreau/archive/2009/07/api_design_vs_a_1.html
 
  I guess he doesn't get why we did the rename. This reminds me that we
  *really* should improve our release docs before we finalize 1.4!!!
 
  Martijn
 
  --
  Become a Wicket expert, learn from the best: http://wicketinaction.com
  Apache Wicket 1.3.5 is released
  Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.
 

Re: Tim Boudreau doesn't like getModel() - getDefaultModel()

[tetsuo]

'IModel? getModel()' instead of 'Object getModel()', and 'IModelT
getModel()' instead of 'T getModel()', sorry.

And sorry for flooding the mailing list, this is the last one, I promise :)



On Mon, Jul 6, 2009 at 3:54 PM, tetsuo ronald.tet...@gmail.com wrote:

 What if Component was not generified, and had an 'Object getModel()' method
 instead of 'Object getDefaultModel()', and the components that do benefit
 from generics, simply override the method to return 'T' (then the component
 class would have a T type parameter)? The compiler accepts this just fine.

 Tetsuo




 On Mon, Jul 6, 2009 at 3:48 PM, tetsuo ronald.tet...@gmail.com wrote:

 I've just read the explanation in a Tim's blog post comment. Oh, well,
 generics definitely isn't easy to grasp...

 I myself have observed that my (wicket) code is so much readable without
 most generics declarations. Even when using components that do have models
 (Textfield, for example) I didn't gain anything for adding the angle
 brackets, since the models in general use reflection (PropertyModel,
 CompoundPropertyModel, etc.), and don't make any use of the build-time
 validation at all.

 sigh...

 Tetsuo




 On Mon, Jul 6, 2009 at 3:35 PM, tetsuo ronald.tet...@gmail.com wrote:

 I understand the getModelObject() thing, but I not about the
 getDefaultModel(). Why is that?

 I've found an e-mail (
 http://mail-archives.apache.org/mod_mbox/wicket-dev/200806.mbox/%3c23eb48360806190903y27f3baeaua2db57e392497...@mail.gmail.com%3e)
 that states that it may be removed in 1.5.

 Why rename getModel to getDefaultModel just to take it out later?

 Not a critic, just trying to understand.

 Tetsuo




 On Mon, Jul 6, 2009 at 11:18 AM, Jeremy Thomerson 
 jer...@wickettraining.com wrote:

 A good overall read, but he also seemed to miss the reason we have
 getModel**Object**.  He doesn't think that's necessary, but misses
 that there is also getModel (without object) and the word does clarify
 the difference.

 Anyway, a good read on overall API design, though.  I'd recommend it
 to others with the caveat that I also disagree with his last part
 about the rename.

 --
 Jeremy Thomerson
 http://www.wickettraining.com




 On Mon, Jul 6, 2009 at 8:22 AM, Martijn
 Dashorstmartijn.dasho...@gmail.com wrote:
 
 http://weblogs.java.net/blog/timboudreau/archive/2009/07/api_design_vs_a_1.html
 
  I guess he doesn't get why we did the rename. This reminds me that we
  *really* should improve our release docs before we finalize 1.4!!!
 
  Martijn
 
  --
  Become a Wicket expert, learn from the best:
 http://wicketinaction.com
  Apache Wicket 1.3.5 is released
  Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.
 

Re: Tim Boudreau doesn't like getModel() - getDefaultModel()

[tetsuo]

Now I get it, thanks.

Indeed, it's hard to think in a better solution (without ditching generics
altogether).

Tetsuo



On Mon, Jul 6, 2009 at 4:19 PM, Matej Knopp matej.kn...@gmail.com wrote:

 Problem is setDefaultModelObject().

 If you have setModelObject(Object o) you can not override it in
 subclass and restrict the parameter.

 -Matej

 On Mon, Jul 6, 2009 at 8:58 PM, tetsuoronald.tet...@gmail.com wrote:
  'IModel? getModel()' instead of 'Object getModel()', and 'IModelT
  getModel()' instead of 'T getModel()', sorry.
 
  And sorry for flooding the mailing list, this is the last one, I promise
 :)
 
 
 
  On Mon, Jul 6, 2009 at 3:54 PM, tetsuo ronald.tet...@gmail.com wrote:
 
  What if Component was not generified, and had an 'Object getModel()'
 method
  instead of 'Object getDefaultModel()', and the components that do
 benefit
  from generics, simply override the method to return 'T' (then the
 component
  class would have a T type parameter)? The compiler accepts this just
 fine.
 
  Tetsuo
 
 
 
 
  On Mon, Jul 6, 2009 at 3:48 PM, tetsuo ronald.tet...@gmail.com wrote:
 
  I've just read the explanation in a Tim's blog post comment. Oh, well,
  generics definitely isn't easy to grasp...
 
  I myself have observed that my (wicket) code is so much readable
 without
  most generics declarations. Even when using components that do have
 models
  (Textfield, for example) I didn't gain anything for adding the angle
  brackets, since the models in general use reflection (PropertyModel,
  CompoundPropertyModel, etc.), and don't make any use of the build-time
  validation at all.
 
  sigh...
 
  Tetsuo
 
 
 
 
  On Mon, Jul 6, 2009 at 3:35 PM, tetsuo ronald.tet...@gmail.com
 wrote:
 
  I understand the getModelObject() thing, but I not about the
  getDefaultModel(). Why is that?
 
  I've found an e-mail (
 
 http://mail-archives.apache.org/mod_mbox/wicket-dev/200806.mbox/%3c23eb48360806190903y27f3baeaua2db57e392497...@mail.gmail.com%3e
 )
  that states that it may be removed in 1.5.
 
  Why rename getModel to getDefaultModel just to take it out later?
 
  Not a critic, just trying to understand.
 
  Tetsuo
 
 
 
 
  On Mon, Jul 6, 2009 at 11:18 AM, Jeremy Thomerson 
  jer...@wickettraining.com wrote:
 
  A good overall read, but he also seemed to miss the reason we have
  getModel**Object**.  He doesn't think that's necessary, but misses
  that there is also getModel (without object) and the word does
 clarify
  the difference.
 
  Anyway, a good read on overall API design, though.  I'd recommend it
  to others with the caveat that I also disagree with his last part
  about the rename.
 
  --
  Jeremy Thomerson
  http://www.wickettraining.com
 
 
 
 
  On Mon, Jul 6, 2009 at 8:22 AM, Martijn
  Dashorstmartijn.dasho...@gmail.com wrote:
  
 
 http://weblogs.java.net/blog/timboudreau/archive/2009/07/api_design_vs_a_1.html
  
   I guess he doesn't get why we did the rename. This reminds me that
 we
   *really* should improve our release docs before we finalize 1.4!!!
  
   Martijn
  
   --
   Become a Wicket expert, learn from the best:
  http://wicketinaction.com
   Apache Wicket 1.3.5 is released
   Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.