Why not just use the whiteboard pattern? You said: whiteboard ... does not
make sure that all of the servlets are available at the time the server is
started. Why is that important?
Regards
Neil
--
Neil Bartlett
Sent from a phone
On Wednesday, 26 February 2014 at 09:47, Balázs Zsoldos
Unfortunately most frameworks export the tracker package directly, rather than
from a separate bundle, despite it not being part of the core spec.
BJ, what's to stop a framework providing an optimised ServiceTracker
implementation? The tracker package is very odd in that OSGi directly provides
Actually I hope that with JPM4J integration (see jpm4j.org) we will be able
to do much better than Maven...
As Ferry points out, the problem with using Maven central directly is that
most of its contents are not bundles. JPM is an effort to create a global
repository for OSGi bundles, however we
Yes your understanding is exactly right. You can use multiple versions of
the same module concurrently.
There is one caveat, which is to do with the interfaces between the
modules. You said that A depends on B v1, and C depends on B v2. That's
fine unless A and C need to communicate with each
at large scale to create bundles externally for each
new jar version.
Christian
Am 17.11.2013 11:44, schrieb Neil Bartlett:
Actually I hope that with JPM4J integration (see jpm4j.org) we will be
able to do much better than Maven...
As Ferry points out, the problem with using Maven central
to accept all the decisions already made by others.
As for Windows... I'm sorry but Windows will always be a second or even third
class platform for developers.
Neil
--
Neil Bartlett
Sent from a phone
On Sunday, 17 November 2013 at 11:41, Tom Eugelink wrote:
On 2013-11-17 11:44, Neil
Did you take a look at the book suggestions you received on the other mailing list? I particularly recommend OSGi in Action (Hall et al) and Enterprise OSGi in Action (Ward and Cummins).After that, it's best to try to apply what you have learned to something real, even if it's only small scale.
...@gmail.com) wrote:
Just a curiosity...
why Bndtools uses Ant instead Maven ?
Cristiano
On 03/10/13 13:49, Neil Bartlett wrote:
Did you take a look at the book suggestions
you received on the other mailing list? I pa
Christian,
I consider that to be one of the worst features of Blueprint, so I
would be very opposed to adding it to DS!
Regards
Neil
On Fri, Sep 13, 2013 at 11:17 AM, Christian Schneider
ch...@die-schneider.net wrote:
I think you can take a look at what aries blueprint does for these cases.
be interested to
learn why and what would be better behaviours. Perhaps the blueprint
standard can be enhanced.
Christian
On 13.09.2013 12:19, Neil Bartlett wrote:
Christian,
I consider that to be one of the worst features of Blueprint, so I
would be very opposed to adding it to DS
Thomas, if you use DS idiomatically then the service reference cannot
change to null during your method call.
First, as Chris pointed out, static references will not change while
your component is active, because as soon as the referenced services
goes away your component will be deactivated. So
The Bundle.update() method does not take a location URL as input.
Regards, Neil
--
Neil Bartlett
Sent from a phone
On Tuesday, 18 June 2013 at 14:34, antonin.chaza...@orange.com wrote:
Dear,
I have a question about Bundle's update(InputStream input), and String
getLocation
Yep...
Require-Capability: osgi.service;
filter:=(objectClass=org.example.foo.MyService); effective:=active;
resolution:=optional;
(the 'effective' directive is not directly related to optionality, but is
probably a good idea when talking about a service dependency)
Neil
On Fri, Apr 26, 2013
at 7:31 PM, Raymond Auge raymond.a...@liferay.comwrote:
Got it!
Was a wishful over-simplification I guess.
On Fri, Apr 26, 2013 at 2:26 PM, Neil Bartlett njbartl...@gmail.comwrote:
Not really. The resolver is just a service that resolves a set of
capabilities and requirements, and works out
Yes there is.
You don't specify which flavour of annotations you are using. Assuming the
standard ones from DS 1.2:
@Component(properties = { foo=bar, foo=baz })
Alternatively with the bnd annotations:
@Component(properties = foo=bar|baz)
Regards
Neil
On Tue, Apr 16, 2013 at 9:12 PM,
DS spec allowed for it.
On Tue, Apr 16, 2013 at 4:23 PM, Raymond Auge raymond.a...@liferay.comwrote:
Thank you Neil,
Sorry, I'm currently using the bnd annotations (1.50.0, haven't upgraded
yet, will soon).
- Ray
On Tue, Apr 16, 2013 at 4:17 PM, Neil Bartlett njbartl...@gmail.comwrote
How?
If such a scanning tool could exist, and was able to tell the
difference between a consumer type and a provider type in arbitrary
code, then we could use the same technique in our build tool and
dispense with the Provider/ConsumerType annotations.
Neil
On Mon, Apr 15, 2013 at 3:50 AM,
I strongly disagree as well. The co-location of interfaces within a
package is the best indicator that they are related; if we separate
them then we lose this connection and all concept of what the contract
is.
Example: ConfigurationAdmin (provider) and ConfigurationListener
(consumer). The
Yes you can do this without any problems. Just include both the
Service-Component header for DS, and the blueprint XML files under
OSGI-INF/blueprint. You will also need both the corresponding runtime
bundles installed and active. Then it will all Just Work (TM).
Neil
On Thu, Mar 28, 2013 at
:)
2013/3/28 Neil Bartlett njbartl...@gmail.com
Both will be registered. DS will register the service(s), and Blueprint
will also register the service(s). If there are any overlaps then you may
get two instances of some services.
I don't think it's a very good idea to do this. A more
You need to show where the getInstance() method is called. Since you don't
call it from your start() or stop() method, I suspect you must be calling
it from another bundle or a thread. Both of these could cause the old
version to be pinned in memory; meaning you will have both the old and new
: *A unique subscription service for key technologies in
your project.
*Rebaze Onsite: *Our way to improving your development team on site.
On Tue, Jan 29, 2013 at 2:21 PM, Neil Bartlett njbartl...@gmail.comwrote:
This seems an entirely reasonable requirement. It doesn't come from PDE
This is another reason why you should keep APIs separate from
implementations. While there is often a need to go back and change an old
version of an implementation package, APIs should really only ever move
forwards. For example if you really need to delete a method that you added
in version 1.1,
Yes, sorry -- I agree with Tom's amended approach.
On Tue, Jan 22, 2013 at 3:53 PM, David Bosschaert
david.bosscha...@gmail.com wrote:
Thanks all for the responses.
On 22 January 2013 15:32, Neil Bartlett njbartl...@gmail.com wrote:
The best way to deal with split packages is to hot have
Very good question. This is why we distinguish between provider
implemented and consumer implemented interfaces. Usually to a developer
the role of the interface is clear, as you have intuitively grasped:
interfaces that are merely callbacks or listeners are generally consumer
implemented. In bnd
No, behaviour 2 is correct. The result from getImportingBundles()
represents wirings, and there is no purpose in creating a wiring from
a bundle to itself.
When you see a bundle importing and exporting a package, it means that
the framework has a choice to select either the import OR the export.
Rainer,
When I recommended that technique I wasn't aware of the existing
functionality in CQ5 that Felix mentioned. Since that does exist I
would now recommend you use that -- there's no point reinventing the
wheel.
Regarding your point about installation order: in OSGi you should
never have to
David,
I am maintaining Bindex and also Bindex2 which is the new R5-based
version. It can be found on the rfc112 branch of the same GitHub
project, and it is quite far along in terms of functionality.
Contributions welcome.
Regards
Neil
On Thu, Jul 5, 2012 at 9:45 AM, David Bosschaert
uot;q"
package can be found.
Kind regards,
Neil Bartlett
Shigekuni Kondo
4 June 2012 13:08
Hi OSGi Experts,I
have questions about Export Package in Core spec(R4.3).[Condition]BundleA:
Import-Package: p, r Export-Package: q; uses:=pBundleB:
Import-Package: qBundl
i.orghttps://mail.osgi.org/mailman/listinfo/osgi-dev
Neil Bartlett
9 May 2012 06:04
Hello Balzs,
With regard to service versioning, OSGi does already do this, pretty
much exactly as you have described. But you seem to be saying that this
is missing. Could you clarify please?
Reg
.
Neil
On Wed, May 9, 2012 at 9:42 AM, Neil Bartlett njbartl...@gmail.com wrote:
There are advantages and disadvantages with both approaches, i.e.
including service APIs in the provider bundle versus separating them into
pure API bundles. Each approach involves trade-offs, and as a result even
Hello Balzs,
With regard to service versioning, OSGi does already do this, pretty
much exactly as you have described. But you seem to be saying that this
is missing. Could you clarify please?
Regards,
Neil
Balzs Zsoldos
9 May 2012 00:31
Hi,first of
all, I am sorry I
This is correct/expected behaviour.
The Service-Component header is ignored if it appears in the manifest
of a fragment, however the XML descriptor can appear in a fragment if
it is referenced from the Service-Component header in the manifest of
its host bundle.
See section 112.4.1 of the
Guillaume,
In this case the bundle will be fully started, i.e. forced to start without
regard for its policy. Because of this I recommend that you *always* start
bundles with the START_ACTIVATION_POLICY flag.
I believe that it was discussed that the default behaviour of the zero-arg
start()
with you that in general, lazy activation is a hack... it
complicates the bundle lifecycle and is too easily abused. I am much more a fan
of the style of laziness supported by DS and iPOJO.
Neil
On Wednesday, 11 January 2012 at 17:20, Richard S. Hall wrote:
On 1/11/12 12:04 , Neil Bartlett
Yes, I believe that it should always require an explicit operation to activate
a bundle. If the framework were to automatically start a bundle from RESOLVED
state then there would be no way for a deployer to disable a bundle, short of
uninstalling it.
Neil
On Wednesday, 11 January 2012 at
is used.
I guess I agree with you that eager activation should always be possible, but
following the bundle's policy makes most sense to me as a default.
Neil
On Wednesday, 11 January 2012 at 17:45, Richard S. Hall wrote:
On 1/11/12 12:34 , Neil Bartlett wrote:
Unfortunately I have seen
Hello Matias,
My apologies, somebody should have tried to answer this question much earlier.
Blueprint does not do anything like this. You may want to use it for
other things, but it's irrelevant for the problem you describe. Nor is
there really anything in core OSGi... the core can tell you
Giuseppe,
Bear in mind that it's also important what the target service is doing. If
there is one target service and it goes away very briefly (e.g. for its bundle
to be updated) then the component binding to it will of course have to be
unbound first and then rebound later.
The dynamic
Raymond,
I think you may have gone off on a tangent there. Why shouldn't a library like
XStream depend on the OSGi LogService? It's only a couple of interfaces… far
better than Log4J or Commons Logging or even SLF4J.
There is nothing in the ideals of OSGi that is opposed to modern Java
Hi Ferry,
Could you clarify question 1? I don't understand what you're asking for there.
In reply to point 2, and not disagreeing with anything Mike said… standard OBR
(both the current released version and the new RFC) can do this too, but you
need an index generator that knows about DS.
The
Hello Lindsay,
These are excellent questions. I agree with you that maintaining
versions is too hard for humans to manage, and tools need to take over
most of this task.
Before getting into what tools can do, make sure you have read the
OSGi Semantic Versioning whitepaper[1], which sets out the
It sounds likely that you are picking up an incompatible service.
Check whether you open the ServiceTracker with open(true) or
open(false)... or just open(), which is equivalent to
open(false).
FYI the open(false)/open() variant is nearly always correct.
To explain a little more... the service
I know as little as BJ does about ZK... however, if those resources are
being loaded from bundles then you may be able to assume that the class
names they refer to are classes either contained in visible from the same
bundle that contained the resource. In which case you could use the
Chris,
The Felix SCR implementation offers a service interface
org.apache.felix.scr.ScrService that gives you an introspection API
for the state of DS components.
I believe the Equinox DS implementation now offers the same service,
so it's becoming a kind of de facto standard, but I would also
Hi Phillipp,
The OSGi service registry itself won't care about you doing this. The
EventAdmin implementation *might*, but it depends on the
implementation's internals... though they should be able to handle
this scenario cleanly.
Here is what should happen:
1) Your handler is called by the
You only mentioned it once, and you said it's not an option because
it's C rather that C++. I'm curious why that matters?
When it comes to type safety, even Java OSGi is not particularly
typesafe as services must be casted before they can be used. At least
this will remain the case until 4.3
Just to add one additional point: I believe that a bundle should never
call System.exit(). As a bundle you don't know whether you are in a
pure OSGi runtime, or whether OSGi is embedded inside a larger
application.
Use one of the techniques described by Thomas and Richard to shutdown
the
Hi Hamlet,
My responses inline below.
On Fri, Mar 4, 2011 at 6:50 AM, Hamlet DArcy hamlet.da...@canoo.com wrote:
Hi all,
I am hoping for some architectural/design guidance.
I have an existing application that loads executes Groovy scripts from disk
in order to provide custom logic to
Inline again...
On Fri, Mar 4, 2011 at 7:24 AM, Hamlet DArcy hamlet.da...@canoo.com wrote:
My goal is to have groovy.* packages in the Import-Package list but not the
Export-Package list. Then it will be a dependency that can vary between
bundles. And it needs to vary between bundles. We
Bram,
The HttpContext can load resources from wherever it likes, based on
whatever rules it chooses.
The implementations in Felix etc that you have found are just that:
implementations. They do not imply any constraint on other potential
implementations.
Regards,
Neil
On Mon, Feb 28, 2011 at
Scott,
I think that for the older frameworks, registering the service against
the API bundle (i.e. the exporter) is probably the best compromise.
It does limit the RSA provider to supporting only one version of the
service interfaces in case there are multiple, but this feels like a
reasonable
On Mon, Feb 21, 2011 at 10:49 AM, Peter Kriens peter.kri...@aqute.biz wrote:
I think we have think a bit deeper. Assume you have 2 exporters of IFoo that
are both compatible with the proxy you generate. Shouldn't you create a proxy
for both?
Ideally yes, but this doesn't seem to be
Hi Scott,
Replies inline.
On Sun, Feb 20, 2011 at 3:58 PM, Scott Lewis sle...@composent.com wrote:
First a little background
ServiceTracker has two open methods:
public void open(boolean trackAllServices) and public void open() (which
calls open(false))
The javadocs for
is in a consistent state and
ensure that all services are started, right?
Eugen
Am 16.02.2011 um 18:53 schrieb Neil Bartlett:
Hi Eugen,
This is a very interesting question, thanks for asking it!
I appreciate that dynamics are not a big feature of enterprise
applications, but there is one
inconsistently. But in OSGi there is no point in time where I can ensure that
my application is in a consistent state and ensure that all services are
started, right?
Eugen
Am 16.02.2011 um 18:53 schrieb Neil Bartlett:
Hi Eugen,
This is a very interesting question, thanks for asking it!
I
Hi Eugen,
This is a very interesting question, thanks for asking it!
I appreciate that dynamics are not a big feature of enterprise
applications, but there is one time when ALL applications are dynamic,
and that is during startup (also, less importantly, during shutdown).
This is what I find
the OSGi 4 jar in the class path then set the below
mentioned property in my application. But then also the behavior is unchanged.
Regards
Vikash Agrawal
-Original Message-
From: osgi-dev-boun...@mail.osgi.org [mailto:osgi-dev-boun...@mail.osgi.org]
On Behalf Of Neil Bartlett
Sent
] on
behalf of Neil Bartlett [njbartl...@gmail.com]
Sent: Wednesday, February 09, 2011 8:13 AM
To: OSGi Developer Mail List
Subject: Re: [osgi-dev] OSGi-eclipse files creation issues
Hi Vikash,
All OSGi frameworks need to create a data storage area, to allow them to
persist and restore the state
DS principally defines *components*. A component can depend on a
service by declaring a reference element in its XML descriptor (or
if you're using the cool Bnd annotations, an @Reference annotation in
the Java source).
In addition a component can itself provide a service, using the
service
Why do you feel that DS disobeys the ServiceFactory contract?
Sent from my BlackBerry
On 19 Nov 2010, at 10:12, Martin Ždila m.zd...@mwaysolutions.com wrote:
On Fri, Nov 19, 2010 at 11:04 AM, Neil Bartlett njbartl...@gmail.com wrote:
Creating objects of different classes based
Peter,
As far as I can tell, CXF DOSGi is no longer actively maintained. It
is the reference implementation, but it has serious bugs that are not
being fixed.
ECF is not yet compliant with the latest specification, so is a little
behind CXF in that respect. However the ECF team are actively
Wouldn't it be nice if we could get these auto-replies and other spam
removed from the mailing list??
On Mon, Sep 27, 2010 at 7:39 AM, ashish.motiv...@oracle.com wrote:
I am out of office and will be back on Oct 3rd. I will periodically check
email.
If this is urgent, pl contact my manager,
Is adding the split attribute to the Import-Package really the best
solution? It assures that the importer gets only part of the package, and it
also makes a mess of the manifest. Surely it's better to ensure that an
aggregating bundle exists... then importers can simply import org.eclipse.ui
Michael,
Private packages merely means the packages that are not exported by
a bundle. They are only visible within that bundle, hence private.
In contrast, a package that is exported is public.
The class space of a bundle can of course also include the public
packages of that bundle. However,
Of Neil Bartlett
Sent: Monday, August 30, 2010 11:25 AM
To: OSGi Developer Mail List
Subject: Re: [osgi-dev] question about class space in OSGi R4 core
Michael,
Private packages merely means the packages that are not exported by
a bundle. They are only visible within that bundle, hence
Take a look at the refreshPackages method of the PackageAdmin service.
Note that the refresh operation is intended to delimit batched
uninstall/update operations by a management agent. For example if you have
10 bundles to uninstall, then do NOT refresh between each bundle, but save
it until all
David,
The JAR File Specification allows you to place whatever arbitrary
headers you like in the MANIFEST.MF. They will be ignored by OSGi.
Regards,
Neil
On Wed, Jun 16, 2010 at 7:36 AM, David Conde dco...@citic.es wrote:
Hi,
What could I use in order to provide some custom information in
Like Tom, I'm concerned that you have fixed the problem in the wrong way, ie
a way that will create bigger problems later.
What did you change in config.ini?
Rgds, Neil
Sent from my BlackBerry®
-Original Message-
From: Asier Aranbarri Beldarrain aranbar...@gmail.com
Sender:
Agreed, except the extender pattern usually means examining installed
bundles using the Bundle.getHeader() or Bundle.getEntry() methods.
David talked about examining bundles *before* installation, which
implies using the java.util.Jar API to read jars from the filesystem.
Neil
On Wed, Jun 16,
Andrea,
That sounds about right. With DS1.1 using the activate attribute of
the component element, the method can throw both checked and unchecked
exceptions. In either case SCR should log the error to LogService (if
present) and should not register any services for the instance.
Neil
On Mon,
I meant whichever bundle was throwing the error. Never mind as you have stated
they are all active.
Trying the Felix event admin will not help. As I said, this problem has nothing
to do with implementations, it is a static class resolution problem.
Unfortunately it is impossible to debug the
have the same build
configuration.
Thanks for your help, appreciated ,
Asier
On 30 March 2010 14:19, Neil Bartlett njbartl...@gmail.com
mailto:njbartl...@gmail.com mailto:njbartl...@gmail.com
mailto:njbartl...@gmail.com wrote
2010 14:19, Neil Bartlett njbartl...@gmail.com
mailto:njbartl...@gmail.com mailto:njbartl...@gmail.com
mailto:njbartl...@gmail.com wrote:
The listener bundle is not importing the package
org.osgi.service.event.
This should have been caught at build
The listener bundle is not importing the package org.osgi.service.event.
This should have been caught at build-time. What development
environment or OSGi tooling are you using? Eclipse PDE would show this
as a compilation error, and bnd (or a bnd-based tool such as Maven's
bundle plugin) would
stacktrace to see
where the problem is.
Miguel
On Tue, Mar 16, 2010 at 12:55 PM, Neil Bartlett njbartl...@gmail.com
wrote:
Eva,
You haven't given the stack trace of the error or much other context,
e.g. it looks like it should be coming from the dispatching thread
rather than from
I'm not uncomfortable with the delayed flushing of the caches. After all,
we're talking about the JVM either crashing or being forcibly shutdown -- we
shouldn't expect it to be able to recover to exactly the same state.
So long as the framework is able to detect the problem when it next starts
My apologies, I misread your email; I though you said you WERE using -clean.
Neil
On Thu, Mar 4, 2010 at 12:58 PM, Neil Bartlett njbartl...@gmail.com wrote:
David,
If you are using the -clean option then this explains why the bundles
are disappearing. I recommend not using the -clean option
Nobody is suggesting that OSGi is a bad choice for your scenario. It's
just that there is nothing in your scenario that particularly requires
OSGi -- everything is fairly easily achievable with other, perhaps
more mainstream, technologies.
Therefore the case to make to your boss must focus on the
There is nothing wrong with using the org.hsqldb.jdbc.JDBCDriver class.
Asier: have you packaged HSQLDB as an OSGi bundle, or have you added
it to your bundle classpath using the Bundle-Classpath header? Note
that it is not enough to simply put a copy of hsqldb.jar inside your
bundle. However, I
Andrea,
Concurrent delivery is certainly an option for EventAdmin implementers
to support, but it is not mandated by the specification.
To put it bluntly, I think that the existing open source
implementations come nowhere near to offering the kind of powerful
features that EventAdmin
Wim,
At the low level this can be achieved by registering instances of the
java.util.concurrent.Executor interface (from the Java 5 concurrency
libs) as services -- then a bundle wishing to execute work can submit
it to a registered Executor rather than explicitly create its own
threads. The
Sorry if I am missing something obvious, but what is wrong with new
FileInputStream(...) ?
Neil
On Mon, Feb 1, 2010 at 9:12 AM, Asier Aranbarri Beldarrain
aranbar...@gmail.com wrote:
Hi everyone:
I need to load a config.properties file from outside an osgi bundle and I'm
having real issues
2010 10:41, Jean-Baptiste Onofré j...@nanthrax.net wrote:
Hi Neil,
The FileInputStream() usage is correct too. I simply focus on another way
to do it using blueprint :)
Regards
JB
Neil Bartlett wrote:
Sorry if I am missing something obvious, but what is wrong with new
FileInputStream
-file-install-part-2-dynamic-configurations/
Miguel
Sent from Madrid, Spain
On Mon, Jan 4, 2010 at 2:25 PM, Neil Bartlett njbartl...@gmail.com
mailto:njbartl...@gmail.com wrote:
Miguel,
FileInstall by default looks in a directory named load relative to
the working directory
Asier,
Do you have an event admin bundle installed and active? The Equinox
implementation is called org.eclipse.equinox.event.
Without that bundle active you will of course always get null when
trying to obtain the EventAdmin service.
Regards,
Neil
On Mon, Nov 9, 2009 at 12:01 PM, Asier
you to join orkut! (cato kato)
2. Problems with OSGi PostEvent (Asier Aranbarri Beldarrain)
3. Re: Problems with OSGi PostEvent (Neil Bartlett)
--
Message: 1
Date: Mon, 09 Nov 2009 06:07:29 +
From: cato kato
I see. From experience, it will always be wired to the existing
package, but I'm not sure if this is mandated behaviour.
Neil
On Fri, Jun 19, 2009 at 2:27 PM, Guillaume Nodetgno...@gmail.com wrote:
My question, is more if foo-2.0 is already installed and then we
install foo-1.0, is there a
bundles whose names end with
.serviceimpl in a dedicated startUp-bundle.
Kind regards,
Eugen
Am Apr 30, 2009 um 16:23 schrieb Neil Bartlett:
While I agree with Peter and Hal, I think the heart of your problem is
the mismatch between the preferred lifecycles of bundles in Eclipse
David,
You can use the getBundle(Class) method of the PackageAdmin service.
To quote the JavaDocs:
Returns the bundle from which the specified class is loaded. The
class loader of the returned bundle must have been used to load the
specified class. If the class was not loaded by a bundle
I have had some experience with obfuscating an Eclipse RCP
application. As Richard points out, obfuscation of the internal
bytecode of methods is not a problem.
However, most obfuscators also try to rename classes, methods and
packages in order to make it harder to understand what they are for,
101 - 191 of 191 matches
Mail list logo
