JBossDeveloper

R:

Looks like InvocationContextProvider as an SPI is pretty useless. We can move the "isEmpty" support to the API InvocationContext. This allows us to make the three-arg InvocationImpl constructor public.

Additionally we can add an "Iterable<?> getKeys" to InvocationContext.

Don't be scared to touch this project BTW; it's basically a prototype playground now.

I've committed the changes above in r3824.

S,
ALR

OT: what's up with invokable with a k? "Invocable" is actually a dictionary word[1] not just a geek neologism.

[1] http://dictionary.reference.com/browse/invocable

Well "Invokable" yields 84k hits on google, while "invocable" yields only 82k. Does this prove anything? Probably not :)

"bstansberry@jboss.com" wrote:
OT: what's up with invokable with a k? "Invocable" is actually a dictionary word[1] not just a geek neologism.

[1] http://dictionary.reference.com/browse/invocable

Ok, never mind, invokable is fine. :)

TBH, it bugged me a lot, because it seemed either a spelling error or us coining an unnecessary neologism for something not particularly sexy. But google clearly shows we're not coining a neologism; that spelling is used all over the place in software.

The google data is just reinforcing the fact that developers can't spell :)

We probably should go with the correct spelling either way. I thought maybe the google data would give an obvious answer, but it just muddied the waters a bit more.

I guess there's no reason a chain of interceptors couldn't be downloaded by a Naming client

The main issue here is wire compatibility. Unless there are means on the client to load the interceptors in isolation you can't communicate with different server versions. The same goes for any metadata map.

For EJB there are two use cases where proxies come into play:

1. JNDI

2. return a self reference

public MyInterface getSelfReference() {
   return sessionContext.getBusinessObject(MyInterface.class);
}

Now picture it simply with a proxy containing an URL. I would return a proxy [url="here:EJB1"]. Now if it goes through Remoting it knows it's 'there' and thus transform to [url="remoting:node1:EJB1"].

The same goes for JNDI. If we've unified the transports both JNDI and EJBs are always 'there'.

So in essence the base proxy is transport unaware.

Ridiculus. If I can connect to HA-JNDI I know where every node is within my own network topology. So I would know that cluster1 consists of node1 and node2.

So in essence proxy [url="remoting:node1:EJB1"] comes in through clustering which has a logical mapping of node1 to cluster1 and thus transforms to [url="clustered:cluster1:EJB1"].

wolfc wrote:

 

I guess there's no reason a chain of interceptors couldn't be downloaded by a Naming client

The main issue here is wire compatibility. Unless there are means on the client to load the interceptors in isolation you can't communicate with different server versions. The same goes for any metadata map.

That's an implementation detail though.  This kind of thing can be done without messing up wire compatibility.

wolfc wrote:

 

For EJB there are two use cases where proxies come into play:

1. JNDI

2. return a self reference

 

public MyInterface getSelfReference() {
   return sessionContext.getBusinessObject(MyInterface.class);
}

 

Now picture it simply with a proxy containing an URL. I would return a proxy [url="here:EJB1"]. Now if it goes through Remoting it knows it's 'there' and thus transform to [url="remoting:node1:EJB1"].

 

The same goes for JNDI. If we've unified the transports both JNDI and EJBs are always 'there'.

 

So in essence the base proxy is transport unaware.

If you do this by URL (URI, really, from what you've got there), then you still need some way to map a URI scheme to a transport implementation of some sort.  And if you're going to do that, why not let remoting do it for you, since it has already has a thing to support that?  And if you're going to do that, why not just tie the proxy impl to remoting and save yourself some coding?

ron.sigal@jboss.com wrote:

"david.lloyd@jboss.com" wrote:

This way you may have multiple, identical connections with different names, if that is desired.

One of the nice things about the way it works in R2 is that the user doesn't even have to be aware of the issue. Maybe we could do it either way, according to some configurable setting. Or not.

That's actually a sort of anti-feature.  The fact is you do have to be aware of the issue, if you want to avoid surprises (especially when there's a firewall involved, for example).  And pooling by hostname and port, while convenient, is not semantically "correct", or is it correct to pool by hostname/port+some configuration items.  And resource cleanup is always best accomplised explicitly when you're dealing with OS resources.  Thus if the connection lifecycle is controlled by the user, but a mechanism is provided to "register" connections so that unrelated apps can use them, this is the best solution.

Ideally, a complex client would have a series of connections and would be able to know via a service location mechansim what the "best" connection is for communicating with some specific target service.