July 2007 - jboss-dev-forums - Jboss List Archives

[Design of JBoss Portal] - Initiall identity model discussion

by bdaw

I want to add a place to discuss the future of identity model. * The concept of communities/groups There were many requests to have a notion of 'group of roles' in portal. Basically it means additional entity that group current portal roles. Also there is a wider concept of community in portal which involves common portal resources (portals, pages, wikis, forums etc.). * Evolution of the API API needs to cover such concepts better. Some ideas (to just give a direction) - http://docs.jboss.com/jbpm/v3/userguide/taskmanagement.html#theidentitymodel Both things may (or may not) also touch current security model. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4061245#4061245 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4061245

18 years, 9 months

1
0
0 / 0

[Design of JBossCache] - Re: JBossCache 2.1.0 - AOP framework

by julien＠jboss.com

You want also to be sure that JBoss AOP offers a public API that will not change over time. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4061242#4061242 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4061242

18 years, 9 months

1
0
0 / 0

[Design of JBoss Portal] - Re: myFacesExstensionsFilter exception

by k3nnymusic

I don't have lines from wiki in any .xml files View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4061241#4061241 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4061241

18 years, 9 months

1
0
0 / 0

[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> | --> |  |  |  |  |  |  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

1
0
0 / 0

[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

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: Precedence

by alesj

I've re-written sorting. I'm using simple transitive closure. It sorts a lot better. :-) The issue I'm having is with DeployerFlowUnitTestCase.testInputOutputMultipleTransient(); Should we make this work? Since in my opinion this _is_ a loop. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4061233#4061233 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4061233

18 years, 9 months

1
0
0 / 0

[Design of JBoss Portal] - Re: Initial UI Server Prototype Discussion

by julien＠jboss.com

Request context, it is pretty much like ServerInvocationContext today (would probably change in the future). View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4061217#4061217 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4061217

18 years, 9 months

1
0
0 / 0

[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

1
0
0 / 0

[Design of JBoss Portal] - Object model

by julien＠jboss.com

The object model is serializable and modelize the concepts that the ui server operates on. Nothing much to say for now. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4061212#4061212 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4061212

18 years, 9 months

1
0
0 / 0

[Design of JBoss Portal] - Paradigm 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 operates on an object model that is defined by the module. The object model must be serializable. The consumer provides a request context that is the service contract between the consumer implementation and the producer implementation. Pretty much like the PortletInvocationContext. Eveything that the producer needs from the consumer (callbacks) should be on the request context. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4061211#4061211 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4061211

18 years, 9 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-dev-forums July 2007