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

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:
public class Runner { /** * @param args */ public static void main(String[] args) { // TODO Auto-generated method stub com.playgroud.test.Child c1 = new com.playgroud.test.Child(); System.out.println("After Constructor is done: "+c1); } }public class Child extends Parent { private String x = null; private String y; public String getY() { return y; } public void setY(String y) { this.y = y; } public String getX() { return x; } public void setX(String x) { this.x = x; } @Override public void setInit() { setX("hello"); setY("good bye"); System.out.println("Once setInit is done: "+this.toString()); } public String toString(){ return getX()+" and "+getY(); } public Child(){ super(); System.out.println("Child constructor at exit: "+this.toString()); } }public abstract class Parent { public Parent(){ System.out.println("Parent constructor before calling setInit(): "+this.toString()); setInit(); System.out.println("Parent constructor after calling setInit(): "+this.toString()); } public abstract void setInit(); } Output: Parent constructor before calling setInit(): null and null Once setInit is done: hello and good bye Parent constructor after calling setInit(): hello and good bye Child constructor at exit: null and good bye After Constructor is done: null and good bye
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.

Sorry about that! And yes you are right, I missed the variable name. So much for fast edits!
here it the super class:
package com.playgroud.test; public abstract class Parent { public Parent(){ setInit(); } public abstract void setInit(); }

So here are two essentially identical classes (note difference line 5)
package com.playgroud.test; public class Child extends Parent { private String x = null; public String getX() { return x; } public void setX(String x) { this.x = x; } @Override public void setInit() { setX("hello"); } public String toString(){ return getX(); } public Child(){ super(); } }
and
package com.playgroud.test; public class Child2 extends Parent { private String x; public String getX() { return x; } public void setX(String x) { this.x = x; } @Override public void setInit() { setX("hello"); } public String toString(){ return getX(); } public Child(){ super(); } }
Here is the tester:
package com.playground; public class Runner { /** * @param args */ public static void main(String[] args) { // TODO Auto-generated method stub com.playgroud.test.Child c1 = new com.playgroud.test.Child(); com.playgroud.test.Child2 c2 = new com.playgroud.test.Child2(); System.out.println(c1); System.out.println(c2); } }
here is the outcome:
null hello
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

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
public class FakeInvManagerBean implements FakeInvManagerRemote, FakeInvManagerLocal { private static final int DEFAULT_BASSIS = 1; @PersistenceContext(unitName = "InvShoes") public EntityManager em; }
Code for JSF bean that calls the manager:
public class InvManagerJSFBean { @EJB(mappedName = "FakeInvToolApp/FakeInvManagerBeanShoes/local") private FakeInvManagerLocal invShoes; @EJB(mappedName = "FakeInvToolApp/FakeInvManagerBeanShirts/local") private FakeInvManagerLocal Shirts; private String invMgrJNDIName; public FakeInvManagerLocal getInvMgrShoes(){ return invShoes; } public FakeInvManagerLocal getInvMgrShirts(){ return invShirts; } public boolean createStockShoes = false;//this will be changed dynamically depending on which stock we are manipulating. public String createStock() throws NamingException { if(createStockShoes) getInvMgrShoes().createInventory(getBasisId(), getInventoryId(), getStockLevel()); else getInvMgrShirts().createInventory(getBasisId(), getInventoryId(), getStockLevel()); return "InventoryCreated"; } }
ejb-jar.xml
<enterprise-beans> <session> <ejb-name>FakeInvManagerBeanShoes</ejb-name> <business-local>com.inventory.access.FakeInvManagerLocal</business-local> <business-remote>com.inventory.access.FakeInvManagerRemote</business-remote> <ejb-class>com.inventory.access.FakeInvManagerBean</ejb-class> <session-type>Stateless</session-type> <persistence-context-ref> <persistence-context-ref-name>com./WhoCares</persistence-context-ref-name> <persistence-unit-name>InvShoes</persistence-unit-name> <injection-target> <injection-target-class>com.inventory.access.FakeInvManagerBean</injection-target-class> <injection-target-name>em</injection-target-name> </injection-target> </persistence-context-ref> </session> <session> <ejb-name>FakeInvManagerBeanShirts</ejb-name> <business-local>com.inventory.access.FakeInvManagerLocal</business-local> <business-remote>com.inventory.access.FakeInvManagerRemote</business-remote> <ejb-class>com.inventory.access.FakeInvManagerBean</ejb-class> <session-type>Stateless</session-type> <persistence-context-ref> <persistence-context-ref-name>com./WhoCares2</persistence-context-ref-name> <persistence-unit-name>InvShirts</persistence-unit-name> <injection-target> <injection-target-class>com.inventory.access.FakeInvManagerBean</injection-target-class> <injection-target-name>em</injection-target-name> </injection-target> </persistence-context-ref> </session> </enterprise-beans>

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 ]

Hi:
I am trying to setup a very simple page. Two dropdown values of the second one are dependended on the first one:
<f:view> <h:form> <h:inputText value="#{simple.simple}"></h:inputText> <h:selectOneMenu id="applicationInput" value="#{simple.application}"> <f:selectItems value="#{simple.applications}" /> </h:selectOneMenu> <h:selectOneMenu id="featureInput" value="#{simple.feature}"> <f:selectItems value="#{simple.featuresList}" /> </h:selectOneMenu> <h:commandButton action="#{simple.action}" value="submit"></h:commandButton> </h:form> </f:view>
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:
package simple; import javax.faces.model.SelectItem; import com.support.uiview.ApplicationBean; import com.support.uiview.FeatureBean; public class Simple { private String simple; private SelectItem[] applications; private SelectItem[] featuresList; private String feature; private String application; public String getSimple() { return simple; } public void setSimple(String simple) { this.simple = simple; } public String action() { setSimple(getSimple().toUpperCase()); simple = application; return "success"; } public SelectItem[] getApplications() { setApplicationList(new ApplicationBean()); return applications; } public void setApplications(SelectItem[] applications) { this.applications = applications; } private void setApplicationList(ApplicationBean applications) { if (applications == null || applications.getApplications() == null) { return; } this.applications = new SelectItem[applications.getApplications().length]; for (int indx = 0; indx < applications.getApplications().length; indx++) { this.applications[indx] = new SelectItem(applications .getApplications()[indx], applications.getApplications()[indx]); } } public String getApplication() { return application; } public void setApplication(String application) { this.application = application; } public SelectItem[] getFeaturesList() { setFeaturesLists(new FeatureBean(getApplication())); return featuresList; } public void setFeaturesList(SelectItem[] featuresList) { this.featuresList = featuresList; } private void setFeaturesLists(FeatureBean featureBean) { if (featureBean == null || featureBean.getFeatures() == null) { return; } featuresList = new SelectItem[featureBean.getFeatures().length]; for (int indx = 0; indx < featureBean.getFeatures().length; indx++) { featuresList[indx] = new SelectItem( featureBean.getFeatures()[indx], featureBean.getFeatures()[indx]); } } public String getFeature() { return feature; } public void setFeature(String feature) { this.feature = feature; } } /** * */ package com.support.uiview; /** * @author twolak * */ public class FeatureBean { private String[] features; public FeatureBean(String applicationName){ initializeFeature(applicationName); } private void initializeFeature(String appplicationName){ if(appplicationName==null){ String []feat = new String[1]; feat[0] = appplicationName+""; setFeatures(feat); return; } String []feat = new String[2]; feat[0] = appplicationName+" Feature/Capability 1"; feat[1] = appplicationName+" Feature/Capability 2"; setFeatures(feat); } public String[] getFeatures() { return features; } public void setFeatures(String[] features) { this.features = features; } } package com.support.uiview; public class ApplicationBean { private String[] applications; public ApplicationBean(){ String[] appList = new String[11]; appList[0] = new String("App1" ); appList[1] = new String("App2"); appList[2] = new String("App3"); setApplications(appList); } public String[] getApplications() { return applications; } public void setApplications(String[] applications) { this.applications = applications; } }

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:
<navigation-rule> <from-view-id>/Simple.jsp</from-view-id> <navigation-case> <from-outcome>success</from-outcome> <to-view-id>/Simple.jsp</to-view-id> </navigation-case> </navigation-rule> <managed-bean> <managed-bean-name>simple</managed-bean-name> <managed-bean-class>simple.Simple</managed-bean-class> <managed-bean-scope>request</managed-bean-scope> </managed-bean>