Hello Bill,
The marshalling problem on the Value objects can easily be avoided if you calculate the serialVersionUID manually by using the serialver tool on each of your value objects. You just need to establish guidelines, which define when to re-calculate the serialVersionUID (The most conservative approach would be to recalculate it whenever you make a change to the value object).
The steps which you would need to apply to each of your value objects would be:
- Use serialver tool on the class --> will give you a unique number
- Define "static final long serialVersionUID" in your value object and initialize it with the return value from the
serialver tool
- compile, package and deploy as with any other hava class
The following article might be helpful.
Regards
Gallus
http://www.jguru.com/faq/view.jsp?EID=5063
-----Original Message-----
From: Koscho, William [mailto:william_koscho@(protected)]
Sent: Wed 11/5/2003 9:41 AM
To: J2EEPATTERNS-INTEREST@(protected)
Cc:
Subject: Re: EJB Versioning
Why would we get the marshalling problem? Maybe I don't understand the details of it enough....could you explain a little more? Won't the container regenerate a proxy for the client?
Bill
-----Original Message-----
From: An interest list for Sun Java Center J2EE Pattern Catalog [mailto:J2EEPATTERNS-INTEREST@(protected)
Sent: Wednesday, November 05, 2003 10:29 AM
To: J2EEPATTERNS-INTEREST@(protected)
Subject: Re: EJB Versioning
We are trying to solve same problem here. But we have not found a way to get this problem solve. I suppose what you are doing can solve the interface problem, but what about the Value Object versioning. I believe you might getting marshalling error since all your value object gets recompiled when you generate the new Bean for version 1.1.
Scott
-----Original Message-----
From: An interest list for Sun Java Center J2EE Pattern Catalog [mailto:J2EEPATTERNS-INTEREST@(protected)
Sent: Wednesday, November 05, 2003 5:59 AM
To: J2EEPATTERNS-INTEREST@(protected)
Subject: EJB Versioning
I would like to be able to deploy multiple versions of an EJB, and have multiple clients select the version that want to use.
For example, I would like to deploy version 1.0 of Bean1 and version 1.1 of Bean1? Then have Client1 choose version 1.0 and Client2 choose version 1.1.
Can the container handle multiple versions of the same bean?
Assuming it cannot and we can only deploy a single version of the bean (i.e. version 1.1 of Bean1), then I can have an env entry in the deployment description with a "VersionNumber" variable. Then the client can check that environment variable once it receives the interface to the bean.
Once it has the version number, I am looking for a pattern to apply that will allow the client to behave differently based on that version. For example, when the client sees version 1.0 it displays the default screen, but when it sees version 1.1, it will call an additional method on the EJB and display an extra combo-box on the UI.
Any help is greatly appreciated.
Thanks,
Bill Koscho
Technical Specialist, Customer Service Development
Medco Health Solutions
Email: william_koscho@(protected)
Pager: 1-800-759-8888 PIN: 1781595
Phone: 201-269-2219
_____
This e-mail message and any attachments contain confidential information from Medco Health Solutions, Inc. If you are not the intended recipient, you are hereby notified that disclosure, printing, copying, distribution, or the taking of any action in reliance on the contents of this electronic information is strictly prohibited. If you have received this e-mail message in error, please immediately notify the sender by reply message and then delete the electronic message and any attachments.
==================================================================== Companion Site: http://www.corej2eepatterns.com J2EE BluePrints: http://java.sun.com/blueprints/corej2eepatterns List Archive: http://archives.java.sun.com/archives/j2eepatterns-interest.html Unsubscribing: email "signoff J2EEPATTERNS-INTEREST" to listserv@(protected)
==================================================================== Companion Site: http://www.corej2eepatterns.com J2EE BluePrints: http://java.sun.com/blueprints/corej2eepatterns List Archive: http://archives.java.sun.com/archives/j2eepatterns-interest.html Unsubscribing: email "signoff J2EEPATTERNS-INTEREST" to listserv@(protected)
_____
This e-mail message and any attachments contain confidential information from Medco Health Solutions, Inc. If you are not the intended recipient, you are hereby notified that disclosure, printing, copying, distribution, or the taking of any action in reliance on the contents of this electronic information is strictly prohibited. If you have received this e-mail message in error, please immediately notify the sender by reply message and then delete the electronic message and any attachments.
==================================================================== Companion Site: http://www.corej2eepatterns.com J2EE BluePrints: http://java.sun.com/blueprints/corej2eepatterns List Archive: http://archives.java.sun.com/archives/j2eepatterns-interest.html Unsubscribing: email "signoff J2EEPATTERNS-INTEREST" to listserv@(protected)
