[RT] The impact of using OSGi

[Carsten Ziegeler <cz...@apache.org>]

A lot of people have asked me during the ApacheCon (and via mail) what
the move to OSGi would mean from a user/developer perspective. So I
think it's time to discuss this a little bit further; we already did
this briefly at the hackathon, but of course we should continue this
here visibile for everyone.

(The following is how I understand/see the whole thing, please correct
me if required).

First of all, we have an RT about the goals for the next version[1]. As
noted there, the goals are independent from OSGi and the vision is to
*explore* OSGi in the next months. So actually using OSGi is not carved
in stone, but currently it looks like OSGi is the best available
alternative.
The most important goal for myself is 7): compatibility. I don't want to
rewrite each and every piece of code we've done in the past five years.
And I think it's as important to not increase the high learning curve by
introducing another "thing". Ok, from what we discussed in the last
weeks, it seems to me that we can achieve these goals.

So, what does all of this OSGi stuff mean? OSGi provides some nice
features, like isolated class loading and depedency resolution. And it's
exactly this where we want to use it.

Although OSGi is a component container by itself, we will not replace
ECM with the OSGi one. This means for a java developer nothing really
changes, you just use ECM like you did before or you use
Spring/Hivemind/Pico/whatever like you did before. Everything looks the
same.

Underneath, our own ECM implementation will use OSGi to get components
from another bundle, but this is totally transparent. The only thing you
have to do is defining your block dependencies properly. By this our own
ECM implementation will be able to lookup components from the blocks you
depend on.

For a Cocoon user (writing sitemaps, using xml and xslt) everything
should stay the same. It just works like it does today.

Now, there is one thing to consider: using OSGi means, everything is a
bundle. So whatever you develop, it must be a bundle. Currently people
are using totally different ways of developing. Some are using directly
Eclipse, others are using build systems (which copy files to the webapp
directory), others are using the compiling classloader etc. And there is
no "single right way". For me right now, this is the challenging part.
We must enable rapid development (we have it in the goals as number 3)
and I think this should not require any OSGi knowledge. I hope we get at
this point. Later on, for deployment it's ok to define the dependencies
and whatever is required.

The first time I talked with Stefano about this topic (when he visited
us in Paderborn - gosh, is this really now nearly three years ago?) we
talked about a smooth migration path: you could simply use your old
applications as they are for 2.1.x without using bundles/blocks and they
would simply still work (with all the disadvantages of course). Or you
could "migrate" and use the (new) blocks. I'm not sure anymore how we
wanted to achieve this, but I think the basic idea was to just deploy
the whole cocoon application as a big single block including everything.

On this topic, what do people expect in terms of performance? (I know it
might be a little bit early) With OSGi we add another layer/isolation,
so does this cost performance significantly?

BTW, what is the status about the dependency definition (block.xml).
What are we planning to use?

Regards
Carsten

[1] http://marc.theaimsgroup.com/?t=112177144100004&r=1&w=2
-- 
Carsten Ziegeler - Open Source Group, S&N AG
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/

Re: [RT] The impact of using OSGi

[Sylvain Wallez <sy...@apache.org>]

Bertrand Delacretaz wrote:

> Le 25 juil. 05, à 10:31, Sylvain Wallez a écrit :
>
>> ...- from a technical POV, OSGi is lightweight and has at least 3 
>> robust opensource implementations. So we just have to use one of 
>> them, and not spend time about writing the container. And this as an 
>> immediate effect: during the ApacheCon hackaton, the question that 
>> were raised where of much lower level than those we ever had before 
>> regarding real blocks...
>
>
> I take it that you mean much *higher* level ;-)


Well, high or low, it all depends on how you turn it :-)

By "lower level", I meant questions closer to implementation problems, 
and not brainstorming about what blocks should be.

> And I agree, one big benefit of going for OSGI for the classloading 
> machinery is that it helps us focus on our "core business".


Exactly.

Sylvain

-- 
Sylvain Wallez                        Anyware Technologies
http://apache.org/~sylvain            http://anyware-tech.com
Apache Software Foundation Member     Research & Technology Director

Re: [RT] The impact of using OSGi

[Bertrand Delacretaz <bd...@apache.org>]

Le 25 juil. 05, à 10:31, Sylvain Wallez a écrit :
> ...- from a technical POV, OSGi is lightweight and has at least 3 
> robust opensource implementations. So we just have to use one of them, 
> and not spend time about writing the container. And this as an 
> immediate effect: during the ApacheCon hackaton, the question that 
> were raised where of much lower level than those we ever had before 
> regarding real blocks...

I take it that you mean much *higher* level ;-)

And I agree, one big benefit of going for OSGI for the classloading 
machinery is that it helps us focus on our "core business".

BTW, for people who haven't seen it yet, a summary of what we did and 
discussed is available at 
http://wiki.apache.org/cocoon/Blockathon2005Report

-Bertrand

Re: [RT] The impact of using OSGi

[Niclas Hedhman <ni...@hedhman.org>]

On Wednesday 10 August 2005 21:46, Upayavira wrote:
> The question
> is, what if a piece of configuration information is needed by OSGi _and_
> Cocoon, because our use-case is broader than that of OSGi. Should we use
> the manifest.mf file and have our own systems consume that as well as
> OSGi, or alernatively use the block.xml file, and have manifest.mf
> generated from that.

AFAIU, extending the use of the Manifest is "Ok" from both Java's and OSGi's 
point of view. If manifest headers of "Cocoon-XYZ" format is used, I am 
pretty confident that there are no future "issues" with conflicting names.

My own usage pattern is basically; Use a single manifest entry to point to a 
resource within the bundle which contains further information about what one 
is trying to do. But, in the case of "real blocks" I foresee that there are 
some overlap between the "classloading mechanism" needed from OSGi and 
"SiteMap resolutions" provided by Cocoon core, which would suggest that the 
"raw data" is in source form of Cocoon's chosen format, and relevant 
"compilers" creates the necessary division into one, two or more runtime 
parts required.
(This is when you don't want to depend on Maven 1 ;o) )

On a related note, some thought is probably required to "draw the line in the 
sand" for what is Core API and pure implementation. Although startlevels can 
ensure starting orders and that missing classes in a bundle therefor can be 
supplied properly, I get the impression that this is "bad practice" and that 
each bundle should carry all the classes required for its full instantiation.
OSGi will take care of which actual class instance that will be used.
Export of the entire Cocoon codebase of today seems like a bad idea, yet there 
is no good line in the older parts what is api vs implementation. General 
rule; start small and expand with need.


Also, I am in the process of creating a Log4J bundle for OSGi, and I am 
totally open to suggestions on the best way forward with this. The generic 
LogService is indeed very rudimentary, and can potentially be very slow 
(object creation when not needed), but I think there should be an integrated 
solution of both the OSGi LogService as well as some better API, such as 
SLF4J or Jakarta commons-logging, in the same implementation.
I assume that the result will either be hosted at Apache Logging or the new 
Apache OSGi project.


Just my few thoughts on the subject.


Cheers
Niclas

Re: [RT] The impact of using OSGi

[Upayavira <uv...@odoko.co.uk>]

Carsten Ziegeler wrote:
> Daniel Fagerstrom schrieb:
> 
>>At some point in time, e.g. now ;) we need to decide that we go for 
>>OSGi. Keeping all roads open at all time means that we just reinvent 
>>whats allready is standardized in OSGi.
>>
>>For functionality that we allready have, we must of course respect back 
>>compability and write wrappers beween what we have and the new OSGi 
>>based implementations. But for new functionallity I think that we should 
>>reuse as much as possible of what allready is in OSGi.
>>
>>
> 
> I think we should use OSGi *just* for the "core blocks" implementation
> which is class loading, versioning and installation and that's it.
> But that's just my opinion.

I would say that it would certainly make sense to start there. As time 
passes, the Oscar(whatever) project matures, we can start using more of 
its generic services where they help us. But for now, it probably makes 
sense to just use the necessary.

Regards, Upayavira

Re: [RT] The impact of using OSGi

[Daniel Fagerstrom <da...@nada.kth.se>]

Niclas Hedhman wrote:

>On Thursday 11 August 2005 06:34, Vadim Gritsenko wrote:
>  
>
>>Isn't it the first goal to make (any) existing block (with no code
>>modifications) run under OSGi?
>>    
>>
>
>AFAIU, Existing blocks would run unchanged in the ECM<->OSGi bridge bundle.
>
>I think Daniel is talking "real blocks" here,
>
I guess we want to move the existing "compile time" blocks to real 
blocks, (whatever that means).

> and I think that would require 
>the blocks to have OSGi code in them, at least for the Bundle Activator and 
>ServiceFactory. 
>
At least that is IMO the preferable approach (see my previous mail).

>Of course there is an option to make a Cocoon specific 
>abstraction level on top of the basic OSGi mechanisms, but to me it seems to 
>only hamper the progress, resulting in endless debates of what to expose and 
>not.
>  
>
Agree, we have an oportunity to make the block level of Cocoon an open 
standard based architecture that makes it easy for external projects to 
provide blocks. And we also have the chance to colaborate actively with 
other Apache projects for common inreastructure and bundles, and 
fullfill some of the promises from Avalon that its community dynamics 
killed.

But that will not happen automatically, we need to keep our emotional 
need for NIH under strict control to make it happen.

>Put the stick in the ground. Declare "OSGi bundles is the plugin mechanism for 
>Cocoon." Then move from there. :o)
>  
>
+1000!

/Daniel

Re: [RT] The impact of using OSGi

[Nicola Ken Barozzi <ni...@apache.org>]

Niclas Hedhman wrote:
> On Thursday 11 August 2005 06:34, Vadim Gritsenko wrote:
> 
>>Isn't it the first goal to make (any) existing block (with no code
>>modifications) run under OSGi?
> 
> AFAIU, Existing blocks would run unchanged in the ECM<->OSGi bridge bundle.
> 
> I think Daniel is talking "real blocks" here, and I think that would require 
> the blocks to have OSGi code in them, at least for the Bundle Activator and 
> ServiceFactory. Of course there is an option to make a Cocoon specific 
> abstraction level on top of the basic OSGi mechanisms, but to me it seems to 
> only hamper the progress, resulting in endless debates of what to expose and 
> not.

This had come up during the first Blockathon day when I was present, and
it seemed to me that there were no real objections. OSGi is not a plain
POJO system, and in part this is nice as it does not depart too much
from some Avalon constructs.

> Put the stick in the ground. Declare "OSGi bundles is the plugin mechanism for 
> Cocoon." Then move from there. :o)

Build it, show it, and if there are objections, let them be in code.

-- 
Nicola Ken Barozzi                   nicolaken@apache.org
            - verba volant, scripta manent -
   (discussions get forgotten, just code remains)
---------------------------------------------------------------------

Re: [RT] The impact of using OSGi

[Niclas Hedhman <ni...@hedhman.org>]

On Thursday 11 August 2005 06:34, Vadim Gritsenko wrote:
> Isn't it the first goal to make (any) existing block (with no code
> modifications) run under OSGi?

AFAIU, Existing blocks would run unchanged in the ECM<->OSGi bridge bundle.

I think Daniel is talking "real blocks" here, and I think that would require 
the blocks to have OSGi code in them, at least for the Bundle Activator and 
ServiceFactory. Of course there is an option to make a Cocoon specific 
abstraction level on top of the basic OSGi mechanisms, but to me it seems to 
only hamper the progress, resulting in endless debates of what to expose and 
not.

Put the stick in the ground. Declare "OSGi bundles is the plugin mechanism for 
Cocoon." Then move from there. :o)

Cheers
Niclas

Re: [RT] The impact of using OSGi

[Reinhard Poetz <re...@apache.org>]

Daniel Fagerstrom wrote:

> In the active approach we need to continue the work that Sylvain has 
> started, and we need to decide what to export from each block - 
> everything or just the API.
> 
> Anyway, as the active approach is more scalable and the passive one 
> requires some work to be done that not will be reused if we continue 
> with the active approach, it seemed better to me (and others) to start 
> with the active approach right away.

The "passive approach" leads to too many expored packages as the component 
manager is in the core bundle and it has to have access to all necessary 
packages in order to do its job. IMO this is a prove of concept but not more.

If we want to do the things right, we have to go for the "active approach" to 
get all the advantages Daniel mentioned. Except that we have to restructure 
things, which is of course painful, I can't see any disadvantages. Hence a clear 
+1 for the active approach from me.

IMO we should get it working and then we will do as much as possible to make 
this next-generation Cocoon as backwards-compatible as possible and provide the 
necessary migration information to package Cocoon 2.1 applications as a block 
(bundle).

-- 
Reinhard Pötz           Independent Consultant, Trainer & (IT)-Coach 

{Software Engineering, Open Source, Web Applications, Apache Cocoon}

                                        web(log): http://www.poetz.cc
--------------------------------------------------------------------

	

	
		
___________________________________________________________ 
Gesendet von Yahoo! Mail - Jetzt mit 1GB Speicher kostenlos - Hier anmelden: http://mail.yahoo.de

Re: [RT] The impact of using OSGi

[Niclas Hedhman <ni...@hedhman.org>]

On Friday 12 August 2005 21:07, Vadim Gritsenko wrote:
> > whereas Daniel is making a more evolutionary approach
> > starting with what OSGi *is*, and continue from there with "solutions to
> > use-cases".
>
> I don't see what usecase it can possibly solve if it does not provide
> necessary level of isolation blocks need.

The OSGi specification is fairly exact on many isolation points.
Bundles are classloader isolated, and if the bundles play the game according 
to the specification, then the full isolation needed will be provided.

Some of the "need to play along" are;

 *  If you call bundleContext.getService(), i.e. a lookup, you must call the 
bundleContext.ungetService() when you no longer need it.

 *  If you hold on to a service for long (undefined), you should implement a 
ServiceListener and call ungetService(), when the service is removed. You 
should also unget it and get a new reference if the service is modified.

The above is essentially a matter of letting go of references to instances, so 
that the classes can be GCed.


The specification is fairly clear that for when a bundle is installed or 
started, only 2 possible outcomes are allowed;

  * Successful.
  * Failure, and the state of the entire platform must be identical to the 
state prior to attempting the operation.


As for multiple versions of the same service;

OSGi has covered this in the specification as well. Again, it is fairly 
important that bundles plays by the rules, and unfortunately one can get away 
with not playing too well.

<quote src="R3 spec" >
The Export-Package manifest header allows a bundle to export Java packages to 
other bundles, exposing the packages to other bundles. The Framework must 
guarantee that classes and resources in the exported package's name-space are 
loaded from the exporting bundle. Additionally, the package's classes and 
resources must be shared among bundles that import the package. See Importing 
Packages on page 48. If more than one bundle declares the same package in its 
Export-Package manifest header, the Framework controls the selection of the 
exporting bundle. The Framework must select for export the bundle offering 
the highest version of the declared package.
</quote>

Furthermore;

<quote src="R3 spec" >
Exporting a package does not imply that the exporting bundle will actually use 
the classes it offers for export. Multiple bundles can offer to export the 
same package; the Framework must select only one of those bundles as the 
exporter. A bundle will implicitly import the same package name and version 
level as it exports, and therefore a separate Import-Package manifest header 
for this package is unnecessary. If the bundle can function using a lower 
specification version of the package than it exports, then the lower version 
can be specified in an Import-Package manifest header.
</quote>

This means that exported (i.e. public) packages has a whole set of 
compatibility requirements attached to them, which IMVHO is a GoodThing.

Classes/interfaces that are not part of exported packages (e.g. Eclipse places 
them in package names "internal") are classloader separated and only a 
concern within the Bundle.

<quote src="R3 spec." >
=== Recommended Export Strategy ===

Although a bundle can export all its classes to other bundles, this practice 
is discouraged except in the case of particularly stable library packages 
that will need updating only infrequently. The reason for this caution is 
that the Framework may not be able to promptly reclaim the space occupied by 
the exported classes if the bundle is updated or uninstalled. 

Bundle designs that separate interfaces from their implementations are 
strongly preferred. The bundle developer should put the interfaces into a 
separate Java package to be exported, while keeping the implementation 
classes in different packages that are not exported. 

If the same interface has multiple implementations in multiple bundles, the 
bundle developer can package the interface package into all of these bundles; 
the Framework must select one, and only one, of the bundles to export the 
package, and the interface classes must be loaded from that bundle. 
Interfaces with the same package and class name should have exactly the same 
signature. Because a modification to an interface affects all of its callers, 
interfaces should be carefully designed and remain backward compatible once 
deployed.
</quote>


I hope this provides some confidence that "isolation" is the last of Cocoon's 
worries. :o)
OSGi will, however, not provide much help for the "compile blocks" of today to 
automatically receive any isolation from each other, other than isolation of 
the entire bundle containing the ECM + its blocks. So, the idea of creating a 
bundle that wraps "compile blocks" and in that way creates a "real block", is 
a good idea for migration path. But it should IMHO, not be the primary future 
recommended pattern.



Cheers
Niclas

Re: [RT] The impact of using OSGi

[Vadim Gritsenko <va...@reverycodes.com>]

Niclas Hedhman wrote:
> This discussion is a bit weird, since I think Vadim tries to super-impose the 
> previous/standing definition of what "real blocks" encompass on top of the 
> OSGi architecture,

Of course: the goal is the same, it is just the way to get there is different. 
imho & iiuc.


> whereas Daniel is making a more evolutionary approach 
> starting with what OSGi *is*, and continue from there with "solutions to 
> use-cases".

I don't see what usecase it can possibly solve if it does not provide necessary 
level of isolation blocks need.

Vadim

Re: [RT] The impact of using OSGi

[Niclas Hedhman <ni...@hedhman.org>]

On Thursday 11 August 2005 23:12, Daniel Fagerstrom wrote:
> At component level, you can connect a Map with any
> content to  a service, then you can use a subset of the LDAP query
> language on  these maps during lookup, so each component factory that is
> registred as an OSGi service could certainly be namespaced with a block
> name if we want to.

And the ServiceFactory (OSGi term) will get the Bundle reference of the 
requestor, and could potentially discriminate accordingly.

This discussion is a bit weird, since I think Vadim tries to super-impose the 
previous/standing definition of what "real blocks" encompass on top of the 
OSGi architecture, whereas Daniel is making a more evolutionary approach 
starting with what OSGi *is*, and continue from there with "solutions to 
use-cases".

IMHO, Daniel's approach is more likely to succeed, and not become another 
Cocoon2 excercise, where too grand goals just delayed the project to the 
point of exhausting the folks doing the work.

Daniel (Sylvain?), I suggest that you lay out some basic thoughts on sitemap 
management and custom URL handling, which I think are the critical pieces at 
this point. 
In principle, OSGi bundles are effectively not very relevant to the Cocoon 
discussion. Merely a classloader and application packaging concern. What 
matters are services. And ideally, each service interface is fairly small, 
and allows for implementations that do not depend on heaps of other services.
I think it would be good to see some examples of how that could look like.


Cheers
Niclas

Re: [RT] The impact of using OSGi

[Sylvain Wallez <sy...@apache.org>]

Vadim Gritsenko wrote:

> Daniel Fagerstrom wrote:
>
>> Vadim Gritsenko wrote:
>>
>>> Daniel Fagerstrom wrote:
>>>
>>>> There are two main alternatives: register the component manager as 
>>>> a service or register the components as services. We found the 
>>>> later alternative more atractive as OSGi allready contains a nice 
>>>> and flexible service registration and service lookup mechanism. 
>>>> Adding an extra layer just seemed to complicate things.
>>>
>>>
>>> Not sure it will fly, though.
>>>
>>> First, it means that you are managing 'fine' components with coarse 
>>> container.
>>
>>
>> To be a little bit more exact it is not actual components that are 
>> exposed but component factories.
>
>
> This does not look like a good idea at all. In many scenarios, service 
> (Threadsafe Component) must really be instantiated once in order to 
> work properly. Cron, RunnableManager, DatasourceComponent come to mind.
>
> There is of course set of components which can be instantiated 
> multiple times - Poolables and SingleThreaded.


According to the OSGi specification, a service is a singleton for a 
given bundle: different bundles _can_ be given different objects for the 
same services, but a given bundle will always obtain the _same_ object 
when it asks for a service.

What that means is that only components exposed as singletons can be 
exported as OSGi service and thus between blocks. This means ThreadSafe 
components that already have the singleton semantics and also poolable 
components wrapped in a ThreadSafe proxy that is available in ECM+

When exporting components as OSGi services, the OSGiCoreServiceManager 
registers an OSGi ServiceFactory that wraps an ECM ComponentHandler 
after having controlled that this handler actually manages a singleton.

<snip/>

> Hm... I think you are mixing three concerns here in one:
>
>   (1) How cocoon block obtains classes exported from non-cocoon,
>       pure OSGi block


Classes are obtained as usual by using them (classloader stuff). 
Services are obtained by the good old 
ServiceManager.lookup(ServiceInterface.class.getName()) which is 
implemented as an OSGi service lookup.

>   (2) How cocoon block obtains *component* (not class! not factory!)
>       exported from another cocoon block


ServiceManager.lookup() ! The factory stuff is hidden in 
OSGiConreServiceManager

>   (3) How non-cocoon, pure OSGi block obtains components exported by
>       cocoon block


Cocoon components are exported as OSGi services using their role, which 
happens to be the name of the service interface, as required by OSGi. 
For components having multiple implementations, the hint is stored in 
the OSGi property dictionary used to register the service.

> I suggest to ignore the third and concentrate on second. Third can 
> come later - if ever - if need arise - and can be implemented as you 
> describe it, by exporting each component as a 'service'. First is 
> necessary only if you want to package some .jar files as blocks or use 
> 3rd party blocks, also can be ignored for the time being.


Well, it seems to me we have the 3 of them right now :-)

Sylvain

-- 
Sylvain Wallez                        Anyware Technologies
http://people.apache.org/~sylvain     http://www.anyware-tech.com
Apache Software Foundation Member     Research & Technology Director

Re: [RT] The impact of using OSGi

[Vadim Gritsenko <va...@reverycodes.com>]

Daniel Fagerstrom wrote:
> Vadim Gritsenko wrote:
> 
>> Daniel Fagerstrom wrote:
>>
>>> There are two main alternatives: register the component manager as a 
>>> service or register the components as services. We found the later 
>>> alternative more atractive as OSGi allready contains a nice and 
>>> flexible service registration and service lookup mechanism. Adding an 
>>> extra layer just seemed to complicate things.
>>
>> Not sure it will fly, though.
>>
>> First, it means that you are managing 'fine' components with coarse 
>> container.
> 
> To be a little bit more exact it is not actual components that are 
> exposed but component factories.

This does not look like a good idea at all. In many scenarios, service 
(Threadsafe Component) must really be instantiated once in order to work 
properly. Cron, RunnableManager, DatasourceComponent come to mind.

There is of course set of components which can be instantiated multiple times - 
Poolables and SingleThreaded.


>> I feel that real block should be represented in OSGi as a single 
>> 'Cocoon Block Service'.
> 
> That would IMO make the block architecture unnecesarilly monolithic. For 
> exporting a sitemap service it makes sense to export some kind of Cocoon 
> block service, we need a service that can take a request object and 
> return a response object

Or sitemap InvokeContext and return ProcessingPipeline. Whatever.


> and above that fullfill some protocol for block 
> attributes and polymorphic sitemap extension, that seem rather Cocoon 
> specific.

Ok


> But exporting components, why should that be part of the service that 
> exports sitemap functionality?

So just I better understand your point, how do you envision Batik Block 1.0 and 
Batik Block 2.0 register SVGSerializer service in the OSGi container?

And how consumer which knows he is wired to Batik Block 'Latest Release' finds it?


> Furthermore, the concept of components is 
> not specific to Cocoon even if their specific interfaces or container 
> might be, so why should the registration an lookup of components 
> (services) be tied to the sitemap functionality or something Cocoon 
> specific whatsoever.

It shouldn't be tied to anything Cocoon specific. Just get ServiceManager and 
make a lookup for anything you are wired to - and you are done :-)

And anything you are not wired to is not available (otherwise mess ensues).

Hm... I think you are mixing three concerns here in one:

   (1) How cocoon block obtains classes exported from non-cocoon,
       pure OSGi block
   (2) How cocoon block obtains *component* (not class! not factory!)
       exported from another cocoon block
   (3) How non-cocoon, pure OSGi block obtains components exported by
       cocoon block

I suggest to ignore the third and concentrate on second. Third can come later - 
if ever - if need arise - and can be implemented as you describe it, by 
exporting each component as a 'service'. First is necessary only if you want to 
package some .jar files as blocks or use 3rd party blocks, also can be ignored 
for the time being.


> By making our block architecture as Cocoon agnostic as possible at the 
> inter block level we makes it much easier to use it together with 
> externally developed blocks (bundles).

As long as you can mix and match those bundles. IIRC, one of the main 
requirements for the real blocks is the ability to have two different versions 
of same block used in two other blocks, simultaneously.

And any additional block deployment should not change what other blocks are 
seeing / using - avoid side effects.


> Also OSGi already have good 
> mechanisms for service registration, lookup and event handling, no need 
> to reinvent or circumvent it at the inter block level.

As long as it helps to reach the goal - fine.


>> Second, block is wired to several other blocks, and all (java classes, 
>> components, pipelines) it can see must be either in the Cocoon Core or 
>> in one of the blocks which are wired to it.
> 
> OSGi R3 does not have any concept of one bundle depending on another, 
> they depend on and exposes packages.

How conflicting packages are handled.


>> If you declare all of the components from all of the blocks, won't 
>> they be available to everybody?
> 
> Only to those who import them. Furthermore there are Java security based 
> mechanisms in OSGi for giving detailed access control between bundles, I 
> have no idea about how it is used though.

How you pick version of the package you need.


>> IIRC, block must not be able to lookup any other class, component, 
>> pipeline from any other block but only from those wired to it.
> 
> At the class level you get something similar by declaring what packages 
> the block import. At component level, you can connect a Map with any 
> content to  a service, then you can use a subset of the LDAP query 
> language on  these maps during lookup, so each component factory that is 
> registred as an OSGi service could certainly be namespaced with a block 
> name if we want to. Then the inter block component lookup mechanism can 
> limit its search to blocks that are declared to be connected.

If it's done once when block is loading - fine. Not sure it's ok for each 
component lookup though.


> Something 
> similar can be used for refering to pipelines in other blocks.

You can't refer to 'pipeline' - only to sitemap.


>> So at the time of block loading, 'block(s) loader/manager' can lookup 
>> Cocoon Block service instances for all blocks referenced from this 
>> one, and pass these services to the block, and after that block can 
>> lookup everything it needs autonomly.
> 
> As indicated above this can be solved without needing a monolithic 
> Cocoon Block service. The advantage with not having such a central point 
> is that it imposes less Cocoon specific restrictions on blocks and also 
> that it makes it easier to use the mechanisms that allready are provided 
> by OSGi for service register/unregister events.

I think advantage of single point of entry is simplification of code & more 
efficient runtime. It seems easier to connect one ECM+* to another ECM+* by 
passing a reference than doing all those LDAP queries.

Vadim

Re: [RT] The impact of using OSGi

[Daniel Fagerstrom <da...@nada.kth.se>]

Vadim Gritsenko wrote:

> Daniel Fagerstrom wrote:
>
>> Vadim Gritsenko wrote:
>>
>>> Daniel Fagerstrom wrote:
>>
<snip/>

>>>> In the active approach the inter block component handling is 
>>>> handled through OSGi services. To be able to register a service the 
>>>> block needs an OSGi Activator class.
>>>
>>> (minimally, i'd think block only needs to register it's component 
>>> manager service, everything else you can get from it)
>>
>> There are two main alternatives: register the component manager as a 
>> service or register the components as services. We found the later 
>> alternative more atractive as OSGi allready contains a nice and 
>> flexible service registration and service lookup mechanism. Adding an 
>> extra layer just seemed to complicate things.
>
>
> Not sure it will fly, though.
>
> First, it means that you are managing 'fine' components with coarse 
> container.

To be a little bit more exact it is not actual components that are 
exposed but component factories.

> I feel that real block should be represented in OSGi as a single 
> 'Cocoon Block Service'.

That would IMO make the block architecture unnecesarilly monolithic. For 
exporting a sitemap service it makes sense to export some kind of Cocoon 
block service, we need a service that can take a request object and 
return a response object and above that fullfill some protocol for block 
attributes and polymorphic sitemap extension, that seem rather Cocoon 
specific.

But exporting components, why should that be part of the service that 
exports sitemap functionality? Furthermore, the concept of components is 
not specific to Cocoon even if their specific interfaces or container 
might be, so why should the registration an lookup of components 
(services) be tied to the sitemap functionality or something Cocoon 
specific whatsoever.

By making our block architecture as Cocoon agnostic as possible at the 
inter block level we makes it much easier to use it together with 
externally developed blocks (bundles). Also OSGi already have good 
mechanisms for service registration, lookup and event handling, no need 
to reinvent or circumvent it at the inter block level.

> Second, block is wired to several other blocks, and all (java classes, 
> components, pipelines) it can see must be either in the Cocoon Core or 
> in one of the blocks which are wired to it.

OSGi R3 does not have any concept of one bundle depending on another, 
they depend on and exposes packages.

> If you declare all of the components from all of the blocks, won't 
> they be available to everybody?

Only to those who import them. Furthermore there are Java security based 
mechanisms in OSGi for giving detailed access control between bundles, I 
have no idea about how it is used though.

> IIRC, block must not be able to lookup any other class, component, 
> pipeline from any other block but only from those wired to it.

At the class level you get something similar by declaring what packages 
the block import. At component level, you can connect a Map with any 
content to  a service, then you can use a subset of the LDAP query 
language on  these maps during lookup, so each component factory that is 
registred as an OSGi service could certainly be namespaced with a block 
name if we want to. Then the inter block component lookup mechanism can 
limit its search to blocks that are declared to be connected. Something 
similar can be used for refering to pipelines in other blocks.

> So at the time of block loading, 'block(s) loader/manager' can lookup 
> Cocoon Block service instances for all blocks referenced from this 
> one, and pass these services to the block, and after that block can 
> lookup everything it needs autonomly.

As indicated above this can be solved without needing a monolithic 
Cocoon Block service. The advantage with not having such a central point 
is that it imposes less Cocoon specific restrictions on blocks and also 
that it makes it easier to use the mechanisms that allready are provided 
by OSGi for service register/unregister events.

>>> The Cocoon Kernel will have to have an 'OSGi Activator', but not 
>>> each block. You are not seriously planning to force each block 
>>> developer to start creating their own activators, right? It's 
>>> implemented once in kernel, and referenced across all blocks.
>>
>> Yes
>
> That was my point - blocks won't have OSGi code :-)

Sure, there where some fine details to clarify though ;)

/Daniel

Re: [RT] The impact of using OSGi

[Vadim Gritsenko <va...@reverycodes.com>]

Daniel Fagerstrom wrote:
> Vadim Gritsenko wrote:
> 
>> Daniel Fagerstrom wrote:
>>
>>> Vadim Gritsenko wrote:
>>>
>>>> Daniel Fagerstrom wrote:
>>>>
>>>>> Vadim Gritsenko wrote:
>>>>>
>>>>>> I'd even say that at this point in time, none of the existing 
>>>>>> blocks should be aware of OSGi existence but only Cocoon "Kernel", 
>>>>>> which uses OSGi to manage (load/unload) blocks on the fly.
>>>>>
>>>>> Do you have any specific design for achieving this that you are 
>>>>> going to propose?

But in the end we do agree as it seems :-)

<snip/>

>>> And one active way, where the block contain an own component manager 
>>> and an component manager <-> OSGi bridge.
>>
>> Obviously, each block contains (at least) one sitemap. Each sitemap 
>> creates own component manager. So we have this covered.
> 
> You are running ahead ;) we are only talking about "component only" 
> blocks yet.

So they can have root component manager then :-)


> This far there have not been much discussions about how to 
> add the sitemap aspect to the OSGi based architecture. I have some ideas 
> about how to achieve it and will write an RT about it. In my design a 
> block that provides sitemap functionality will register a block service 
> that then can be used by a central blocks manager block. A block will be 
> able to have any mix of passive library export, active component export 
> and export of sitemap services.
> 
> So some blocks will contain a sitemap but for most of the current ones 
> that doesn't make sense as they only export compinents. Ok, in some 
> sense we can achieve that by having a sitemap without pipeline sections.

Or root component manager :-)


>> Obviously, component manager has to interoperate with OSGi in order to 
>> get handle on 'parent' component manager ('Parent' here in quotes 
>> because component lookup strategy for that parent manager should 
>> change from what we have today.)
>>
>> So no surprise here.
> 
> This is allready to a large extent implemented, take a look at 
> o.a.c.core.osgi.

Cool.


>>> In the active approach the inter block component handling is handled 
>>> through OSGi services. To be able to register a service the block 
>>> needs an OSGi Activator class.
>>
>> (minimally, i'd think block only needs to register it's component 
>> manager service, everything else you can get from it)
> 
> There are two main alternatives: register the component manager as a 
> service or register the components as services. We found the later 
> alternative more atractive as OSGi allready contains a nice and flexible 
> service registration and service lookup mechanism. Adding an extra layer 
> just seemed to complicate things.

Not sure it will fly, though.

First, it means that you are managing 'fine' components with coarse container. I 
feel that real block should be represented in OSGi as a single 'Cocoon Block 
Service'.

Second, block is wired to several other blocks, and all (java classes, 
components, pipelines) it can see must be either in the Cocoon Core or in one of 
the blocks which are wired to it.

If you declare all of the components from all of the blocks, won't they be 
available to everybody? IIRC, block must not be able to lookup any other class, 
component, pipeline from any other block but only from those wired to it.

So at the time of block loading, 'block(s) loader/manager' can lookup Cocoon 
Block service instances for all blocks referenced from this one, and pass these 
services to the block, and after that block can lookup everything it needs 
autonomly.


>> The Cocoon Kernel will have to have an 'OSGi Activator', but not each 
>> block. You are not seriously planning to force each block developer to 
>> start creating their own activators, right? It's implemented once in 
>> kernel, and referenced across all blocks.
> 
> Yes

That was my point - blocks won't have OSGi code :-)

<snip/>

Vadim

Re: [RT] The impact of using OSGi

[Daniel Fagerstrom <da...@nada.kth.se>]

Vadim Gritsenko wrote:

> Daniel Fagerstrom wrote:
>
>> Vadim Gritsenko wrote:
>>
>>> Daniel Fagerstrom wrote:
>>>
>>>> Vadim Gritsenko wrote:
>>>>
>>>>> I'd even say that at this point in time, none of the existing 
>>>>> blocks should be aware of OSGi existence but only Cocoon "Kernel", 
>>>>> which uses OSGi to manage (load/unload) blocks on the fly.
>>>>
>>>> Why?
>>>>
>>>> Do you have any specific design for achieving this that you are 
>>>> going to propose?
>>>
>>> May be I skipped important message - is there any reason why block's 
>>> classes has to import OSGi?
>>
>> Yes. There are two main ways of handling blocks with OSGi, one 
>> passive way that I describe in 
>> http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=112362483115086&w=2 
>> and that we have implemented part of, for testing the concept, in the 
>> template block.
>
>
> How tis 'passive' way solves dynamic unloading of blocks? And 
> particularly I don't like 'build time configuration'. Does not sound 
> like real blocks to me. Moving on...

It is not that bad, some central blocks manager can register a listener 
for installation, update and uninstallation of bundles. It can then 
check the bundle that has change state for a configuration file and 
handle it accordingly: i.e. register its components, update them or 
unregister them. So it can be made dynamic, still it requires all 
packages to be exported and requires everything to be handled of the 
central component manager (ECM++). So it is not as scalable as the 
active approach.

>> And one active way, where the block contain an own component manager 
>> and an component manager <-> OSGi bridge.
>
> Obviously, each block contains (at least) one sitemap. Each sitemap 
> creates own component manager. So we have this covered.

You are running ahead ;) we are only talking about "component only" 
blocks yet. This far there have not been much discussions about how to 
add the sitemap aspect to the OSGi based architecture. I have some ideas 
about how to achieve it and will write an RT about it. In my design a 
block that provides sitemap functionality will register a block service 
that then can be used by a central blocks manager block. A block will be 
able to have any mix of passive library export, active component export 
and export of sitemap services.

So some blocks will contain a sitemap but for most of the current ones 
that doesn't make sense as they only export compinents. Ok, in some 
sense we can achieve that by having a sitemap without pipeline sections.

> Obviously, component manager has to interoperate with OSGi in order to 
> get handle on 'parent' component manager ('Parent' here in quotes 
> because component lookup strategy for that parent manager should 
> change from what we have today.)
>
> So no surprise here.

This is allready to a large extent implemented, take a look at 
o.a.c.core.osgi.

>> Sylvain have started to implement the later approach, see 
>> http://marc.theaimsgroup.com/?t=112231957500003&r=1&w=2.
>>
>> In the active approach the inter block component handling is handled 
>> through OSGi services. To be able to register a service the block 
>> needs an OSGi Activator class.
>
>
> (minimally, i'd think block only needs to register it's component 
> manager service, everything else you can get from it)

There are two main alternatives: register the component manager as a 
service or register the components as services. We found the later 
alternative more atractive as OSGi allready contains a nice and flexible 
service registration and service lookup mechanism. Adding an extra layer 
just seemed to complicate things.

> The Cocoon Kernel will have to have an 'OSGi Activator', but not each 
> block. You are not seriously planning to force each block developer to 
> start creating their own activators, right? It's implemented once in 
> kernel, and referenced across all blocks.

Yes

<snip/>

>> If we follow the passive approach all blocks need manifest files 
>> where all packages are exported. Also we need to implement some 
>> mechanisms for using the configuration from the block, (as described 
>> in more detail in the reference above).
>>
>> In the active approach we need to continue the work that Sylvain has 
>> started, and we need to decide what to export from each block - 
>> everything or just the API.
>
> Best would be API only; if it makes prototyping easier - exporting 
> everything is Ok tradeoff for a time being.

We probably have to start by exporting about everything, but we should 
strive to refactor it to only export APIs.


<snip/>

>>                       --- o0o ---
>>
>> We should IMO make a clear distinction between intra and inter block 
>> aspects: within current blocks we should not require any OSGi use, 
>> thing should work as before. But as inter block apects are 
>> essentially new functionallity we shouldn't beforehand limit 
>> ourselves and instead use the best technical solution available.
>
> To me 'best technical solution' should blend in inter block aspects 
> into ServiceManager (as additional syntax for role?

This is basically what is done in o.a.c.core.osgi, and there is a new 
"exported=true" attribute for exporting components from the block.

> or new component such as BlockManager?),

That is my idea for blocks with sitemap functionality, they have an 
internal BlockManager and exports a block service.

> possibly even without direct access to OSGi internals so that 
> implementation details of block management are hidden.
>
> As a side effect, blocks won't need much (if any) code changes 
> (package restructuring excluded).

That is the intension.

<snip/>

/Daniel

Re: [RT] The impact of using OSGi

[Vadim Gritsenko <va...@reverycodes.com>]

Daniel Fagerstrom wrote:
> Vadim Gritsenko wrote:
> 
>> Daniel Fagerstrom wrote:
>>
>>> Vadim Gritsenko wrote:
>>>
>>>> I'd even say that at this point in time, none of the existing blocks 
>>>> should be aware of OSGi existence but only Cocoon "Kernel", which 
>>>> uses OSGi to manage (load/unload) blocks on the fly.
>>>
>>> Why?
>>>
>>> Do you have any specific design for achieving this that you are going 
>>> to propose?
>>
>> May be I skipped important message - is there any reason why block's 
>> classes has to import OSGi?
> 
> Yes. There are two main ways of handling blocks with OSGi, one passive 
> way that I describe in 
> http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=112362483115086&w=2 and 
> that we have implemented part of, for testing the concept, in the 
> template block.

How tis 'passive' way solves dynamic unloading of blocks? And particularly I 
don't like 'build time configuration'. Does not sound like real blocks to me. 
Moving on...


> And one active way, where the block contain an own 
> component manager and an component manager <-> OSGi bridge.

Obviously, each block contains (at least) one sitemap. Each sitemap creates own 
component manager. So we have this covered.

Obviously, component manager has to interoperate with OSGi in order to get 
handle on 'parent' component manager ('Parent' here in quotes because component 
lookup strategy for that parent manager should change from what we have today.)

So no surprise here.


> Sylvain have 
> started to implement the later approach, see 
> http://marc.theaimsgroup.com/?t=112231957500003&r=1&w=2.
> 
> In the active approach the inter block component handling is handled 
> through OSGi services. To be able to register a service the block needs 
> an OSGi Activator class.

(minimally, i'd think block only needs to register it's component manager 
service, everything else you can get from it)

The Cocoon Kernel will have to have an 'OSGi Activator', but not each block. You 
are not seriously planning to force each block developer to start creating their 
own activators, right? It's implemented once in kernel, and referenced across 
all blocks.


> Our hope is that it will be enough with a 
> generic ServiceManagerActivator that the block just refer to in the 
> manifest, but we don't know that yet.

Exactly my point.


> The active approach is preferable to the passive one as it makes it 
> possible for the block to just expose the API, the implementation can be 
> shielded.

Sounds good.


> Also it gives the possiblity to use different component 
> containers in different blocks in an interoperable way (ECM++, Spring, 
> Pico etc).

Whatever.


>> Isn't it the first goal to make (any) existing block (with no code 
>> modifications) run under OSGi?
> 
> We could do that with the passive approach, although  the package 
> structure needs to be changed in some places. But it seemed like people 
> prefered to focus on the active approach during the blockathon.

Good.


> Wheter 
> approach we take we must start with fixing the package structure as 
> discussed before so that each block has unique packages, two blocks with 
> the same package but with different content will lead to problems'as 
> discussed before.

Everything has a price, and this is price to have 'active OSGi blocks'.


> If we follow the passive approach all blocks need manifest files where 
> all packages are exported. Also we need to implement some mechanisms for 
> using the configuration from the block, (as described in more detail in 
> the reference above).
> 
> In the active approach we need to continue the work that Sylvain has 
> started, and we need to decide what to export from each block - 
> everything or just the API.

Best would be API only; if it makes prototyping easier - exporting everything is 
Ok tradeoff for a time being.


> Anyway, as the active approach is more scalable and the passive one 
> requires some work to be done that not will be reused if we continue 
> with the active approach, it seemed better to me (and others) to start 
> with the active approach right away.

Agreed.


>                       --- o0o ---
> 
> We should IMO make a clear distinction between intra and inter block 
> aspects: within current blocks we should not require any OSGi use, thing 
> should work as before. But as inter block apects are essentially new 
> functionallity we shouldn't beforehand limit ourselves and instead use 
> the best technical solution available.

To me 'best technical solution' should blend in inter block aspects into 
ServiceManager (as additional syntax for role? or new component such as 
BlockManager?), possibly even without direct access to OSGi internals so that 
implementation details of block management are hidden.

As a side effect, blocks won't need much (if any) code changes (package 
restructuring excluded).


>>> People, at this point of time it seem rather pointless to me to 
>>> impose all sorts of restrictions on how we should implement blocks. 
>>> Instead of discussing about how to not implement blocks I would 
>>> prefer to focus on discussing how to implement them or even actually 
>>> continue implementing them ;)
>>
>>
>> Sorry, had no time to look at it :-(
>>
>> I noticed though that currently there is no 'CocoonServler' which 
>> would bootstrap OSGi container, isn't it?
> 
> 
> We are still waiting for someone who want it enough to do the work ;) 
> More seriously I thik we can wait with that until we move to Oscar OSGi. 
> The mechanism for starting an OSGi framework is not standaridised. And 
> there migth be some issues with Java security and URL handler 
> registration when using an OSGi container within a servlet container, 
> those issues would be easier to handle in an Apache project as Oscar.

I see.

Thanks for the mail,

Vadim

Re: [RT] The impact of using OSGi

[Daniel Fagerstrom <da...@nada.kth.se>]

Vadim Gritsenko wrote:

> Daniel Fagerstrom wrote:
>
>> Vadim Gritsenko wrote:
>>
>>> I'd even say that at this point in time, none of the existing blocks 
>>> should be aware of OSGi existence but only Cocoon "Kernel", which 
>>> uses OSGi to manage (load/unload) blocks on the fly.
>>
>>
>> Why?
>>
>> Do you have any specific design for achieving this that you are going 
>> to propose?
>
>
> May be I skipped important message - is there any reason why block's 
> classes has to import OSGi?

Yes. There are two main ways of handling blocks with OSGi, one passive 
way that I describe in 
http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=112362483115086&w=2 and 
that we have implemented part of, for testing the concept, in the 
template block. And one active way, where the block contain an own 
component manager and an component manager <-> OSGi bridge. Sylvain have 
started to implement the later approach, see 
http://marc.theaimsgroup.com/?t=112231957500003&r=1&w=2.

In the active approach the inter block component handling is handled 
through OSGi services. To be able to register a service the block needs 
an OSGi Activator class. Our hope is that it will be enough with a 
generic ServiceManagerActivator that the block just refer to in the 
manifest, but we don't know that yet.

The active approach is preferable to the passive one as it makes it 
possible for the block to just expose the API, the implementation can be 
shielded. Also it gives the possiblity to use different component 
containers in different blocks in an interoperable way (ECM++, Spring, 
Pico etc).

> Isn't it the first goal to make (any) existing block (with no code 
> modifications) run under OSGi?

We could do that with the passive approach, although  the package 
structure needs to be changed in some places. But it seemed like people 
prefered to focus on the active approach during the blockathon. Wheter 
approach we take we must start with fixing the package structure as 
discussed before so that each block has unique packages, two blocks with 
the same package but with different content will lead to problems'as 
discussed before.

If we follow the passive approach all blocks need manifest files where 
all packages are exported. Also we need to implement some mechanisms for 
using the configuration from the block, (as described in more detail in 
the reference above).

In the active approach we need to continue the work that Sylvain has 
started, and we need to decide what to export from each block - 
everything or just the API.

Anyway, as the active approach is more scalable and the passive one 
requires some work to be done that not will be reused if we continue 
with the active approach, it seemed better to me (and others) to start 
with the active approach right away.

                       --- o0o ---

We should IMO make a clear distinction between intra and inter block 
aspects: within current blocks we should not require any OSGi use, thing 
should work as before. But as inter block apects are essentially new 
functionallity we shouldn't beforehand limit ourselves and instead use 
the best technical solution available.

>> People, at this point of time it seem rather pointless to me to 
>> impose all sorts of restrictions on how we should implement blocks. 
>> Instead of discussing about how to not implement blocks I would 
>> prefer to focus on discussing how to implement them or even actually 
>> continue implementing them ;)
>
> Sorry, had no time to look at it :-(
>
> I noticed though that currently there is no 'CocoonServler' which 
> would bootstrap OSGi container, isn't it?

We are still waiting for someone who want it enough to do the work ;) 
More seriously I thik we can wait with that until we move to Oscar OSGi. 
The mechanism for starting an OSGi framework is not standaridised. And 
there migth be some issues with Java security and URL handler 
registration when using an OSGi container within a servlet container, 
those issues would be easier to handle in an Apache project as Oscar.

/Daniel

Re: [RT] The impact of using OSGi

[Vadim Gritsenko <va...@reverycodes.com>]

Daniel Fagerstrom wrote:
> Vadim Gritsenko wrote:
> 
>> I'd even say that at this point in time, none of the existing blocks 
>> should be aware of OSGi existence but only Cocoon "Kernel", which uses 
>> OSGi to manage (load/unload) blocks on the fly.
> 
> Why?
> 
> Do you have any specific design for achieving this that you are going to 
> propose?

May be I skipped important message - is there any reason why block's classes has 
to import OSGi?

Isn't it the first goal to make (any) existing block (with no code 
modifications) run under OSGi?


> People, at this point of time it seem rather pointless to me to impose 
> all sorts of restrictions on how we should implement blocks. Instead of 
> discussing about how to not implement blocks I would prefer to focus on 
> discussing how to implement them or even actually continue implementing 
> them ;)

Sorry, had no time to look at it :-(

I noticed though that currently there is no 'CocoonServler' which would 
bootstrap OSGi container, isn't it?

Vadim

Re: [RT] The impact of using OSGi

[Daniel Fagerstrom <da...@nada.kth.se>]

Vadim Gritsenko wrote:
> Carsten Ziegeler wrote:
> 
>> Daniel Fagerstrom schrieb:
>>
>>> At some point in time, e.g. now ;) we need to decide that we go for 
>>> OSGi. Keeping all roads open at all time means that we just reinvent 
>>> whats allready is standardized in OSGi.
>>>
>>> For functionality that we allready have, we must of course respect 
>>> back compability and write wrappers beween what we have and the new 
>>> OSGi based implementations. But for new functionallity I think that 
>>> we should reuse as much as possible of what allready is in OSGi.
>>>
>>
>> I think we should use OSGi *just* for the "core blocks" implementation
>> which is class loading, versioning and installation and that's it.
>> But that's just my opinion.
> 
> 
> +1
> 
> I'd even say that at this point in time, none of the existing blocks 
> should be aware of OSGi existence but only Cocoon "Kernel", which uses 
> OSGi to manage (load/unload) blocks on the fly.

Why?

Do you have any specific design for achieving this that you are going to 
propose?

People, at this point of time it seem rather pointless to me to impose 
all sorts of restrictions on how we should implement blocks. Instead of 
discussing about how to not implement blocks I would prefer to focus on 
discussing how to implement them or even actually continue implementing 
them ;)

/Daniel

Re: [RT] The impact of using OSGi

[Vadim Gritsenko <va...@reverycodes.com>]

Carsten Ziegeler wrote:
> Daniel Fagerstrom schrieb:
> 
>>At some point in time, e.g. now ;) we need to decide that we go for 
>>OSGi. Keeping all roads open at all time means that we just reinvent 
>>whats allready is standardized in OSGi.
>>
>>For functionality that we allready have, we must of course respect back 
>>compability and write wrappers beween what we have and the new OSGi 
>>based implementations. But for new functionallity I think that we should 
>>reuse as much as possible of what allready is in OSGi.
>>
> 
> I think we should use OSGi *just* for the "core blocks" implementation
> which is class loading, versioning and installation and that's it.
> But that's just my opinion.

+1

I'd even say that at this point in time, none of the existing blocks should be 
aware of OSGi existence but only Cocoon "Kernel", which uses OSGi to manage 
(load/unload) blocks on the fly.

Vadim

Re: [RT] The impact of using OSGi

[Carsten Ziegeler <cz...@apache.org>]

Daniel Fagerstrom schrieb:
> 
> At some point in time, e.g. now ;) we need to decide that we go for 
> OSGi. Keeping all roads open at all time means that we just reinvent 
> whats allready is standardized in OSGi.
> 
> For functionality that we allready have, we must of course respect back 
> compability and write wrappers beween what we have and the new OSGi 
> based implementations. But for new functionallity I think that we should 
> reuse as much as possible of what allready is in OSGi.
> 
> 
I think we should use OSGi *just* for the "core blocks" implementation
which is class loading, versioning and installation and that's it.
But that's just my opinion.

Carsten

-- 
Carsten Ziegeler - Open Source Group, S&N AG
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/

Re: [RT] The impact of using OSGi

[Upayavira <uv...@odoko.co.uk>]

Daniel Fagerstrom wrote:
> Upayavira wrote:
> 
>> Carsten Ziegeler wrote:
>>
>>> Daniel Fagerstrom schrieb:
>>>
>>>
>>>>> From the discussions last week with Reinhard, Daniel and Upayavira 
>>>>> I think using block.xml to generate everything else was the 
>>>>> consensus. See "role of block.xml" in 
>>>>> http://wiki.apache.org/cocoon/Blockathon2005Report
>>>>
>>>>
>>>>
>>>>
>>>> Hmm, was I really part of that concensus? Like Sylvain I prefer to 
>>>> use the OSGi manifest for everything that can be described by that 
>>>> and the block.xml for the rest.
>>>>
>>>> Now, IIUC, the rest of you think that such a solution would be 
>>>> unpractical because of overlap with gump, compile and deploy time 
>>>> dependency descriptors etc. You might very well be right about that, 
>>>> but I prefer to wait and see until we actually start to implement it 
>>>> before we decide.
>>>>
>>>
>>> I prefer a single source of information about a block: the block.xml -
>>> we can then generate everything else out of. This would also keep us
>>> independent from OSGi.
>>> But you're we can start in any way and then change it later on. For
>>> converting an xml to another xml we just need a stylesheet anyway.
>>
>>
>>
>> Yes. To change isn't hard. And, I think experience will guide us. Is 
>> it more important to be able to use standard OSGi bundles within 
>> Cocoon, or to have Cocoon bundles work outside of Cocoon itself, or to 
>> have a Cocoon 'block' as being something that has, from a developer's 
>> point of view, nothing specifically to do with OSGi.
> 
> 
> At some point in time, e.g. now ;) we need to decide that we go for 
> OSGi. Keeping all roads open at all time means that we just reinvent 
> whats allready is standardized in OSGi.

I think that is a different question. I'm all for committing to OSGi, 
after all, we can always roll back as we did with Fortress. Maybe what 
we should do is 'tag' the repository now, before we do anything 
invasive, to make that option simpler. However, I think we have a 
general consensus to push forward with OSGi.

> For functionality that we allready have, we must of course respect back 
> compability and write wrappers beween what we have and the new OSGi 
> based implementations. But for new functionallity I think that we should 
> reuse as much as possible of what allready is in OSGi.

Again, I think the question I was answering is different. The question 
is, what if a piece of configuration information is needed by OSGi _and_ 
Cocoon, because our use-case is broader than that of OSGi. Should we use 
the manifest.mf file and have our own systems consume that as well as 
OSGi, or alernatively use the block.xml file, and have manifest.mf 
generated from that.

And that, I think, is a question we don't need to resolve right away.

>> And these questions we should be able to answer a little further down 
>> the road.
> 
> Exactly, we should let our practical experiences when we start to work 
> at it decide.

Yup.

Regards, Upayavira

Re: [RT] The impact of using OSGi

[Daniel Fagerstrom <da...@nada.kth.se>]

Upayavira wrote:

> Carsten Ziegeler wrote:
>
>> Daniel Fagerstrom schrieb:
>>
>>
>>>> From the discussions last week with Reinhard, Daniel and Upayavira 
>>>> I think using block.xml to generate everything else was the 
>>>> consensus. See "role of block.xml" in 
>>>> http://wiki.apache.org/cocoon/Blockathon2005Report
>>>
>>>
>>>
>>> Hmm, was I really part of that concensus? Like Sylvain I prefer to 
>>> use the OSGi manifest for everything that can be described by that 
>>> and the block.xml for the rest.
>>>
>>> Now, IIUC, the rest of you think that such a solution would be 
>>> unpractical because of overlap with gump, compile and deploy time 
>>> dependency descriptors etc. You might very well be right about that, 
>>> but I prefer to wait and see until we actually start to implement it 
>>> before we decide.
>>>
>>
>> I prefer a single source of information about a block: the block.xml -
>> we can then generate everything else out of. This would also keep us
>> independent from OSGi.
>> But you're we can start in any way and then change it later on. For
>> converting an xml to another xml we just need a stylesheet anyway.
>
>
> Yes. To change isn't hard. And, I think experience will guide us. Is 
> it more important to be able to use standard OSGi bundles within 
> Cocoon, or to have Cocoon bundles work outside of Cocoon itself, or to 
> have a Cocoon 'block' as being something that has, from a developer's 
> point of view, nothing specifically to do with OSGi.

At some point in time, e.g. now ;) we need to decide that we go for 
OSGi. Keeping all roads open at all time means that we just reinvent 
whats allready is standardized in OSGi.

For functionality that we allready have, we must of course respect back 
compability and write wrappers beween what we have and the new OSGi 
based implementations. But for new functionallity I think that we should 
reuse as much as possible of what allready is in OSGi.

> And these questions we should be able to answer a little further down 
> the road.

Exactly, we should let our practical experiences when we start to work 
at it decide.

/Daniel

Re: [RT] The impact of using OSGi

[Upayavira <uv...@odoko.co.uk>]

Carsten Ziegeler wrote:
> Daniel Fagerstrom schrieb:
> 
> 
>>>>From the discussions last week with Reinhard, Daniel and Upayavira I 
>>>think using block.xml to generate everything else was the consensus. See 
>>>"role of block.xml" in http://wiki.apache.org/cocoon/Blockathon2005Report
>>
>>
>>Hmm, was I really part of that concensus? Like Sylvain I prefer to use 
>>the OSGi manifest for everything that can be described by that and the 
>>block.xml for the rest.
>>
>>Now, IIUC, the rest of you think that such a solution would be 
>>unpractical because of overlap with gump, compile and deploy time 
>>dependency descriptors etc. You might very well be right about that, but 
>>I prefer to wait and see until we actually start to implement it before 
>>we decide.
>>
> 
> I prefer a single source of information about a block: the block.xml -
> we can then generate everything else out of. This would also keep us
> independent from OSGi.
> But you're we can start in any way and then change it later on. For
> converting an xml to another xml we just need a stylesheet anyway.

Yes. To change isn't hard. And, I think experience will guide us. Is it 
more important to be able to use standard OSGi bundles within Cocoon, or 
to have Cocoon bundles work outside of Cocoon itself, or to have a 
Cocoon 'block' as being something that has, from a developer's point of 
view, nothing specifically to do with OSGi.

And these questions we should be able to answer a little further down 
the road.

Regards, Upayavira

Re: [RT] The impact of using OSGi

[Carsten Ziegeler <cz...@apache.org>]

Daniel Fagerstrom schrieb:

>> From the discussions last week with Reinhard, Daniel and Upayavira I 
>>think using block.xml to generate everything else was the consensus. See 
>>"role of block.xml" in http://wiki.apache.org/cocoon/Blockathon2005Report
> 
> 
> Hmm, was I really part of that concensus? Like Sylvain I prefer to use 
> the OSGi manifest for everything that can be described by that and the 
> block.xml for the rest.
> 
> Now, IIUC, the rest of you think that such a solution would be 
> unpractical because of overlap with gump, compile and deploy time 
> dependency descriptors etc. You might very well be right about that, but 
> I prefer to wait and see until we actually start to implement it before 
> we decide.
> 
I prefer a single source of information about a block: the block.xml -
we can then generate everything else out of. This would also keep us
independent from OSGi.
But you're we can start in any way and then change it later on. For
converting an xml to another xml we just need a stylesheet anyway.

Carsten

-- 
Carsten Ziegeler - Open Source Group, S&N AG
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/

Re: [RT] The impact of using OSGi

[Daniel Fagerstrom <da...@nada.kth.se>]

Bertrand Delacretaz wrote:
> 
> Le 25 juil. 05, à 12:20, Carsten Ziegeler a écrit :
> 
>> Hmm, I'm a little bit confused if I compare the two response quoted 
>> below.
>>
>> I personally would prefer to go the block.xml way and create OSGi
>> manifests and whatever out of it. With that approach we are still
>> independent from OSGi...
> 
>  From the discussions last week with Reinhard, Daniel and Upayavira I 
> think using block.xml to generate everything else was the consensus. See 
> "role of block.xml" in http://wiki.apache.org/cocoon/Blockathon2005Report

Hmm, was I really part of that concensus? Like Sylvain I prefer to use 
the OSGi manifest for everything that can be described by that and the 
block.xml for the rest.

Now, IIUC, the rest of you think that such a solution would be 
unpractical because of overlap with gump, compile and deploy time 
dependency descriptors etc. You might very well be right about that, but 
I prefer to wait and see until we actually start to implement it before 
we decide.

/Daniel

Re: [RT] The impact of using OSGi

[Bertrand Delacretaz <bd...@apache.org>]

Le 25 juil. 05, à 12:20, Carsten Ziegeler a écrit :

> Hmm, I'm a little bit confused if I compare the two response quoted 
> below.
>
> I personally would prefer to go the block.xml way and create OSGi
> manifests and whatever out of it. With that approach we are still
> independent from OSGi...

 From the discussions last week with Reinhard, Daniel and Upayavira I 
think using block.xml to generate everything else was the consensus. 
See "role of block.xml" in 
http://wiki.apache.org/cocoon/Blockathon2005Report

-Bertrand

Re: [RT] The impact of using OSGi

[Upayavira <uv...@odoko.co.uk>]

Sylvain Wallez wrote:
> Carsten Ziegeler wrote:
> 
>> Hmm, I'm a little bit confused if I compare the two response quoted 
>> below.
>>
>> I personally would prefer to go the block.xml way and create OSGi
>> manifests and whatever out of it. With that approach we are still
>> independent from OSGi.
>>  
>>
> 
> We discussed this at the hackaton and IIRC the result was to consider 
> using Manifest.mf when the information can fit there, which will allow 
> to use all the fancy tools that are available to edit this *standard* file.

As did we, and concluded the opposite. Different part of the hackathon! 
Oh well.

I'd suggest we wait until we get a better sense of what info is required 
before we make a decision. We will need a manifest file. Whether it is 
manually edited or automatically generated is less of an issue at this 
point as compared to what it actually contains.

Regards, Upayavira

Re: [RT] The impact of using OSGi

[Sylvain Wallez <sy...@apache.org>]

Carsten Ziegeler wrote:

>Hmm, I'm a little bit confused if I compare the two response quoted below.
>
>I personally would prefer to go the block.xml way and create OSGi
>manifests and whatever out of it. With that approach we are still
>independent from OSGi.
>  
>

We discussed this at the hackaton and IIRC the result was to consider 
using Manifest.mf when the information can fit there, which will allow 
to use all the fancy tools that are available to edit this *standard* file.

Sylvain

-- 
Sylvain Wallez                        Anyware Technologies
http://apache.org/~sylvain            http://anyware-tech.com
Apache Software Foundation Member     Research & Technology Director

Re: [RT] The impact of using OSGi

[Upayavira <uv...@odoko.co.uk>]

Carsten Ziegeler wrote:
> Hmm, I'm a little bit confused if I compare the two response quoted below.
> 
> I personally would prefer to go the block.xml way and create OSGi
> manifests and whatever out of it. With that approach we are still
> independent from OSGi.

Yup. I noticed that discrepancy. A few of us did discuss this - more in 
relation to Gump than manifests.

We need to clarify the nature of the dependencies that we need to define.

We have package dependencies (handled by OSGi), and bundle dependencies 
(handled by our own block management system). For example, myskin 
extends myapp block.

Which of these do we want to use to do dependency resolution?

If package dependencies are only used by OSGi, I could see some 
rationale for having them in the manifest. However, as soon as they are 
required in more than one place, I say it all goes into block.xml.

(note, we can define a package dependency now, with R4 as 
org.apache.cocoon.generation.Generator which means we can still have 
o.a.c.generation.HTMLGenerator in a separate block, with it exporting 
that class specifically (this functionality is already included in 
Oscar), so we shouldn't need to rename our packages.)

Upayavira

>>>BTW, what is the status about the dependency definition (block.xml).
>>>What are we planning to use?
> 
> 
> Sylvain Wallez wrote:
> 
>>A lot of what's was planned to be in block.xml is already defined by the 
>>OSGi bundle manifest file. So it will be stripped-down to keep only what 
>>is specific to Cocoon blocks.
>>
> 
> Upayavira wrote:
> 
>>Just replying to this bit - Daniel showed me the block.xml before he
>>left ApacheCon. It looks pretty simple. Also, given all the other
>>'dependency' files we will/might need (gump.xml, manifest, maven project
>>files, etc) in a discussion it was suggested that we're better of
>>sticking with our own blocks.xml file - we can always generate anything
>>else we want from that.
>>
>>So, AFAICS, blokc.xml stays as Stefano proposed it.
>>

Re: [RT] The impact of using OSGi

[Carsten Ziegeler <cz...@apache.org>]

Hmm, I'm a little bit confused if I compare the two response quoted below.

I personally would prefer to go the block.xml way and create OSGi
manifests and whatever out of it. With that approach we are still
independent from OSGi.

Carsten

>>BTW, what is the status about the dependency definition (block.xml).
>>What are we planning to use?

Sylvain Wallez wrote:
> 
> A lot of what's was planned to be in block.xml is already defined by the 
> OSGi bundle manifest file. So it will be stripped-down to keep only what 
> is specific to Cocoon blocks.
> 
Upayavira wrote:
> Just replying to this bit - Daniel showed me the block.xml before he
> left ApacheCon. It looks pretty simple. Also, given all the other
> 'dependency' files we will/might need (gump.xml, manifest, maven project
> files, etc) in a discussion it was suggested that we're better of
> sticking with our own blocks.xml file - we can always generate anything
> else we want from that.
>
> So, AFAICS, blokc.xml stays as Stefano proposed it.
>
-- 
Carsten Ziegeler - Open Source Group, S&N AG
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/

Re: [RT] The impact of using OSGi

[Sylvain Wallez <sy...@apache.org>]

Carsten Ziegeler wrote:

>A lot of people have asked me during the ApacheCon (and via mail) what
>the move to OSGi would mean from a user/developer perspective. So I
>think it's time to discuss this a little bit further; we already did
>this briefly at the hackathon, but of course we should continue this
>here visibile for everyone.
>
>(The following is how I understand/see the whole thing, please correct
>me if required).
>
>First of all, we have an RT about the goals for the next version[1]. As
>noted there, the goals are independent from OSGi and the vision is to
>*explore* OSGi in the next months. So actually using OSGi is not carved
>in stone, but currently it looks like OSGi is the best available
>alternative.
>  
>

Yup.

And the fact that a lot of other Apache projects are considering using 
it is a good sign also.

My personal opinion about why OSGi is hot lately despite being 
not-so-new (OSGi 1.0 was issued in 1999) is twofold:

- from a social POV, a lot of people have been trying to define 
containers with classloader isolation (which is different from what we 
use in Cocoon right now). And this led to endless discussions and 
friction about design, semantics, etc, and even community 
self-destruction (Avalon) because people could not came to an agreement. 
OSGi is written "elsewhere", by a committee. A lot of people don't like 
design-by-committee, but it happened that in this particular case, the 
spec is quite good and, well, it _is_ there and we therefore don't need 
to spend time and argue to define what a container should look like.

- from a technical POV, OSGi is lightweight and has at least 3 robust 
opensource implementations. So we just have to use one of them, and not 
spend time about writing the container. And this as an immediate effect: 
during the ApacheCon hackaton, the question that were raised where of 
much lower level than those we ever had before regarding real blocks. In 
other words, after 3 years of thoughts, experiments and discussions, we 
are now in the implementation phase.

>The most important goal for myself is 7): compatibility. I don't want to
>rewrite each and every piece of code we've done in the past five years.
>  
>

I would not state it exactly as a "goal", but rather as an important 
requirement. Otherwise, doing nothing is the easiest way to have no 
compatibility problems :-)

>And I think it's as important to not increase the high learning curve by
>introducing another "thing". Ok, from what we discussed in the last
>weeks, it seems to me that we can achieve these goals.
>  
>

Yup.

>So, what does all of this OSGi stuff mean? OSGi provides some nice
>features, like isolated class loading and depedency resolution. And it's
>exactly this where we want to use it.
>
>Although OSGi is a component container by itself, we will not replace
>ECM with the OSGi one. This means for a java developer nothing really
>changes, you just use ECM like you did before or you use
>Spring/Hivemind/Pico/whatever like you did before. Everything looks the
>same.
>  
>

Yup.

This is what we already called the "two levels of containment" [2]. OSGi 
is to manage blocks and handle inter-block wiring whereas each block can 
have its own lightweight container, i.e. ECM or Spring or whatever.

>Underneath, our own ECM implementation will use OSGi to get components
>from another bundle, but this is totally transparent. The only thing you
>have to do is defining your block dependencies properly. By this our own
>ECM implementation will be able to lookup components from the blocks you
>depend on.
>
>For a Cocoon user (writing sitemaps, using xml and xslt) everything
>should stay the same. It just works like it does today.
>
>Now, there is one thing to consider: using OSGi means, everything is a
>bundle. So whatever you develop, it must be a bundle. Currently people
>are using totally different ways of developing. Some are using directly
>Eclipse, others are using build systems (which copy files to the webapp
>directory), others are using the compiling classloader etc. And there is
>no "single right way". For me right now, this is the challenging part.
>We must enable rapid development (we have it in the goals as number 3)
>and I think this should not require any OSGi knowledge. I hope we get at
>this point. Later on, for deployment it's ok to define the dependencies
>and whatever is required.
>  
>

Yup. A minimal OSGi knowlege will be needed though, to define block 
requirements and exports. But that's mostly about writing a simple 
configuration file.

Furthermore, Eclipse (which is based on OSGi) provides a nice GUI to 
write this manifest file, and there are some cool deployment tools for 
OSGi bundles [3].

>The first time I talked with Stefano about this topic (when he visited
>us in Paderborn - gosh, is this really now nearly three years ago?) we
>talked about a smooth migration path: you could simply use your old
>applications as they are for 2.1.x without using bundles/blocks and they
>would simply still work (with all the disadvantages of course). Or you
>could "migrate" and use the (new) blocks. I'm not sure anymore how we
>wanted to achieve this, but I think the basic idea was to just deploy
>the whole cocoon application as a big single block including everything.
>
>On this topic, what do people expect in terms of performance? (I know it
>might be a little bit early) With OSGi we add another layer/isolation,
>so does this cost performance significantly?
>  
>

No, this should have no impact on performance. Blocks add one level in 
the container hierarchy (crawled up when looking up components), but the 
use of blocks is likely to flatten this hierarchy (blocks are siblings) 
compared to deep sitemap hierarchies as of today.

So in the end, this should really change nothing.

>BTW, what is the status about the dependency definition (block.xml).
>What are we planning to use?
>  
>

A lot of what's was planned to be in block.xml is already defined by the 
OSGi bundle manifest file. So it will be stripped-down to keep only what 
is specific to Cocoon blocks.

Sylvain

>[1] http://marc.theaimsgroup.com/?t=112177144100004&r=1&w=2
>  
>

[2] http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=109770175206107&w=2
[3] http://www.knopflerfish.org/desktop.html

-- 
Sylvain Wallez                        Anyware Technologies
http://apache.org/~sylvain            http://anyware-tech.com
Apache Software Foundation Member     Research & Technology Director

Re: xconf snippets in sitemap (Re: [RT] The impact of using OSGi)

[Sylvain Wallez <sy...@apache.org>]

Upayavira wrote:

> Ross Gardler wrote:
>
>> Upayavira wrote:
>>
>> ...
>>
>>> However, already in trunk you have the ability to specify xconf 
>>> snippets in your sitemap, meaning you don't need to patch the core one.
>>
>>
>>
>> Can you provide a pointer to an example for this. It sounds really 
>> useful for Forrest.
>
>
> Er. It is in trunk. 'Fraid I haven't used it yet, and therefore can't 
> point you at it. But try looking at some of the sitemaps there.


Nono, it's not trunk only, but has been there from day one in the 
TreeProcessor, although undocumented :-)

Basically, just add components as you would to in cocoon.xconf in 
<map:components>. Be aware though that those components can only be used 
in the sitemap that declares them and its children.

Trunk has a few more features than 2.1.x though:
- new components can be added to a selector (in 2.1 a selector can only 
be redefined totally)
- component declarations can be externalized using <include src="">
- each sitemap can have its own classpath (although this feature may be 
dropped in favor of OSGi)

Sylvain

-- 
Sylvain Wallez                        Anyware Technologies
http://apache.org/~sylvain            http://anyware-tech.com
Apache Software Foundation Member     Research & Technology Director

Re: xconf snippets in sitemap (Re: [RT] The impact of using OSGi)

[Carsten Ziegeler <cz...@apache.org>]

Upayavira wrote:
> Ross Gardler wrote:
> 
>>Upayavira wrote:
>>
>>...
>>
>>
>>>However, already in trunk you have the ability to specify xconf 
>>>snippets in your sitemap, meaning you don't need to patch the core one.
>>
>>
>>Can you provide a pointer to an example for this. It sounds really 
>>useful for Forrest.
> 
> 
> Er. It is in trunk. 'Fraid I haven't used it yet, and therefore can't 
> point you at it. But try looking at some of the sitemaps there.
> 
You have the same possibilites in the sitemap as you have in the
cocoon.xconf, just use some includes in the map:components section:

  <map:components>
    <map:include src="my-components.xconf"/>
    <map:include dir="xconfs" pattern="*.xconf"/>
  </map:components>

Everything is resolved relative to the directory of the sitemap, and of
course you can use all available protocols (context: etc.) except the
cocoon: protocol.

Carsten

-- 
Carsten Ziegeler - Open Source Group, S&N AG
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/

Re: xconf snippets in sitemap (Re: [RT] The impact of using OSGi)

[Upayavira <uv...@odoko.co.uk>]

Ross Gardler wrote:
> Upayavira wrote:
> 
> ...
> 
>> However, already in trunk you have the ability to specify xconf 
>> snippets in your sitemap, meaning you don't need to patch the core one.
> 
> 
> Can you provide a pointer to an example for this. It sounds really 
> useful for Forrest.

Er. It is in trunk. 'Fraid I haven't used it yet, and therefore can't 
point you at it. But try looking at some of the sitemaps there.

Regards, Upayavira

xconf snippets in sitemap (Re: [RT] The impact of using OSGi)

[Ross Gardler <rg...@apache.org>]

Upayavira wrote:

...

> However, already in trunk you have the ability to specify xconf snippets 
> in your sitemap, meaning you don't need to patch the core one.

Can you provide a pointer to an example for this. It sounds really 
useful for Forrest.

Ross

Re: [RT] The impact of using OSGi

[Upayavira <uv...@odoko.co.uk>]

JD Daniels wrote:
> Ok, I have a question from a user perspective. I have a large, basically 
> company-wide build system. Each of my own projects has its own build, 
> which is included in a "domain" project. I have as an init task to build 
> cocoon, then all my little projects depending on a properties file 
> whether to include them. Then an awful lot of complicated xpatching to 
> get my final web.xml, cocoon.xconf, and sitemap.xmap.
> 
> will I be able to port (for lack of a better word) these projects into 
> an osgi bundle? ( they all use the CHS design ) how will the hibernate 
> setup and sitemaps be integrated? I have a file in each project 
> pipelines, logging, menus, etc that get patche din during the build. I'm 
> wondering if the goodness of osgi in cocoon will take care of this.
> 
> I am asking because I get the impression the osgi will be "hidden" from 
> me at the level I use cocoon.

Well, as far as OSGi is concerned, no, it won't manage that sort of 
stuff for you. All it will do is manage components from other bundles.

However, already in trunk you have the ability to specify xconf snippets 
in your sitemap, meaning you don't need to patch the core one. As far as 
the web.xml file is concerned, I'd want to see us store the init-params 
in a context independent manner. Where that will be, I don't yet know.

If you want to use xpatch while building your blocks, that's fine!

Personally, I want to see this patching process die, as quickly as 
possible. While it works, it really isn't straight-forward. All 
configuration for a block should either be in the block, or be provided 
at the time you install the block. (e.g. mount point). And the core 
Cocoon should require _NO_ patching at all, even when configuring really 
complex apps - it should be a binary black box to many users.

Hope that helps.

Regards, Upayavira

> Upayavira wrote:
> 
>> Carsten Ziegeler wrote:
>>
>>> A lot of people have asked me during the ApacheCon (and via mail) what
>>> the move to OSGi would mean from a user/developer perspective. So I
>>> think it's time to discuss this a little bit further; we already did
>>> this briefly at the hackathon, but of course we should continue this
>>> here visibile for everyone.
>>>
>>> (The following is how I understand/see the whole thing, please correct
>>> me if required).
>>>
>>> First of all, we have an RT about the goals for the next version[1]. As
>>> noted there, the goals are independent from OSGi and the vision is to
>>> *explore* OSGi in the next months. So actually using OSGi is not carved
>>> in stone, but currently it looks like OSGi is the best available
>>> alternative.
>>> The most important goal for myself is 7): compatibility. I don't want to
>>> rewrite each and every piece of code we've done in the past five years.
>>> And I think it's as important to not increase the high learning curve by
>>> introducing another "thing". Ok, from what we discussed in the last
>>> weeks, it seems to me that we can achieve these goals.
>>>
>>> So, what does all of this OSGi stuff mean? OSGi provides some nice
>>> features, like isolated class loading and depedency resolution. And it's
>>> exactly this where we want to use it.
>>>
>>> Although OSGi is a component container by itself, we will not replace
>>> ECM with the OSGi one. This means for a java developer nothing really
>>> changes, you just use ECM like you did before or you use
>>> Spring/Hivemind/Pico/whatever like you did before. Everything looks the
>>> same.
>>>
>>> Underneath, our own ECM implementation will use OSGi to get components
>>> from another bundle, but this is totally transparent. The only thing you
>>> have to do is defining your block dependencies properly. By this our own
>>> ECM implementation will be able to lookup components from the blocks you
>>> depend on.
>>>
>>> For a Cocoon user (writing sitemaps, using xml and xslt) everything
>>> should stay the same. It just works like it does today.
>>>
>>> Now, there is one thing to consider: using OSGi means, everything is a
>>> bundle. So whatever you develop, it must be a bundle. Currently people
>>> are using totally different ways of developing. Some are using directly
>>> Eclipse, others are using build systems (which copy files to the webapp
>>> directory), others are using the compiling classloader etc. And there is
>>> no "single right way". For me right now, this is the challenging part.
>>> We must enable rapid development (we have it in the goals as number 3)
>>> and I think this should not require any OSGi knowledge. I hope we get at
>>> this point. Later on, for deployment it's ok to define the dependencies
>>> and whatever is required.
>>>
>>> The first time I talked with Stefano about this topic (when he visited
>>> us in Paderborn - gosh, is this really now nearly three years ago?) we
>>> talked about a smooth migration path: you could simply use your old
>>> applications as they are for 2.1.x without using bundles/blocks and they
>>> would simply still work (with all the disadvantages of course). Or you
>>> could "migrate" and use the (new) blocks. I'm not sure anymore how we
>>> wanted to achieve this, but I think the basic idea was to just deploy
>>> the whole cocoon application as a big single block including everything.
>>>
>>> On this topic, what do people expect in terms of performance? (I know it
>>> might be a little bit early) With OSGi we add another layer/isolation,
>>> so does this cost performance significantly?
>>
>>
>>
>>> BTW, what is the status about the dependency definition (block.xml).
>>> What are we planning to use?
>>
>>
>>
>> Just replying to this bit - Daniel showed me the block.xml before he 
>> left ApacheCon. It looks pretty simple. Also, given all the other 
>> 'dependency' files we will/might need (gump.xml, manifest, maven 
>> project files, etc) in a discussion it was suggested that we're better 
>> of sticking with our own blocks.xml file - we can always generate 
>> anything else we want from that.
>>
>> So, AFAICS, blokc.xml stays as Stefano proposed it.
>>
>> Regards, Upayavira
>>
>>
> 

Re: [RT] The impact of using OSGi

[Sylvain Wallez <sy...@apache.org>]

JD Daniels wrote:

> Ok, I have a question from a user perspective. I have a large, 
> basically company-wide build system. Each of my own projects has its 
> own build, which is included in a "domain" project. I have as an init 
> task to build cocoon, then all my little projects depending on a 
> properties file whether to include them. Then an awful lot of 
> complicated xpatching to get my final web.xml, cocoon.xconf, and 
> sitemap.xmap.


That awful xpatching will no more be needed. Each block will contribute 
some of its own components to the whole system.

> will I be able to port (for lack of a better word) these projects into 
> an osgi bundle? ( they all use the CHS design ) how will the hibernate 
> setup and sitemaps be integrated? I have a file in each project 
> pipelines, logging, menus, etc that get patche din during the build. 
> I'm wondering if the goodness of osgi in cocoon will take care of this.
>
> I am asking because I get the impression the osgi will be "hidden" 
> from me at the level I use cocoon.


Your use case seems to be exactly the one where blocks will shine. OSGi 
will not be totally hidden as you'll have to describe your blocks, their 
dependencies and what they provide -- or keep everything in one big 
block as of today...

Sylvain

-- 
Sylvain Wallez                        Anyware Technologies
http://apache.org/~sylvain            http://anyware-tech.com
Apache Software Foundation Member     Research & Technology Director

Re: [RT] The impact of using OSGi

[JD Daniels <jd...@kismetsoftware.com>]

Ok, I have a question from a user perspective. I have a large, basically 
company-wide build system. Each of my own projects has its own build, 
which is included in a "domain" project. I have as an init task to build 
cocoon, then all my little projects depending on a properties file 
whether to include them. Then an awful lot of complicated xpatching to 
get my final web.xml, cocoon.xconf, and sitemap.xmap.

will I be able to port (for lack of a better word) these projects into 
an osgi bundle? ( they all use the CHS design ) how will the hibernate 
setup and sitemaps be integrated? I have a file in each project 
pipelines, logging, menus, etc that get patche din during the build. I'm 
wondering if the goodness of osgi in cocoon will take care of this.

I am asking because I get the impression the osgi will be "hidden" from 
me at the level I use cocoon.

JD

Upayavira wrote:
> Carsten Ziegeler wrote:
> 
>> A lot of people have asked me during the ApacheCon (and via mail) what
>> the move to OSGi would mean from a user/developer perspective. So I
>> think it's time to discuss this a little bit further; we already did
>> this briefly at the hackathon, but of course we should continue this
>> here visibile for everyone.
>>
>> (The following is how I understand/see the whole thing, please correct
>> me if required).
>>
>> First of all, we have an RT about the goals for the next version[1]. As
>> noted there, the goals are independent from OSGi and the vision is to
>> *explore* OSGi in the next months. So actually using OSGi is not carved
>> in stone, but currently it looks like OSGi is the best available
>> alternative.
>> The most important goal for myself is 7): compatibility. I don't want to
>> rewrite each and every piece of code we've done in the past five years.
>> And I think it's as important to not increase the high learning curve by
>> introducing another "thing". Ok, from what we discussed in the last
>> weeks, it seems to me that we can achieve these goals.
>>
>> So, what does all of this OSGi stuff mean? OSGi provides some nice
>> features, like isolated class loading and depedency resolution. And it's
>> exactly this where we want to use it.
>>
>> Although OSGi is a component container by itself, we will not replace
>> ECM with the OSGi one. This means for a java developer nothing really
>> changes, you just use ECM like you did before or you use
>> Spring/Hivemind/Pico/whatever like you did before. Everything looks the
>> same.
>>
>> Underneath, our own ECM implementation will use OSGi to get components
>> from another bundle, but this is totally transparent. The only thing you
>> have to do is defining your block dependencies properly. By this our own
>> ECM implementation will be able to lookup components from the blocks you
>> depend on.
>>
>> For a Cocoon user (writing sitemaps, using xml and xslt) everything
>> should stay the same. It just works like it does today.
>>
>> Now, there is one thing to consider: using OSGi means, everything is a
>> bundle. So whatever you develop, it must be a bundle. Currently people
>> are using totally different ways of developing. Some are using directly
>> Eclipse, others are using build systems (which copy files to the webapp
>> directory), others are using the compiling classloader etc. And there is
>> no "single right way". For me right now, this is the challenging part.
>> We must enable rapid development (we have it in the goals as number 3)
>> and I think this should not require any OSGi knowledge. I hope we get at
>> this point. Later on, for deployment it's ok to define the dependencies
>> and whatever is required.
>>
>> The first time I talked with Stefano about this topic (when he visited
>> us in Paderborn - gosh, is this really now nearly three years ago?) we
>> talked about a smooth migration path: you could simply use your old
>> applications as they are for 2.1.x without using bundles/blocks and they
>> would simply still work (with all the disadvantages of course). Or you
>> could "migrate" and use the (new) blocks. I'm not sure anymore how we
>> wanted to achieve this, but I think the basic idea was to just deploy
>> the whole cocoon application as a big single block including everything.
>>
>> On this topic, what do people expect in terms of performance? (I know it
>> might be a little bit early) With OSGi we add another layer/isolation,
>> so does this cost performance significantly?
> 
> 
>> BTW, what is the status about the dependency definition (block.xml).
>> What are we planning to use?
> 
> 
> Just replying to this bit - Daniel showed me the block.xml before he 
> left ApacheCon. It looks pretty simple. Also, given all the other 
> 'dependency' files we will/might need (gump.xml, manifest, maven project 
> files, etc) in a discussion it was suggested that we're better of 
> sticking with our own blocks.xml file - we can always generate anything 
> else we want from that.
> 
> So, AFAICS, blokc.xml stays as Stefano proposed it.
> 
> Regards, Upayavira
> 
> 

Re: [RT] The impact of using OSGi

[Upayavira <uv...@odoko.co.uk>]

Carsten Ziegeler wrote:
> A lot of people have asked me during the ApacheCon (and via mail) what
> the move to OSGi would mean from a user/developer perspective. So I
> think it's time to discuss this a little bit further; we already did
> this briefly at the hackathon, but of course we should continue this
> here visibile for everyone.
> 
> (The following is how I understand/see the whole thing, please correct
> me if required).
> 
> First of all, we have an RT about the goals for the next version[1]. As
> noted there, the goals are independent from OSGi and the vision is to
> *explore* OSGi in the next months. So actually using OSGi is not carved
> in stone, but currently it looks like OSGi is the best available
> alternative.
> The most important goal for myself is 7): compatibility. I don't want to
> rewrite each and every piece of code we've done in the past five years.
> And I think it's as important to not increase the high learning curve by
> introducing another "thing". Ok, from what we discussed in the last
> weeks, it seems to me that we can achieve these goals.
> 
> So, what does all of this OSGi stuff mean? OSGi provides some nice
> features, like isolated class loading and depedency resolution. And it's
> exactly this where we want to use it.
> 
> Although OSGi is a component container by itself, we will not replace
> ECM with the OSGi one. This means for a java developer nothing really
> changes, you just use ECM like you did before or you use
> Spring/Hivemind/Pico/whatever like you did before. Everything looks the
> same.
> 
> Underneath, our own ECM implementation will use OSGi to get components
> from another bundle, but this is totally transparent. The only thing you
> have to do is defining your block dependencies properly. By this our own
> ECM implementation will be able to lookup components from the blocks you
> depend on.
> 
> For a Cocoon user (writing sitemaps, using xml and xslt) everything
> should stay the same. It just works like it does today.
> 
> Now, there is one thing to consider: using OSGi means, everything is a
> bundle. So whatever you develop, it must be a bundle. Currently people
> are using totally different ways of developing. Some are using directly
> Eclipse, others are using build systems (which copy files to the webapp
> directory), others are using the compiling classloader etc. And there is
> no "single right way". For me right now, this is the challenging part.
> We must enable rapid development (we have it in the goals as number 3)
> and I think this should not require any OSGi knowledge. I hope we get at
> this point. Later on, for deployment it's ok to define the dependencies
> and whatever is required.
> 
> The first time I talked with Stefano about this topic (when he visited
> us in Paderborn - gosh, is this really now nearly three years ago?) we
> talked about a smooth migration path: you could simply use your old
> applications as they are for 2.1.x without using bundles/blocks and they
> would simply still work (with all the disadvantages of course). Or you
> could "migrate" and use the (new) blocks. I'm not sure anymore how we
> wanted to achieve this, but I think the basic idea was to just deploy
> the whole cocoon application as a big single block including everything.
> 
> On this topic, what do people expect in terms of performance? (I know it
> might be a little bit early) With OSGi we add another layer/isolation,
> so does this cost performance significantly?

> BTW, what is the status about the dependency definition (block.xml).
> What are we planning to use?

Just replying to this bit - Daniel showed me the block.xml before he 
left ApacheCon. It looks pretty simple. Also, given all the other 
'dependency' files we will/might need (gump.xml, manifest, maven project 
files, etc) in a discussion it was suggested that we're better of 
sticking with our own blocks.xml file - we can always generate anything 
else we want from that.

So, AFAICS, blokc.xml stays as Stefano proposed it.

Regards, Upayavira

Re: [RT] The impact of using OSGi

[Niclas Hedhman <he...@gmail.com>]

On Monday 08 August 2005 15:01, Nicola Ken Barozzi wrote:
>  I think Cocoon must try using it now: if it works as it
> should, it will be of great help. If not, it has been at least tried.

I also suggest to go straight for Maven2. Check with Brett Porter with the 
list of requirements, and see if M2 is ready for Cocoon usage. Considering 
the number of modules built here, I think the M2 peeps is even interested to 
help out putting it in place, to ensure there is no problems for larger 
scaled systems.


Cheers
Niclas

Re: [RT] The impact of using OSGi

[Nicola Ken Barozzi <ni...@apache.org>]

Torsten Curdt wrote:
>>
>>> ... but I just wanted to expose the mental connections that I've 
>>> been making last week: if we consider moving to Maven, this might  be
>>> the right time to do it, or at least try.
>>
>> Yep. +1!
> 
> ...I know there are quite diverse feelings
> about the build system ...but I would love
> to see that happen.

I have always - and also at fault - criticized Maven as a build system.
That was Maven 1.

Maven 2 is an order of magnitude better, and has very good design
considerations. I think Cocoon must try using it now: if it works as it
should, it will be of great help. If not, it has been at least tried.

-- 
Nicola Ken Barozzi                   nicolaken@apache.org
            - verba volant, scripta manent -
   (discussions get forgotten, just code remains)
---------------------------------------------------------------------

Re: [RT] The impact of using OSGi

[Torsten Curdt <tc...@apache.org>]

>
>> ... but I just wanted to expose the mental connections that I've  
>> been making last week: if we consider moving to Maven, this might  
>> be the right time to do it, or at least try.
>>
>
>
> Yep. +1!

...I know there are quite diverse feelings
about the build system ...but I would love
to see that happen.

cheers
--
Torsten

Re: [RT] The impact of using OSGi

[Antonio Gallardo <ag...@agssa.net>]

Bertrand Delacretaz wrote:

> ... but I just wanted to expose the mental connections that I've been 
> making last week: if we consider moving to Maven, this might be the 
> right time to do it, or at least try.


Yep. +1!

Best Regards,

Antonio Gallardo

Re: [RT] The impact of using OSGi

[Niclas Hedhman <ni...@hedhman.org>]

On Monday 25 July 2005 20:05, Upayavira wrote:
> Niclas Hedhman wrote:
> >>Building when you depend on java code in other bundles isn't that easy.
> >>For one, you may depend upon java classes which are in a jar embedded
> >>within another jar.
> >
> > 3. I think it is expected that classes that a Bundle depends on for its
> > on instantiation and execution, is distributed with it (or referenced in
> > the Manifest to a global resource (probably not recommended but
> > possible).
>
> I don't understand quite how this could work. After all, if one bundle
> depends upon another, if that bundle includes its dependency within it,
> hasn't that killed all benefit? Or must it just include the interface
> that its dependency bundle implements? Is that what you mean?

The classloading mechanism in OSGi is pretty complex, but essentially any 
bundle may export a particular Java class/interface (versioned).

So, if I have a Bundle that depends on AbcService, then my Bundle will not be 
able to "load" unless the AbcService interface is available, the notorious 
NoClassDefFoundError will result.
But, if I include all the classes that are required for my own compile, i.e. 
the interfaces, classes used in method arguments/return-types and exceptions, 
then my bundle can load without problems. And OSGi, will be able to cope with 
this situation when the implementing bundle gets loaded later.

It will also allow my bundle to either be loaded "standby", i.e. not started, 
or even started and be aware of the non-existence of the dependency and 
handle it in runtime, by listening in on Service events (or delegate it to a 
tracker to do it for you).

> > OSGi doesn't Import/Export classes, it only imports/exports packages. And
> > by using differnt <path> in Ant, you can make the distinction.
>
> See [1]. I would assume this is R4 syntax, although I can't be sure.

Ahhh... yes that must be R4. R3 doesn't have it. Ok. So we need better tools 
in the R4 world :o)

> >>So, the only solution we were able to come up with was to
> >>explode the dependency bundle's jar, only extracting the exported
> >>classes/interfaces.
> >
> > Not sure what you mean here.
> >
> > It seems to be a common pattern that a Bundle Jar has the "third-party
> > dependencies" in embedded Jars, while the classes "owned" by that Bundle
> > sits in the Jar root. This makes compiling easy and distribution harder,
> > since you probably want the exported classes from a Bundle to be inside
> > your bundle.
>
> Sorry, don't get why this makes distribution harder.

It means that I want to extract the API classes and re-distribute them in my 
own bundle (see above), which is not totally apparent what that is. And 
taking the entire Bundle is also a waste of payload, since it contains its 
dependencies as well in the embedded Jars.

> > I think there is room for a lot of improvement in the global OSGi
> > community about this. For instance, exported classes could (should?) be
> > published as Maven artifacts, and be referenced in the Manifest as
> > artifact: URLs (I have this working locally), and OSGi will resolve at
> > runtime which bundle actually exposes the exported classes.
>
> Doesn't it do this already? How does Maven add something here?

Yes, OSGi resolves correctly, but it is common that the Bundle classpath is 
set to jars internal to the Jar. By having URLs in the Bundle classpath, 
like;
  artifact:jar:xstream/xstream#1.1
instead, will make it unnecessary to have the xstream-1.1.jar embedded, and 
rely on a Maven-repository-capable resolution/caching system to do this for 
you. Very sweet, provided you use such MRCRCS  :o)


> Yup. Move a few Cocoon devs over to Oscar and get the project going.
> Only problem is I haven't managed to get Cocoon to run with Oscar yet :-(

I have been busy with OSGi in another context, and not looked at the 
Cocoon-connection yet (and probably never will have enough time for that). 
The good side is that we are doing some progress on the tools front, so 
perhaps some of that work will improve life here as well, but that is still 
quite far off. :o(


Cheers
Niclas

Re: [RT] The impact of using OSGi

[Upayavira <uv...@odoko.co.uk>]

Niclas Hedhman wrote:
> On Monday 25 July 2005 18:57, Upayavira wrote:
> 
>>Well, no, it doesn't. OSGi by default doesn't do any dependency
>>resolution. Either by package, or by 'block'. In which case, if we use
>>Maven for it at build time, we're still stuck with a need for it at
>>deploy time, which seems a little odd.
> 
> There are a few issues in play here;
>   1. Depending on Services.
>   2. Depending on specific bundles.
>   3. Depending on Java interfaces, not "owned" by the current bundle.

Yup. Now, in Cocoon's 'sitemap blocks', as Stefano defined them, a block 
is identified by its namespace, and blocks depend upon each other via 
these namespaces. I'm not yet sure whether we can implement that kind of 
dependency management using point 2 above or not. I hope so!

>>Building when you depend on java code in other bundles isn't that easy.
>>For one, you may depend upon java classes which are in a jar embedded
>>within another jar. 
> 
> 3. I think it is expected that classes that a Bundle depends on for its on 
> instantiation and execution, is distributed with it (or referenced in the 
> Manifest to a global resource (probably not recommended but possible).

I don't understand quite how this could work. After all, if one bundle 
depends upon another, if that bundle includes its dependency within it, 
hasn't that killed all benefit? Or must it just include the interface 
that its dependency bundle implements? Is that what you mean?

>>Secondly, the bundle you 
>>are depending upon might only export some of its classes. Ant can't
>>specify only certain classes in its classpath (I dunno if Maven can
>>handle this). 
> 
> OSGi doesn't Import/Export classes, it only imports/exports packages. And by 
> using differnt <path> in Ant, you can make the distinction. 

See [1]. I would assume this is R4 syntax, although I can't be sure.

>>So, the only solution we were able to come up with was to 
>>explode the dependency bundle's jar, only extracting the exported
>>classes/interfaces.
> 
> Not sure what you mean here.
> 
> It seems to be a common pattern that a Bundle Jar has the "third-party 
> dependencies" in embedded Jars, while the classes "owned" by that Bundle sits 
> in the Jar root. This makes compiling easy and distribution harder, since you 
> probably want the exported classes from a Bundle to be inside your bundle.

Sorry, don't get why this makes distribution harder.

> I think there is room for a lot of improvement in the global OSGi community 
> about this. For instance, exported classes could (should?) be published as 
> Maven artifacts, and be referenced in the Manifest as artifact: URLs (I have 
> this working locally), and OSGi will resolve at runtime which bundle actually 
> exposes the exported classes.

Doesn't it do this already? How does Maven add something here?

>>This seems to me to be an OSGi specific problem, which, to my mind,
>>would be best sorted in an OSGi context.
> 
> Agree. Cocoon should probably forward "usage issues" to the incubating Oscar 
> project, and until that settles, the migration from a single Cocoon bundle to 
> use OSGi bundles in Cocoon will be somewhat 'icky'.

Yup. Move a few Cocoon devs over to Oscar and get the project going. 
Only problem is I haven't managed to get Cocoon to run with Oscar yet :-(

Regards, Upayavira

[1] http://oscar.objectweb.org/oscar-alpha.html#export-filters

Re: [RT] The impact of using OSGi

[Niclas Hedhman <ni...@hedhman.org>]

On Monday 25 July 2005 18:57, Upayavira wrote:

> Well, no, it doesn't. OSGi by default doesn't do any dependency
> resolution. Either by package, or by 'block'. In which case, if we use
> Maven for it at build time, we're still stuck with a need for it at
> deploy time, which seems a little odd.

There are a few issues in play here;
  1. Depending on Services.
  2. Depending on specific bundles.
  3. Depending on Java interfaces, not "owned" by the current bundle.

> Building when you depend on java code in other bundles isn't that easy.
> For one, you may depend upon java classes which are in a jar embedded
> within another jar. 

3. I think it is expected that classes that a Bundle depends on for its on 
instantiation and execution, is distributed with it (or referenced in the 
Manifest to a global resource (probably not recommended but possible).


> Secondly, the bundle you 
> are depending upon might only export some of its classes. Ant can't
> specify only certain classes in its classpath (I dunno if Maven can
> handle this). 

OSGi doesn't Import/Export classes, it only imports/exports packages. And by 
using differnt <path> in Ant, you can make the distinction. 

> So, the only solution we were able to come up with was to 
> explode the dependency bundle's jar, only extracting the exported
> classes/interfaces.

Not sure what you mean here.

It seems to be a common pattern that a Bundle Jar has the "third-party 
dependencies" in embedded Jars, while the classes "owned" by that Bundle sits 
in the Jar root. This makes compiling easy and distribution harder, since you 
probably want the exported classes from a Bundle to be inside your bundle.

I think there is room for a lot of improvement in the global OSGi community 
about this. For instance, exported classes could (should?) be published as 
Maven artifacts, and be referenced in the Manifest as artifact: URLs (I have 
this working locally), and OSGi will resolve at runtime which bundle actually 
exposes the exported classes.

> This seems to me to be an OSGi specific problem, which, to my mind,
> would be best sorted in an OSGi context.

Agree. Cocoon should probably forward "usage issues" to the incubating Oscar 
project, and until that settles, the migration from a single Cocoon bundle to 
use OSGi bundles in Cocoon will be somewhat 'icky'.



Cheers
Niclas

Re: [RT] The impact of using OSGi

[Brett Porter <br...@apache.org>]

Torsten Curdt wrote:

>>> ...OSGi by default doesn't do any dependency resolution. Either by 
>>> package, or by 'block'. In which case, if we use Maven for it at 
>>> build time, we're still stuck with a need for it at deploy time, 
>>> which seems a little odd...
>>>
>>
>> I don't think we should use Maven for runtime dependency  resolution,
>> as it's not its role.
>>
>
> ...I think the dependency resolution is definitely an overlap
> with maven. The questions is whether there is code or at least
> knowledge that makes sense to share.
>
Would like to avoid too much cross-posting, but here goes :)

Portions of Maven2's code could definitely be used for runtime
dependency resolution, if that is required. The code is built around
components, of which the artifact management is one that is independant
of the rest of the Maven code. This is what is primarily used to build
the Ant tasks and exposes all of the dependency features Maven has.

It is independant of the metadata (though I haven't done any tests with
anything else, there is no tie in the code), so theoretically it could
resolve OSGi bundles directly. However if you end up using Maven (or the
Ant tasks) as the build system as well, it would work as is using
maven-project and the existing POM files from the repository (which
should include enough data to construct the information for an OSGi bundle).

To draw a parallel to this situation, there is actually a
repository-enabled version of the Plexus container that has been used in
the past which does runtime resolution of components from the Maven
repository using the artifact code - so it is definitely possible. This
is basically how Maven 2's plugin architecture works.

We have a couple of people looking into writing OSGi build plugins for
Maven and with everything going on at the moment in that space, Maven's
ability to work with OSGi will definitely be important going forward.

Hope this helps. I'll try and follow this thread from the archives of
the cocoon list, but feel free to post back to maven-dev again if there
are any questions.

Cheers,
Brett



---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: [RT] The impact of using OSGi

[Brett Porter <br...@apache.org>]

Torsten Curdt wrote:

>>> ...OSGi by default doesn't do any dependency resolution. Either by 
>>> package, or by 'block'. In which case, if we use Maven for it at 
>>> build time, we're still stuck with a need for it at deploy time, 
>>> which seems a little odd...
>>>
>>
>> I don't think we should use Maven for runtime dependency  resolution,
>> as it's not its role.
>>
>
> ...I think the dependency resolution is definitely an overlap
> with maven. The questions is whether there is code or at least
> knowledge that makes sense to share.
>
Would like to avoid too much cross-posting, but here goes :)

Portions of Maven2's code could definitely be used for runtime
dependency resolution, if that is required. The code is built around
components, of which the artifact management is one that is independant
of the rest of the Maven code. This is what is primarily used to build
the Ant tasks and exposes all of the dependency features Maven has.

It is independant of the metadata (though I haven't done any tests with
anything else, there is no tie in the code), so theoretically it could
resolve OSGi bundles directly. However if you end up using Maven (or the
Ant tasks) as the build system as well, it would work as is using
maven-project and the existing POM files from the repository (which
should include enough data to construct the information for an OSGi bundle).

To draw a parallel to this situation, there is actually a
repository-enabled version of the Plexus container that has been used in
the past which does runtime resolution of components from the Maven
repository using the artifact code - so it is definitely possible. This
is basically how Maven 2's plugin architecture works.

We have a couple of people looking into writing OSGi build plugins for
Maven and with everything going on at the moment in that space, Maven's
ability to work with OSGi will definitely be important going forward.

Hope this helps. I'll try and follow this thread from the archives of
the cocoon list, but feel free to post back to maven-dev again if there
are any questions.

Cheers,
Brett

Re: [RT] The impact of using OSGi

[Torsten Curdt <tc...@apache.org>]

>> ...OSGi by default doesn't do any dependency resolution. Either by  
>> package, or by 'block'. In which case, if we use Maven for it at  
>> build time, we're still stuck with a need for it at deploy time,  
>> which seems a little odd...
>>
>
> I don't think we should use Maven for runtime dependency  
> resolution, as it's not its role.
>

...I think the dependency resolution is definitely an overlap
with maven. The questions is whether there is code or at least
knowledge that makes sense to share.

cheers
--
Torsten

Re: [RT] The impact of using OSGi

[Torsten Curdt <tc...@apache.org>]

>> ...OSGi by default doesn't do any dependency resolution. Either by  
>> package, or by 'block'. In which case, if we use Maven for it at  
>> build time, we're still stuck with a need for it at deploy time,  
>> which seems a little odd...
>>
>
> I don't think we should use Maven for runtime dependency  
> resolution, as it's not its role.
>

...I think the dependency resolution is definitely an overlap
with maven. The questions is whether there is code or at least
knowledge that makes sense to share.

cheers
--
Torsten

Re: [RT] The impact of using OSGi

[Sylvain Wallez <sy...@apache.org>]

Upayavira wrote:

> My feeling is that the sort of things we're going to hit are going to 
> be very generic, and thus relevant to OSGi in general. Therefore, I'd 
> have the discussion over at Oscar-dev, and see how they approach it. 
> Now, if they use Maven...


There's an ongoing discussion on oscar-dev about a maven plugin to build 
manifest files. And there's also http://mavenosgiplugin.berlios.de/

Sylvain

-- 
Sylvain Wallez                        Anyware Technologies
http://apache.org/~sylvain            http://anyware-tech.com
Apache Software Foundation Member     Research & Technology Director

Re: [RT] The impact of using OSGi

[Upayavira <uv...@odoko.co.uk>]

Bertrand Delacretaz wrote:
> Le 25 juil. 05, à 13:43, Upayavira a écrit :
> 
>> ....My feeling is that the sort of things we're going to hit are going 
>> to be very generic, and thus relevant to OSGi in general. Therefore, 
>> I'd have the discussion over at Oscar-dev, and see how they approach 
>> it. Now, if they use Maven...
> 
> 
> According to oscar-dev (I don't think that list is archived yet), 
> someone has already written a plugin for Maven 2 to generate OSGI 
> bundles, and is apparently going to commit it to oscar-dev soon.

Yes, which is why I said "if they use...". We'll see what that plugin 
does. But as I say, we need build _and_ deploy time dependency 
resolution, and AFAIK Maven only offers build time. So let's wait and 
see what this Maven thing does at Oscar, and see whether it helps us.

Regards, Upayavira

Re: [RT] The impact of using OSGi

[Bertrand Delacretaz <bd...@apache.org>]

Le 25 juil. 05, à 13:43, Upayavira a écrit :

> ....My feeling is that the sort of things we're going to hit are going 
> to be very generic, and thus relevant to OSGi in general. Therefore, 
> I'd have the discussion over at Oscar-dev, and see how they approach 
> it. Now, if they use Maven...

According to oscar-dev (I don't think that list is archived yet), 
someone has already written a plugin for Maven 2 to generate OSGI 
bundles, and is apparently going to commit it to oscar-dev soon.

-Bertrand

Re: [RT] The impact of using OSGi

[Upayavira <uv...@odoko.co.uk>]

Bertrand Delacretaz wrote:
> Le 25 juil. 05, à 12:57, Upayavira a écrit :
> 
>> ...OSGi by default doesn't do any dependency resolution. Either by 
>> package, or by 'block'. In which case, if we use Maven for it at build 
>> time, we're still stuck with a need for it at deploy time, which seems 
>> a little odd...
> 
> 
> I don't think we should use Maven for runtime dependency resolution, as 
> it's not its role.
> 
> My point was that, as our build system will have to change a lot for 
> OSGI (I assume, based on the need to create multiple bundles and to make 
> it easy to add metadata to them) , and we've been talking about moving 
> to Maven a few times without finding sufficient motivation to do it, the 
> move to OSGI might be the right time to move to Maven as well.
> 
> But it's only a suggestion, as I'm not going to work on it in the next 
> few weeks, and it has (IMHO) nothing to do with runtime. Just meant to 
> [RT] the idea.

My feeling is that the sort of things we're going to hit are going to be 
very generic, and thus relevant to OSGi in general. Therefore, I'd have 
the discussion over at Oscar-dev, and see how they approach it. Now, if 
they use Maven...

Regards, Upayavira

Re: [RT] The impact of using OSGi

[Bertrand Delacretaz <bd...@apache.org>]

Le 25 juil. 05, à 12:57, Upayavira a écrit :

> ...OSGi by default doesn't do any dependency resolution. Either by 
> package, or by 'block'. In which case, if we use Maven for it at build 
> time, we're still stuck with a need for it at deploy time, which seems 
> a little odd...

I don't think we should use Maven for runtime dependency resolution, as 
it's not its role.

My point was that, as our build system will have to change a lot for 
OSGI (I assume, based on the need to create multiple bundles and to 
make it easy to add metadata to them) , and we've been talking about 
moving to Maven a few times without finding sufficient motivation to do 
it, the move to OSGI might be the right time to move to Maven as well.

But it's only a suggestion, as I'm not going to work on it in the next 
few weeks, and it has (IMHO) nothing to do with runtime. Just meant to 
[RT] the idea.

-Bertrand

Re: [RT] The impact of using OSGi

[Upayavira <uv...@odoko.co.uk>]

Carsten Ziegeler wrote:
> Upayavira wrote:
> 
>>Can someone explain how maven/OSGi would play together? OSGi has the 
>>ability to download and install packages. It doesn't though have any 
>>dependency resolution stuff in it. Does Maven provide that? However, 
>>IIUC, Maven is a build-time tool, and any dependency resolution we use 
>>should be usable at runtime (even if that isn't always the best time to 
>>do it). Could Maven handle this usecase too?
>>
> 
> As you said Maven is a build-time tool, so we should use it for that
> case. afaiu OSGi will do all the run-time stuff for us.

Well, no, it doesn't. OSGi by default doesn't do any dependency 
resolution. Either by package, or by 'block'. In which case, if we use 
Maven for it at build time, we're still stuck with a need for it at 
deploy time, which seems a little odd.

> But we need something that can compile our java code. In Maven you
> simply define on which other projects/jars you depend and maven does the
> downloading/resolution stuff and then compiles your code.

Building when you depend on java code in other bundles isn't that easy. 
For one, you may depend upon java classes which are in a jar embedded 
within another jar. Java/ant can't handle that. Secondly, the bundle you 
are depending upon might only export some of its classes. Ant can't 
specify only certain classes in its classpath (I dunno if Maven can 
handle this). So, the only solution we were able to come up with was to 
explode the dependency bundle's jar, only extracting the exported 
classes/interfaces.

This seems to me to be an OSGi specific problem, which, to my mind, 
would be best sorted in an OSGi context.

> And we need a tool that creates a bundle out of the source tree
> (creating a jar, building the manifest, stuffing all resources into it
> etc.). There will be a Maven plugin for this, I think, so we could
> simply use it.

Well, once you've exploded your dependencies, building a bundle should 
be pretty trivial, shouldn't it?

> But I agree that there are some more questions, so I think we should
> simply experiment a little bit with one block, like Bertrand suggested,
> and see what the outcome is.

Yup, definitely.

Upayavira

Re: [RT] The impact of using OSGi

[Carsten Ziegeler <cz...@apache.org>]

Upayavira wrote:
> 
> Can someone explain how maven/OSGi would play together? OSGi has the 
> ability to download and install packages. It doesn't though have any 
> dependency resolution stuff in it. Does Maven provide that? However, 
> IIUC, Maven is a build-time tool, and any dependency resolution we use 
> should be usable at runtime (even if that isn't always the best time to 
> do it). Could Maven handle this usecase too?
> 
As you said Maven is a build-time tool, so we should use it for that
case. afaiu OSGi will do all the run-time stuff for us.
But we need something that can compile our java code. In Maven you
simply define on which other projects/jars you depend and maven does the
downloading/resolution stuff and then compiles your code.

And we need a tool that creates a bundle out of the source tree
(creating a jar, building the manifest, stuffing all resources into it
etc.). There will be a Maven plugin for this, I think, so we could
simply use it.

But I agree that there are some more questions, so I think we should
simply experiment a little bit with one block, like Bertrand suggested,
and see what the outcome is.

Carsten

-- 
Carsten Ziegeler - Open Source Group, S&N AG
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/

Re: [RT] The impact of using OSGi

[Upayavira <uv...@odoko.co.uk>]

Carsten Ziegeler wrote:
> Bertrand Delacretaz wrote:
> 
>>Apart from that, my impression is that the biggest impact might be on 
>>the build system and on the directory structure of our code: separating 
>>the code in a way that makes sense for bundles (separate interfaces 
>>from implementations, separate units of functionality) would make the 
>>mapping to OSGI bundles much easier, and may make the core code easier 
>>to understand.
>>
>>BTW this maps nicely to the Maven concept of smaller projects organized 
>>in a hierarchy, and people are working on a Maven 2 plugin to create 
>>OSGI bundles, so we have some hints here ;-)
>>
>>I won't be able to help much this month due to more holidays, and as 
>>usual whoever does the work decides, but I just wanted to expose the 
>>mental connections that I've been making last week: if we consider 
>>moving to Maven, this might be the right time to do it, or at least 
>>try.
>>
> 
> Yes, definitly, +5 - has anyone already done some steps towards this?
> I'm planning to have a look at it in the next days.

Can someone explain how maven/OSGi would play together? OSGi has the 
ability to download and install packages. It doesn't though have any 
dependency resolution stuff in it. Does Maven provide that? However, 
IIUC, Maven is a build-time tool, and any dependency resolution we use 
should be usable at runtime (even if that isn't always the best time to 
do it). Could Maven handle this usecase too?

Regards, Upayavira

Re: [RT] The impact of using OSGi

[Daniel Fagerstrom <da...@nada.kth.se>]

Bertrand Delacretaz wrote:
<snip/>
> Last week I tried loading the template block (that Reinhard has hacked 
> to be an OSGI bundle) in OSGI dynamically, after starting without it, 
> but it didn't work, as the cocoon_servlet bundle (IIRC) was looking for 
> some xconf resource from the template block at startup and failed.

The aim with making a bundle of the template block was to test the 
simplest way of implementing blocks with OSGi. The idea is as follows: 
the template block is a passive library bundle (no activator) that 
exports all its packages. The Cocoon core bundle is configured to 
dynamically import all o.a.c packages:

   DynamicImport-Package: org.apache.cocoon.*

This makes it possible for the service manager in the Cocoon core bundle 
to create all components where the classes are installed in the 
framework and that are in o.a.c.**. The implementation don't contain any 
dynamic handling of configurations, IIUC the needed configuration for 
the template block is handled statically of the build system.

Configurations could be handled dynamically by letting the Cocoon 
servlet bundle register a bundle update listener that gets notified each 
time a bundle is installed, updated or uninstalled and checks if the 
bundle contains a configuration file and updates its service manager in 
that case.

Such a system would be a better and dynamic replacement of the compile 
time blocks of today. But it has two important drawbacks: it require 
blocks to export all packages and it makes the block dependent of the 
component manager (ECM++) of the Cocoon core.

The solution with having a per block component manager that publish 
components as OSGi services, that Sylvain is working on makes the system 
much more flexible and scalable. Different blocks can be managed by 
different component managers: ECM++, SPring, Pico, ... Also it is enough 
that the block export the API of the components, implementation classes 
can be shielded.

> But in theory OSGI-based blocks could already be built totally outside 
> of the main build, and loaded later as bundles.

Yes, but to make it practical we would need dynamic configuration 
handling. And as the component manager per block is much better we 
shoould focus on that.

/Daniel

Re: [RT] The impact of using OSGi

[Bertrand Delacretaz <bd...@apache.org>]

Le 25 juil. 05, à 12:13, Carsten Ziegeler a écrit :

> Bertrand Delacretaz wrote:
>> ....if we consider
>> moving to Maven, this might be the right time to do it, or at least
>> try.
>>
> Yes, definitly, +5 - has anyone already done some steps towards this?
> I'm planning to have a look at it in the next days.

Note that just creating a completely separate block in an OSGI bundle 
built with Maven 2 would be a good way of experimenting, without 
disrupting the trunk.

Last week I tried loading the template block (that Reinhard has hacked 
to be an OSGI bundle) in OSGI dynamically, after starting without it, 
but it didn't work, as the cocoon_servlet bundle (IIRC) was looking for 
some xconf resource from the template block at startup and failed.

But in theory OSGI-based blocks could already be built totally outside 
of the main build, and loaded later as bundles.

-Bertrand

Re: [RT] The impact of using OSGi

[Ralph Goers <Ra...@dslextreme.com>]

Carsten Ziegeler wrote:

>Bertrand Delacretaz wrote:
>  
>
>>Apart from that, my impression is that the biggest impact might be on 
>>the build system and on the directory structure of our code: separating 
>>the code in a way that makes sense for bundles (separate interfaces 
>>from implementations, separate units of functionality) would make the 
>>mapping to OSGI bundles much easier, and may make the core code easier 
>>to understand.
>>
>>BTW this maps nicely to the Maven concept of smaller projects organized 
>>in a hierarchy, and people are working on a Maven 2 plugin to create 
>>OSGI bundles, so we have some hints here ;-)
>>
>>I won't be able to help much this month due to more holidays, and as 
>>usual whoever does the work decides, but I just wanted to expose the 
>>mental connections that I've been making last week: if we consider 
>>moving to Maven, this might be the right time to do it, or at least 
>>try.
>>
>>    
>>
>Yes, definitly, +5 - has anyone already done some steps towards this?
>I'm planning to have a look at it in the next days.
>
>Carsten
>
>  
>
Since I've had to look over how to build a block in the last few days 
and have quite a bit of experience with Maven 1 I've had a chance to 
think about the problems here:
1.   gump.xml has all the dependencies for everything.  This has to 
change with a move to maven.  Each block needs its own project.xml with 
its own dependencies.
2.   The "main" project directory needs its own project.xml.
3.   Currently we allow building blocks to be controlled by propery 
settings. This should actually stop.  Instead, the main project 
properties should contain a pattern to cause all the blocks to be built.
4.  The individual artificts constructed by maven should be placed in a 
repository (i.e. the core and all the blocks).
5.  The Cocoon download should consist of downloading the core (or maybe 
just a project.xml that depends on the core). The customer should (or 
could) modify/create a project.xml that identifies which blocks they 
want. Running maven would then download them all.
6.  The sample site needs to be broken into its own block that depends 
on all the cocoon blocks.

Basically, this is a major pain but, IMO, would result in a cleaner 
build system and would be easier for end users as they would not have to 
download the source any more.

Re: [RT] The impact of using OSGi

[Carsten Ziegeler <cz...@apache.org>]

Bertrand Delacretaz wrote:
> 
> Apart from that, my impression is that the biggest impact might be on 
> the build system and on the directory structure of our code: separating 
> the code in a way that makes sense for bundles (separate interfaces 
> from implementations, separate units of functionality) would make the 
> mapping to OSGI bundles much easier, and may make the core code easier 
> to understand.
> 
> BTW this maps nicely to the Maven concept of smaller projects organized 
> in a hierarchy, and people are working on a Maven 2 plugin to create 
> OSGI bundles, so we have some hints here ;-)
> 
> I won't be able to help much this month due to more holidays, and as 
> usual whoever does the work decides, but I just wanted to expose the 
> mental connections that I've been making last week: if we consider 
> moving to Maven, this might be the right time to do it, or at least 
> try.
> 
Yes, definitly, +5 - has anyone already done some steps towards this?
I'm planning to have a look at it in the next days.

Carsten


-- 
Carsten Ziegeler - Open Source Group, S&N AG
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/

Re: [RT] The impact of using OSGi

[Jason van Zyl <ja...@maven.org>]

On Mon, 2005-07-25 at 10:24 +0200, Bertrand Delacretaz wrote:
> Hi Carsten,

> BTW this maps nicely to the Maven concept of smaller projects organized 
> in a hierarchy, and people are working on a Maven 2 plugin to create 
> OSGI bundles, so we have some hints here ;-)

As m2's notion of small separate builds came from my first workings with
Avalon I think it is definitely a good fit. I talked at length with Alex
and Enrique about Oscar and am definitely thinking along the lines of
phasing out Plexus and using Oscar. Ultimately this means m2 being OSGi-
based. So I'm definitely interested in seeing how you deal with this
situation as you have many more users of Cocoon then the Plexus folks. 

-- 
jvz.

Jason van Zyl
jason at maven.org
http://maven.apache.org

Simplex sigillum veri. (Simplicity is the seal of truth.)

Re: [RT] The impact of using OSGi

[Bertrand Delacretaz <bd...@apache.org>]

Hi Carsten,

I totally agree with your view and your goals about compatibility.

Just a few comments:

> ....Now, there is one thing to consider: using OSGi means, everything 
> is a
> bundle. So whatever you develop, it must be a bundle...

For people who are not familiar with OSGI: an OSGI bundle is nothing 
complicated, it's just a jar with some OSGI-specific fields in the 
manifest, so it's not a big deal.

Apart from that, my impression is that the biggest impact might be on 
the build system and on the directory structure of our code: separating 
the code in a way that makes sense for bundles (separate interfaces 
from implementations, separate units of functionality) would make the 
mapping to OSGI bundles much easier, and may make the core code easier 
to understand.

BTW this maps nicely to the Maven concept of smaller projects organized 
in a hierarchy, and people are working on a Maven 2 plugin to create 
OSGI bundles, so we have some hints here ;-)

I won't be able to help much this month due to more holidays, and as 
usual whoever does the work decides, but I just wanted to expose the 
mental connections that I've been making last week: if we consider 
moving to Maven, this might be the right time to do it, or at least 
try.

-Bertrand