Re: Wicket + Guice + Transactional

2014-03-02 Thread uwe schaefer


On 02.03.2014 14:51, Bill Speirs wrote:

field in the object. However it ONLY does this when I mark the methods as
@Transactional
yes, guice creates a proxy if it needs to (and it needs to if it needs 
to intercept the method call due to @Transactional).
the point is here, try wrapping a wicket proxy around (or make the 
wicket-injector do the injection rather than guice itself), and your 
serialization problems are gone.


cu uwe

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



UnsupportedCharsetException

2014-01-06 Thread Uwe Schaefer
Hi Wicketeers,

crawling our logs, we found the above exception as a result of a weird
request that set the following headers on a GET request:

Content-Type: text/html; charset=auto

I don't know which UserAgent sent that, but it happened and brought the
following exception on tomcat 6.0.37:

java.nio.charset.UnsupportedCharsetException: auto
at java.nio.charset.Charset.forName(Charset.java:543)
at
org.apache.wicket.protocol.http.RequestUtils.getCharset(RequestUtils.java:195)
at
org.apache.wicket.protocol.http.servlet.ServletWebRequest.getCharset(ServletWebRequest.java:476)
at
org.apache.wicket.protocol.http.servlet.ServletWebRequest.getContextRelativeUrl(ServletWebRequest.java:209)
at
org.apache.wicket.protocol.http.servlet.ServletWebRequest.init(ServletWebRequest.java:113)
at
org.apache.wicket.protocol.http.servlet.ServletWebRequest.init(ServletWebRequest.java:83)
at
org.apache.wicket.protocol.http.WebApplication.newWebRequest(WebApplication.java:448)
at
org.apache.wicket.protocol.http.WebApplication.createWebRequest(WebApplication.java:493)
at
org.apache.wicket.protocol.http.WicketFilter.processRequest(WicketFilter.java:196)
at
org.apache.wicket.protocol.http.WicketFilter.doFilter(WicketFilter.java:282)

even though we are not aware of the semantics of the above header, it
can happen.

to work around we extended a ServletWebRequest to add
public Charset getCharset() {
try {
return super.getCharset();
} catch (UnsupportedCharsetException ignore) {
return getDefaultCharset();
}
}

Now we are wondering, if RequestUtils:
public static Charset getCharset(HttpServletRequest request)
{
Charset charset = null;
if (request != null)
{
String charsetName = request.getCharacterEncoding();
if (charsetName != null)
{
charset = Charset.forName(charsetName);
}
}
if (charset == null)
{
charset = getDefaultCharset();
}
return charset;
}

should be more resilient to weird charsetNames coming from the container
(like 'auto' in our example) and return the default charset or a better
Exception that by default is mapped to HTTP StatusCode 406 ?

Should we create an issue for that?

cu uwe

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



Re: unwanted DefaultPageManagerProvider

2013-10-25 Thread uwe schaefer

On 10/25/2013 09:39 AM, Sven Meier wrote:

Hi Sven,


I think we have to improve Application#setPageMangerProvider():
 public synchronized final void setPageManagerProvider(final
IPageManagerProvider provider)
WDYT?


better, but to my understanding, not quite there yet.

while that helps cleanly shutting down the unwanted (default) 
PageManagerProvider, imho, we should make sure, that the user has the 
chance to register his PageManagerProvider, before the get-call is being 
issued.


in our case, with the above fix, we still have a call originating from 
sessionUnbound, that tries to work with the default PMP, which then 
complains about the file/directory he thinks is associated to the 
session being unbound, does not exist. (because, we dont use the 
DiskPageManager, duh :) )


how about registering to the container AFTER wicket init() has been 
executed, so that the application has had the chance to swap the default 
PMP for some other before it is called first?


for a quick workaround we introduced an application state flag being 
flipped from INITIALIZING to RUNNING at the end of init() and just 
return from sessionUnbound unless this flag is RUNNING.


not quite as elegant - in other words hacky - but works for now.

cu uwe

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



Re: unwanted DefaultPageManagerProvider

2013-10-24 Thread uwe schaefer

On 22.10.2013 10:22, Sven Meier wrote:

Hi Sven,


currently there's no way to change the PageManager once it's fetched in
Application#internalGetPageManager().


agreed.


Do you have a stacktrace for the code triggering
Application.getPageManagerProvider().get() ? Besides devutils I don't
see any call to this from Wicket.


it is the sessionUnbound method that supposedly was triggered by the 
container doing its clustering while wicket still initializes;


Application:478
public void sessionUnbound(final String sessionId){
  internalGetPageManager().sessionExpired(sessionId);
  ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^
}

cu uwe

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



Re: unwanted DefaultPageManagerProvider

2013-10-21 Thread uwe schaefer

On 10/21/2013 09:07 AM, Martin Grigorov wrote:

Hi Martin,


I hope the ticket will describe better what and the damage is done
actually means.


sorry if i was unclear. looks like i got lost in the details.

the actual damage is: there is a Thread started and associated with a
AsynchronousDataStore, which is not used and superseeded during init() 
with the HttpSession-based DataStore to be actually used.


There is no obvious way to get a reference to that thread, so that it 
cannot be stopped on destruction of the application - thus redeployment 
gets problematic.


cu uwe

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



Re: unwanted DefaultPageManagerProvider

2013-10-18 Thread uwe schaefer

On 18.10.2013 09:03, Martin Grigorov wrote:

Hi Martin,


Can you give more details about the setup and the problem ?


of course. we use two Tomcat6 with clustering enabled (Backup-Manager) 
with apache in front using sticky sessions.


when redeploying, we restart tomcat.

Now when one tomcat is restarted and the wicket initializes, there is a 
time-window in which wicket is not yet fully initialized (and our 
DataStore is not yet set), yet the application is already bound as an 
UnbindingListener.


This is where we see sessionUnbound being called, which as i mentioned, 
causes a default datastore (disk) being wrapped in an AsyncDatastore and 
the damage is done:


Application:478
public void sessionUnbound(final String sessionId){
  internalGetPageManager().sessionExpired(sessionId);
}

Application:1387
pageManager = pageManagerProvider.get(getPageManagerContext());

DefaultPageManagerProvider:58
if (dataStore.canBeAsynchronous())
{
  int capacity = storeSettings.getAsynchronousQueueCapacity();
  dataStore = new AsynchronousDataStore(dataStore, capacity);
}

and then AsynchronousDataStore:97
pageSavingThread.start();

what other info in particular are you looking for?
i could create a quickstart and attach it to a jira issue.

cu uwe

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



Re: unwanted DefaultPageManagerProvider

2013-10-17 Thread uwe schaefer

On 14.10.2013 21:41, uwe schaefer wrote:


 could it also be a
racecondition with clustering and

public void sessionUnbound(final String sessionId)

being called before init() returns?


after further investigation it is pretty clear, that the above race 
condition happens (at least on tomcat6) - so if noone objects, i would 
hop to jira and create an issue for that.


our quick workaround includes ignoring all 
WebApplicatoin.sessionUnbound(String) calls until initialization is 
complete.


cu uwe


-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



unwanted DefaultPageManagerProvider

2013-10-14 Thread uwe schaefer

Hi

we seem to face a little problem here with wicket 6.11:

Application.class:708

setPageManagerProvider(new DefaultPageManagerProvider(this));

sets the default provider here. Lateron [during init()] we replace this 
one by using the snippet from HttpSessionDataStore's javadocs:


setPageManagerProvider(new DefaultPageManagerProvider() {
 protected IDataStore newDataStore() {
  return  new HttpSessionDataStore(
   pageManagerContext, new PageNumberEvictionStrategy(20));
 }
}

for clustering.

Now the problem is, if anyone (in between) is able to call 
getPageManagerProvider().get() on the application, this would (and does) 
create a dangeling pageSavingThread by wrapping the unwanted 
defaultProvider into an AsynchronousDataStore.


... bad thing.

We seem to have this situation, where an Initializer is calling the 
above code.


Now for the question: what is the suggested way to register a 
PageManagerProvider BEFORE anyone asks for it?


cu uwe

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



Re: unwanted DefaultPageManagerProvider

2013-10-14 Thread uwe schaefer

On 14.10.2013 21:10, uwe schaefer wrote:


Now for the question: what is the suggested way to register a
PageManagerProvider BEFORE anyone asks for it?


PS: rather than an initializer being the culprit, could it also be a 
racecondition with clustering and


public void sessionUnbound(final String sessionId)

being called before init() returns?

cu uwe

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



Re: DI Through Constructors w/Wicket

2013-07-01 Thread uwe schaefer

On 06/29/2013 03:13 PM, William Speirs wrote:


I'm strongly leaning towards the best practice of: If you're having to
create an injector in your unit test, then you're doing it wrong.


maybe it makes it worse in your perspective, but yuo might want to have 
a look at jukito.


https://code.google.com/p/jukito/

at least it makes it easy to combine mockitoguice

cu uwe

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



Re: clustering and failover

2013-06-30 Thread uwe schaefer

On 06/29/2013 03:49 PM, William Speirs wrote:

Another consideration is if you're using any authentication
Been there, still have the bite marks from that :-)


*g* thanks Bill, i planned to do session clustering, but have the 
pagemap seperate, so that i hopefully would not run into this.


cu uwe


-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



Re: DI Through Constructors w/Wicket

2013-06-30 Thread uwe schaefer

On 06/29/2013 03:13 PM, William Speirs wrote:


Hi Bill,

I'm strongly leaning towards the best practice of: If you're having to
create an injector in your unit test, then you're doing it wrong.


me too. well, normally.
i came to the idea, that UI-Tests are not stricly unit-tests in most of 
the cases anyway, so i'd consinder this rule to be in the depends-area.


anyway, what you could do is to have constructor-injection for your 
tests while using the guice-provided at runtime. on the other hand,

you certainly dont want have this in your code everywhere:

new LinkVoid(link,someServiceInstance){...}

as this makes you code hard to change.
if you'd test the Link in isolation that'd be perfect, but given this 
link is in a panel, in a panel, in a panel, in a panel of your page, 
dependency passing becomes ridiculous...



Am I totally wrong here? Am I missing something? I'd love people's
feedback on this!


stomach feeling: i am with you avoiding guice in unit tests. for 
wicket-tests it is hard, and pollutes the production code more than it 
helps, imho.


cu uwe

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



Re: clustering and failover

2013-06-28 Thread uwe schaefer

On 06/28/2013 09:19 AM, Martin Grigorov wrote:

Hi Martin,

i already saw and consider your memcached-based session management, thanks.
the reason i ask the wicket mailing list is, that i assume that wicket 
only needs part of the pagemap (namely the current page) to serve a 
request, so that - hopefully - the data needed to serve a single request 
can be smaller if the pagemap is kept seperate from the session.


is this assumption correct?

cu uwe


I think you should ask this question in Tomcat mailing list.
Also check https://code.google.com/p/memcached-session-manager/


On Fri, Jun 28, 2013 at 8:46 AM, Uwe Schäfer u...@codesmell.de wrote:


hi

quick question about clustering: am i right to believe that putting
session/pagemap data in a memcached-like storage has advantages over the
tomcat session clustering in terms of latency and robust failover behaviour?
i mean, the latter obviously has the data nearby (when assuming sticky
sessions) whereas the first needs to grab it from (and push it to) external
storage every time even though it is far more selective about what it needs.

i was wondering if tomcat session clustering can effectivly update only
the dirty parts of the session data?

i'd love any kind of feedback on that topic INCLUDING 'depends'-answers :)

cu uwe

--**--**-
To unsubscribe, e-mail: 
users-unsubscribe@wicket.**apache.orgusers-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



wicketstuff-core:jquery accordion broken

2009-04-13 Thread uwe schaefer

hi

currently the accordion in jquery-examples does not work in FF or IE.

jQuery.filter(expr, [i]).r is undefined
http://localhost:8080/resources/org.wicketstuff.jquery.accordion.JQAccordion/jquery.accordion.pack.js
Line: 1

is this known, or should i try diggin in?

about jquery anyway: i recognized that the jquery project in wstuff-core 
does not use the jslib project to define its dependency to the jquery 
lib. is this intended, or could/should it be changed? using 
wstuff-core/jslib would make it possible to combine components built on 
top of jquery from different projects without suffering.


cu uwe


-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org