• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Tim Cooke
  • Ron McLeod
  • paul wheaton
  • Jeanne Boyarsky
Sheriffs:
  • Paul Clapham
  • Devaka Cooray
Saloon Keepers:
  • Tim Holloway
  • Roland Mueller
  • Himai Minh
Bartenders:

MDB : dynamic selector

 
Greenhorn
Posts: 6
  • Likes 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hello,

I have several servers running the same code but each handling specific messages (they are spread by geographical area and must should treat all messages related to their area)

I thought to use a single queue and a message selector to filter the different message.

The question is: how to write Java code and deployment plan so that the selector is configured dynamically, based on a config file, the config of application server ( Geronimo 2.2)

The goal is to have the same EAR deployed on all servers.

Thank you.
 
Ranch Hand
Posts: 110
Google Web Toolkit Java Google App Engine
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Wow, I liked the question, I don't know the answer but I'll look into it and I think you must also ask this on stackoverflow (and post the link here).
 
Jayr Motta
Ranch Hand
Posts: 110
Google Web Toolkit Java Google App Engine
  • Likes 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Let's go.

You haven't said what other technologies you're using besides MDB, so I'll give a solution to EJB 3.1 and if you're using 3.0 or 2.x(improbable) we analyze another approach.

You can try to explore the @Startup to obtain the value specified in the deployment descriptor at bootstrap time, then you'll be able to obtain a value like: "US" for United States, "BR" for Brazil and so on. Then you set it on a constant or something like this, but I think the constant will be the best solution.

Done this, you can use the constant on the:



I haven't tested it and I think that a better solution can be ellaborated.
 
Fred Motte
Greenhorn
Posts: 6
  • Likes 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thanks a lot for your quick answer,

I'm using Geronimo 2.2 (EJB 3.0), if I remember @startup doesn't exist yet in 3.0.
In order to trig some processing I've already used a workaround : A web application (servlet) that use the <load-on-startup>.
I will try to define a constant at this time and use it.

Thank you for the idea, I will keep you informed...
 
Jayr Motta
Ranch Hand
Posts: 110
Google Web Toolkit Java Google App Engine
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Fred,

Once I was using JBoss and the same problem because there were no specification to boostrap listener for enterprise application as we have for web applications, then I looked all over the internet and found a specific feature of JBoss that allowed me to write services to my application service and specify then to run when the application started, then I've used this feature to achieve this result.

It was bad because I got stucked on a specific vendor but I could avoid add a web application structure just to add this feature. On the other hand, adding the web structure isn't so bad once it's covered by a specification that will ensure portability, I think it will work well, let me know the result please!

 
Fred Motte
Greenhorn
Posts: 6
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Aaarrrg,

It seems that Attribute value must be a "compile time" constant.
I explain :

It works fine when I declare my constant like this :



But if I want to compute my constant like this :


I get the error code "Attribute value must be constant" during the compilation of



I'm affraid that annotation must be well define even before initialization of static class.

Thread found on javaRanch : Setting Dynamic element values in an Annotation
 
Jayr Motta
Ranch Hand
Posts: 110
Google Web Toolkit Java Google App Engine
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
What if you do:

<message-driven>
<activation-config>
<activation-config-property>
<activation-config-property-name>messageSelector</activation-config-property-name>
<activation-config-property-value>property = "US"</activation-config-property-value>
</activation-config-property>
</activation-config>
</message-driven>

at ejb-jar.xml?

It will be set at "assembly time" as you said you want.
 
Fred Motte
Greenhorn
Posts: 6
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Yes,
It is what I do currently,
but I have to build an ejb-jar.xml for each server and package them each in an ear different .

AFAIK, ejb-jar.xml is only read when deploying ear.

I think, I'm not enough skilled in Java EE and thus I should miss something trivial ?

Fred.
 
Jayr Motta
Ranch Hand
Posts: 110
Google Web Toolkit Java Google App Engine
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hm, I think I'm confused. You want a config file to config the message selector per-application but you do not want to use the ejb-jar,xml because you'd have to change it per-application.

This is the role that ejb-jar.xml must play, it can be used to configure different environments like development, production , etc, but it also can be used to change some few characteristics of a given instance of the same software.

In fact, according to the ejb specification, as an Application Assembler you're able to get a lot of different beans from different applications and build a new applications just wiring them in the deployment descriptor. Obviously there are some stuff that can't be done with deployment descriptor but as you've explained this is not your case. In other words, you don't have to recompile your application every time you want to tweak some configuration, you just change what you want in the deployment descriptor and that's it.

Try to explain better what you want if what I understood is wrong and I'll keep trying to help you, ok?

 
Fred Motte
Greenhorn
Posts: 6
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi,

I understand you are a bit confused....
Yes, I would like a config file to change some few characteristics of a given instance of the same soft but not ejb-jar.xml.

With ejb-jar.xml, I'm able to deploy a ear (the same for all server) with a separate ejb-jar.xml (specific to each server).
This step is acceptable for the first deployment of the server

But each time I need to update the software, I also need to deploy the ear with its specific ejb-jar.xml,

That is not easy to get the ejb-jar of a specific server in order to deploy a new ear.

Moreover, I have already a config file (simple property file) used by other process in the server and already containing the relevant information (geographical area).

You know, it would be cleaner to use this information to build my selector...

I will learn more about deployment and descriptor on Geronimo. perhaps, I miss something.

Thank you.
 
Jayr Motta
Ranch Hand
Posts: 110
Google Web Toolkit Java Google App Engine
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Yeah, I don't understand your need then. I really think you'll not find anything simpler than just tweak a configuration in ejb-jar.xml for each different geographical area.

You can try another approach by writing your messages listeners on top of stateless session beans and defining the message selector at runtime, maybe then you could get this information from the database.

Getting the information of a .properties file will be almost the same that get the information from the ejb-jar.xml, compile-time configs as annotations are doesn't work for you and it's also harder because you would have to recompile everything every time.

Fckn' dilemma uh?
 
Ranch Hand
Posts: 489
Eclipse IDE Tomcat Server Java
  • Likes 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

I have several servers running the same code but each handling specific messages (they are spread by geographical area and must should treat all messages related to their area)

I thought to use a single queue and a message selector to filter the different message.



Just curious, how is it that the same code treats different messages the same?

As you rightly pointed, if you had the same queue for multiple messages, you would use message selectors so that the messages can be filtered for different mdbs to take different action. But reading through your post, there is only one mdb.

 
Fred Motte
Greenhorn
Posts: 6
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi ramprasad,

In fact servers handle also VPN connection and message are regarding management od those vpn connection.

A WebService server receive command, and after processing convert them in message for the "vpn server".

In order to be efficient regarding the VPN connection, vpn client must establish connections close to their location.

We have several server deserving different geographic area.

So, the message and their processing are the same on all server, just they location differ.
There is one MDB per server, each listening on a specific JMS property like country or area.

The WebService server knows the vpn server and dispatch message to each of them.

I don't want to build an ear for each server (especially in case of update).
Now I'm looking for an signle ear and a geronimo deployment plan for each server. but I get stuck with geronimo deployment plan..
I 'm a newbie with java EE and Geronimo, so If somebody has an idea...

Thanks a lot for all your comment...

Fred...
 
ramprasad madathil
Ranch Hand
Posts: 489
Eclipse IDE Tomcat Server Java
  • Likes 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
So if all mdbs are the same, how do you determine which location the mdb should serve? As far as I can think, it should either be

1. You would either look up the location to serve from some apis your application has. In which case you really do not need the mdb to know through a property the location it has to serve.

2. or else you would read the location from the message property value (that you propose to use as a selector) again within your code using the message.getProperty() api. Which again makes the message selector redundant. You may as well do a branching logic using the property value inside the code.

Message selectors are used to serve different mdbs listening on the same queue for different messages. Since the messages are different, they would have different processing logic, are separate and different beans.Hence you push the job of message filtering (sending the right msg to the right mdb) to the provider rather than to the application. In your case, it does look like you can deploy the same mdb without message selectors and use the value of the property inside the mdb to determine further processing. That is unless there is something you have not told us

cheers,
ram.

 
With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
reply
    Bookmark Topic Watch Topic
  • New Topic