Re: [VOTE] Release CXF dOSGi 1.2 - Take 2
+1 Cheers, Marc Am 21.07.2010 08:45, schrieb Eoghan Glynn: Folks, Now that the release notes are all fixed up, I'm calling a second vote to release CXF Distributed OSGi 1.2. The release notes contain a description of new features and bugs fixed in this release: http://svn.apache.org/repos/asf/cxf/dosgi/trunk/distribution/sources/src/main/release/release_notes.txt The new staging area is: https://repository.apache.org/content/repositories/orgapachecxf-025 The various distributions can be downloaded as follows: - Source: https://repository.apache.org/content/repositories/orgapachecxf-025/org/apache/cxf/dosgi/cxf-dosgi-ri-source-distribution/1.2 - Multi-bundle: https://repository.apache.org/content/repositories/orgapachecxf-025/org/apache/cxf/dosgi/cxf-dosgi-ri-multibundle-distribution/1.2 - Single-bundle: https://repository.apache.org/content/repositories/orgapachecxf-025/org/apache/cxf/dosgi/cxf-dosgi-ri-singlebundle-distribution/1.2 This release is tagged with cxf-dosgi-ri-1.2 at: http://svn.apache.org/repos/asf/cxf/dosgi/tags/cxf-dosgi-ri-1.2 The vote will remain open for at least 72 hours. Please consider this call to vote as my +1. Cheers, Eoghan
Re: CXF-DOSGi passing the OSGi Remote Services and Remote Service Admin CT
Hi Fabio, I have removed the irritating log message from this method so it is fixed ;-) Cheers Marc On 06/12/2010 12:17 AM, Fabio souza wrote: > Hi Marc and David, > > First of all, congratulations!!! Recently, I have decided to study cxf dosgi > and I have downloaded v1.2 of the source code and built it. While testing, I > saw one of those SEVERE messages in the screen. That happened when I > unregistered a service that was exported. I saw that the problem was in > method removeExportReference of the TopologyManager, and I made some small > modifications to make it work. Could you tell me if this method was fixed? > Thank you very much! > > Best regards, > > Fabio > > On Fri, Jun 11, 2010 at 12:53 PM, David Bosschaert < > david.bosscha...@gmail.com> wrote: > > >> Great, thanks Marc! >> >> I think we're getting close to something that is releasable. >> >> Tasks left would be: >> * Add a configuration item org.apache.cxf.rs.port. Sergey is this >> something that you might have time for? Or maybe we can do this >> together? >> * Make sure all the demos work (and update the docs) - this is >> something I would be happy to help out with. >> * When the above is done, cut the actual release candidate(s). >> >> Cheers, >> >> David >> >> On 11 June 2010 15:32, Marc Schaaf wrote: >> >>> Hi, >>> >>> I just committed some changes which remove the "severe" messages that >>> where produced during the normal operation of the Topology Manager. Two >>> of them where obsolete by now and one concerned some missing >>> functionality of the Topology Manager that I've now added. This >>> concerned in particular the behaviour of the Topology Manager regarding >>> the import of services when the DSW is detected/added after the service >>> to be imported was found which is supported now. >>> >>> Cheers, >>> Marc >>> >>> On 05/12/2010 06:40 PM, David Bosschaert wrote: >>> >>>> Hi all, >>>> >>>> Earlier this week the OSGi Alliance has approved the OSGi 4.2 >>>> Enterprise Conformance Tests and Reference Implementations. The >>>> CXF-DOSGi project [1] is the Reference Implementation for the >>>> following OSGi 4.2 specs [2]: >>>> >>>> * Chapter 13 - Remote Services >>>> This spec describes Distributed OSGi from a user's point of view. It >>>> standardizes the properties that can be put on an OSGi service to make >>>> it available remotely and how a consumer can find out whether it's >>>> dealing with a local service or a remote one. >>>> >>>> * Chapter 122 - Remote Services Admin >>>> This spec standardizes the interfaces between internal components >>>> Remote Services implementations typically have. A Distribution >>>> Provider, Topology Manager and Discovery System. This makes it >>>> possible to mix&match these components from various implementations. >>>> For more information see slides 6-8 at [3]. >>>> >>>> Many kudos to Marc Schaaf as he did a lot of the recent RI work. >>>> Also many kudos to Tim Diekmann from TIBCO who wrote the actual CT >>>> tests despite his busy schedule. >>>> >>>> So now that we have a passing RI I think it would make sense to start >>>> planning a CXF-DOSGi release. I'm wondering what we should do before >>>> that... >>>> 1. There are some SEVERE 'warnings' coming up, I believe from the >>>> Topology Manager. We should probably take a look at those. >>>> 2. I once added some Discovery system tests, which I ended up not >>>> enabling because of memory issues. I might want to try and get them >>>> working on all platforms. >>>> 3. Anything else? >>>> >>>> Best regards, >>>> >>>> David >>>> >>>> [1] http://cxf.apache.org/distributed-osgi.html >>>> [2] http://www.osgi.org/Download/Release4V42 >>>> [3] http://www.slideshare.net/bosschaert/whats-newinos-gi42enterprise >>>> >>>> >>> >>> >> > > >
Re: CXF-DOSGi passing the OSGi Remote Services and Remote Service Admin CT
Hi, I just committed some changes which remove the "severe" messages that where produced during the normal operation of the Topology Manager. Two of them where obsolete by now and one concerned some missing functionality of the Topology Manager that I've now added. This concerned in particular the behaviour of the Topology Manager regarding the import of services when the DSW is detected/added after the service to be imported was found which is supported now. Cheers, Marc On 05/12/2010 06:40 PM, David Bosschaert wrote: > Hi all, > > Earlier this week the OSGi Alliance has approved the OSGi 4.2 > Enterprise Conformance Tests and Reference Implementations. The > CXF-DOSGi project [1] is the Reference Implementation for the > following OSGi 4.2 specs [2]: > > * Chapter 13 - Remote Services > This spec describes Distributed OSGi from a user's point of view. It > standardizes the properties that can be put on an OSGi service to make > it available remotely and how a consumer can find out whether it's > dealing with a local service or a remote one. > > * Chapter 122 - Remote Services Admin > This spec standardizes the interfaces between internal components > Remote Services implementations typically have. A Distribution > Provider, Topology Manager and Discovery System. This makes it > possible to mix&match these components from various implementations. > For more information see slides 6-8 at [3]. > > Many kudos to Marc Schaaf as he did a lot of the recent RI work. > Also many kudos to Tim Diekmann from TIBCO who wrote the actual CT > tests despite his busy schedule. > > So now that we have a passing RI I think it would make sense to start > planning a CXF-DOSGi release. I'm wondering what we should do before > that... > 1. There are some SEVERE 'warnings' coming up, I believe from the > Topology Manager. We should probably take a look at those. > 2. I once added some Discovery system tests, which I ended up not > enabling because of memory issues. I might want to try and get them > working on all platforms. > 3. Anything else? > > Best regards, > > David > > [1] http://cxf.apache.org/distributed-osgi.html > [2] http://www.osgi.org/Download/Release4V42 > [3] http://www.slideshare.net/bosschaert/whats-newinos-gi42enterprise >
Re: svn commit: r937947 - in /cxf/dosgi/trunk: discovery/distributed/cxf-discovery/src/main/java/org/apache/cxf/dosgi/discovery/zookeeper/ distribution/single-bundle/src/main/resources/OSGI-INF/ dsw/
Hi David,
I'm sorry but I currently don't have the time to implement the test
cases. I will add them as soon as possible, probably in two weeks from
now when I will have some more time on my hands.
Cheers,
Marc
David Bosschaert wrote:
> Thanks Marc!
> One comment I have is that there are no CXF-DOSGi unit tests for this
> code. I know that it's tested in the OSGi TCK but it would be good to
> have some tests for it in the CXF-DOSGi codebase.
> Do you think you can add these?
>
> Cheers,
>
> David
>
> On 26 April 2010 08:30, wrote:
>> Author: mschaaf
>> Date: Mon Apr 26 07:30:42 2010
>> New Revision: 937947
>>
>> URL: http://svn.apache.org/viewvc?rev=937947&view=rev
>> Log:
>> - some additions to the zookeeper discovery to be compiant with the TCK
>> - some refactoring in the zookeeper discovery
>> - added some basic security checks to the DSW to comply with the TCK
>> security tests
>>
>> Added:
>>cxf/dosgi/trunk/distribution/single-bundle/src/main/resources/OSGI-INF/
>>
>> cxf/dosgi/trunk/distribution/single-bundle/src/main/resources/OSGI-INF/permissions.perm
>> Modified:
>>
>> cxf/dosgi/trunk/discovery/distributed/cxf-discovery/src/main/java/org/apache/cxf/dosgi/discovery/zookeeper/EndpointListenerTrackerCustomizer.java
>>
>> cxf/dosgi/trunk/discovery/distributed/cxf-discovery/src/main/java/org/apache/cxf/dosgi/discovery/zookeeper/InterfaceDataMonitorListenerImpl.java
>>
>> cxf/dosgi/trunk/discovery/distributed/cxf-discovery/src/main/java/org/apache/cxf/dosgi/discovery/zookeeper/InterfaceMonitor.java
>>
>> cxf/dosgi/trunk/discovery/distributed/cxf-discovery/src/main/java/org/apache/cxf/dosgi/discovery/zookeeper/Util.java
>>
>> cxf/dosgi/trunk/dsw/cxf-dsw/src/main/java/org/apache/cxf/dosgi/dsw/handlers/ClientServiceFactory.java
>>
>> cxf/dosgi/trunk/dsw/cxf-dsw/src/main/java/org/apache/cxf/dosgi/dsw/handlers/ServiceInvocationHandler.java
>>
>> cxf/dosgi/trunk/dsw/cxf-dsw/src/main/java/org/apache/cxf/dosgi/dsw/service/RemoteServiceAdminCore.java
>>
>> cxf/dosgi/trunk/dsw/cxf-dsw/src/main/java/org/apache/cxf/dosgi/dsw/service/RemoteServiceAdminInstance.java
>>
>> Modified:
>> cxf/dosgi/trunk/discovery/distributed/cxf-discovery/src/main/java/org/apache/cxf/dosgi/discovery/zookeeper/EndpointListenerTrackerCustomizer.java
>> URL:
>> http://svn.apache.org/viewvc/cxf/dosgi/trunk/discovery/distributed/cxf-discovery/src/main/java/org/apache/cxf/dosgi/discovery/zookeeper/EndpointListenerTrackerCustomizer.java?rev=937947&r1=937946&r2=937947&view=diff
>> ==
>> ---
>> cxf/dosgi/trunk/discovery/distributed/cxf-discovery/src/main/java/org/apache/cxf/dosgi/discovery/zookeeper/EndpointListenerTrackerCustomizer.java
>> (original)
>> +++
>> cxf/dosgi/trunk/discovery/distributed/cxf-discovery/src/main/java/org/apache/cxf/dosgi/discovery/zookeeper/EndpointListenerTrackerCustomizer.java
>> Mon Apr 26 07:30:42 2010
>> @@ -71,14 +71,21 @@ public class EndpointListenerTrackerCust
>> for (String key : sref.getPropertyKeys()) {
>> LOG.finest("modifiedService: property: " + key + " => " +
>> sref.getProperty(key));
>> }
>> -String[] scopes =
>> getStringPlusProperty(sref.getProperty(EndpointListener.ENDPOINT_LISTENER_SCOPE));
>> -LOG.fine("trying to discover service for scopes[" + scopes.length +
>> "]: ");
>> +
>> +String[] scopes = Util.getScopes(sref);
>> +
>> +LOG.info("trying to discover services for scopes[" + scopes.length
>> + "]: ");
>> if(scopes!=null) for (String scope : scopes) {
>> -LOG.fine("Scope: "+scope);
>> +LOG.info("Scope: "+scope);
>> }
>> if (scopes.length > 0) {
>> for (String scope : scopes) {
>> LOG.fine("*** Handling scope: " + scope);
>> +if("".equals(scope) || scope == null){
>> +LOG.warning("skipping empty scope from EndpointListener
>> from " + sref.getBundle().getSymbolicName());
>> +continue;
>> +}
>> +
>> String objClass = getObjectClass(scope);
>> LOG.fine("*** objectClass: " + objClass);
>>
>> @@ -100,10 +107,10 @@ public class EndpointListenerTrackerCust
>> interest.im.close();
>> interest.im = null;
>> }
>> -
>> +
>> InterfaceMonitor dm = new
>> InterfaceMonitor(zooKeeperDiscovery.getZookeeper(),
>>objClass,
>> interest, scope, bctx);
>> -dm.process();
>> +dm.start();
>> interest.im = dm;
>>
>> List handledScopes =
>> handledEndpointlisteners.get(sref);
>> @@ -149,34 +156,7 @@ public class EndpointListenerTrackerCust
>>
>> }
>>
>> -pr
Re: dOSGi: Change the startup of the DSW to Spring
Thanks for the comments! I agree with David, we already need spring for many other things. However I would also like to have a non spring solution here but the only other one that comes to my mind is to introduce some kind of lazy loading mechanism for the intent map. This mechanism would than load it as soon as spring is ready. However I don't think that this is a better solution as this means that from the perspective of a user the DSW is completely started but in the background not all functionality is available yet. So from my point of view the spring solution seems OK (at least for now). Cheers Marc David Bosschaert wrote: I think this would be a good improvement since solves the race condition that causes the error as raised in DOSGI-66. I'm glad to see that some more explanation around the work was provided in the bug as well. At the moment CXF-DOSGi uses Spring for various things. Its really an implementation detail. I think it would be better to refactor that dependency into an OSGi Blueprint dependency at some point in the future as Blueprint is a standard and Spring isn't. But that's really something separate... Cheers, David On 25 February 2010 10:26, Sergey Beryozkin wrote: Hi My concern is that the way intents maps are loaded is the implementation detail of DSW and even though using Spring is what we use at the moment to load them I'm feeling we should not exclude other options (to make it easier for 'interested' OSGI non-Spring aware containers to integrate/inlcude DOSGI RI). Thus making DSW to start from Spring does not look like an ideal option to me...Also, as I noted in [1], we could find it more difficult to do things other than expressing service registration or dependencies requirements which is what you can do in Spring DM contexts cheers, Sergey - Original Message - From: "Marc Schaaf" To: Sent: Thursday, February 25, 2010 9:33 AM Subject: dOSGi: Change the startup of the DSW to Spring Hi, with regard to [1] I would like to change the startup of the dOSGi DSW from a normal OSGi activator to Spring. This way the DSW would be started by the Spring OSGi Extender bundles which would solve an issue with the intent map loading. Currently the intent map is only successfully loaded by the DSW if the Spring OSGi Extender was started before. Are there any objections against this approach ? Thanks, Marc [1] http://issues.apache.org/jira/browse/DOSGI-66
dOSGi: Change the startup of the DSW to Spring
Hi, with regard to [1] I would like to change the startup of the dOSGi DSW from a normal OSGi activator to Spring. This way the DSW would be started by the Spring OSGi Extender bundles which would solve an issue with the intent map loading. Currently the intent map is only successfully loaded by the DSW if the Spring OSGi Extender was started before. Are there any objections against this approach ? Thanks, Marc [1] http://issues.apache.org/jira/browse/DOSGI-66
