Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Archived » Eclipse Communications Framework (ECF) » Simple Headless XMPPS Container
Simple Headless XMPPS Container [message #615258] Fri, 20 April 2007 11:51 Go to next message
Bob Brady is currently offline Bob BradyFriend
Messages: 7
Registered: July 2009
Junior Member
Hi ECF,

Sorry for the repost, I made mistake but now try make tidy.

I need to use the ECF libs in a headless, programmatic way outside of
OSGi/Eclipse runtime. The code I've used in the past allowed me to add
the Container type description so that I could get an IContainer from
the factory and proceed with getting a connection.

Unfortunately, the API has changed quite a bit and the working code I
had is now broken. Could somebody help me out with a working code
snippet to create an ecf.xmpps.smack container outside of Eclipse?

The old working code is below. I tried experimenting with
BaseContainerInstantiator, but now even ContainerFactory.getDefault() is
throwing NullPointerExceptions in headless, non-Eclipse runtime.

Thanks,
Bob


Old ECF 0.7-0.8 Working Code

// Create IContainerInstantiator manually
IContainerInstantiator instantiator = new ContainerInstantiator();

// Create a container description that associates the
// appropriate name with the instantiator
// These values from org.eclipse.ecf.example.collab plugin.xml
//<containerFactory> element

String[] argTypes =
{"org.eclipse.ecf.core.identity.ID","java.lang.Integer"};
String[] argDefaults = {"","30000"};
String[] argNames = {"id", "keepAlive"};


// Generic used here, but ecf.xmpps.smack desired
ContainerTypeDescription cd = new
ContainerTypeDescription("ecf.generic.client",
instantiator,"ecf.generic.client", argTypes, argDefaults, argNames);

// Add this new description to ContainerFactory
IContainerFactory factory = ContainerFactory.getDefault();
factory.addDescription(cd);
Re: Simple Headless XMPPS Container [message #615261 is a reply to message #615258] Fri, 20 April 2007 17:47 Go to previous messageGo to next message
Scott Lewis is currently offline Scott LewisFriend
Messages: 1038
Registered: July 2009
Senior Member
Hi Bob,

As you've discovered, we have been moving away from maintaining support
for non OSGi/Equinox runtimes. The reason for this is that as we do
more and more that depends upon the Equinox runtime (use OSGi services,
extension registry, logging, etc), and the Equinox runtime itself
changes, it becomes much harder to avoid violating the runtime
constraints of other environments (e.g. java applications WRT
initialization of plugins, classloading assumptions, etc).

I think the problems you are currently experiencing are probably a
result of my work on this bug:

https://bugs.eclipse.org/bugs/show_bug.cgi?id=176322

I suspect what happened here is that in order to allow ECF to have
minimal dependencies on Eclipse's core runtime (and *only* the minimal
dependencies on Equinox's common and util classes as per this
bug...which exist on all Equinox versions...e.g. eRCP, servers, Eclipse,
RCP, etc) I suspect that the core runtime jar that you are using now no
longer contains some of the interfaces and classes that the ECF core
code references...and so the ECF core stuff can't be loaded/instances
created because these classes can't be found (and/or because no 'start'
method is being called as application). It may very well run if you
provide other/new jars in the application classpath (see the 'Plug-in
Dependencies for the given plugins in Eclipse/PDE).

So I guess at this point I have to ask Bob and everyone: how important
is it that ECF be able to run in non-OSGi runtimes?

Because if we try to maintain the ability to run in both OSGi runtimes
(with minimal constraints as per bug above) AND try to run as java
application outside of OSGI runtime it may become extremely difficult to
maintain this.

Obviously I/we want to be able to run ECF code in as many runtimes as
possible (which is really why we made the changes described in 176322),
but we're at a point where this can/will become quite difficult for a
small team.

Scott


Bob Brady wrote:
> Hi ECF,
> S
> Sorry for the repost, I made mistake but now try make tidy.
>
> I need to use the ECF libs in a headless, programmatic way outside of
> OSGi/Eclipse runtime. The code I've used in the past allowed me to add
> the Container type description so that I could get an IContainer from
> the factory and proceed with getting a connection.
>
> Unfortunately, the API has changed quite a bit and the working code I
> had is now broken. Could somebody help me out with a working code
> snippet to create an ecf.xmpps.smack container outside of Eclipse?
>
> The old working code is below. I tried experimenting with
> BaseContainerInstantiator, but now even ContainerFactory.getDefault() is
> throwing NullPointerExceptions in headless, non-Eclipse runtime.
>
> Thanks,
> Bob
>
>
> Old ECF 0.7-0.8 Working Code
>
> // Create IContainerInstantiator manually
> IContainerInstantiator instantiator = new ContainerInstantiator();
>
> // Create a container description that associates the
> // appropriate name with the instantiator
> // These values from org.eclipse.ecf.example.collab plugin.xml
> //<containerFactory> element
>
> String[] argTypes =
> {"org.eclipse.ecf.core.identity.ID","java.lang.Integer"};
> String[] argDefaults = {"","30000"};
> String[] argNames = {"id", "keepAlive"};
>
>
> // Generic used here, but ecf.xmpps.smack desired
> ContainerTypeDescription cd = new
> ContainerTypeDescription("ecf.generic.client",
> instantiator,"ecf.generic.client", argTypes, argDefaults, argNames);
>
> // Add this new description to ContainerFactory
> IContainerFactory factory = ContainerFactory.getDefault();
> factory.addDescription(cd);
Re: Simple Headless XMPPS Container [message #615267 is a reply to message #615261] Fri, 20 April 2007 23:31 Go to previous messageGo to next message
Scott Lewis is currently offline Scott LewisFriend
Messages: 1038
Registered: July 2009
Senior Member
Hi Bob,

Also, BTW...I did some work today (Friday April 20) and fixed the NPE's
you saw in accessing the ContainerFactory.getDefault(). So it may very
well be that you can/could now get further with setting up the
ContainerFactory manually as you were doing.

If you (Bob) would try out the new code (checked in but not yet
deployed...so you will have to load into workspace and compile) and let
us know if you get further (probably to ecf-dev would be better than
this), then we'll see if we can get you running with xmpp/xmpps.

But I would still like to hear from everyone about the lengths they
would like us to go to support running ECF in java application
environments (e.g.) as I request below.

Scott


Scott Lewis wrote:
> Hi Bob,
>
> As you've discovered, we have been moving away from maintaining support
> for non OSGi/Equinox runtimes. The reason for this is that as we do
> more and more that depends upon the Equinox runtime (use OSGi services,
> extension registry, logging, etc), and the Equinox runtime itself
> changes, it becomes much harder to avoid violating the runtime
> constraints of other environments (e.g. java applications WRT
> initialization of plugins, classloading assumptions, etc).
>
> I think the problems you are currently experiencing are probably a
> result of my work on this bug:
>
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=176322
>
> I suspect what happened here is that in order to allow ECF to have
> minimal dependencies on Eclipse's core runtime (and *only* the minimal
> dependencies on Equinox's common and util classes as per this
> bug...which exist on all Equinox versions...e.g. eRCP, servers, Eclipse,
> RCP, etc) I suspect that the core runtime jar that you are using now no
> longer contains some of the interfaces and classes that the ECF core
> code references...and so the ECF core stuff can't be loaded/instances
> created because these classes can't be found (and/or because no 'start'
> method is being called as application). It may very well run if you
> provide other/new jars in the application classpath (see the 'Plug-in
> Dependencies for the given plugins in Eclipse/PDE).
>
> So I guess at this point I have to ask Bob and everyone: how important
> is it that ECF be able to run in non-OSGi runtimes?
>
> Because if we try to maintain the ability to run in both OSGi runtimes
> (with minimal constraints as per bug above) AND try to run as java
> application outside of OSGI runtime it may become extremely difficult to
> maintain this.
>
> Obviously I/we want to be able to run ECF code in as many runtimes as
> possible (which is really why we made the changes described in 176322),
> but we're at a point where this can/will become quite difficult for a
> small team.
>
> Scott
>
>
> Bob Brady wrote:
>> Hi ECF,
>> S
>> Sorry for the repost, I made mistake but now try make tidy.
>>
>> I need to use the ECF libs in a headless, programmatic way outside of
>> OSGi/Eclipse runtime. The code I've used in the past allowed me to
>> add the Container type description so that I could get an IContainer
>> from the factory and proceed with getting a connection.
>>
>> Unfortunately, the API has changed quite a bit and the working code I
>> had is now broken. Could somebody help me out with a working code
>> snippet to create an ecf.xmpps.smack container outside of Eclipse?
>>
>> The old working code is below. I tried experimenting with
>> BaseContainerInstantiator, but now even ContainerFactory.getDefault()
>> is throwing NullPointerExceptions in headless, non-Eclipse runtime.
>>
>> Thanks,
>> Bob
>>
>>
>> Old ECF 0.7-0.8 Working Code
>>
>> // Create IContainerInstantiator manually
>> IContainerInstantiator instantiator = new ContainerInstantiator();
>>
>> // Create a container description that associates the
>> // appropriate name with the instantiator
>> // These values from org.eclipse.ecf.example.collab plugin.xml
>> //<containerFactory> element
>>
>> String[] argTypes =
>> {"org.eclipse.ecf.core.identity.ID","java.lang.Integer"};
>> String[] argDefaults = {"","30000"};
>> String[] argNames = {"id", "keepAlive"};
>>
>>
>> // Generic used here, but ecf.xmpps.smack desired
>> ContainerTypeDescription cd = new
>> ContainerTypeDescription("ecf.generic.client",
>> instantiator,"ecf.generic.client", argTypes, argDefaults, argNames);
>>
>> // Add this new description to ContainerFactory
>> IContainerFactory factory = ContainerFactory.getDefault();
>> factory.addDescription(cd);
Re: Simple Headless XMPPS Container [message #615276 is a reply to message #615267] Wed, 25 April 2007 13:39 Go to previous message
Bob Brady is currently offline Bob BradyFriend
Messages: 7
Registered: July 2009
Junior Member
Scott Lewis wrote:
> Also, BTW...I did some work today (Friday April 20) and fixed the NPE's
> you saw in accessing the ContainerFactory.getDefault(). So it may very
> well be that you can/could now get further with setting up the
> ContainerFactory manually as you were doing.

Thanks a lot Scott!
>
> If you (Bob) would try out the new code (checked in but not yet
> deployed...so you will have to load into workspace and compile) and let
> us know if you get further (probably to ecf-dev would be better than
> this), then we'll see if we can get you running with xmpp/xmpps.

I'll do that. I'm swamped right now, but will report back as soon as I can.

-Bob
Previous Topic:ECF Bundle Documentation
Next Topic:ECF dev build 4.24.2007
Goto Forum:
  


Current Time: Fri Apr 19 15:20:45 GMT 2024

Powered by FUDForum. Page generated in 0.01936 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top