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]
