[JBoss AS Development] - Re: Naming over Remoting 3
by david.lloyd＠jboss.com
"ron.sigal(a)jboss.com" wrote : "bstansberry(a)jboss.com" wrote :
| | Are we finally going to get rid of JRMPInvoker in AS 6?
| |
|
| For that matter, what about the rest of the org.jboss.invocation.* stuff? And what about the org.jboss.proxy.* stuff? Will it stay where it is, or, maybe, move to invokablecontainer?
|
| Moving the Naming proxy back to the server makes me want to use GenericProxyFactory, but that depends on the Invoker interface. So that makes me want to write Remoting3Invoker and Remoting3InvokerProxy integration classes.
|
| So many questions. DML, I'll bet you already have a plan.
No plan. But I do have an opinion. Well, more like a general principle.
Invocation proxies like ALR's project should generally only be used to implement specifications which define the invocation of methods on remote objects (e.g. RMI, EJB3, probably a few others). If what you're implementing is a service (such as JNDI for example) which can be expressed in terms of a fixed set of request and reply types, it's better/cleaner/simpler/more efficient to get rid of the remote proxy idea and just use straight request/reply objects directly.
That said, I still think that ALR's invocation object (and surrounding infrastructure) should be the sole mechanism, or the basis thereof, by which proxied remote method invocations are transmitted across the wire and consumed. All the other invocation mechanisms should go away.
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4267210#4267210
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4267210
14 years, 5 months
[JBoss OSGi Development] - Incompatible framework dependencies
by thomas.diesler＠jboss.com
Folks,
these dependencies currently prevent the scheduled Beta5 release on 01-Dec-2009
| <version.jboss.classloading>2.0.8-SNAPSHOT</version.jboss.classloading>
| <version.jboss.deployers>2.0.9-SNAPSHOT</version.jboss.deployers>
| <version.jboss.kernel>2.2.0-SNAPSHOT</version.jboss.kernel>
|
We proabably need to rollback to the versions that are installed in jboss-6.0.0.M1 otherwise the JBoss OSGi release cannot happen.
I realize that framework trunk needs to work with possibly newer SNAPSHOT versions than are installed in the supported target containers. As a consequence we probably need to decouple the MC Framework from JBoss OSGi and move it out of the reactor to projects/runtime/framework/trunk where it originally cam e from.
The downside of this is that the framework independent integration tests (i.e. examples, functional) are not available for trunk anymore, which was the original motivation to make framework a reactor project.
If framework should stay a reactor project we cannot update the above mentioned dependencies in an uncoordinated way. Compatible updates are ok however as long as the enterprise examples run in all supported target containers.
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4267205#4267205
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4267205
14 years, 5 months
[JBoss AS Development] - Re: Naming over Remoting 3
by ALRubinger
"ron.sigal(a)jboss.com" wrote : For that matter, what about the rest of the org.jboss.invocation.* stuff? And what about the org.jboss.proxy.* stuff? Will it stay where it is, or, maybe, move to invokablecontainer?
To be clear, invokablecontainer really offers very little above straight-up reflection that makes j.l.r.Method serializable. Maybe a couple of convenience containers (@see the testsuite for how these work).
Its real value is in a wire protocol that's tested for both forward- and backward-compatibility. Basically the class InvocationImpl and its tests.
But then again, that's the scope of the thing. Its intended to be extended via composition to add on your requirements, or supplemented w/ JBMAR or R3.
S,
ALR
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4267196#4267196
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4267196
14 years, 5 months
[JBoss AS Development] - Re: Naming over Remoting 3
by bstansberry＠jboss.com
"ron.sigal(a)jboss.com" wrote : "bstansberry(a)jboss.com" wrote :
| | Will there be step where the server controls creation of the proxy used for the actual lookup? With what you describe above, the creation of the proxy is completely driven by the client. Which is fine for the initial connection to the server, but removes the ability for the server to customize the proxy.
| |
|
| Actually, the proxy returned by NamingProxyFactory is the proxy that does the actual lookup. Hmmm. Are you referring, perhaps, to using JRMPProxyFactory to add interceptors to a proxy? I didn't think of that, probably since there don't seem to be any actual examples in the out-of-the-box configurations. OK, I'll work on that.
Yes, that's the concept I mean. JBoss AS has traditionally put the server in charge of determining the behavior and initial state of proxies, because the server has more information (complex configs, runtime state of the server/cluster etc).
HANamingService is an example; it's just that the proxy it creates is mostly statically defined, not defined by some XML configuration or something. It does have dynamic state though (the list of targets). And actually, the behavior of its proxies is somewhat externally configurable - the load balance policy to use is configurable (see all/deploy/cluster/hajndi-jboss-beans.xml, the "loadBalancePolicy" attribute.)
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4267176#4267176
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4267176
14 years, 5 months
[JBoss AS Development] - Re: Naming over Remoting 3
by david.lloyd＠jboss.com
"ron.sigal(a)jboss.com" wrote : point.connect()? I.e., keep a repository of reusable connections, keyed on URI and OptionMap?
It seems inevitable that we'll need a connection pooling mechanism, but maybe it'd be better to do by name (e.g. a named index into a predefined connection configuration map), so you could, for example, have:
| Connection c = pool.getConnection("foobar");
|
Then if the named connection is configured but not connected, it would be connected; otherwise if it's already connected, the existing connection is returned.
This way you may have multiple, identical connections with different names, if that is desired.
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4267175#4267175
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4267175
14 years, 5 months