[Design of JBoss Portal] - Re: myFacesExstensionsFilter exception
by k3nnymusic
I am tryied to configure MyFaces in 4.2 version from wiki topic, but i dont have lines:
| ......
| <listener>
| <listener-class>org.jboss.web.jsf.integration.config.JBossJSFConfigureListener</listener-class>
| </listener>
| -->
| <!-- Comment/Remove this -->
| <!-- Listens to all web app lifecycle events so that @PreDestroy can be called on -->
| <!-- JSF managed beans that go out of scope. You can comment this out if you -->
| <!-- don't use JSF or you don't use annotations on your managed beans. -->
| <!--
| <listener>
| <listener-class>com.sun.faces.application.WebappLifecycleListener</listener-class>
| </listener>
| .....
but only:
<!-- ================== Common Listener Configuration ==================== -->
| <!--<listener>
| <listener-class>org.jboss.web.tomcat.security.SecurityFlushSessionListener</listener-class>
| </listener> --> in my D:\jboss-portal-2.6\server\default\deploy\jbossweb-tomcat55.sar\conf\web.xml file.
A change it to
<listener>
| <listener-class>org.apache.myfaces.webapp.StartupServletContextListener</listener-class>
| </listener> and add libs, and I have still the same problem.
Any sugestions?
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4061240#4061240
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4061240
18 years, 9 months
[Design of JBossCache] - JBossCache 2.1.0 - AOP framework
by manik.surtani@jboss.com
The current (1.4.x and 2.0.0) versions of JBoss Cache used hand-wired interceptor chains to apply aspects to the underlying data structure. E.g., a put() call on the cache would:
1) Use a Method representing an internal equivalent of put(), and pass this along with parameters (wrapped in a MethodCall object) up an interceptor chain.
2) The interceptor chain would apply an aspect to the call and pass the call up.
3) The final interceptor would use reflection and invoke the MethodCall on the cache again.
I think there is good cause to replace this with a more sophisticated AOP framework:
1) Writing/maintaining our own interceptor handling code is unnecessary and boiler-plate
2) An AOP fwk would mean that the interceptors can be applied to other objects as well, not just Cache (e.g., Node)
3) We can do away with the myriad of public "internal" method counterparts to public API methods on the cache - as these are otherwise open to misuse.
4) Allow for end users to add their own aspects (*)
(*) This may not be a good thing.
The criteria I need to think about when picking an AOP framework are:
1) Efficiency - our use case of the fwk is not a complex one. The fwk should be able to handle this very efficiently.
2) Bloat - footprint should be small and not bring in (too big) a chain of dependencies.
3) Readability/maintainability/debuggability - this is part of the reason I want to move away from the current design in the first place.
I haven't spent a whole lot of time evaluating frameworks yet, and hence this thread to discuss the pros and cons of various frameworks/approaches out there - including the "don't change the current setup" approach.
Cheers,
Manik
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4061238#4061238
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4061238
18 years, 9 months
[Design of JBoss Portal] - Re: Initial UI Server Prototype Discussion
by julien@jboss.com
The consumer and producer exchange data using a protocol, which simply means that the consumer makes a request, the producer perform something and returns back a response that the consumer should handle.
The protocol needs to be modelled under the form of a hierarchy of serializable objects.
public abstract class UIRequest implements Serializable { }
public abstract class UIResponse implements Serializable { }
Now the hardest part is to modelize the protocol such as it can handle our use cases.
The following in based on the concepts today that exist in the core of portal and are just an example, it's probably going to change:
// Obtain a page from the producer
| public class GetUIElement extends UIRequest {
| private String elementId;
| ...
| }
// Process an opaque URL
| public class ProcessURL extends UIRequest {
| private String url;
| ...
| }
// Move a window
| public class MoveWindow extends UIRequest {
| ...
| }
// Remove a window
| public class RemoveWindow extends UIRequest {
| ...
| }
etc....
The kind of responses are
public class GetUIElementResponse extends UIResponse {
| // Contains the elements necessary for the consumer to build the element on screen
| }
public class RedirectLocationResponse extends UIResponse {
| // The producer wants the consumer to show an URL
| // Translates into send redirect in the classic
| // Translates into document.location = location in the ajax
| private String location;
| ...
| }
etc...
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4061214#4061214
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4061214
18 years, 9 months