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.
Joined: Jul 28, 2011
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...
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!
Joined: Jul 28, 2011
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.
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?
Joined: Jul 28, 2011
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.
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.
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.
Joined: Jul 28, 2011
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...
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