Andy Piper

Hi Gildas

Gildas Cuisinier wrote:With Spring Dm, it is possible to import and export services at application startup.

Yes - this is the default behaviour. Services defined/referenced using <osgi:service> and <osgi:reference>
are defined when the application context is created.

Gildas Cuisinier wrote:
On import, it is possible to define a cardinality 0, to make the service optional. What is practical.

Yes, that's cardinality "0..1"

Gildas Cuisinier wrote:
But on the export, it exports all configured services at bundle startup.
But is it possible to export services dynamically?

Sure, you can use the OsgiServiceFactoryBean directly and create it lazily. There is a registerService property that you
can set to control this behaviour (or at least there was, haven't checked recently)

Gildas Cuisinier wrote:
Use case
If a condition is verified, a service will be exported.
Once this condition changes, the service will be unpublished from the OSGi registry.
Once the condition is verified again, the service will be exported again.

Does SpringDm provided a mechanism for that, or do we necessarily use the OSGi API manually?

At some point it may be easier to use the OSGi API manually, or you can maniulate the bean registry directly
to create/destroy the beans you are interested in.

David Newton wrote:It does, thanks. I work on some apps that have their own classloaders and was wondering if they'd conflict with how OSGi does its classloading--haven't had time to look into it at all yet.

David, there would almost certainly be some interaction. How much pain you feel would probably be proportional to how OSGi conformant you want your application to be. Obviously you can do things like put things on the bootclasspath to subvert pretty much all of OSGi's classloading behaviour and not feel any pain at all - but if you want to reap the benefits of OGSi you might need to look more carefully at how the app doe classloading.

For context we (Oracle in the CEP product that I work on) use custom classloaders for certain behaviour inside our OSGi container and it works fine.

Johan Pelgrim wrote:Hi Thierry & Andy,

In your opinion, what has been the adoption level of the Spring dm Server (and maybe OSGI in general) up to this point and how will the submission of the dm Server project to the Eclipse foundation contribute to that?

http://www.eclipse.org/proposals/virgo

Cheers,

Johan Pelgrim
The Netherlands

Hi Johan,

That's a good question. Remember that I work for Oracle (ex BEA) so my perspective may be a little biased - and this answer is only my personal opinion

I believe that dm Server has been trying unsuccessfully to compete head-to-head with WebLogic Server (and others). The problem is that it doesn't have the features or
hardening that enterprise customers expect and also the group that may be in favor using of dm Server (the developers) are not the ones making the buying decisions.
I think the fact that dm Server is being donated to Eclipse is probably because it is not gaining sufficient traction.

As to how its donation will change the OSGi landscape, that's really hard to say. Obviously the issue is that there are already other open source servers out there so
customers really need to believe that dm Server delivers superior value in order to choose it over another. That probably means customers already using Spring and OSGi
which must be a very small subset. I think the real value of the Gemini project in general is that it will mean many OSGi components are developed as open source and therefore can be readily adopted by customers and vendors alike. Virgo will no doubt contribute to that process by providing an integrated platform for people to experiment with and
also encourage the development of an ecosystem which surely must be vital to the adoption of OSGi.

andy

Hello

Gildas Cuisinier wrote:Does the book deals with Spring Dm assuming that the server used is Spring DM Server (now aka Virgo) or is agnostic of any specific server?

The book is almost entirely agnostic to the specific server used and deals with the specifics of Spring DM itself. We talk about dm Server a little, but not a great deal.

Gildas Cuisinier wrote:Specifically, Dm Server allows using JPA easily with PAR Archive, but this archive format is specific to DM Server.
Does your book present the use of JPA in a portable way?

Yes, we discuss how to use JPA without the need for invoking any proprietary extensions such as the PAR format.

andy