Re: [osgi-dev] Maximum number of bundles and services in one OSGi framework
Commercial products with 5000+ bundles have been shipping for some years on Equinox. Dunno about service counts but there are no real limits in the spec. Jeff On 2010-12-05, at 5:22 PM, Martin Petzold wrote: Hi folks, what is the maximum number of bundles and services I can install/register in one OSGi framework? What is the maximum amount of remote services in a service environment, probably = max. of in one OSGi framework? Is the limitation on some type of identifier or is it the number of threads the JVM can provide or something different? Of course memory in the end... How many bundles and services have you already had running in one OSGi framework? Thanks, Martin ___ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev ___ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev
Re: [osgi-dev] Utility package as a bundle?
On 2010-12-02, at 11:29 AM, Richard S. Hall wrote: Well, one thing is clear, if classes appear in your API, then you clearly expect bundles to collaborate around those classes, so having a bunch of bundles embedding there own copies of these classes would be really dumb since none of them would be compatible with each other. I think you have to differentiate between classes for collaboration and utility classes (i.e., ones not for collaboration). Which is Path? (Path is an Eclipse class used for representing and manipulating filesystem-like paths) To many it is simply used internally because it has lots of great helpers and does it right for off the wall cases. For others it is exposed on their API as a arg/return type rather than forcing rock/stick programming. Should some people embed Path in their bundle while others share one implementation? For those who share, where does the implementation go? A common datatype bundle? :-) If everyone embeds is that really dumb or the intended purpose of the uses clause? Jeff ___ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev
Re: [osgi-dev] Utility package as a bundle?
Can you not see that Path would be defined as a utility or not by the bundle that uses it? Give me some credit. Of course. If I use Path, but it is not exposed in my API, then I can treat it as a utility class. That doesn't prevent other bundles from treating it as a shared class. It just means we might not use the same version among all bundles, but for those embedding it because it is not exposed via their API, this will cause no issues whatsoever for them, nor the sharing bundles. But this still begs the question of how should people make available the utility (english meaning of the word) classes that are being shared. Should they be in one bundle? Should each bundle have its own copy but import/export and use uses? System designers still face this question. And if you have a bunch of bundles intending to collaborate around a given set of types and they all embed their own copies and don't import/export them (i.e., make them substitutable), then it is really dumb. Its not dumb. it doesn't work. :-) Jeff ___ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev
Re: [osgi-dev] Utility package as a bundle?
It may be the only way but I have to say I'd be concerned about maintenance if we ended up shipping 100 copies of the same util classes. Historically in Eclipse we have had a number of widely used utility classes that had subtle/complex behaviour (e.g., StringMatcher, Path, ...). The sort of thing that you think should be easy but turn out to be hard. Inevitably bugs crop up or tweaks are done. If every user of those classes had their own copy, deploying changes would be a nightmare. In the end there is a balance in there somewhere. Jeff On 2010-12-01, at 10:16 AM, Marcel Offermans wrote: A smarter bundle tool should be able to eliminate unused utility classes from such bundles, greatly reducing their size. But making bundles more fine grained is definitely a good tip too. Greetings, Marcel On 1 Dec 2010, at 15:58 , Simon J Archer wrote: I have had a similar experience with utility bundles. Be sure to carefully manage the prerequisites of a commonly used bundle. The trouble, as Jeff correctly pointed out, is that they become dumping grounds for useful types, and as a result their prerequisites (that is, the other bundles upon which they depend) tend to grow. While having a large number of prerequisites is not in itself a bad thing, it has a negative impact on all those bundles higher on the stack that just want to use one or two types in the utility bundle. In my case I saw a small 2 MB application balloon to over 20 MB just because someone updated one of the packages I imported, and consequently the bundle's prerequisites. So, what's the solution? Ensure that your utility bundle remains highly cohesive and does not become a grab-bag of unrelated helpers. Far better to create multiple finely-grained, highly cohesive (and loosely coupled!) bundles since this will result in a far more flexible bundle dependency graph, be it at the cost of some complexity. I've seen first hand the reaction people have to finely grained bundles, and I've seen people merge bundles to make things easier. The reality is that when you merge bundles you are trading flexibility for simplicity (less bundles). One day I'll write a packaging tool that merges bundles for deployment, giving us the best of both worlds. To that end, I would like to suggest using Import-Package rather than Require-Bundle, since this gives you more flexibility regarding you prerequisites. But let's save that debate for other thread. Simon From:Peter Kriens peter.kri...@aqute.biz To: OSGi Developer Mail List osgi-dev@mail.osgi.org Date:12/01/2010 04:00 AM Subject: Re: [osgi-dev] Utility package as a bundle? Sent by: osgi-dev-boun...@mail.osgi.org The problem with util bundles is that their transitive dependency has a tendency to swell. That would be no problem if the util bundle was cohesive but they rarely are. Example, I once debugged a case where about 20 Mb of external dependencies were dragged in because the developers used one two line method in Apache commons collection. For this reason, bnd has the Conditional-Package instruction. This instruction is ignored while building the bundles but after the content is set, it will match any imports against this instruction. Any matching packages are copied to the bundle which is then reanalyzed until no more matching imported packages are found. For example: Private-Package: biz.aQute.whatever.impl.* Conditional-Package: biz.aQute.util.* Any imports from biz.aQute.util.* will automatically be included in your bundle in your private are. That is, these utils will not be shared. Many bundles can include the same package, one of the great advantages of OSGi over other Java module systems. Obviously this will create redundancy but it gives you less coupling, there is a of course a trade off. However, it is binary redundancy, the source code is still in one location. I find this Conditional-Package to be extremely effective for specially developed util jars. The model works best when the utils themselves are in separate packages, this allows you to pick and choose and not pay for unwanted dependencies. Kind regards, Peter Kriens On 1 dec 2010, at 00:51, Wesley Silva wrote: Hi, I'm currently migrating an existing web application to OSGI. During the process I saw the utility package, where there are classes to manipulate things like date, strings, files, cryptography and so on. Almost all web applications in my company have this kind of package so I was wondering if it was a good idea to turn it into a reused piece of software. So here is my question, is it a good idea to turn it into a bundle? If so, how would this bundle look like? Would it publish some service thought interfaces or just export packages? Any suggestions? --
Re: [osgi-dev] Utility package as a bundle?
On 2010-12-01, at 3:26 PM, Marcel Offermans wrote: Well, there can obviously be a difference between the deployment view for a project, where you have only a single copy of such utility classes (in other words, I'm totally against making copies of the source code here) and how to package the sources into bundles, the deployment view. So with only one source copy, which gets compiled and included into each bundle that uses it I feel you get the best of both worlds: no duplication of source code and no coupling at deployment time. Right I was assuming no source duplication (that would be a nightmare!). Even so, we likely have dozens if not a hundred bundles that use some of these utility classes. In many cases there is no build that does them all and they are on different release cycles and ... So actually propagating changes is a challenge as it means rebuilding and redeploying all the bundles not just one. But I totally agree, there is a balance here, and there is no generic answer. :) Absolutely. The topics I mentioned are things to watch for not nails in the coffin. Jeff ___ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev
Re: [osgi-dev] Service dependencies
DS should do this just fine. Declare a component for B and say it needs C. Not sure what you meant about *service* A being started but... Did you mean *bundle* A? Assuming yes, the topic here is not so much which bundles are started but which DS components are activated. Make sense or did I misunderstand? Jeff On 2010-11-30, at 11:08 AM, Peter Lauri wrote: Hi, If I have a bundle A that is providing a service B only if service C is available. Is it possible in the osgi framework to track these kind of dependencies/states. Bundle A will start perfectly fine and initially not publish any service as service C is not available in the system. Some other bundle D will after som time start and then publishes service C. At that point service B is published as service C was tracked. But before bundle D was started, could the service A then have an state of started but waiting for additional services to become a service provider? Maybe this is not fully clear, please let me know if this was completely not understandable. With regards, Peter Lauri * Sent on the road from my iPad ___ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev ___ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev
Re: [osgi-dev] Utility package as a bundle?
What Richard said plus a cautionary note. These sorts of common or util bundles have a way of growing and taking on a life of their own. People have a tendency to use them as dumping grounds for that little class that everyone will want etc. To help mitigate this tendency: - clearly define the scope of what goes in the bundle and what does not - maintain high coherence in your package namespace (don't just put all the things in a utils package) - encourage people to use Import-Package to enable shipping various shapes of util bundle From an organizational point of view, you likely want to also establish what group/team/person is responsible for the content of the bundle(s). Topics like content regulation, maintenance, ... Jeff On 2010-11-30, at 7:32 PM, Richard S. Hall wrote: A simple library bundle would likely just export the packages it wishes to share. Not all bundles need to provide services. Services decouple bundles from implementation details, enabling multiple providers and dynamism. Package sharing is another valid form of bundle collaboration, it is just a little less flexible. That doesn't mean it should be avoided completely, nor can it. Now if you thought you might have multiple implementations of these utilities that you wanted to swap out dynamically, then defining services might make sense. But even at the package level you can have multiple implementations, it only means that swapping out implementations is slightly more traumatic on your system. - richard On 11/30/10 6:51 PM, Wesley Silva wrote: Hi, I'm currently migrating an existing web application to OSGI. During the process I saw the utility package, where there are classes to manipulate things like date, strings, files, cryptography and so on. Almost all web applications in my company have this kind of package so I was wondering if it was a good idea to turn it into a reused piece of software. So here is my question, is it a good idea to turn it into a bundle? If so, how would this bundle look like? Would it publish some service thought interfaces or just export packages? Any suggestions? -- Att, Wesley MSc Candidate in Software Engineering Specialist in Test Analisys (CIn/UFPE - Motorola) B.S. in Computer science - UFS Sun Certified Java Programmer Sun Certified Web Component Developer ___ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev ___ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev ___ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev
Re: [osgi-dev] import/export package vs services
IMHO there is a line there somewhere where code is just code. A base 64
encoder could just be a mess of statics on a class somewhere. Should Arrays be
a service? Do we need a HashMapFactory service? How you draw the line is up to
your and your expected user's requirements. If you think that someone might
actually have a better base 64 encoder or somehow not want to use yours in
their deployment, then services are likely good for you. Otherwise, just write
the code and use it.
Jeff
On 2010-11-18, at 9:14 AM, Jean-Baptiste Onofré wrote:
Hi Alexander,
I prefer to use service because your bundle is completely decoupled from the
interface.
As the service is identified by an interface, you can change your
implementation without changing your bundle.
If you use Import/Export, changing the implementation means that you have to
update your bundle, which is not the case using a service.
Regards
JB
On 11/18/2010 09:01 AM, Alexander Shutyaev wrote:
I have a very general question concerning usage of services versus
Import/Export package. What would be the main principles in choosing
between one of these schemes?
Let's say I want to write a BASE64 encode/decode utility. Plain old java
way would be to write a class like
public class Base64Utility
{
public static String encode(byte[] data) {}
public static byte[] decode(String encodedData) {}
}
To use it I would Import the package it resides in and then write
something like
String s = Base64Utility.encode(mydata);
On the other hand I could register an OSGi service under an interface
similar to the class shown above. That would require some extra actions.
But is it right to create service for such a primitive class? How do I
know when to use a service and when to just Import/Export the class
(sorry, package) I need?
___
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev
___
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev
___
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev
Re: [osgi-dev] Convert monolithic Java app to OSGi
FWIW, the stuff coming out of e4 (new design of the Eclipse platform) is all dependency injection. That may help you out. Jeff On 2010-11-11, at 8:33 AM, Philipp Kursawe wrote: Hello, OSGi without DS is like programming with a Java assembler instead of using ecj. Maybe fun for masochists but not for getting the hang of what OSGi is really about. Although I have run into situations where you could not use DS (especially inside Eclipse views) and had to resort to ServiceTracker. Regards, Phil ___ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev ___ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev
Re: [osgi-dev] Convert monolithic Java app to OSGi
I too believe that we are agreeing. Before everyone gets bent out of shape about classifying programmers (not my goal), my point is that IMHO most Java programmers in the wild today have no need to reference an OSGi API package. They might do well to use a *pattern* that OSGi also uses but the extender and white board patterns are not exclusively OSGi and do not require OSGi. Don't get me wrong, I like all this stuff and think it very valuable. However, the adoption challenge that OSGi faces is increased if people think they have to swallow the whole pill to see the shining path. Philipp knows a lot about OSGi so understands but others looking to migrate may not. Many folks have derived huge benefit simply from being modular. Not a single service or dynamic behaviour in sight. The message is API, high cohesion, low coupling, ... as software engineering goals. OSGi supplies a number of mechanisms for achieving these. I think we should do more to promote the incremental OSGi adoption by doing a better job of hiding it. As for testing, PDE (headless or GUI) has enabled running JUnit tests with and without OSGi for years. But running a test in OSGi still requires more work than running one stand alone with injected mocked up objects. Referencing OSGi API in general requires OSGi to be running. That in turn requires all manner of other bundles, configuration, ... I spent years doing that and found it hard and frustrating. Switching to DI, EasyMock et al and writing code that did not depend on OSGi API or require a running framework made testing much easier. Jeff On 2010-11-11, at 8:32 AM, Peter Kriens wrote: Jeff, though I do believe we agree in general I do not see the concept of a normal programmer. A good module (function - module - class - package - bundle) is highly cohesive, meaning it focuses on a single problem domain. If you're problem domain happens to be simplifying the life of other programmers the OSGi API is often right at the heart of that domain because patterns like the extender and white board do simplify solutions in this domain. However, if you write a tax return application, OSGi has no place in your code. I therefore do not think we can make the distinction between normal programmers and special programmers? that easy. There are undoubtedly programmers that will never have to touch OSGi API but imho it is often too much of a benefit to utilize one of the OSGi patterns, turning normal programmers into middleware programmers. They key thing is not to minimize the domains in one component. Last thing, with bnd(tools) there is no difference in testing anymore between straight JUnit and JUnit that runs inside a framework, both inside Eclipse and outside Eclipse with ant or some other build tool. Kind regards, Peter Kriens On 10 nov 2010, at 16:05, Jeff McAffer wrote: Don't program to the OSGi api !!! What do you mean by that? That is the first point I generally make in my OSGi Best Practices talks. Basically it comes down to use dependency injection. Whether that is DS, blueprint, pico container, ... And it doesn't matter if you are injecting services, extensions, beans, In fact the point is that you don't know or care what they are. The example we develop in the OSGi book (http://equinoxosgi.org) ends up with 80 bundles and very few have ANY reference to OSGi packages. This makes it easy to test, easier to write and easier to reuse. Normal programmers should not be referencing OSGi API You can start with your non-osgi application, launching an embedding osgi framework (see core spec) and aggregating the first parts into a service/component approach, step by step. That was the plan. Put everything into one bundle and start up the application. If its still running and behaving like it did before start to carve out small parts into OSGi services. Like Peter suggested. I think Oliver's approach was somewhat different. If I got it right, he is saying leave your non-OSGI thing and run a framework inside it. Carve out parts of the app and have them run in that embedded framework. Basically eat the monolithic wad from the inside out. Mixed opinions on my part. It may avoid/defer some classloading nastiness but it may also artificially introduce some as you cross the OSGi/non-OSGi boundary. My first inclination would be along Peter's lines of wrapping the big chunks in bundles and refactor them. This has worked well for me and my clients in the past. As for the native stuff, you don't have to use a fragment. Fragments are useful if you want to ship for multiple platforms and don't want to ship all platforms to everyone. Other than that, there is no particular value in using them. Jeff ___ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev
Re: [osgi-dev] Convert monolithic Java app to OSGi
Don't program to the OSGi api !!! What do you mean by that? That is the first point I generally make in my OSGi Best Practices talks. Basically it comes down to use dependency injection. Whether that is DS, blueprint, pico container, ... And it doesn't matter if you are injecting services, extensions, beans, In fact the point is that you don't know or care what they are. The example we develop in the OSGi book (http://equinoxosgi.org) ends up with 80 bundles and very few have ANY reference to OSGi packages. This makes it easy to test, easier to write and easier to reuse. Normal programmers should not be referencing OSGi API You can start with your non-osgi application, launching an embedding osgi framework (see core spec) and aggregating the first parts into a service/component approach, step by step. That was the plan. Put everything into one bundle and start up the application. If its still running and behaving like it did before start to carve out small parts into OSGi services. Like Peter suggested. I think Oliver's approach was somewhat different. If I got it right, he is saying leave your non-OSGI thing and run a framework inside it. Carve out parts of the app and have them run in that embedded framework. Basically eat the monolithic wad from the inside out. Mixed opinions on my part. It may avoid/defer some classloading nastiness but it may also artificially introduce some as you cross the OSGi/non-OSGi boundary. My first inclination would be along Peter's lines of wrapping the big chunks in bundles and refactor them. This has worked well for me and my clients in the past. As for the native stuff, you don't have to use a fragment. Fragments are useful if you want to ship for multiple platforms and don't want to ship all platforms to everyone. Other than that, there is no particular value in using them. Jeff ___ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev
Re: [osgi-dev] Logging from within OSGi services and bundles
Igmar, Look at the code mentioned. It uses the SecurityManager.getClassContext() to get the current call stack in terms of classes. Then you walk down the list until you get to the class you want, get its loader and get the bundle. Jeff On 2010-11-03, at 10:37 AM, Igmar Palsenberg wrote: Hi Jeff, - in Y walk down the stack the number of frames you are from the real logger (e.g., X calls Y directly, look down one or two frames). - Get the classloader for the method running in that frame. - If you are on a recent framework then that classloader may well be a org.osgi.framework.BundleReference. If it is, cast and call getBundle(). - carry on For some sample stack walking code, look at Equinox's ContextFinder.basicFindClassLoaders() method [0]. A problem with that is that the stacktrace doesn't give me bundle information. If you have 2 bundles with the same class Foo(), you don't know which bundle that Foo in the stacktrace refers to. You only get a name / method, not a reference, else you could have find out what classloader loaded that class, and so find out the bundle. It's a nasty problem, but solution is more then welcome : All generic code logging in one file isn't usefull without info what bundle used the generic code. Igmar ___ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev ___ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev
Re: [osgi-dev] Downloading and installing a bundle
Out of the box OSGi frameworks will install bundles from remote URLs. While the downloading capabilities (e.g, restartability, ...) are framework implementation dependent most frameworks I know of do NOT support download restart. There are several options for provisioning OSGi systems. For example, Equinox p2 (http://eclipse.org/equinox/p2) has sophisticated download and staging capabilities. Jeff On 2010-10-29, at 6:24 AM, pavithra shankar wrote: -- Forwarded message -- From: pavithra shankar pavi@gmail.com Date: Fri, Oct 29, 2010 at 3:54 PM Subject: Downloading and installing a bundle To: knopflerfish-de...@knopflerfish.org Hi all, Suppose the bundle is not locally present and it is to be fetched from a remote server. 1. Does osgi specifications support the downloading and installing of a bundle over the network? 2. if yes, during the course of such an installation, if the network connection is interrupted ,( and the bundle jar file is a huge one) is downloading from the point where it left off supported or will the whole jar have to be downloaded again from the beginning/reloaded? Thank you in advance. ___ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev ___ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev
Re: [osgi-dev] Remote OSGI
The Eclipse Communications Framework project (ECF)[0] has support for the distributed OSGi standards. Among the many examples they have on the wiki is http://wiki.eclipse.org/Using_Spring_with_ECF_Remote_Services . Jeff [0] http://eclipse.org/ecf On 2010-10-14, at 10:01 AM, Peter Lauri wrote: Hi, We have been trying to develop some applications with distributed OSGI using CXF DOSGI. However, we have faced some problems with that. Do you have any recommendations for any framework to use for Distributed OSGIs? We have a OSGI environment in Virgo that needs to use a service on another Virgo that is connected via a SOCKS5 proxy. /Peter ___ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev ___ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev
Re: [osgi-dev] How to get runtime Memory Usage for an OSGi bundle..?
At one point in the past we (Equinox team) had connections to the IBM J9 JVM that could tell you about the space taken for each bundle wrt *classes* and literals. The Eclipse Core Tools [0] still have that support in but I doubt that the VM side still works. Also in the past (and perhaps still) the J9 guys worked on Resource Managed (RM) support that allowed for tracking and control of heap memory usage on a per classloader (e.g., bundle) basis. I don't know the status of this work. Jeff [0] http://wiki.eclipse.org/Core_Tools On 2010-06-15, at 7:57 AM, BJ Hargrave wrote: I don't know of such a command and I am not sure one can be properly written. There is no way to properly assign a memory object to a specific bundle. For example, which bundle should be the owner of a HashMap object? No matter what rules you construct to decide this, there is a reasonable case in which your rule is wrong. -- BJ Hargrave Senior Technical Staff Member, IBM OSGi Fellow and CTO of the OSGi Alliance hargr...@us.ibm.com office: +1 386 848 1781 mobile: +1 386 848 3788 From:Ashish Billore1 ashish.billo...@in.ibm.com To:osgi-dev@mail.osgi.org Date:2010/06/15 07:36 Subject:[osgi-dev] How to get runtime Memory Usage for an OSGi bundle..? Sent by:osgi-dev-boun...@mail.osgi.org Hello Everyone, I am working on optimization and performance tuning of an OSGi based server application (uses customized Equinox as runtime and has OSGi bundles and headless Eclipse Plugins as building block). For this, I need to get the profiling data about OSGi bundles and plugins running in the application. So, is there any command or utility which can give me memory footprint of a given bundle/plugin? Some command like: osgimemusage bundle_id I tried using some of the profilers out there (Eclipse TPTP) etc, however, they have problems like: - Too heavy, they introduce their own overheads and most of the time the app jvm crashes (due to out-of-memory errors or problem with the remote agent). - Give very low level profiling info (i.e. gives info about java classes and application class level info) however, I am more interested in knowing these details at the bundle level. Thanks for the help. Best Regards, Ashish Billore ___ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev ___ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev ___ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev
Re: [osgi-dev] ConfigAdmin and DS Component Factory
The OSGi and Equinox book (http://equinoxosgi.org) has pretty detailed coverage and examples of ConfigAdmin and ComponentFactories individually but at as Neil says, they are not particularly linked. Jeff On 2010-03-11, at 7:38 AM, Neil Bartlett wrote: Phil, ConfigAdmin and DS Component Factories do not work together. You are required to programmatically call newInstance() yourself. However it should be possible to build a bridge from a ComponentFactory to a ManagedServiceFactory. ManagedServiceFactory is not deprecated. Regards Neil On Thu, Mar 11, 2010 at 12:30 PM, Philipp Kursawe phil.kurs...@gmail.com wrote: Hello, someone out there that can explain me how the ConfigAdmin and DS Component Factories work together? I was under the impression that each factory configuration created will invoke the newInstance method of the DS component factory? Or do I have to create the instances myself programmatically? What properties have to be set in the factory configuration to provoke a creation of a new instance with that factory? Do I need to set the service.factoryPid to the id of the factory? There seem to be no tutorials out there when or how to use the DS component factory. Only for the deprecated (?) ManagedServiceFactory. Thanks, Phil ___ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev ___ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev ___ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev
Re: [osgi-dev] Osgi Launchers Question
Thanks for the clarification. So the problem is that the bundles you install programmatically are gone when you restart. Perhaps Pax Runner is removing them? (dunno much about it). At an abstract level there is a conflict where you want a declarative configuration but want to programmatically modify it. This is fine but there will come a time when these two conflict in some way. I mention this because it would be reasonable for a launcher to have a mode where it removed anything it did not install (i.e., declarative spec wins). I'm NOT saying this is what is happening to you, but just that it is something to think about in your system design. Anyway, you might also look at how they are being installed programmatically. Is it that they are no longer installed? or just not started? Otherwise, perhaps it is a quirk of the implementations you are using and should be reported to them as a bug/question. Jeff On 2010-03-04, at 8:48 AM, David Conde wrote: Hi Jeff, I expect from a launcher something which allows me to start my OSGI application in a easy and fast way just configurating in a configuration file. I have tried with Pax Runner and at least until this moment I could not remain the bundles which were not installed by Pax Runner configuration file but were installed by my InstallerBundleManager bundle by programming across using BundleContext.install method, after restarting this launcher. I do not know why a OSGI feature like Remaining of installed bundles after restarting the framework is not being performed if I launch Equinox by using Pax Runner Launcher. Since it is a requirement for me that installed bundles by programming remain installed after restarting I asked in this email list about other options or launchers which can solve my problem and in order to know if somebody who have used Pax Runner has faced with the same problem. I have done tests with Equinox via console and I have checked that the installed bundles via programming remain after Equinox restarts, so I just need a simple launcher that make easy all the installation proccess. Thank you in advance David -Mensaje original- De: osgi-dev-boun...@mail.osgi.org [mailto:osgi-dev-boun...@mail.osgi.org] En nombre de Jeff McAffer Enviado el: jueves, 04 de marzo de 2010 14:20 Para: OSGi Developer Mail List Asunto: Re: [osgi-dev] Osgi Launchers Question On 2010-03-04, at 7:58 AM, David Conde wrote: Regarding my last question I was wrong when I wrote because I really meant what was the most used Launcher (instead of bundle) by Equinox developers? I think this whole discussion really revolves around what you mean by launcher. What behavior or functionality are you expecting the launcher to do. To answer your question directly about Equinox, Equinox comes with a native executable (typically eclipse.exe or launcher.exe) that does all manner of fancy stuff around splash screens, JVM discovery and invocation etc. It can be branded with icons etc to match your product requirements. Installation of bundles can be done declaratively in the config.ini file with not need for any additional bundles. If you are using the o.e.e.simpleconfigurator bundle, you can use the bundles.info file for a bit easier management and manipulation If you want really sophisticated provisioning and installation facilities, look at Equinox p2. If you are looking for embedding the framework in another Java environment then there are calls you can do using the standard OSGi launching API. So, it really depends on exactly what you are hoping for. Jeff ___ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev ___ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev ___ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev
Re: [osgi-dev] How to persuade Boss to adopt OSGI ?
For a bit of a broad view of OSGi, what it is, where its from, why it is interesting, check out Chapter 1 [1] of the OSGi and Equinox book [2]. The latter part talks about NASA's adoption of OSGi in both client and server settings. You might also look at the Foreword by Adrian Colyer. It talks about why SpringSource adopted OSGi Jeff [1] http://equinoxosgi.org/OSGi%20and%20Equinox%20-%20Ch01.pdf [2] http://equinoxosgi.org On 2010-03-02, at 9:41 AM, Abhishek kapoor wrote: Hi All, My apologies, but so far I have received responses with suggest not to use OSGI for future development, please accept my humble request to explain why we should not adopt OSGI for future architecture of our application. Thanks San On Tue, Mar 2, 2010 at 7:43 PM, Landry Stephane Zeng Eyindanga landry-stephane.zeng-eyinda...@bull.net wrote: Hello, Actually, JOnAS is the best way to easily conciliate OSGi, and J2EE worlds. It also offers many J2EE an OSGi technical services that could help you. Le 3/2/2010 1:49 PM, Miguel a écrit : start stop processes can be a method with an id argument... threads can be stored in a list, hash or similar ... It should be better than a bundle for each process ... in my opinion it is a little weird what you comment .. Miguel On Tue, Mar 2, 2010 at 1:15 PM, Abhishek kapoor abhishekkapoor2...@gmail.com wrote: Hi Chris, Thread pooling can sort some of the issues but we need the facility to start and stop the process independently. Also it will be great to reload the process again with some change and not to mention versioning between bundles with changes etc.. Thanks San Thanks On Tue, Mar 2, 2010 at 5:13 PM, Christopher Armstrong carmstr...@fastmail.com.au wrote: Why not move the code into the same process, and run each as a separate thread? There are plenty of thread pooling technologies about. Bundles don't run in OSGi like processes, they have a start and stop method, but if they are to run an active task, they will need to start up a thread for themselves anyway (which is effectively what happens when you create a process in the operating system - it starts your process with one thread ( the main thread) and executes your code on it until the thread exits). Cheers Chris On 02/03/2010, at 22:20 PM, Abhishek kapoor wrote: Hi Chris, Thanks for your time and comments. What I meant by single process per JVM is. At the moment we use, lets say process A which fetch data from DB and process accordingly. We initiate a JVM for the respective process [that is a instance of JVM is booted for that process]. We do similar thing for atleast 30 process, that create 30 instance for JVM, so in-order to avoid one instance of JVM per process, i thought why not incorporate in osgi framework by creating bundle per process instead new JVM instance. Application is back middle system so i don't understand the need J2EE stack for it. Hope this time I am much clear. Thanks San On Tue, Mar 2, 2010 at 4:15 PM, Christopher Armstrong carmstr...@fastmail.com.au wrote: Hi I don't know what you are looking for from this list, but you are unlikely to find it. At a quick glance, the requirements you mention below could be easily fulfilled by a enterprise J2EE stack or written into a lightweight container framework like Spring. Why do you need OSGi? You are also unclear on what you mean by a separate process per JVM. All Java applications, including a running OSGi framework, use one process per JVM instance. If you mean a single process per requirement, that still is not unusual - using something like JMS for integration would fit well with such an architecture. Cheers Chris On 02/03/2010, at 20:59 PM, Abhishek kapoor wrote: Dear Member, Thanks for reading this email. I need your kind help regarding convincing my manager to adopt OSGI in our future development. Below is the current application architecture We are telecom company and at the moment we use separate JVM per process for our middleware for Order management system. Below are the general overview of the all the process 1) Fetch data [ JDBC]from DB do some processing insert the processed data into DB 2) One of the process send data outside our system through webservice 3) One of the process receive data from outside and pushes into DB so that our internal process can work accordingly 4) Each process polls the data at given specified time for it processing 5) Each process also use extensive logging Since it is a legacy system I do understand the above mentioned process flow is horrible. I guess in past developers decided single process per JVM to achieve modularity. Any Help is appreciated Any case history related to telecom to convince my manager will highly beneficial Thanks San
Re: [osgi-dev] Using Databases in OSGI
Suggest you look at EclipseLink (http://eclipse.org/eclipselink). It is fully OSGi integrated, implements JPA 1.0 and is the reference implementation for JPA 2.0. Jeff Jeff McAffer | CTO | EclipseSource | +1 613 851 4644 j...@eclipsesource.com | http://eclipsesource.com On 2009-12-23, at 9:08 AM, Miguel wrote: thank you everybody, I was currently bundleling the drivers and so on... JPA seems to be a great soluction. has anybody tried to use osgi with JPA? How can make it run? I don't really understand the example of the web http://www.dynamicjava.org/projects/dynamic-jpa. As far as I have seen , you need to define your entity, your persistent xml file and also use /org.dynamicjava.jpa-api-1.0.jar ... I guess , the driver must be also deploy somehow ... but I don't get it working ... could anybody help me? Where can i finde extra information about that? thank you once more! Miguel Sent from Madrid, Spain On Wed, Dec 23, 2009 at 2:09 PM, tommy bit...@gmail.com wrote: I bundled every jdbc driver , create some connection bundles for these bundles, then use dbcp bundle to access database, if i want to switch other database, just start the connection bundle of database which want to connect, stop the others. i think JPA is good solution. best regards Tommy Wed, Dec 23, 2009 at 10:08:49AM +, David Bosschaert wrote: I would suggest using JPA, this is part of the OSGi Enterprise release and there are several implementations of this already available. See http://www.osgi.org/download/osgi-4.2-enterprise-early-draft4.pdf Best regards, David Miguel wrote: hi all, I am looking for the best way to implement a database access using OSGI standard API. I know that spring has several developments to access databases whatever the database is. Is there any current developments like these spring frameworks to make easier the interaction with databases? best regards, Miguel Sent from Madrid, Spain ___ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev ___ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev ___ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev ___ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev ___ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev
Re: [osgi-dev] Can i split web application in OSGi?
Take a look at the server side OSGi support in Equinox. http://www.eclipse.org/equinox/server/ In particular look for the bridged setup. The doc on the web is a little dated but there is up to the minute stuff in the OSGi and Equinox book (http://equinoxosgi.org) in Chapters 18 and 19. Jeff Jeff McAffer | CTO | EclipseSource | +1 613 851 4644 j...@eclipsesource.com | http://eclipsesource.com On 2009-12-23, at 8:32 AM, tommy wrote: hi all: I have a big web application, i want to split the appliction to some bundles. Every bussiness service is a indepency bundle in OSGi. So i need share Servlet context in these bundles. Every bundle has some reources , servlets etc. How can i use same servlet context in all servlet bundles? Please help me, sorry for my english. best regards Tommy ___ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev ___ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev
Re: Antw: Re: [osgi-dev] Synchronization Problem
Have you been running with DS debugging on in Equinox? Put the following on your VM args -Dequinox.ds.print=true This dumps all manner of very useful information. Also, you might like the ls and comp console commands. Run with - console and use those to explore your components. Jeff On 4-Sep-09, at 6:51 AM, Heiko Waldschmidt wrote: Thanks for your help. The Equinox-Console show only one Bundle - Bundle-SymbolicName: the.name;singleton=true doesn't solve the problem. We will try to get our Bundles running with Felix to get a better Idea what's the reason of our problem. Maybe we get some more Information when we use Felix. Felix Meschberger fmesc...@gmail.com 09/04/09 10:40 Hi, Heiko Waldschmidt schrieb: New Day, new Ideas about my Problem. The framework starts more than one instance of my component ... this is the real cause - so synchronization couldn't work. What's the state of the art way to get a singleton component? Hmm, the SCR does not by itself create multiple instances of the same component -- unless the component is created due to factory configuration instances being created and configured. [ or the component is a component factory and some code calls ComponentFactory.newInstance(), but this is probably not the case here ]. The only other explanation I have is, that your bundle is installed multiple times, which is perfectly possible. To prevent this set the singleton parameter on the Bundle-SymbolicName header: Bundle-SymbolicName: the.name;singleton=true Regards Felix ___ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev ___ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev ___ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev
Re: [osgi-dev] Articles about OSGi and hot plugging
The upcoming OSGi and Equinox book (http://my.safaribooksonline.com/9780321561510) has a chapter (22), Dynamic Best Practices that my be useful to you. The preliminary content for that chapter is available now. Jeff Eugen Reiswich wrote: Hey folks, Can please someone point me to articles about OSGi and hot plugging - especially about chances, risks and solutions. Thanks! Regards, Eugen ___ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev ___ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev
Re: [osgi-dev] Best practice to decouple remote technology from bundles
Eugen, Just FYI, you don't actually have to wait. As Peter aluded, there are several implementations available now. The spec appears to be undergoing change but if you want to get started and are willing to adapt when the spec settles knock yourself out. I have used the ECF remote messaging to great success in a few cases. You can do the current distributed services draft spec style or the native ECF style. Plug in different transports, ... Jeff Eugen Reiswich wrote: Thanks Peter, this is exactly what I wanted to know! I will wait for RFC 119... Kind regards Eugen Am May 20, 2009 um 17:02 schrieb Peter Kriens: The upcoming R4.2 will provide a Remote Services section that allows you to decouple bundles from the underlying distribution provider. This means that the only dependency in your code you have on the distribution provider is a number of properties + the OSGi service API. These properties should be settable by configuration management. The intention is that you can switch distribution provider without changing your app bundles, only have to change the properties. We are currently working very hard to create the spec based on the RFC 119 for this area and things are still a bit in flux so the RFC 119 is currently unfortunately a bit stale. ECF, CXF, and others are implementing this specification as distribution providers. Kind regards, Peter Kriens On 19 mei 2009, at 20:05, Eugen Reiswich wrote: Hi, we are developing a client/server application with osgi. Say I have three bundles: 1. client 2. common (includes the service interface and domain value objects) 3. server (includes the service implementation) We've started to develop our application with the remote technology RMI but switched now to Riena. As it was really a pain to remove all RMI dependencies from our code (e.g. all RemoteExceptions) I wonder if there is a best practise approach how to achieve a loose coupling of a specific remote technology in our osgi bundles without using tons of wrappers. Regards, Eugen ___ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev ___ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev ___ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev ___ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev
Re: [osgi-dev] Certain service registration
The DS tooling in Eclipse is reasonably comprehensive. See http://eclipsesource.com/blogs/2009/03/03/osgi-declarative-services-tooling/ I've been using DS and this tooling for some time now and it does pretty much all that is needed. The set of refactorings and validations available increases everyday. One thing that was mentioned was the lack of support for multiple components in one XML file. Currently this is true. Perhaps I have just adapted or just don't see this as a problem. When starting out with DS (this was before the DS tooling) my first inclination was to put all components for a bundle in one file. The result was simpler management of the manifest.mf. Great. The downsides were; it does not save on XML and it was then harder to refactor my bundles and move components around. This approach also lets you see what components are in a bundle without having to look at the XML (assuming you use decent names for the files). Everyone is different but for my money I prefer putting components in individual files. I program with DS pretty much every day and honestly have little idea what the XML looks like and certainly have not edited it directly in quite some time. Repo stats may show me as an XML programmer but statistics can be deceiving. my 2c... Jeff Jeff McAffer | CTO | EclipseSource | +1 613 851 4644 j...@eclipsesource.com | http://eclipsesource.com Aaron Zeckoski wrote: I was (and am) concerend about living in xml hell as well. Nothing is quite so much fun as looking at my developer profile in ohloh and finding out I am apparently an xml programmer primarily... sigh. That said, there are some plugins I have used that help with this (http://felix.apache.org/site/apache-felix-maven-scr-plugin.html) but if someone knows of a nice blog entry or listing of tools related to DS I would greatly appreciate a link or two (and probably others might as well). Thanks! -AZ On Thu, Apr 30, 2009 at 11:41 PM, Scott Lewis sle...@eclipsesource.com wrote: Hi Eugen, Eugen Reiswich wrote: Hi Neil, stuff deleted Is DS really the only way? I have downloaded Eclipse M6 and tested the DS-Editor. Well, how do I say it polite? If I have 2, 3 or even more components in one bundle that require OSGi services I have to create (if I got it right) 2, 3 or even more XML files with service-component-descriptions. This sounds like XML-hell. Although I sympathize/empathize, I don't think DS constitutes XML-hell. DS is not the only way, but it does manage inter-service dependencies very effectively IMHO. I've been using it rather heavily recently, and after some initial learning time for me, I now consider it very helpful (and I was skeptical about xml hell as well). And the DS tooling in Eclipse 3.5 is still very early...it will improved/extended quickly I expect. Even so, I've found it very helpful in its current state (although still have plenty of suggestions for improvements in the tooling). In any event, I wouldn't dismiss DS too quickly, if that's your inclination. My $0.02. Scott ___ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev ___ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev
Re: [osgi-dev] osgi and version numbers
that is exactly what I am asking. When OSGi breaks the binary compatibility, will the major version number be incremented. The answer appears to be yes. Great. Thanks Jeff BJ Hargrave wrote: I am not sure what you are asking for. Section 3.6.2 of the spec outlines the common versioning policy of major changes being incompatible which is how we do operate at OSGi with respect to versioning. Hence the framework package is still 1.x. I can see changing all the package.html files to use ranges in the example import package statements. -- BJ Hargrave Senior Technical Staff Member, IBM OSGi Fellow and CTO of the OSGi Alliance hargr...@us.ibm.com office: +1 386 848 1781 mobile: +1 386 848 3788 From: Jeff McAffer j...@code9.com To: OSGi Developer Mail List osgi-dev@mail.osgi.org Date: 2009/01/19 23:26 Subject: [osgi-dev] osgi and version numbers Sent by: osgi-dev-boun...@mail.osgi.org Do you think that OSGi will evolve its package version numbers in a way similar to the Eclipse version numbering schemes? That is, does it make any sense today to spec Import-Package elements along the lines of org.osgi.service.component;version="[1.0.0,2.0.0)", org.osgi.service.http;version="[1.2.0,2.0.0)" with an expectation that versions of these services fitting these ranges will be binary backward compatible? What is the best practice recommendation for people writing bundles now but anticipating changes in OSGi 2.0/5.0/whatever the next real big spec change is... Jeff ___ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev ___ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev ___ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev
Re: [osgi-dev] RMI + OSGi - UnmarshalException
You might also look at the Eclipse Communications Framework (ECF) project (http://eclipse.org/ecf) which has a number of distributed/remote communications facilities for OSGi. An RFC119 implementation should show up there soon too. Jeff David Bosschaert wrote: Hi Serguey, One thing that might help you here is using an implementation of the Distributed OSGi specification (RFC 119 in http://www.osgi.org/download/osgi-4.2-early-draft2.pdf ) This allows you to distribute OSGi services. RFC 119 isn't completely finalized yet and at this stage there isn't a fully complete implementation yet, but you can start playing with the Reference Implementation in Apache CXF. Currently in the sandbox - were working on making it part of the core code base and improving the docs at the moment. To build test, just check it out from SVN http://svn.apache.org/repos/asf/cxf/sandbox/dosgi Then run mvn install Cheers, David Niclas Hedhman wrote: On Tue, Dec 16, 2008 at 8:27 PM, Serguey Asael Shinder serguey.asael.shin...@ericsson.com wrote: This is from February of this year, does anyone know what the latest on this issue is? Do you have any suggestions as to how we can get around this issue? We would prefer if possible not to have to put all our classes in the same bundle. Thanks in advance for your help. 1. Either you turn on dynamic classloading for RMI, with all what that means, or you have all the needed classes visible to the server (which is the case causing you problem here). 2. If you go dynamic RMI classloading - you need to establish codebase, probably only way is to use java.rmi.server.codebase property, AND you must use a SecurityManager. 3. If you go 'all classes in Bundles', then you have a visibility issue. RMI might not be able to pick up the right classloader (have not confirmed that), in which case you need to use the RMIClassLoaderSpi to provide the mechanism manually. This is 'classloader hell' on an extreme. Both OSGi and RMI assume that they know classloading better than the other, so they end up being largely incompatible. And we programmers have no clue what is going on, because we have been so lazy over the years to use a flat/linear classloading space. Personally, I think it is time for a new, optimized, simplified binary and high performant Remote call system, where all these things are taken care of. But, everyone is busy criticizing RMI and promote so called platform independent solutions, that have all these problems, much slower, LCD issues and more... Well... Cheers Niclas ___ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev ___ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev /div ___ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev
Re: [osgi-dev] Put API/SPI/implementation into separate bundles?
Or even something like Equinox's p2 support. It allows you to publish bundles and collections of bundles and manage dependencies on arbitrary capabilities and requirements. To a certain degree you can do similar things with OBR it is just harder to create the metadata and the capability namespace is not (AFAIK) extensible. See http://wiki.eclipse.org/Equinox/p2 Jeff Stuart McCulloch wrote: 2008/9/24 Yvan Royon [EMAIL PROTECTED] Sorry to bump a 4 month old thread... On Mon, Jun 9, 2008 at 09:18, Peter Kriens [EMAIL PROTECTED] wrote: The whole problem with modularity is the -granularity-. If you make the granularity too small you end up with too many artifacts to comprehend. If you make it too large you do not get the desired mix and match behavior. Compare this with recursive component models, say, Fractal. Maybe SCA fits the bill also. With these systems you have composite components and unit components. A unit components contains actual code (impl, api, whatever). It can be as small as the developers' smallest unit of reuse. A composite component embeds unit components and/or other composite components. It allows you to package and distribute your code: the whole app is a composite, then inside are composites that relate to different parts in the design of your application, then ... etc. You ony need a single component to deploy the whole application, whether it is a SimpleHttpClient or the whole HugeAndComplex IDE. It is thus much simpler for an end-user or admin to browse a catalogue and to choose an application to deploy. The way I see it, an OSGi bundle tries to fit both granularities at the same time. Thus, it is up to the packager to choose one or the other, or a little of both, and it can be ugly. In my opinion, OSGi (or maybe just OBR and the shell service) needs a way to express "group-of-bundles-that-go-together-to-form-a-useful-app", so that developers and packagers can express both granularities. perhaps something like this :) http://www.osgi.org/javadoc/r4/org/osgi/service/deploymentadmin/DeploymentPackage.html although there's still plenty of scope for further development / tooling... -- Yvan Royon ___ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev -- Cheers, Stuart ___ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev ___ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev
