Win a copy of Spring Boot in Practice this week in the Spring forum!

Tomasz Wolak

Greenhorn
+ Follow
since May 06, 2008
Cows and Likes
Cows
Total received
0
In last 30 days
0
Total given
0
Likes
Total received
0
Received in last 30 days
0
Total given
0
Given in last 30 days
0
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Tomasz Wolak

Thanks!

I understand the differences of acknowledgment types in the consumer of the message, and the significance of the setting the acknowledgment type during creation of the consumer. I just fail to see it's significance in message producers: as far as I see it there is no impact of the acknowledgment type when creating the producer: regardless of the type of acknowledgment selected there is no need to change the code or expected different behavior. For example consumer CLIENT_ACKNOWLEDGE requires the message to be explicitly acknowledged by using ObjectMessage acknowledge() method. As far as I see it producer requires no such action: in fact the message receipt by JMS provider is guaranteed upon successful completion of the send()/publish() method.

If in fact my assumption is corrected (i.e. acknowledgment type has no impact on the message producer) then I think I would rather see have two different ways creating the session object: one for consumers who would like to control both the message acknowledgment and transaction boundaries and second one for producers whose only option is whether the is transacted or not.

Cheers!
Tomek
Hi:
I am pretty sure I know what the answer is but I would like to have a confirmation. When creating a JMS session for the purpose of using the session to create message producer: is there any significance of specifying what the acknowledgment mode should be? My understanding is that the message is stored by JMS provider upon exit from the publish(), send() methods and regardless of what the mode was set to be. In which case the acknowledgment mode is message consumer only concept?
Thanks for you input!
Tomek
Thanks. This is indeed what I have suspected. This is not to say that I think it makes sense makes logical sense but that's another discussion.

So here is follow up question: other than starting off with uninitialized variables to begin with, is there something else that will allow subclass to set up variables when called upon from the constructor of the superclass without fearing that it'll be wiped out?
Thanks
Tomek
10 years ago
I've just run at this today at work.
I watched this in debugger and I know what it is doing. I just don't understand why.
When the constructor to the super is invoked it first goes to implemented setInit() method.
The method in the child is invoked and the 'x' attribute is set (in both implementation of child).
The super.constructor regains control and now it get's interesting: the class that is initiated with "null" is reset to null even though it was set by the setInit() method.
I would expect the constructor in Parent not reset the value to "null" if it was already initiated by child class. OR I would expect both cases to behave in the same way.
I modified this bit more to illustrate what is doing. This time I only have one implementation of the child to make things easier to follow. The child class has two attributes one initialized to 'null' the other not at all:

You can clearly see that both attributes are set. But somehow the constructor re-initiates the already set attributes IF the attributes are initiated in the class declaration to begin with.

This sort of feels like a bug to me.
10 years ago
Sorry about that! And yes you are right, I missed the variable name. So much for fast edits!
here it the super class:
10 years ago
So here are two essentially identical classes (note difference line 5)

and

Here is the tester:

here is the outcome:

Note the difference (line5): Child initialized the "X" variable to "null" while the Child2 didn't.
This seems a bit odd behaviour to me? I don't understand why this would take place. Your explanation i appreciated. I am using java (build 1.6.0_23-b05).
Thanks for input!
Tomek
10 years ago
Hi:
The concept is very simple: one class definition, two references each defined in ejb-jar.xml. Even though references have been configured to use different persistence context (InvShoes/InvShirts) they both use the persistence context that was injected using the annotation (InvShoes). The only way I get the reference to use the configured persistence context is to remove the annotation that injects the persistence context.
Given the server I use (Jboss 5) jdk 1.6 and ebj-jar.xml definition why is configuration NOT overriding the injection via annotation.
Not sure how much simpler I can make this.
Hi:
I thought that you should be able to override @PersistenceContext annotation using ejb-jar.xml file. Either I am doing something wrong or there is another issue that I am not aware of.
Simple concept: to learn innards of EJB I created a very simple eCommerce app. The store has two diffrent sources of inventory (let say we can sell shoes and shirts). To manage the inventory I created an inventory manager. You need separate manager to manage each inventory source. Since the managers perform the same functions and only differ in which inventory source they manipulate I only need one class and I'll configure two different instances. Here is my setup:
Code for the Manager

Code for JSF bean that calls the manager:

ejb-jar.xml


I am deploying on Jboss5.0 and the server comes up clean, there are two beans registered, I have two different datastores configured and accessible. However, when I try to run it I always end up creating the new stock in ONE database ("InvShoes") so the one that was injected using @PersistenceContext annotation. I can fix this really easy if I remove the @PersistenceContext(unitName = "InvShoes") annotation from the bean. Therefore, it appears that @PersistenceContext is not being overwritten by the values in the ejb-jar.xml. It was my understanding that the configuration file always trumps the annotation so what is going on here?
Appreciate your input.
Tomasz
Yes, changing the scope to "session" works. This however, does not solve my problem I don't want this "Simple" bean to be session scoped. The other thing is Why is it that the "action" is invoked only every second time if it's request scoped and all the time when it's session scoped?
Thanks for your help.
Tom
[ May 07, 2008: Message edited by: Tomasz Wolak ]
14 years ago
JSF
Hi:
I am trying to setup a very simple page. Two dropdown values of the second one are dependended on the first one:

basically upon clicking the button I want the form to be redrawn with features populated based on the application name.
Here is the form code:


the Simple.java is request scoped.

Now here is he the issue: the form works only EVERY second time. When submitted for the first time it works as designed, the form is re-drawn with the values of the second input influced by the fist one. However, on second click the values of the first one are reset to the initial state and not ate all dynamically set.
I have spend whole day on this and I am not any closer to solving this. Any suggestions on how to do this are welcome. If there is an alternative to redrawing the second dropdown upon change of the first one without resetting the whole page please let me know.
Thanks a million!
Tom
faces-config:
14 years ago
JSF