Mmmm, I wondering if Weld events are a good match for this kind of task...

Maybe by doing something like:

@RequestScoped
class HomePageController{

def load(@Observes @Page{val name="/home.jsp"} PageContext page){
  // Here I could do things like page.getHttpRequest();
}
}

Of course, now the question is how to trigger the event from the Filter.doFilter, because Filters are not (currently) manageable by Weld

Gavin King wrote on Nov 16, 2009 00:55:


Weld: Give me all the java.lang.Class with annotation XXX. Is there a way to ask Weld for that?

And... would you recommend that... or the event approach?

Gavin King wrote on Nov 16, 2009 01:06:

Francisco Peredo wrote on Nov 16, 2009 00:58:

Gavin King wrote on Nov 16, 2009 00:55:


Weld: Give me all the java.lang.Class with annotation XXX. Is there a way to ask Weld for that?

And... would you recommend that... or the event approach?

What are you trying to achieve here, Francisco? Hack up something quickly that works, or are you trying to build a web framework?

Well, first, hack up something quickly that works ;-). Maybe something you guys are willing to include as an official Weld example of Weld/JSP/Scala integration... and of course, after that I would love to see it become a framework.

If you're trying to build a framework, then that counts as a portable extension, and we have a specific SPI for doing portable extensions - which is much more powerful and flexible and gets you access to much more of the guts of the objects you are working with. But it is also going to take a bit more code and a bit more testing and tweaking to get it all working right.

Sounds interesting... where do I download that?

Gavin King wrote on Nov 16, 2009 01:02:


In a Java EE environment, servlet filters can inject beans (including Event), as required by the CDI spec. They are defined as a Java EE component class supporting injection. Not sure what restrictions exist in the case of our Tomcat integration. Do you know that it doesn't work, are are you just assuming? Did you try it?

No... did not try it... going to try... but I am suspect that it might not work because I did not copy weld-tomcat-support.jar in to Tomcat lib (I had it at WEB-INF\lib but it was silly to have it there, that is not its place, so I deleted it). I just don't like to have to add anything to non-classpathhell-free app servers... (sadly I am not such a fan of Geronimo either, and AFAIK JbossAs still has nothing to deal with that problem).

Well, in case it is not currently supported, get the BeanManager from JNDI and call BeanManager.fireEvent().

Thanks!

Gavin King wrote on Nov 16, 2009 02:49:


You don't have to download anything, it's part of CDI. All CDI implementations have to provide this. You already have it, as part of Weld.

Thanks again! Any step by step tutorials ;-) ?

I decided to go for the event approach... implemented it... but now I am getting:

javax.enterprise.inject.UnproxyableResolutionException: Normal scoped bean org.jboss.weld.bean-flat-ManagedBean-class org.jboss.weld.examples.numberguess.Game is not proxyable
     at org.jboss.weld.Validator.validateBean(Validator.java:85)
     at org.jboss.weld.Validator.validateRIBean(Validator.java:100)
     at org.jboss.weld.Validator.validateBeans(Validator.java:282)
     at org.jboss.weld.Validator.validateDeployment(Validator.java:268)
     at org.jboss.weld.bootstrap.WeldBootstrap.validateBeans(WeldBootstrap.java:389)
     at org.jboss.weld.environment.servlet.Listener.contextInitialized(Listener.java:158)
     at org.apache.catalina.core.StandardContext.listenerStart(StandardContext.java:3843)
     at org.apache.catalina.core.StandardContext.start(StandardContext.java:4342)
     at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1045)
     at org.apache.catalina.core.StandardHost.start(StandardHost.java:719)
     at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1045)
     at org.apache.catalina.core.StandardEngine.start(StandardEngine.java:443)
     at org.apache.catalina.core.StandardService.start(StandardService.java:516)
     at org.apache.catalina.core.StandardServer.start(StandardServer.java:710)
     at org.apache.catalina.startup.Catalina.start(Catalina.java:578)
     at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
     at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
     at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
     at java.lang.reflect.Method.invoke(Method.java:597)
     at org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:288)
     at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:413)

Searched the word proxyable in weld-reference.pdf, but could not find it...

All I added to Game.scala was:

def load(@Observes @Page{val name="/home.jsp"} pageContext:PageContext ){
    var attributeNames =Collections.list(pageContext.request.getAttributeNames());   
    for (attributeName <- Conversions.convertList(attributeNames))
        logger.info(attributeName.asInstanceOf[String]);
  }

Grrrrr... (Damned Whole words only search in Acrobat Reader) The word the word proxyable is not there, but the word unproxyable is :-P

May I suggest changing the error message to:

Normal scoped bean is {} unproxyable

You know, to make it easier for newbies... ;-)

Turns out that Scala, when having code like this:

def load(@Observes @Page{val name="/home.jsp"} pageContext:PageContext ){
    var attributeNames =Collections.list(pageContext.request.getAttributeNames());   
    for (attributeName <- Conversions.convertList(attributeNames))
        logger.info(attributeName.asInstanceOf[String]);
  }

internally generates a final method for logger because for is a Comprehension(and that makes the class unproxyable), happily I found a workaround:

def load(@Observes @Page{val name="/home.jsp"} pageContext:PageContext ){
    var attributeNames =Collections.list(pageContext.request.getAttributeNames()); 
    var currentLogger:Logger=logger;
    for (attributeName <- Conversions.convertList(attributeNames))      
        currentLogger.info(attributeName.asInstanceOf[String]);
  }

I wonder why the Scala compiler does not do that, instead of generating a final method