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

[Design of POJO Server] - Re: @JMX aspect and aop/mc integration

by bstansberry＠jboss.com

Do we still want to do the AUTO/STRICT/NONE approach. I moved away from this to do AS 5 Beta1 stuff and forgot about this. It's simple enough to add AUTO/STRICT/NONE. Just need to decide how to handle the registerDirectly attribute since it's been around a while. 1) It has the same meaning as STRICT, so we can deprecate it and javadoc it as causing STRICT behavior if set to true and the annotation is configured for AUTO (the default). Otherwise it has no effect. This means usages that specified registerDirectly=true or didn't deploy a standard mbeanl get consistent behavior. The (probably nonexistent) cases of someone who deployed a valid standard mbean but wanted a proxy registered anyway will break. 2) Remove it and accept complaints about an API change between a beta and a CR. I'd say go with #1. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4061544#4061544 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4061544

18 years, 9 months

1
0
0 / 0

[Design of JBoss Remoting, Unified Invokers] - Re: Fully asynchronous invocation

by david.lloyd＠jboss.com

Expanding on this idea: there are two basic thread arrangements that affect asynchronous invocations. The first is the stereotypical server methodology: basically a Selector and a thread pool. A message coming across the wire is (typically) handled immediately. The second is the stereotypical client methodology: the client owns the connection, but there is no dedicated thread to handle asynchronous messages. The FutureReply model can work with both of these models with varying degrees of success. With the server model, it's easy - messages are always handled immediately. If there's a request completion notifier registered on the FutureReply, the callback can be called instantly. The client model is a little trickier, but still doable. Basically, any time a client thread makes a call into Remoting, the thread can be "borrowed" to do a bit of work, especially if it was just going to block anyway. This isn't a perfect solution, since if the user never calls into Remoting, they will never get their "asynchronous" notifications. Perhaps these potential limitations are outweighed by the benefit of not having to deal with a dedicated thread pool on the client. Alternatively, asynchronous calls could simply be disallowed if there's no thread available to monitor for replies. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4061525#4061525 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4061525

18 years, 9 months

1
0
0 / 0

[Design of JBoss Portal] - JBPORTAL-1541

by julien＠jboss.com

Chris I saw you fixed a bug, can you add a test case for it in the PortalObjectContainerTestCase ? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4061521#4061521 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4061521

18 years, 9 months

1
0
0 / 0

[Design of JBoss Portal] - Re: Initiall identity model discussion

by julien＠jboss.com

here are a few use case we need to answer for the groups: - notion of JavaEE security: the membership of a user for a group should imply a JavaEE role. - notion of business role: the membership of a user for a such group has a business semantic. - notion of community: the membership of a user for such group implies that he can share a specific business domain with users of the same community. - notion of common profile: the membership of a user for such a group will overwrite or provide default values for the user's profile - notion of preferences: the membership of a user for such a group will make him use a specific customization of a portlet (furthermore customizable or not) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4061519#4061519 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4061519

18 years, 9 months

1
0
0 / 0

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

by julien＠jboss.com

at the same type I don't like objects which have fields which are unused or have no meaning if a discriminant has some value, it makes debugging harder and the model harder to understand. we'll find the right balance. "chris.laprun(a)jboss.com" wrote : "sohil.shah(a)jboss.com" wrote : anonymous wrote : | | | There are also other valid points that makes me prefer a hierarchy over an objects that aggregates all: | | | | | | - easier to debug | | | - easier to categorize | | | - inheritance and polymorphism can be leveraged | | | | | | | These are actually valid points. | | | | I am more concerned about the hierarchy overload from the standpoint of what objects are used/exposed to the Controller layer as it integrates with the UI Server. | | | | Same here. I tend to prefer a generic object to handle as much as possible with only minimal sub-classes as required. As far as debugging goes, toString is our friend: as long as we have enough information in the object (and we should), we should be able to have a toString method that could be leveraged while debugging. | | I don't like huge hierarchy of weak objects (objects that don't do much, if anything at all, and we do have some objects like that)... They result in lots of classes with no obvious benefits. Inheritance and polymorphism works well for worker objects, not so much for data objects. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4061516#4061516 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4061516

18 years, 9 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: Tracking WF path of execution

by kukeltje

Bill, I assume with 'process definition instances' you mean an instance of a process definition, so a 'running' one, not the definition itself. If so can you elaborate a little more on this 'things like this' in relation to your remark about hibernate? I do not fully get what you mean by this. And when you are at it, I also do not grasp the 'instance-per-request for actions' View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4061509#4061509 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4061509

18 years, 9 months

1
0
0 / 0

[Design of JBoss Portal] - Re: Initiall identity model discussion

by chris.laprun＠jboss.com

I like the idea of group of roles. I think this could be modeled as roles implying some other roles. As far as security goes, finer-grained security would be good. For example, for the demo portal, it would be good to have an admin user that can only look at the admin data, not modify it. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4061471#4061471 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4061471

18 years, 9 months

1
0
0 / 0

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

by chris.laprun＠jboss.com

"sohil.shah(a)jboss.com" wrote : anonymous wrote : | | There are also other valid points that makes me prefer a hierarchy over an objects that aggregates all: | | | | - easier to debug | | - easier to categorize | | - inheritance and polymorphism can be leveraged | | | | These are actually valid points. | | I am more concerned about the hierarchy overload from the standpoint of what objects are used/exposed to the Controller layer as it integrates with the UI Server. | Same here. I tend to prefer a generic object to handle as much as possible with only minimal sub-classes as required. As far as debugging goes, toString is our friend: as long as we have enough information in the object (and we should), we should be able to have a toString method that could be leveraged while debugging. I don't like huge hierarchy of weak objects (objects that don't do much, if anything at all, and we do have some objects like that)... They result in lots of classes with no obvious benefits. Inheritance and polymorphism works well for worker objects, not so much for data objects. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4061470#4061470 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4061470

18 years, 9 months

1
0
0 / 0

[Design of JBoss internal QA (Test Suite)] - Re: JBossClusteredTestCase et al in standalone test module

by bstansberry＠jboss.com

Any news on getting these moved? Leaving these classes in the AS testsuite module is a barrier to getting EJB3 removed from the AS codebase (besides making working on EJB3 clustering a pain). I can add them to the test project myself, but I don't want to remove them from the AS/testsuite unless a new version of jboss-test.jar is available on both AS trunk and Branch_4_2. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4061462#4061462 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4061462

18 years, 9 months

1
0
0 / 0

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

by julien＠jboss.com

agreed for all points. about the model, we should modelize what we have today which is rather simple and trivial. We will think about updating it in the future. "sohil.shah(a)jboss.com" wrote : This is a good discussion thread...so far let me summarize the points that we are in agreement on for the UI Server architecture, to push the prototype further | | 1/ the ui server should have its own module that does not depend upon core or theme framework and introduce its own concepts | | 2/ testing it in core should be done using a core-uiserver module (temporary) that reuses core + uiserver module and produce a jboss-portal.sar that mixes both | | 3/ the protocol between the consumer and producer (let's call them like in WSRP) needs to be done really using a protocol modeled under the form of data objects (I am going to describe that in another post). | | 4/ in the core-uiserver part, the current core controller should be reused with with separate implementation of ResponseHandler that would adapt the current core controller command framework to the ui server protocol. | | 5/ 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. | | 6/ It could be an option, however I would prefer to separate protocol request state from protocol request meta data. On example is that the type of a request is a meta data and I want rather to use a design which use annotations. | | Point still open for discussion: | | Hierarchially how broad should the UIServer Object model be. | | 1/ Should it be slim | | 2/ Should it be an extensible hierarchy of Objects. | | IMO- I prefer an extensible hierarchy of Objects as long as this entire hierarchy is not exposed/exploited on the client side of things, making client side integration code quite complex and not so de-coupled | | What I am suggesting is a simple object based protocol between the Controller layer and the UI Server layer and an extensible hierarchy of UI Objects to be used internally by the UI Server | | Clarification: when I say client side in this case, I mean the Controller layer which is a consumer to the UIServer. | | View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4061402#4061402 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4061402

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