Wicket
  1. Wicket
  2. WICKET-1130

Injection of Bound Instance Fails with Exception

    Details

    • Type: Bug Bug
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Won't Fix
    • Affects Version/s: 1.3.0-beta4
    • Fix Version/s: None
    • Component/s: wicket-guice
    • Labels:
      None

      Description

      If I try to inject an explicitly bound instance into a component, injection fails with an exception in the creation of the CGLIB proxy:

      java.lang.IllegalArgumentException: Superclass has no null constructors but no arguments were given

      Stupidly, I forgot to save the whole stack trace and the code is now gone from my codebase (since I needed it to work). To repeat:

      @Override
      public void configure() {
      bind(EntityManager.class).toInstance(manager);
      }

      Seems wicket-guice is assuming that it needs to create a new instance of everything that's injected, and since EntityManager doesn't have a no-args constructor, such an action fails. Just an assumption anyway...

        Activity

        Hide
        Marek Šabo added a comment -

        This one gave me run for my money, anyway, I did suggested workaround with empty constructor but I had to set it to protected, package-private resulted in IllegalAccessException. Cheers.

        Show
        Marek Šabo added a comment - This one gave me run for my money, anyway, I did suggested workaround with empty constructor but I had to set it to protected, package-private resulted in IllegalAccessException. Cheers.
        Igor Vaynberg made changes -
        Status In Progress [ 3 ] Resolved [ 5 ]
        Assignee Igor Vaynberg [ ivaynberg ]
        Resolution Won't Fix [ 2 ]
        Hide
        Igor Vaynberg added a comment -

        no easy way to fix this.

        Show
        Igor Vaynberg added a comment - no easy way to fix this.
        Martin Grigorov made changes -
        Fix Version/s 1.5-M4 [ 12315483 ]
        Jeremy Thomerson made changes -
        Fix Version/s 1.5-M4 [ 12315483 ]
        Fix Version/s 1.5-M3 [ 12315329 ]
        Eelco Hillenius made changes -
        Attachment GuiceLazyInitProxyFactory.java [ 12451134 ]
        Hide
        Eelco Hillenius added a comment -

        Hmmmpfff, well, seems like there still can be issues with it, so scratch this. See http://stackoverflow.com/questions/1706751 for the problem. We probably need to rewrite gclib out of it in order to make this work.

        Show
        Eelco Hillenius added a comment - Hmmmpfff, well, seems like there still can be issues with it, so scratch this. See http://stackoverflow.com/questions/1706751 for the problem. We probably need to rewrite gclib out of it in order to make this work.
        Igor Vaynberg made changes -
        Fix Version/s 1.5-M3 [ 12315329 ]
        Fix Version/s 1.5-M2 [ 12315237 ]
        Hide
        Eelco Hillenius added a comment -

        @Casper there isn't really a meaningful way to include more as that's specific to my app.

        The meat of the trick is just this:

        	final Parameters parameters = new Parameters();
        	for (Constructor c : originalType.getConstructors()) {
        		if (c.getParameterTypes().length == 0) {
        			// ok, we're good, default constructor
        			break;
        		} else if (c.getAnnotations().length > 0) {
        			for (Annotation a : c.getAnnotations()) {
        				if (Inject.class.isAssignableFrom(a.getClass())) {
        					// ah, we have a guice injector
        					parameters.parameterTypes = c.getParameterTypes();
        				}
        			}
        		}
        	}
        	if (parameters.parameterTypes != null) {
        		Object[] dummyArgs = new Object[parameters.parameterTypes.length];
        		for (int i = 0; i < dummyArgs.length; i++) {
        			dummyArgs[i] = null;
        		}
        		parameters.dummyArgs = dummyArgs;
        	}
        

        in the else branch of createProxy (which is activated when the type is not a primitive or an interface) and then at the end of the method:

        	Object proxy = null;
        	if (parameters.parameterTypes == null) {
        		proxy = e.create();
        	} else {
        		proxy = e.create(parameters.parameterTypes,
        				parameters.dummyArgs);
        	}
        

        And then in between those blocks:

        	Enhancer e = new Enhancer() {
        		@Override
        		protected Object firstInstance(Class type) throws Exception {
        			Object instance = null;
        			Method setter = type.getDeclaredMethod(
        					"CGLIB$SET_THREAD_CALLBACKS",
        					new Class[] { Callback[].class });
        			setter.invoke(null,
        					new Object[] { new Callback[] { handler } });
        			try {
        
        				instance = GuiceComponentInjector.getInjector()
        						.getInstance(type);
        			} finally {
        				setter.invoke(null, new Object[] { null });
        			}
        			return instance;
        		}
        	};
        

        which overrides the default behavior of Enhancer by using a Guice Injector instance to get the 'first instance' rather than trying to construct it through regular Java reflection.

        If you'd dig deeper (again sorry I don't have the spare cycles myself), you could probably do this neater by writing a custom Enhancer rather than extending the current one; you may be able to get around doing the constructor arguments introspection to start with if you do that. For now, this code works but the main difficulty is where to get the Guice Injector instance from: LazyInitProxyFactory currently is independent of which DI framework is used, so it'll probably require a API break to get this done properly in Wicket.

        Show
        Eelco Hillenius added a comment - @Casper there isn't really a meaningful way to include more as that's specific to my app. The meat of the trick is just this: final Parameters parameters = new Parameters(); for (Constructor c : originalType.getConstructors()) { if (c.getParameterTypes().length == 0) { // ok, we're good, default constructor break ; } else if (c.getAnnotations().length > 0) { for (Annotation a : c.getAnnotations()) { if (Inject.class.isAssignableFrom(a.getClass())) { // ah, we have a guice injector parameters.parameterTypes = c.getParameterTypes(); } } } } if (parameters.parameterTypes != null ) { Object [] dummyArgs = new Object [parameters.parameterTypes.length]; for ( int i = 0; i < dummyArgs.length; i++) { dummyArgs[i] = null ; } parameters.dummyArgs = dummyArgs; } in the else branch of createProxy (which is activated when the type is not a primitive or an interface) and then at the end of the method: Object proxy = null ; if (parameters.parameterTypes == null ) { proxy = e.create(); } else { proxy = e.create(parameters.parameterTypes, parameters.dummyArgs); } And then in between those blocks: Enhancer e = new Enhancer() { @Override protected Object firstInstance( Class type) throws Exception { Object instance = null ; Method setter = type.getDeclaredMethod( "CGLIB$SET_THREAD_CALLBACKS" , new Class [] { Callback[].class }); setter.invoke( null , new Object [] { new Callback[] { handler } }); try { instance = GuiceComponentInjector.getInjector() .getInstance(type); } finally { setter.invoke( null , new Object [] { null }); } return instance; } }; which overrides the default behavior of Enhancer by using a Guice Injector instance to get the 'first instance' rather than trying to construct it through regular Java reflection. If you'd dig deeper (again sorry I don't have the spare cycles myself), you could probably do this neater by writing a custom Enhancer rather than extending the current one; you may be able to get around doing the constructor arguments introspection to start with if you do that. For now, this code works but the main difficulty is where to get the Guice Injector instance from: LazyInitProxyFactory currently is independent of which DI framework is used, so it'll probably require a API break to get this done properly in Wicket.
        Igor Vaynberg made changes -
        Fix Version/s 1.5-M1 [ 12313078 ]
        Fix Version/s 1.5-M2 [ 12315237 ]
        Hide
        Caspar MacRae added a comment -

        @Eelco would you please attach the rest of the source?

        I've only looked at this briefly, but am guessing you've had to refactor back from GuiceComponentInjector down to the underlying Inject interface to pass the type back.

        thanks.

        Show
        Caspar MacRae added a comment - @Eelco would you please attach the rest of the source? I've only looked at this briefly, but am guessing you've had to refactor back from GuiceComponentInjector down to the underlying Inject interface to pass the type back. thanks.
        Eelco Hillenius made changes -
        Assignee Alastair Maw [ almaw ]
        Eelco Hillenius made changes -
        Attachment GuiceLazyInitProxyFactory.java [ 12451134 ]
        Hide
        Eelco Hillenius added a comment -

        Amazing that this issue has been unresolved for such a long time: it isn't that hard to fix, and without the fix it makes Guice integration with Wicket really a whole lot less attractive. I never realized because while I've been using Guice for a while, I hadn't used it together with Wicket yet.

        Anyway, attached is a partial fix that I use for a system I work on. I've had this fix for a while, hoping I could find time to properly implement it for Wicket, but alas, I haven't found the time to do that just yet. So I'm attaching my fix and idea here so that if anyone else has a few spare cycles, at least the idea is there.

        The main change is the replacement of LazyInitProxyFactory so that:
        1) rather than constructing instances through reflection, ask the Guice injector to give an instance
        2) if there is a non-default constructor annotated with @Inject, use these parameters (and dummy values) for constructing the proxy

        Having looked at this issue, I also wonder if 1) shouldn't be done for Spring also.

        Looks to me like it can't be fixed without breaking at least some parts of the API, though it'll be internal for most users.

        Show
        Eelco Hillenius added a comment - Amazing that this issue has been unresolved for such a long time: it isn't that hard to fix, and without the fix it makes Guice integration with Wicket really a whole lot less attractive. I never realized because while I've been using Guice for a while, I hadn't used it together with Wicket yet. Anyway, attached is a partial fix that I use for a system I work on. I've had this fix for a while, hoping I could find time to properly implement it for Wicket, but alas, I haven't found the time to do that just yet. So I'm attaching my fix and idea here so that if anyone else has a few spare cycles, at least the idea is there. The main change is the replacement of LazyInitProxyFactory so that: 1) rather than constructing instances through reflection, ask the Guice injector to give an instance 2) if there is a non-default constructor annotated with @Inject, use these parameters (and dummy values) for constructing the proxy Having looked at this issue, I also wonder if 1) shouldn't be done for Spring also. Looks to me like it can't be fixed without breaking at least some parts of the API, though it'll be internal for most users.
        Hide
        Igor Vaynberg added a comment -

        hmm, i gues you were injecting a class, disregard my earlier comment.

        Show
        Igor Vaynberg added a comment - hmm, i gues you were injecting a class, disregard my earlier comment.
        Hide
        Igor Vaynberg added a comment -

        interesting because i thought you were injecting an interface.in which case a jdk proxy is used instead of the cglib one....

        Show
        Igor Vaynberg added a comment - interesting because i thought you were injecting an interface.in which case a jdk proxy is used instead of the cglib one....
        Hide
        Tuomas Karkkainen added a comment -

        Yes, adding the noarg constructor is a solution. Finding it, based on the error message thrown is some trouble, especially given it works when the injection is in an injected child. In our case its a third party class too, which adds some trouble for us.

        I agree the patch is lousy.

        Show
        Tuomas Karkkainen added a comment - Yes, adding the noarg constructor is a solution. Finding it, based on the error message thrown is some trouble, especially given it works when the injection is in an injected child. In our case its a third party class too, which adds some trouble for us. I agree the patch is lousy.
        Hide
        Igor Vaynberg added a comment -

        unfortunately this is a limitation of java/cglb. easiest thing to do is to add a package-private noarg constructor to the class. was this the underlying reason for your previous troubles?

        i cant say that i agree with your patch either, there may be other reasons why IllegalArgumentException is thrown from e.create() no?

        Show
        Igor Vaynberg added a comment - unfortunately this is a limitation of java/cglb. easiest thing to do is to add a package-private noarg constructor to the class. was this the underlying reason for your previous troubles? i cant say that i agree with your patch either, there may be other reasons why IllegalArgumentException is thrown from e.create() no?
        Hide
        Tuomas Karkkainen added a comment -

        injecting concrete classes without zero argument constructor into wicket components fails, even if the injection is properly configured.

        I have this:

        public ConcreteClass(String a, String b)

        { ... }

        bind(ConcreteClass.class).toInstance(new ConcreteClass("a","b"));

        if I have

        @Inject
        private ConcreteClass concreteClass

        in a wicket component it will not be injected but cglib will complain. If I have it instead in a secondary dependency guice will inject it fine, which is confusing. e.g.

        public class ConcreteClassHolder {
        @Inject
        private ConcreteClass concreteClass;
        public getConcreteClass()

        {...}

        }
        public class SomethingPanel extends Panel

        { @Inject private ConcreteClassHolder concreteClassHolder; }

        Instead of confusingly failing, with a "Superclass has no null constructors but no arguments were given", I would prefer wicket to atleast check for this condition in LazyInitProxyFactory:

        public static Object createProxy(final Class type, final IProxyTargetLocator locator)

        { ... return e.create(); }

        with maybe:

        try

        { return e.create(); }

        catch (final IllegalArgumentException iae)

        { throw new RuntimeException("Cannot proxy concrete class with no zero args constructor here, use an interface or see JIRA issue WICKET-1130."); }
        Show
        Tuomas Karkkainen added a comment - injecting concrete classes without zero argument constructor into wicket components fails, even if the injection is properly configured. I have this: public ConcreteClass(String a, String b) { ... } bind(ConcreteClass.class).toInstance(new ConcreteClass("a","b")); if I have @Inject private ConcreteClass concreteClass in a wicket component it will not be injected but cglib will complain. If I have it instead in a secondary dependency guice will inject it fine, which is confusing. e.g. public class ConcreteClassHolder { @Inject private ConcreteClass concreteClass; public getConcreteClass() {...} } public class SomethingPanel extends Panel { @Inject private ConcreteClassHolder concreteClassHolder; } Instead of confusingly failing, with a "Superclass has no null constructors but no arguments were given", I would prefer wicket to atleast check for this condition in LazyInitProxyFactory: public static Object createProxy(final Class type, final IProxyTargetLocator locator) { ... return e.create(); } with maybe: try { return e.create(); } catch (final IllegalArgumentException iae) { throw new RuntimeException("Cannot proxy concrete class with no zero args constructor here, use an interface or see JIRA issue WICKET-1130."); }
        Hide
        Igor Vaynberg added a comment -

        even though the api is public, if you add a package-private constructor no one will see it outside of the classes that live in the same package - which of course should only be your classes. so there is really no harm...but really you should consider making it an interface, i dont know if you thought about unit testing or not, but people will probably want to mock the entity manager and if it is an interface it will be that much easier.

        Show
        Igor Vaynberg added a comment - even though the api is public, if you add a package-private constructor no one will see it outside of the classes that live in the same package - which of course should only be your classes. so there is really no harm...but really you should consider making it an interface, i dont know if you thought about unit testing or not, but people will probably want to mock the entity manager and if it is an interface it will be that much easier.
        Hide
        Daniel Spiewak added a comment -

        Thought about that, but there's two problems. First, it's a public API, so even if it is my project I don't want to mess too much with it. More importantly though, the class actually needs those constructor parameters in order to do anything useful. I suppose though that cglib is actually creating a delegate proxy, so it would still work. I wonder if a possible workaround would be to derive a class from EntityManager which has a package-private default constructor, then bind to this instance. Would be a bit ugly though since every usage of EntityManager in code would have to be changed to use this internal deviant.

        Show
        Daniel Spiewak added a comment - Thought about that, but there's two problems. First, it's a public API, so even if it is my project I don't want to mess too much with it. More importantly though, the class actually needs those constructor parameters in order to do anything useful. I suppose though that cglib is actually creating a delegate proxy, so it would still work. I wonder if a possible workaround would be to derive a class from EntityManager which has a package-private default constructor, then bind to this instance. Would be a bit ugly though since every usage of EntityManager in code would have to be changed to use this internal deviant.
        Hide
        Igor Vaynberg added a comment -

        which is a shame, because if it was an interface it would work just fine what you can try is adding a package-level default constructor. that way cglib can create the subclass and no one outside your api will see it.

        Show
        Igor Vaynberg added a comment - which is a shame, because if it was an interface it would work just fine what you can try is adding a package-level default constructor. that way cglib can create the subclass and no one outside your api will see it.
        Hide
        Daniel Spiewak added a comment -

        Ok, I can happily wait. I figured it was going to be a bit of a sticky issue, but I was still hopeful.

        BTW, I'm not injecting an interface but an actual class. EntityManager is a class in ActiveObjects which shares the same name as the interface in JPA (they serve almost identical purposes).

        Show
        Daniel Spiewak added a comment - Ok, I can happily wait. I figured it was going to be a bit of a sticky issue, but I was still hopeful. BTW, I'm not injecting an interface but an actual class. EntityManager is a class in ActiveObjects which shares the same name as the interface in JPA (they serve almost identical purposes).
        Igor Vaynberg made changes -
        Fix Version/s 1.3.3 [ 12313047 ]
        Fix Version/s 1.5-M1 [ 12313078 ]
        Hide
        Igor Vaynberg added a comment -

        moving this to 1.5.

        basically when injecting instances of concrete classes we are limited by cglib which requires a default visible constructor and no final methods so that it can create a subclass for our proxy.

        once we switch to jdk5 we can require usage of annotations for injection and then we can remove the proxies and use hooks in page serialization to inject objects and hooks in deserialzation to make sure injected fields are skipped.

        Show
        Igor Vaynberg added a comment - moving this to 1.5. basically when injecting instances of concrete classes we are limited by cglib which requires a default visible constructor and no final methods so that it can create a subclass for our proxy. once we switch to jdk5 we can require usage of annotations for injection and then we can remove the proxies and use hooks in page serialization to inject objects and hooks in deserialzation to make sure injected fields are skipped.
        Hide
        Alastair Maw added a comment -

        So this sort of thing is a limitation in cglib. We need to proxy the class using an Enhancer, so that it can be serialized, and the class needs to have a zero-arg constructor in order for cglib to be able to do that.

        I don't understand why this is failing for you, as you should surely be injecting against an interface, in which case this should work just fine.

        I.e:
        bind(javax.persistence.EntityManager.class).toInstance(hibernateEntityManager) or whatever.

        So no, this probably isn't ever going to be fixed, as it's pretty much impossible to do so.

        There are two alternatives:

        • We inject the object, not a proxy. This will either cause serialization errors (in your case), or the session size to blow up. Neither sounds good.
        • We get clever about serializing/deserializing pages, and effectively do the "proxying" there. We'd probably need to require annotations for this - it's not going to make it in before 1.4.
        Show
        Alastair Maw added a comment - So this sort of thing is a limitation in cglib. We need to proxy the class using an Enhancer, so that it can be serialized, and the class needs to have a zero-arg constructor in order for cglib to be able to do that. I don't understand why this is failing for you, as you should surely be injecting against an interface, in which case this should work just fine. I.e: bind(javax.persistence.EntityManager.class).toInstance(hibernateEntityManager) or whatever. So no, this probably isn't ever going to be fixed, as it's pretty much impossible to do so. There are two alternatives: We inject the object, not a proxy. This will either cause serialization errors (in your case), or the session size to blow up. Neither sounds good. We get clever about serializing/deserializing pages, and effectively do the "proxying" there. We'd probably need to require annotations for this - it's not going to make it in before 1.4.
        Hide
        Alastair Maw added a comment -

        This is getting looked at right now. Will keep you posted.

        Show
        Alastair Maw added a comment - This is getting looked at right now. Will keep you posted.
        Alastair Maw made changes -
        Status Open [ 1 ] In Progress [ 3 ]
        Hide
        Igor Vaynberg added a comment -

        it will get looked at whenever Al has time or someone comes up with a patch. i think Al is the only one from the core team using guice so the rest of us have no idea what the problem is or how to fix it.

        Show
        Igor Vaynberg added a comment - it will get looked at whenever Al has time or someone comes up with a patch. i think Al is the only one from the core team using guice so the rest of us have no idea what the problem is or how to fix it.
        Frank Bille Jensen made changes -
        Fix Version/s 1.3.2 [ 12312942 ]
        Fix Version/s 1.3.3 [ 12313047 ]
        Frank Bille Jensen made changes -
        Fix Version/s 1.3.1 [ 12312500 ]
        Fix Version/s 1.3.2 [ 12312942 ]
        Hide
        Chris Davies added a comment -

        Reproduced the behaviour by creating a simple singleton (SomeSingleton) and tried to @Inject it into a page after binding the same way as described. Root cause stack trace is:

        java.lang.IllegalArgumentException: No visible constructors in class foo.SomeSingleton
        at net.sf.cglib.proxy.Enhancer.filterConstructors(Enhancer.java:531)
        at net.sf.cglib.proxy.Enhancer.generateClass(Enhancer.java:448)
        at net.sf.cglib.core.DefaultGeneratorStrategy.generate(DefaultGeneratorStrategy.java:25)
        at net.sf.cglib.core.AbstractClassGenerator.create(AbstractClassGenerator.java:216)
        at net.sf.cglib.proxy.Enhancer.createHelper(Enhancer.java:377)
        at net.sf.cglib.proxy.Enhancer.create(Enhancer.java:285)
        at org.apache.wicket.proxy.LazyInitProxyFactory.createProxy(LazyInitProxyFactory.java:164)
        at org.apache.wicket.guice.GuiceComponentInjector.inject(GuiceComponentInjector.java:112)
        at org.apache.wicket.guice.GuiceComponentInjector.onInstantiation(GuiceComponentInjector.java:193)
        at org.apache.wicket.Application.notifyComponentInstantiationListeners(Application.java:973)
        at org.apache.wicket.Component.<init>(Component.java:865)
        at org.apache.wicket.MarkupContainer.<init>(MarkupContainer.java:104)
        at org.apache.wicket.Page.<init>(Page.java:230)
        at org.apache.wicket.markup.html.WebPage.<init>(WebPage.java:185)
        at foo.TestPage.<init>(TestPage.java:20)
        at java.lang.reflect.Constructor.newInstance(Constructor.java:513)
        at java.lang.Class.newInstance0(Class.java:355)
        at java.lang.Class.newInstance(Class.java:308)
        at org.apache.wicket.session.DefaultPageFactory.newPage(DefaultPageFactory.java:58)
        at org.apache.wicket.request.target.component.BookmarkablePageRequestTarget.newPage(BookmarkablePageRequestTarget.java:262)
        at org.apache.wicket.request.target.component.BookmarkablePageRequestTarget.getPage(BookmarkablePageRequestTarget.java:283)
        at org.apache.wicket.request.target.component.BookmarkablePageRequestTarget.processEvents(BookmarkablePageRequestTarget.java:210)
        at org.apache.wicket.request.AbstractRequestCycleProcessor.processEvents(AbstractRequestCycleProcessor.java:90)
        at org.apache.wicket.RequestCycle.processEventsAndRespond(RequestCycle.java:1094)
        at org.apache.wicket.RequestCycle.step(RequestCycle.java:1169)
        at org.apache.wicket.RequestCycle.steps(RequestCycle.java:1248)
        at org.apache.wicket.RequestCycle.request(RequestCycle.java:489)
        at org.apache.wicket.protocol.http.WicketFilter.doGet(WicketFilter.java:343)
        at org.apache.wicket.protocol.http.WicketFilter.doFilter(WicketFilter.java:193)
        at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1084)
        at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:360)
        at org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:216)
        at org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:181)
        at org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:712)
        at org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:405)
        at org.mortbay.jetty.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:211)
        at org.mortbay.jetty.handler.HandlerCollection.handle(HandlerCollection.java:114)
        at org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:139)
        at org.mortbay.jetty.Server.handle(Server.java:313)
        at org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:506)
        at org.mortbay.jetty.HttpConnection$RequestHandler.headerComplete(HttpConnection.java:830)
        at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:514)
        at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:211)
        at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:381)
        at org.mortbay.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java:396)
        at org.mortbay.thread.BoundedThreadPool$PoolThread.run(BoundedThreadPool.java:442)

        Show
        Chris Davies added a comment - Reproduced the behaviour by creating a simple singleton (SomeSingleton) and tried to @Inject it into a page after binding the same way as described. Root cause stack trace is: java.lang.IllegalArgumentException: No visible constructors in class foo.SomeSingleton at net.sf.cglib.proxy.Enhancer.filterConstructors(Enhancer.java:531) at net.sf.cglib.proxy.Enhancer.generateClass(Enhancer.java:448) at net.sf.cglib.core.DefaultGeneratorStrategy.generate(DefaultGeneratorStrategy.java:25) at net.sf.cglib.core.AbstractClassGenerator.create(AbstractClassGenerator.java:216) at net.sf.cglib.proxy.Enhancer.createHelper(Enhancer.java:377) at net.sf.cglib.proxy.Enhancer.create(Enhancer.java:285) at org.apache.wicket.proxy.LazyInitProxyFactory.createProxy(LazyInitProxyFactory.java:164) at org.apache.wicket.guice.GuiceComponentInjector.inject(GuiceComponentInjector.java:112) at org.apache.wicket.guice.GuiceComponentInjector.onInstantiation(GuiceComponentInjector.java:193) at org.apache.wicket.Application.notifyComponentInstantiationListeners(Application.java:973) at org.apache.wicket.Component.<init>(Component.java:865) at org.apache.wicket.MarkupContainer.<init>(MarkupContainer.java:104) at org.apache.wicket.Page.<init>(Page.java:230) at org.apache.wicket.markup.html.WebPage.<init>(WebPage.java:185) at foo.TestPage.<init>(TestPage.java:20) at java.lang.reflect.Constructor.newInstance(Constructor.java:513) at java.lang.Class.newInstance0(Class.java:355) at java.lang.Class.newInstance(Class.java:308) at org.apache.wicket.session.DefaultPageFactory.newPage(DefaultPageFactory.java:58) at org.apache.wicket.request.target.component.BookmarkablePageRequestTarget.newPage(BookmarkablePageRequestTarget.java:262) at org.apache.wicket.request.target.component.BookmarkablePageRequestTarget.getPage(BookmarkablePageRequestTarget.java:283) at org.apache.wicket.request.target.component.BookmarkablePageRequestTarget.processEvents(BookmarkablePageRequestTarget.java:210) at org.apache.wicket.request.AbstractRequestCycleProcessor.processEvents(AbstractRequestCycleProcessor.java:90) at org.apache.wicket.RequestCycle.processEventsAndRespond(RequestCycle.java:1094) at org.apache.wicket.RequestCycle.step(RequestCycle.java:1169) at org.apache.wicket.RequestCycle.steps(RequestCycle.java:1248) at org.apache.wicket.RequestCycle.request(RequestCycle.java:489) at org.apache.wicket.protocol.http.WicketFilter.doGet(WicketFilter.java:343) at org.apache.wicket.protocol.http.WicketFilter.doFilter(WicketFilter.java:193) at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1084) at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:360) at org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:216) at org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:181) at org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:712) at org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:405) at org.mortbay.jetty.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:211) at org.mortbay.jetty.handler.HandlerCollection.handle(HandlerCollection.java:114) at org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:139) at org.mortbay.jetty.Server.handle(Server.java:313) at org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:506) at org.mortbay.jetty.HttpConnection$RequestHandler.headerComplete(HttpConnection.java:830) at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:514) at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:211) at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:381) at org.mortbay.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java:396) at org.mortbay.thread.BoundedThreadPool$PoolThread.run(BoundedThreadPool.java:442)
        Frank Bille Jensen made changes -
        Fix Version/s 1.3.1 [ 12312500 ]
        Fix Version/s 1.3.0-rc3 [ 12312886 ]
        Frank Bille Jensen made changes -
        Fix Version/s 1.3.0-rc2 [ 12312513 ]
        Fix Version/s 1.3.0-rc3 [ 12312886 ]
        Johan Compagner made changes -
        Field Original Value New Value
        Assignee Alastair Maw [ almaw ]
        Fix Version/s 1.3.0-rc2 [ 12312513 ]
        Daniel Spiewak created issue -

          People

          • Assignee:
            Igor Vaynberg
            Reporter:
            Daniel Spiewak
          • Votes:
            2 Vote for this issue
            Watchers:
            9 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development