[news.eclipse.technology.ecf] Re: org.eclipse.ecf.example.collab problem

[Scott Lewis <slewis@xxxxxxxxxxxxx>]

Hi Simon,

Yes...thanks for the fix!

Scott

Simon Li wrote:
> Hi, Scott and Li-Te
>
> I have the same "class not found" problem while MANIFEST.MF file is correct.
> I checked the run configuration, in class path page, I found
> org.eclipse.ecf.example.collab was not in the user entry.
>
> I solved it by adding that project.
>
> My enviorment:
> Win2000 Sp4,
> Eclispe SDK 3.1M6,
> emf-sdo-xsd-SDK-I200504070700.zip
> org.eclipse.ecf-1.0.0.M1.zip
>
> Best Regards!
> Simon
>
> "Li-Te" <li-te_cheng@xxxxxxxxxx> wrote in message
> news:420A65A6.8090807@xxxxxxxxxxxxx
>
> > Hi Scott,
> >
> > Ok - it was indeed a problem with the MANIFEST.MF file.  I refreshed it
> > and the example app works fine now.
> >
> > Thanks,
> >
> > Li-Te
> >
> > Scott Lewis wrote:
> >
> > > Hi Li-Te,
> > >
> > > Thanks for the info...couple of comments and questions below:
> > >
> > > Li-Te wrote:
> > >
> > >
> > > > Hi,
> > >
> > > <stuff deleted>
> > >
> > > > Now the joinGroup call appears to be successful.  There must be a typo
> > > > somewhere with an extra slash.
> > >
> > >
> > > OK...I did find a typo and fixed in the source/config files.  Thanks.
> > > Getting an update for the org.eclipse.ecf.example.collab and
> > > org.eclipse.ecf.provider plugins will get you the fixed code.
> > >
> > >
> > >
> > > > b) ClassNotFoundException: RemoteSharedObjectMsgEvent
> > >
> > > <stack trace deleted>
> > >
> > > > It looks like a classloader problem with RemoteSharedObjectMsgEvent,
> > > > which is defined in the org.eclipse.ecf.example.collab plugin, whereas
> > > > the rest of the ECF Event classes are found in the org.eclipse.ecf
> > > > plugin.
> > >
> > >
> > > There's a feature of OSGI that we are depending upon here...and that's
> > > provided via the 'DynamicImport-Package' property in the
> > > org.eclipse.ecf.provider plugin.  In the manifest.mf file in the
> > > org.eclipse.ecf.provider plugin is a line that looks like this:
> > >
> > > DynamicImport-Package: *
> > >
> > > The OSGI-spec'd behavior for this is that any classes exposed by other
> > > plugins (via the Export-Package: property in manifest.mf) should be
> > > seen/loaded by the plugin declaring the DynamicImport-Package wildcard
> > > as above.  So in the manifest.mf for the org.eclipse.ecf.example.collab
> > > plugin should be:
> > >
> > > Export-Package: org.eclipse.ecf.example.collab.share,
> > > org.eclipse.ecf.example.collab.share.url,
> > > org.eclipse.ecf.example.collab.share.io
> > >
> > > (on one line)
> > >
> > > And this *should* allow the org.eclipse.ecf.provider plugin classloader
> > > (the one doing the object deserialization) to find the
> > > org.eclipse.ecf.example.collab.share.RemoteSharedObjectMsgEvent class,
> > > load it, and deserialize the stream.
> > >
> > > This is working fine for my/our tests...I'm currently at a loss as to
> > > why it would not be working for you.  Can you make sure that the
> > > respective manifest.mf files have the lines above in them (they do in
> > > the checkedin versions...I just checked now).
> > >
> > > Then, assuming they are there in your copies...what platform are you
> > > running on and what version of Eclipse are you using?  Is there a chance
> > > that the OSGI behavior for classloading is not working right on that
> > > platform/version?
> > >
> > > I will also attempt to reproduce on my machine given a whole new
> > > installation/etc.  I would appreciate any further assistance you can
> > > give on this, as it's obviously important to make sure that this
> > > mechanism works as expected until ECF puts something else in place (i.e.
> > > to allow plugins to register their packages with providers rather than
> > > using DynamicImport-Package.
> > >
> > > Thanks,
> > >
> > > Scott
> > >
> > >
> > >
> > > > Any thoughts?
> > > >
> > > > Thanks,
> > > >
> > > > Li-Te