Hello again,
thanks for your questions. With regards to your first question, I
think it's basically the same answer as I posted earlier today, that
you can create an ObjectInputStream associated with an arbitrary
HelperContext.
However, as an aside, I realised in my earlier response that I perhaps
slightly misrepresented the SDO API's capability, saying that it has
no way to deal with your issue. That's a slight inaccuracy, since we
are using SDO's API to read the object, but just providing a
customised ObjectInputStream, so I should have said that the SDO API
has no explicit means of solving the issue, but currenlty relies on
implementations to do the kind of thing we have done by providing a
specialised ObjectInputStream.
As to your second question, If I understand it correctly you are
addressing similar issues to Christian as reported here
https://issues.apache.org/jira/browse/TUSCANY-1113. It's worth
following the link in Christian's JIRA through to the earlier
discussions on the mailing list, since updating types and namespaces
has its pitfalls. However, I think if you create your HelperContexts
using the org.apache.tuscany.sdo.api.SDOHelper#createHelperContext(boolean)
method that was introduced as part of the fix for that JIRA then I
think that may get you along the way to solving your issues.
Regards, Kelvin.
On 30/11/2007, EG Koron [EMAIL PROTECTED] wrote:
Recently I have used sdo in my works.In my works distributed EJB component
will cooperate with each other while using sdo as parameter. While using the
SDO, I find that
1)If each EJB create it's own scope(HelpContext), and define types in . So
while EJB container received incoming calling and UnSerialize Object , a
type not found exception raised.
After checking the source code in JDK and SDO, I find the while calling
ObjectOutputStream.writeObject(), JDK will call the writeReplace Method in
DataObjectImpl, and the DataObjectImpl.writeReplace will return a
ExternalizableDelegator whose target is set as the DataObject itself. However
while ObjectInputStream.readObject(), JDK will just create a
ExternalizableDelegator whose target is set null. so by default, all type
info will got from default scope. so the type not found exception raised;
So Is there some way could choice the scope, that I have not seen in SDO?
2) If all EJB in one JavaVM using same the default scope to store metadata,
but while I change the xsd(store type description), and redeploy the EJB ,
then using xsdHelper.define() to redefine the changed xsd. I found the
changed type isnot been update in default scope.
So is there some way I could control xsdHelper.define() to update type info
Thanks
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
