-
1. Re: Support for remote invocation - Question about JNDI names
jaikiran Nov 19, 2011 9:23 PM (in response to dastraub)1 of 1 people found this helpfulDaniel Straub wrote:
- the appName/moduleName (name of the ear or jar file) contains often a version number or other extensions (like SNAPSHOT) - that means this part isn't constant. The client needs update with every new version ...
This can be overriden to a name of your choice in the application.xml (for application names) and ejb-jar.xml/web.xml (for module names).
Daniel Straub wrote:
- the beanName is the name of the implementation class, so in your code sample the client has a dependency to this internal detail of the app ! Don't refactor ...
Again, this can be overriden to whatever name you want to give, either via the "name" attribute of @Stateless/@Stateful annotation or via ejb-jar.xml
Having said that, we are definitely going to think whether this can improved. Thanks for the feeback!
-
2. Re: Support for remote invocation - Question about JNDI names
dastraub Nov 20, 2011 7:25 AM (in response to jaikiran)Thats makes the picture clearer - particulary the correlation between the different names and where to redefined this !
Another question to the "jboss-ejb-client.properties" file.
This looks like what mod_cluster resolved for web applications comes now back for remote ejb-calls (worker.properties ...)
In the past we uses only two standard properties : Context.PROVIDER_URL and CONTEXT.INITIAL_CONTEXT_FACTORY to define a remote connection. Now we need an additional property file.
It is not possible for a ContextFactory to initialize the remoting stuff with defaults and other given properties ?
In the past we had also the following options :
- ejb3-interceptors-aop.xml to define or fine tuning the client and server side interceptor stack. We used this also very often to add some 'vertical behavior' to applications at system level
- clustering : failover for stateless, replication for stateful sessionbeans
Where are this features now ?
-
3. Re: Support for remote invocation - Question about JNDI names
jaikiran Nov 21, 2011 3:09 AM (in response to dastraub)1 of 1 people found this helpfulDaniel Straub wrote:
Thats makes the picture clearer - particulary the correlation between the different names and where to redefined this !
Yeah, I actually have already described these details in that chapter https://docs.jboss.org/author/display/AS71/EJB+invocations+from+a+remote+client+using+JNDI. You probably missed it (but that's OK).
Daniel Straub wrote:
Another question to the "jboss-ejb-client.properties" file.
This looks like what mod_cluster resolved for web applications comes now back for remote ejb-calls (worker.properties ...)
It might look similar but mod_cluster wasn't what we had in mind when we came up with that file But yeah, I see what you mean. That properties file is a way to configure your client to point to server targets.
Daniel Straub wrote:
In the past we uses only two standard properties : Context.PROVIDER_URL and CONTEXT.INITIAL_CONTEXT_FACTORY to define a remote connection. Now we need an additional property file.
It is not possible for a ContextFactory to initialize the remoting stuff with defaults and other given properties ?
The jboss-ejb-client.properties isn't just meant for JNDI lookups. Although the JNDI lookups do by default use that information for communicating with the server. That's one of the reasons why we did not add these details to the jndi.properties. As for guessing some default values - I think the only thing that we could guess is the host property for a connection and default it to localhost and the port property and default it to 4447. But that really won't be useful for real applications because:
1) For real applications, the host isn't really a localhost since it's a remote client
2) For establishing a connection, we need to authenticate with the server which means that the client has to configure the authentication information. This is something we cannot and shouldn't really guess.
That's just some of the reasons that I can think of now, for not defaulting to some values for establishing a connection. Ultimately the client would have to configure the properties file for the application (where or not we default some of those values).
Daniel Straub wrote:
In the past we had also the following options :
- ejb3-interceptors-aop.xml to define or fine tuning the client and server side interceptor stack. We used this also very often to add some 'vertical behavior' to applications at system level
AS7 no longer relies on AOP for interceptors. Neither on the client side nor on the server side. We do have a way to allow client interceptors, but I think I'll have to look at it a bit to see if we can improve the implementation and allow for a deterministic ordering of the client interceptors. I'll take a look at this, during this week. But the real question is, what kind of logic do you expect in your client interceptors? Can you explain that "vertical behaviour" use case and other use cases where you used these interceptors?
- clustering : failover for stateless, replication for stateful sessionbeans
That's something we haven't yet implemented for EJBs. There's a discussion on the AS7 dev mailing list on how it might be implemented, but right now it's not ready.
-
4. Re: Support for remote invocation - Question about JNDI names
dastraub Nov 23, 2011 5:04 AM (in response to jaikiran)Can you explain that "vertical behaviour" use case and other use cases where you used these interceptors?
Some examples :
- in a large distributed application (with 2-4 server hops) we add a unique ID (in fact we use the HTTP session id) to follow a call trough different servers (logs). That means, the first client add his ID in the invocation metadata and by the following servers in a interceptor we put this in the log4j NDC or in a thread local
- same idea : in a financial application we had the requirement to log the ip-adresses of the caller, at caller side we add this to the transport and reuse it at receiver side
- in a application where we use some kind of "time shifting" we initialize some variables in a interceptor
- and so on
As you can see, we use it for logging purpose, transfering additional data or use the interceptor for global initializing.