JBossDeveloper

 

"ron.sigal@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.

 

"ron.sigal@jboss.com" wrote:

"bstansberry@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.)

 

"ron.sigal@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

 

"ron.sigal@jboss.com" wrote:

"bstansberry@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.

 

"ron.sigal@jboss.com" wrote:
If it's intended to be generally extensible, then isn't "ejb3" in the package names misleading? How about "invokable" in place of "ejb3"?

Yep, I started building it in EJB3, then committed into repos/common. So either I'll refactor it, or if someone else beats me to it feel free.

S,
ALR

 

"ron.sigal" wrote:
Are you ok with "ejb3" -> "invokable"? Do you still want it in repos/common?

Sure, I hadn't given it much thought. I'd say let's keep it in the same repo for now so that we can "svn mv" without losing version history.

The groupId might change eventually too, who knows? I'd say let's just keep the naming until we know the intent of the project IMO.

"ron.sigal" wrote:
I'm curious why org.jboss.ejb3.container.core.MapBasedInvocationContext is a non-public class (which requires the related tests to go in org.jboss.ejb3.container.core instead of org.jboss.test.ejb3.container.core), but the other classes in org.jboss.ejb3.container.core are public.

Because it didn't *need* to be public, so I scoped it down as small as possible. :) By convention lately I've been doing this so that I can have tests in the same packages and get at package-private members.

S,
ALR

PS - Hehe, "package-private members".

 

"ron.sigal@jboss.com" wrote:
I'm not sure if you mean "naming" specifically with respect to maven, or if you're saying "leave the package names alone".

Oh, just meant that in addition to package names changing, maybe the Maven IDs will eventually too. So long as everything stays consistent and descriptive I don't mind whatever we change it to.

S,
ALR