Re: SV: Multiple wicket applications in a single WAR
I don't think it is a good idea to have multiple applications in one
war. Wicket stores static state in ThreadLocals (Application, Session,
etc.). All apps in the same war share the same ClassLoader and thus the
same static ThreadLocal instances. There might be circumstances when the
state somehow gets messed up. I'm sure this is the source of your
problems. So, either go for one app for all users or create two separate
war files.
Reinhard
Am 10.12.2010 07:07, schrieb fstof:
Oh and I excluded the session code for the simple reason, that I dont think
it is relevant, as it is the applications that get mixed up
fstof wrote:
Igor Vaynberg-2 wrote:
a reproducible test case :)
-igor
If I could reproduce it I'm pretty sure I would have been able to solve it
:) The thing is It happens like once a week, and we have not seen it
happen in any of our DEV/PRE environments
Zilvinas Vilutis wrote:
1. No one will steal your non-working code - that's for sure :)
2. Try to explain the scenario in more details. Are you using Spring
Security or just wicket? What brings you to the app after login -
component.continueToOriginalDestination() ?
1. Steeling my code is the least of my problems :)
2. We are not using spring at all, Only wicket-auth-roles.
(AuthenticatedWebApplication / AuthenticatedWebSession)
When loading the app in the browser it loads the HomePage /
ThirdPartyHomePage. Both of these have the annotation
@AuthorizeInstantiation("user") which causes the redirecting the the
SignInPage / SignInThirdPartyPage
And that is exactly where it goes pear shaped.
When calling the mapping for the one Application
(MMSAHealthWebApplication) it would load the page SignInThirdPartyPage
which belongs to the other app
So I'll add some more code...
1. We have a base Application class:
public abstract class MMSAAbstractWebApplication extends
AuthenticatedWebApplication {
private static Logger log =
LoggerFactory.getLogger(MMSAAbstractWebApplication.class);
protected void init() {
log.info("initialising application");
super.init();
// Get the logger
IRequestLoggerSettings reqLogger =
Application.get().getRequestLoggerSettings();
// Enable the logger
reqLogger.setRequestLoggerEnabled(true);
getRequestCycleSettings().setRenderStrategy(Settings.ONE_PASS_RENDER);
mountPages();
}
private void mountPages() {
mountBookmarkablePage("/registration", RegistrationPage.class);
...
}
}
2. Then we have 2 subclasses (these are the ones mapped in web.xml)
public class MMSAHealthWebApplication extends MMSAAbstractWebApplication {
private static Logger log =
LoggerFactory.getLogger(MMSAHealthWebApplication.class);
@Override
protected Class
getWebSessionClass() {
return MMSAHealthWebSession.class;
}
protected Class getSignInPageClass() {
return SignInPage.class;
}
public Class getHomePage() {
return HomePage.class;
}
protected void init() {
log.info("initialising application");
super.init();
}
}
And
public class MMSAThirdPartyWebApplication extends
MMSAAbstractWebApplication {
private static Logger log =
LoggerFactory.getLogger(MMSAThirdPartyWebApplication.class);
@Override
protected Class
getWebSessionClass() {
return MMSAThirdPartyWebSession.class;
}
protected Class getSignInPageClass() {
return SignInThirdPartyPage.class;
}
public Class getHomePage() {
return ThirdPartyHomePage.class;
}
protected void init() {
log.info("initialising application");
super.init();
}
}
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: Wicketstuff releases?
I'd like to second Maartens point. Identical releases to Wicket itself would mean that it always depends on Wicket. Independent releases would not be possible. Bugs could not be fixed and new features could not be added without a new Wicket release. This doesn't really make sense to me. Reinhard Jeremy Thomerson schrieb: Now that Wicket 1.4.0 is out, I wonder which wicketstuff core version is compatible. There is no 1.4.0 version of wicketstuff core (yet?). Should I use 1.4-rc8-SNAPSHOT? It should be just 1.4-SNAPSHOT. 1.4-rc8-SNAPSHOT was an accidental relic of after I built rc8 Side note: I don't see the version of wicket-stuff has to match exactly with version of wicket ? Suppose someone releases wicketstuff-core-1.4.0 today, and tomorrow some bugs are fixed in wicketstuff-core, then we can't release these bug-fixes until wicket 1.4.1 is out ? IMO, wicket is just a dependency of wicketstuff-code (as defoined in the pom) and both projects should use their own unrelated version numbers. wdyt ? When I setup wicketstuff-core, I proposed that we structure it to have identical releases to Wicket. The community agreed. I still think this should be the case. -- Jeremy Thomerson http://www.wickettraining.com - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: cwiki code blocks render poorly on firefox, chrome, safari
OK, sorry, I didn't read that. My bad. But please don't panic, I was just trying to help identify the problem... Martijn Dashorst schrieb: You're completely reasoning the wrong way. The static HTML files are the right links. Never, NEVER link to a confluence internal page, since that puts more load on the server without any due cause. If you had read the big warning sign on the top of the root wiki page, you would have read: Linking to the wiki To help with the server loading, please only link to pages under the http://cwiki.apache.org/WICKET/ static root. This is the proper way to linking to our documentation. The issue with the code blocks is something I'll take up with infra@ and see if there's something that can be done. Martijn On Wed, Aug 12, 2009 at 9:18 AM, Reinhard Nägele wrote: I just played around with that a bit. This seems to be a Confluence problem. If you open the URL http://cwiki.apache.org/WICKET/dropdownchoice-examples.html, you get small text areas without proper styling. If you then edit the page and cancel editing again, you are redirected to http://cwiki.apache.org/confluence/display/WICKET/DropDownChoice+Examples. Now everything is fine. It looks like any link that ends with ".html" leads to a bad page. I wonder how come such HTML links are used. These are not standard Confluence links. The problems is that if you open a ".html" link, all links on that page in turn ".html" links again. Compare e. g. http://cwiki.apache.org/WICKET/how-to-do-things-in-wicket.html vs. http://cwiki.apache.org/confluence/display/WICKET/How+to+do+things+in+Wicket. So, every link to the Wiki from the Apache Website should use the correct form. E. g. http://cwiki.apache.org/WICKET/ should be changed to http://cwiki.apache.org/confluence/display/WICKET/Index. Could someone please take care of that. Thanks, Reinhard Per Lundholm schrieb: The ones working is not using a "code" block. Don't know much about the wiki used, but it seems not to set up the width of textareas, leaving them to default width. /Per On Tue, Aug 11, 2009 at 9:37 PM, Troy Cauble wrote: I couldn't find a place on the wiki to point this out, so FYI, many of the wiki pages have code blocks that render poorly on firefox, chrome & safari (all on the Mac). For example, http://cwiki.apache.org/WICKET/dropdownchoice-examples.html I see code blocks with nested scrollpanes and the inner one is only about 20 characters wide, so the code is wrapped tightly. On chrome and safari there's a drag handle where you can pull each one out horizontally to make it readable, but not on firefox. Many of the wiki pages are like this. OTOH, many similar pages are fine. For example http://cwiki.apache.org/WICKET/conditional-validation.html -troy - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: cwiki code blocks render poorly on firefox, chrome, safari
I just played around with that a bit. This seems to be a Confluence problem. If you open the URL http://cwiki.apache.org/WICKET/dropdownchoice-examples.html, you get small text areas without proper styling. If you then edit the page and cancel editing again, you are redirected to http://cwiki.apache.org/confluence/display/WICKET/DropDownChoice+Examples. Now everything is fine. It looks like any link that ends with ".html" leads to a bad page. I wonder how come such HTML links are used. These are not standard Confluence links. The problems is that if you open a ".html" link, all links on that page in turn ".html" links again. Compare e. g. http://cwiki.apache.org/WICKET/how-to-do-things-in-wicket.html vs. http://cwiki.apache.org/confluence/display/WICKET/How+to+do+things+in+Wicket. So, every link to the Wiki from the Apache Website should use the correct form. E. g. http://cwiki.apache.org/WICKET/ should be changed to http://cwiki.apache.org/confluence/display/WICKET/Index. Could someone please take care of that. Thanks, Reinhard Per Lundholm schrieb: The ones working is not using a "code" block. Don't know much about the wiki used, but it seems not to set up the width of textareas, leaving them to default width. /Per On Tue, Aug 11, 2009 at 9:37 PM, Troy Cauble wrote: I couldn't find a place on the wiki to point this out, so FYI, many of the wiki pages have code blocks that render poorly on firefox, chrome & safari (all on the Mac). For example, http://cwiki.apache.org/WICKET/dropdownchoice-examples.html I see code blocks with nested scrollpanes and the inner one is only about 20 characters wide, so the code is wrapped tightly. On chrome and safari there's a drag handle where you can pull each one out horizontally to make it readable, but not on firefox. Many of the wiki pages are like this. OTOH, many similar pages are fine. For example http://cwiki.apache.org/WICKET/conditional-validation.html -troy - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Output to input stream for streaming?
You need to wait until your executor thread has finished. Then it might
work.
Future f = Executors.newSingleThreadExecutor().submit(new Runnable() {
@Override
public void run() {
try {
wb.write(out);
} catch (IOException e) {
MarkupUtils.handleUnexpectedException(e);
}
}
});
f.get();
Erik van Oosten schrieb:
That won't work. Servlets are synchronous; they don't expect anyone
writing the output once the servlet finished.
Regards,
Erik.
Russell Simpkins wrote:
Its not that anything is missing per se, but if you run your output
writer in a separate thread, then the rest of your processing is free
to continue and in your case I'm guessing that the processing has
finished before your output writing has completed. When your servlet
finishes, the last thing that happens is the output stream gets
closed. Try doing the write outside of a thread and see if you get
the same exception.
Russ
Date: Mon, 10 Aug 2009 15:03:13 +0300
Subject: Re: Output to input stream for streaming?
From: martin.maku...@koodaripalvelut.com
To: users@wicket.apache.org
Well well.. I do not understand why it is not possible, in principle.
The input is there. The output is there... what's missing?
**
Martin
2009/8/10 Russell Simpkins :
Martin,
I don't think you can do this in a thread because that lets the
HttpServletResponse end and close your ServletOutputStream.
Russ
Date: Mon, 10 Aug 2009 14:49:58 +0300
Subject: Output to input stream for streaming?
From: martin.maku...@koodaripalvelut.com
To: users@wicket.apache.org
Hi!
I have a HSSF document which can be written to an output stream.
However, I want to stream it to the website visitor, which
requires an
inputstream... I have tried the following, but it somehow doesn't
seem
to work.
Anybody know what can be done to fix it?
final PipedInputStream inputStream = new PipedInputStream();
final PipedOutputStream out;
try {
out = new PipedOutputStream(inputStream);
} catch (IOException e) {
throw new RuntimeException(e);
}
Executors.newSingleThreadExecutor().execute(new Runnable() {
@Override
public void run() {
try {
wb.write(out);
} catch (IOException e) {
MarkupUtils.handleUnexpectedException(e);
}
}
});
IResourceStream resourceStream = new IResourceStream() {
/**
* @see org.apache.wicket.util.resource.IResourceStream#close()
*/
public void close() throws IOException {
inputStream.close();
}
/**
* @see
org.apache.wicket.util.resource.IResourceStream#getContentType()
*/
public String getContentType() {
return getAlternateContentType();
}
/**
* @see
org.apache.wicket.util.resource.IResourceStream#getInputStream()
*/
public InputStream getInputStream()
throws ResourceStreamNotFoundException {
return inputStream;
}
/**
* @see
org.apache.wicket.util.resource.IResourceStream#getLocale()
*/
public Locale getLocale() {
throw new IllegalAccessError("Method not implemented.");
}
/**
* @see
org.apache.wicket.util.resource.IResourceStream#length()
*/
public long length() {
try {
return inputStream.available();
} catch (IOException e) {
MarkupUtils.handleUnexpectedException(e);
}
return 0;
}
/**
* @see
org.apache.wicket.util.resource.IResourceStream#setLocale(java.util.Locale)
*/
public void setLocale(Locale locale) {
throw new IllegalAccessError("Method not implemented.");
}
/**
* @see
org.apache.wicket.util.watch.IModifiable#lastModifiedTime()
*/
public Time lastModifiedTime() {
return
Time.milliseconds(DatabaseServices.getCurrentTimestamp().getTime());
}
};
java.io.IOException: Pipe closed
at java.io.PipedInputStream.checkStateForReceive(Unknown
Source)
at java.io.PipedInputStream.receive(Unknown Source)
at java.io.PipedOutputStream.write(Unknown Source)
at java.io.OutputStream.write(Unknown Source)
at
org.apache.poi.poifs.storage.BigBlock.doWriteData(BigBlock.java:55)
at
org.apache.poi.poifs.storage.DocumentBlock.writeData(DocumentBlock.java:220)
at
org.apache.poi.poifs.storage.BigBlock.writeBlocks(BigBlock.java:86)
at
org.apache.poi.poifs.filesystem.POIFSDocument$BigBlockStore.writeBlocks(POIFSDocument.java:603)
at
org.apache.poi.poifs.filesystem.POIFSDocument.writeBlocks(POIFSDocument.java:275)
at
org.apache.poi.poifs.filesystem.POIFSFileSystem.writeFilesystem(POIFSFileSystem.java:390)
at
org.apache.poi.hssf.usermodel.HSSFWorkbook.write(HSSFWorkbook.java:1168)
**
Martin
Re: Output to input stream for streaming?
How about this:
ByteArrayOutputStream baos = new ByteArrayOutputStream();
wb.write(baos);
InputStream is = new ByteArrayInputStream(baos.toByteArray());
Martin Makundi schrieb:
Hi!
I have a HSSF document which can be written to an output stream.
However, I want to stream it to the website visitor, which requires an
inputstream... I have tried the following, but it somehow doesn't seem
to work.
Anybody know what can be done to fix it?
final PipedInputStream inputStream = new PipedInputStream();
final PipedOutputStream out;
try {
out = new PipedOutputStream(inputStream);
} catch (IOException e) {
throw new RuntimeException(e);
}
Executors.newSingleThreadExecutor().execute(new Runnable() {
@Override
public void run() {
try {
wb.write(out);
} catch (IOException e) {
MarkupUtils.handleUnexpectedException(e);
}
}
});
IResourceStream resourceStream = new IResourceStream() {
/**
* @see org.apache.wicket.util.resource.IResourceStream#close()
*/
public void close() throws IOException {
inputStream.close();
}
/**
* @see org.apache.wicket.util.resource.IResourceStream#getContentType()
*/
public String getContentType() {
return getAlternateContentType();
}
/**
* @see org.apache.wicket.util.resource.IResourceStream#getInputStream()
*/
public InputStream getInputStream()
throws ResourceStreamNotFoundException {
return inputStream;
}
/**
* @see org.apache.wicket.util.resource.IResourceStream#getLocale()
*/
public Locale getLocale() {
throw new IllegalAccessError("Method not implemented.");
}
/**
* @see org.apache.wicket.util.resource.IResourceStream#length()
*/
public long length() {
try {
return inputStream.available();
} catch (IOException e) {
MarkupUtils.handleUnexpectedException(e);
}
return 0;
}
/**
* @see
org.apache.wicket.util.resource.IResourceStream#setLocale(java.util.Locale)
*/
public void setLocale(Locale locale) {
throw new IllegalAccessError("Method not implemented.");
}
/**
* @see org.apache.wicket.util.watch.IModifiable#lastModifiedTime()
*/
public Time lastModifiedTime() {
return
Time.milliseconds(DatabaseServices.getCurrentTimestamp().getTime());
}
};
java.io.IOException: Pipe closed
at java.io.PipedInputStream.checkStateForReceive(Unknown Source)
at java.io.PipedInputStream.receive(Unknown Source)
at java.io.PipedOutputStream.write(Unknown Source)
at java.io.OutputStream.write(Unknown Source)
at org.apache.poi.poifs.storage.BigBlock.doWriteData(BigBlock.java:55)
at
org.apache.poi.poifs.storage.DocumentBlock.writeData(DocumentBlock.java:220)
at org.apache.poi.poifs.storage.BigBlock.writeBlocks(BigBlock.java:86)
at
org.apache.poi.poifs.filesystem.POIFSDocument$BigBlockStore.writeBlocks(POIFSDocument.java:603)
at
org.apache.poi.poifs.filesystem.POIFSDocument.writeBlocks(POIFSDocument.java:275)
at
org.apache.poi.poifs.filesystem.POIFSFileSystem.writeFilesystem(POIFSFileSystem.java:390)
at
org.apache.poi.hssf.usermodel.HSSFWorkbook.write(HSSFWorkbook.java:1168)
**
Martin
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: SVN URL for Wicket 1.4.0 sources?
The same thing happened to me recently. I wanted to check out the release tag and could not find it. I was already sort of surprised when Igor mentioned he'd release from his private sandbox. And now we have a 1.4.0 tag with a 1.4-SNAPSHOT in it and trunk which still has 1.4-SNAPSHOT. That can't be it. Please, guys, rethink your release process. The Maven release plugin is just the standard way of cutting releases. Reinhard James Carman schrieb: Well, think about it this way. In the original message in this thread, Thomas Singer went looking for the 1.4.0 release stuff at the URL: http://svn.apache.org/repos/asf/wicket/tags/wicket-1.4.0 and it wasn't there. Why did he go there? Hmm. Maybe because that's how everyone else does it? Why would Wicket choose to do it differently than everyone else? It just doesn't make any sense to me. Also, in the vote thread, Igor proposed to release 1.4.0 from the following SVN URL: https://svn.apache.org/repos/asf/wicket/sandbox/ivaynberg/wicket-1.4.0 However, you're saying that it was actually released from: https://svn.apache.org/repos/asf/wicket/releases/wicket-1.4.0 So, the released software wasn't built from the URL the community voted on. You can't just move things around and release it. You need to release from the SVN URL in the vote thread, because that's what's being voted upon. On Tue, Aug 4, 2009 at 5:28 AM, Martijn Dashorst wrote: tags/foo is as mutable as releases/foo If a release needs to be cut, we can just do: svn co https://svn.apache.org/repos/asf/wicket/releases/wicket-1.4.0 ./release.sh there are no changes to the release after it has been created. A social convention, just as tagging it. And this is the last thing I'll say about it. Martijn On Tue, Aug 4, 2009 at 11:10 AM, James Carman wrote: On Tue, Aug 4, 2009 at 5:05 AM, Martijn Dashorst wrote: We create a branch of off trunk for future maintenance of wicket 1.4, not from a release branch. wicket/branches/wicket-1.3.x -> created from wicket/trunk when we moved 1.3 to maintenance mode wicket/branches/wicket-1.4.x -> will be created from wicket/trunk when we move 1.4 to mainenance mode wicket/releases/wicket-1.4.1 -> will be created from wicket/trunk if we haven't created branches/wicket-1.4.x yet, or else from branches/wicket-1.4.x Sorry, but this has been the way we have done things since the dawn of the project. Just because you think it is not correct, doesn't invalidate how *we* do things. Correct. Projects do have some leeway, but it is important to be able to re-create the release as it was. With your strategy, you have no idea (without some SVN version magic) how to re-create it if you're checking code into the SVN URL that is used to create the release. The SCM URL in your released pom points to: scm:svn:http://svn.apache.org/repos/asf/wicket/releases/wicket-1.4.0 Which is MUTABLE with your strategy! You don't see a problem with that?!?!?! The SCM URL for releases should point to a tag (which nobody is supposed to modify), not a branch. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org -- Become a Wicket expert, learn from the best: http://wicketinaction.com Apache Wicket 1.4 increases type safety for web applications Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.4.0 - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: WicketTester and org.slf4j.LoggerFactory and org.slf4j.Logger not serializable
If you use slf4j 1.5.3 or newer, serialization should just work fine. See http://www.slf4j.org/faq.html#declared_static Reinhard Jeremy Thomerson schrieb: Your logger instances should either be transient or static - so that they are not serialized. -- Jeremy Thomerson http://www.wickettraining.com On Mon, Jul 27, 2009 at 8:01 PM, David Brown wrote: Hello, I have a Wicket 1.4rc4 application with a homegrown set of JDBC DAO classes: basic JDBC Connection and various methods for SQL queries and transactions. And Connection pooling is imported into the same JDBC DAO class and works well against the JUnit TestCases. The JUnit TestCases for the JDBC DAO implementation is comprehensive and complete with no failed testcases (17 in all). Now, I want to start testing the Pages that use my JDBC DAO class using WicketTester but the TestCases so far are failing with errors. I have scoured this topic with Google and have re-read Dashorst/Hillenius, Kent Tong and the Wicket Wiki and other articles covering WicketTester including the JavaDocs. My TestCases are having trouble with my JDBC DAOs as they not seriablizable because of heavy use of the logging packages: org.slf4j.LoggerFactory and org.slf4j.Logger I don't to remove all of the logging from my JDBC DAOs to implement WicketTester. Is there some way around this type of issue with serialization? Please advise, David. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: jWicket -- jQuery with Wicket integration
Given the fact that there is already wicket-jquery in wicketstoff-core, I wonder how come it is simply possible to add another JQuery integration to wicketstuff. What are the rules for adding stuff there? Can committers just do whatever the like? Doesn't there have to be some voting on the mailing list for things like that? If I was to add yet another JQuery integration, could I just put it in there as well? I'm currently doing a Wicket evaluation. Wicket may become one of the standard frameworks of the company I work for. I really like what I've seen so far, and working with Wicket can be really fun. But what looks pretty messy to me is the way things are organized (documentation, wiki, wicketstuff). To me wicketstuff presents itself as some inofficial playground with lots of badly documented things in it. However, wicketstuff-core (which is not even listed on the wicketstuff wiki (except for a migration guide)) seems to have a somewhat more official character. May the latter be taken as a production-ready supplement to Wicket? I'd appreciate it if some restructuring and clarification came along with the upcoming 1.4 release. Thanks, Reinhard Tauren Mills schrieb: Hi Richard, I actually tried out WiQuery before deciding it wasn't the right tool for me. I can't remember the exact specifics of the issues I had with it, and I only spent about a day with it. But I remember feeling like I was being forced to use it whenever and wherever I wanted to add ANY jQuery to my project. I can see how WiQuery would be good for a developer who doesn't want to touch JS, and only code in Java. With WiQuery, I can add all the functionality I need via the WiQuery API. I have nothing against the project in this regard, it seems like a great solution for that situation. But in my case, I want a wicket/jquery tool that is lightweight and stays out of my way. I would rather code client-side only stuff just in jQuery and not have anything necessary in my server code. The only time I want wicket components to be aware of my jQuery code is if there needs to be some client-server ajax communication. For instance, drag/drop information, or sorting a list of item, etc. From my perspective, I could care less if wicket knows which accordion panel is open in the browser, because *for my application*, that doesn't matter. And I do realize there are *other applications* that this would matter, for which an optional WiQuery accordion plugin would be userful. And when I want to use another add-on jQuery plugin such as superfish.js, I don't want to have to resort to WiQuery hacks or to create my own WiQuery plugin to support it. I am constantly adding little jQuery code here and there, and to have to make WiQuery plugins for it all or to code it using the WiQuery API would be a pain that I'm not willing to put up with. The following posting I made might give a little more insight into the reason I stopped using WiQuery: http://groups.google.com/group/wiquery/browse_thread/thread/190fc243777ea3ba/492092296e40fe10?lnk=gst&q=tauren#492092296e40fe10 I had already found WicketJQuery at the time I tried out WiQuery. WiQuery seemed further along and was easier to add into my application, so I tried it first. But when it failed for me, I gave WicketJQuery a try. At the moment, WicketJQuery (now jWicket) certainly isn't perfect either, but it is closer to meeting my needs. So I offered my help to Stefan to get it mavenized and moved to WicketStuff. We renamed it to jWicket during this transition. This new location will make it more accessible and easier to use for other developers. Of course, I have nothing against joining forces, but I also needed something to solve a problem, and I needed it now. WiQuery wasn't doing it for me, and jWicket was. I also want a light weight tool, and I felt like WiQuery was overkill for my needs. If there is a way to join forces so that one tool can satisfy everyone without becoming some big bloated thing, then I'm all for it! Bottom line is I just want to be able to easily add jQuery code to the client side whenever and wherever I want without having to deal with server side code -- except for when I need client/server communication of jQuery events. Maybe I'm not normal in this regard, but the WiQuery API just doesn't do it for me. I'd rather code the client side in JS/jQuery and keep it out of my java code. Sorry for being long winded. Again, I have nothing against WiQuery, and was quite impressed by it. But it just didn't seem like the right tool for my needs. I'm certainly open to ideas on how to integrate the projects, but from what I can tell, they really have different visions. Tauren On Wed, Jul 22, 2009 at 11:15 AM, richardwilko wrote: Hi, What are the advantages of jWicket over other Wicket jQuery projects (specifically wiQuery)? It would be nice if we could all work together on a single project. wiQuery has already pooled the development resources of two other s
