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