Nancy O'Connell

Thanks for your response, but it does work in RAD 7, on a WAS 6.1 server. We have both ears running on the same server, same profile.

We are upgrading from RAD 7/WAS 6.1 to RAD 7.5 / WAS 7.

Our project currently has multiple ears. On the servers, each ear runs in it's own JVM, but when we test locally, we test multiple ears on the same server. Some of these ears contain the same EJB's - for example, we have a CommonEJB that runs in both EAR_A and EAR_B.

With RAD 7 / WAS 6.1 this works with no problems.

When we try to run the same scenario under RAD 7.5 and WAS 7, we receive the following error:

The com.ejb.CommonHome interface of the Common bean in the CommonEJB.jar module of the EAR_A application cannot be bound to the ejb /com/ejb/CommonHome name location. The com.ejb.CommonHome interface of the Common bean in the CommonEJB.jar module of the EAR_B application has already been bound to the ejb/com//ejb/CommonHome name location.
at com.ibm.ws.runtime.component.EJBContainerImpl.startModule(EJBContainerImpl.java:2728)
at com.ibm.ws.runtime.component.EJBContainerImpl.start(EJBContainerImpl.java:3826)
at com.ibm.ws.runtime.component.ApplicationMgrImpl.start(ApplicationMgrImpl.java:1122)
at com.ibm.ws.runtime.component.DeployedApplicationImpl.fireDeployedObjectStart(DeployedApplicationImpl.java:1319)
at com.ibm.ws.runtime.component.DeployedModuleImpl.start(DeployedModuleImpl.java:609)
at com.ibm.ws.runtime.component.DeployedApplicationImpl.start(DeployedApplicationImpl.java:944)
at com.ibm.ws.runtime.component.ApplicationMgrImpl.startApplication(ApplicationMgrImpl.java:725)
at com.ibm.ws.runtime.component.ApplicationMgrImpl.start(ApplicationMgrImpl.java:2046)
at com.ibm.ws.runtime.component.CompositionUnitMgrImpl.start(CompositionUnitMgrImpl.java:439)
at com.ibm.ws.runtime.component.CompositionUnitImpl.start(CompositionUnitImpl.java:123)
at com.ibm.ws.runtime.component.CompositionUnitMgrImpl.start(CompositionUnitMgrImpl.java:382)
at com.ibm.ws.runtime.component.CompositionUnitMgrImpl.access$300(CompositionUnitMgrImpl.java:110)
at com.ibm.ws.runtime.component.CompositionUnitMgrImpl$CUInitializer.run(CompositionUnitMgrImpl.java:949)
at com.ibm.wsspi.runtime.component.WsComponentImpl$_AsynchInitializer.run(WsComponentImpl.java:349)
at com.ibm.ws.util.ThreadPool$Worker.run(ThreadPool.java:1563)

WSVR0501E: Error creating component com.ibm.ws.runtime.component.CompositionUnitMgrImpl@4eda4eda
com.ibm.ws.exception.RuntimeWarning: javax.naming.NameAlreadyBoundException: The com.Common.ejb.CommonHome interface of the Common bean in the CommonEJB.jar module of the EAR_A application
cannot be bound to the ejb/ejb/CommonHome name location. The com.uhc.edist.Common.ejb.CommonHome
interface of the Common bean in the CommonEJB.jar module of the EAR_B application has already been bound to the ejb/ Common/ejb/CommonHome name location.

I realize that sometimes this message appears as a warning, but here it actually prevents the second EAR from running. There was a similar problem with
WAS 6.1 which was resolved by an update from IBM (PK69778).

We are running WAS 7.0.0.13, and Rational Application Developer Version: 7.5.5.3, Build ID: 20101203_0655.

Does anyone have any ideas?

Thank you very much for your reply. Your book sounds like it will help us tie in the other frameworks and technologies that we will need to use... I look forward to reading it! Thank You again!

This is very timely, as our application is just starting to use Flex, and I have just started a training class in Flex. I'm just wondering what are the biggest challenges that a Java Developer will face in trying to learn Flex. What are the biggest problems and most common mistakes most Java Develoeprs make in Flex? Does your book cover these?

Thanks!

Paul,
Thanks very much for that response. I've often thought that maybe I just wasn't bright enough because I couldn't debug problems simply by looking at the source code. So I'm glad to read that the empirical approach is a better approach to debugging software problems!
I look forward to reading your book and I'm sure it's going to make my life at work much easier...

Thanks,
Nancy

My biggest problem in debugging is often being able to reproduce whatever the problem is. If I can duplicate the problem, I'm usually halfway there.

Without giving too much away, how much of your book covers reproducing defects, and do you have any general tips on how to do that?

Thanks.

I've been working with Struts 1.1 for a few years. Is your book appropriate for someone who has struts 1.1 experience, and needs to understand the differences between 1.1 and 2.0? Does your book cover OGNL? and Xwork? Do you have any pointers for someone upgrading to Struts 2.1?
Thanks.

Thanks for your reply, I agree the nested tags are flaky. Unfortunately, I'm not using struts-el.
I did get this to work correctly by cleaning up my tags - some of my nested tags still had name paramaters and indexed="true" parameters included. Once I deleted all those un-needed paramters, and made sure that all my tags in the iteration were nested, all values and indexes were returned correctly.

I have a pretty standard struts application, but am having an unusual problem, at least one that I've never seen. There is a MedicalForm bean, which has an ArrayList of RateForms. Each RateForm has an arrayList of detailed InfoForms. I am displaying and allowing the user to update the order of the InfoForms on the screen.

My Jsp looks somewhat like this:
<nested:form action="/proposalMedical" >
...
<nested:iterate name="ProposalMedicalForm" property="proposalMedicalRateForm" id="proposalMedicalRateForm" indexId="rateIndexId" >
...
<nested:iterate name="proposalMedicalRateForm" id="proposalMedicalInfoForm" property="proposalMedicalInfoForm" indexId="infoIndexId" >
...

Everything displays correctly - if I have one RateForm with 3 InfoForms, that's what shows up on the screen.

RateForm1
>Info1
>Info2
>Info3

When I submit the screen, the information is mapped back to the form incorrectly. Instead of one RateForm, I now have 3 RateForms, and each RateForm has one InfoForm. In addition, each InfoForm shows up in it's original position in the arraylist. On the first RateForm, Info1 shows up in the first position in the arrayList. On the second RateForm, Info2 shows up in the position of the arrayList, with the first position being null. On the third RateForm, Info3 shows up in the third position of the arraylist.

RateForm1
>Info1

RateForm2
>null
>Info2

RateForm3
>null
>null
>Info3.

Has anyone ever encountered a problem like this before or have any ideas? I'm guessing the indexes for the RateForms are getting updated incorrectly, but I'm not sure why.
Thanks!

Hi Mark, I look forward to reading your book. Without giving too much away, what would you say are the most common issues or problems encountered when trying to design and implement a Web Service Solution? (Beyond the "magic pixie dust" expectations of management)

I just came out of a class where we were discussing AJAX and JSF, so I was very glad to hear about your book. My question is what advantages would you gain by using a JSF and AJAX framework over a STRUTS framework? and what types of applications are more suited to a JSF and AIX framework? Is this type of information this discussed in your book?

Chris,
Thanks for your reply. I think I need to read through your book to get a through understanding of POJO's - but your answer helped clarify what they are and are not...

Thanks again.

If POJO is a "Plain Old Java Object", how is it different than any Java Object? I've read that POJO's are different because they do not follow any typical models or conventions, but is that the only difference? I look forward to reading your book - it sounds very interesting.

Is Hibernate something you would use to replace an architecture like Struts?
In other words, if we have a struts application, could we re-write it using Hibernate? And would it still run under Websphere or WebLogic?

Does the book provide real world examples of how applications can be made better, faster and lighter?

Thank You very much for your reply - it looks like your book will have a lot of very useful information for us!