In my mind, ServiceMix will be agnostic wrt to the OSGi implementation used. At the same time, I'm thinking about creating a distribution for ServiceMix that
would include Felix runtime...

And yeah, OSGi has never been a dependency so far.

I suggest to take a look at spring-osgi too.
See http://www.springframework.org/osgi
I really think we should use it.

Cheers,
Guillaume Nodet


On Aug 24, 2007, at 7:10 PM, Brian O'Neill wrote:

Guillaume,

Just getting grounded...

Would SM 4.0 leverage Felix to get OSGi capabilities?

I took a grep through the code, it doesn't look like it uses it at all
right now:
[EMAIL PROTECTED]:~/dev/apache.org/servicemix-> grep -r "elix" *
and osgi appears only in the eclipse plugins.

Just verifying, OSGi is a brand new dependency for SM, right?

Which leads me to my second question,  do you think the dependency
would be a hard dependency (on the actual felix impl), or would it be
implementation agnostic? (e.g. able to run on Equinox as well)

I am going to pull felix now and start playing around with it.

-brian

On 8/24/07, Guillaume Nodet <[EMAIL PROTECTED]> wrote:


One topic not covered in this excellent post is a standard mechanism
to provide access to other endpoint metadata (e.g. the WSDL file) -
having that as a standard OSGi metadata would be cool (e.g. a WSDL
URI)

Yeah, I have had a closer look at how OSGi provides URL handlers.
This is not as simple as I thought it would be.  OSGI defines
a "bundle:" protocol that can be used to access resources in the bundle. Unfortunately, the url has to contain the bundle id, which means that the URLs have to be built dynamically. I'm sure we can create a spring
bean factory to create those dynamically though...
Or a post factory processor that would process the URIs to rewrite them
and include the bundle id.

This way, the service could contain a WSDL_URL property associated
with it (when registered in the OSGi registry) that would be a bundle url
pointing to the wsdl inside the bundle.  This would solve one of JBI
limitation
which is the ability to have complex WSDLs definitions including other
WSDL or XSD.


I've been thinking about that a bit more.
It seems to me that using a kind of PropertyPlaceHolder (i.e. a
BeanFactoryPostProcessor) sounds like a good idea.
It could check all properties and perform replacement of an url like:
   bundle-ext://org/test/dummy.wsdl
to
   bundle://7.0/org/test/dummy.wsdl
where 7.0 is the bundle id.

Another extension could be a spring bean factory that expose a blob of
xml to an url
for other bundles to consume. Inside your spring definition file, one
would have:

<smx-osgi:export-xml url="org/test/dummy.wsdl>
  <wsdl:description ...>
     ...
  </wsdl:description>
</smx:osgi>

Thus a single configuration file (the spring one) could contain blob
of xml (well,
not only xml i guess) that could be exposed as an url.

I think the first idea will prove really useful to expose a WSDL to
other bundles.
I'm not so sure about the second one...

--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/



--
Brian ONeill
Source Equity (http://www.sourceequity.com)
jBIZint (http://www.jbizint.org)
Technical Architect, Gestalt LLC (http://www.gestalt-llc.com)
mobile:215.588.6024

Reply via email to