Re: [VOTE] Release of the dependency manager 2.0.1

[Pierre De Rop]

+1 (non binding vote)

/pierre

Marcel Offermans wrote:

Hello all,

I'm opening a vote for the 2.0.1 release candidate of the dependency 
manager and its optional shell command bundle. I've compiled 
everything and put it up for testing and checking here:


http://people.apache.org/~marrs/dependencymanager-2.0.1/

The KEYS file for verifying the signature is also in this directory 
and the checksum files should have the correct format.


Please check the release and cast your votes, the vote will be open 
for at least 72 hours:


[ ] +1 Approve the release
[ ] -1 Veto the release (please provide specific comments)

Greetings, Marcel

Re: [VOTE] Release of the dependency manager 2.0.1

[Felix Meschberger]

+1

Regards
Felix

Marcel Offermans schrieb:
> Hello all,
> 
> I'm opening a vote for the 2.0.1 release candidate of the dependency
> manager and its optional shell command bundle. I've compiled everything
> and put it up for testing and checking here:
> 
> http://people.apache.org/~marrs/dependencymanager-2.0.1/
> 
> The KEYS file for verifying the signature is also in this directory and
> the checksum files should have the correct format.
> 
> Please check the release and cast your votes, the vote will be open for
> at least 72 hours:
> 
> [ ] +1 Approve the release
> [ ] -1 Veto the release (please provide specific comments)
> 
> Greetings, Marcel
> 
> 

Re: [Vote] Release Felix Log Service 1.0.0

[Stuart McCulloch]

2009/3/30 Felix Meschberger 

> Hi,
>
> Stuart McCulloch schrieb:
> > also I think we should add a "log" command to the shell otherwise you
> > can't retrieve the log events (unless you add your own log reader...)
>
> How about implementing this in the shell service bundle itself or in a
> standalone bundle. I assume, such a command would only rely on the
> LogReader service and not any implementation details.
>

yes, I was thinking this would go in the shell service bundle ... perhaps
this is a good GSoC candidate?


> As such it would be of use for other LogService implementations.
>
> WDYT ?
>
> Regards
> Felix
>
> >
> >
> >> Regards,
> >> Clement
> >>
> >
>



-- 
Cheers, Stuart

[jira] Closed: (FELIX-973) FilterImpl from Felix Framework does not support none LDAP operators

[Kristian Koehler (JIRA)]

 [ 
https://issues.apache.org/jira/browse/FELIX-973?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Kristian Koehler closed FELIX-973.
--


Thanks!

Kristian

> FilterImpl from Felix Framework does not support none LDAP operators
> 
>
> Key: FELIX-973
> URL: https://issues.apache.org/jira/browse/FELIX-973
> Project: Felix
>  Issue Type: Bug
>  Components: Bundle Repository (OBR)
>Affects Versions: bundlerepository-1.2.1
>Reporter: Kristian Koehler
>Assignee: Richard S. Hall
> Fix For: bundlerepository-1.4.0
>
> Attachments: filter.patch, filter.patch, new_patch.txt, patch.txt
>
>
> Hi
> as discussed on the user mailing list 
> (http://www.mail-archive.com/us...@felix.apache.org/msg03402.html) the 
> framework doesn't support none standard LDAP operators (see also the RFC-0112 
> Bundle Repository). 
> The filter impl throws an exception while parsing a repository file 
> containing filters with this syntax.
> Kristian
> sample stack trace
> --- 8< ---
> ERROR: Error parsing repository metadata
> org.osgi.framework.InvalidSyntaxException: expected ~=|>=|<=
> at org.apache.felix.framework.FilterImpl.(FilterImpl.java:81)
> at 
> org.apache.felix.framework.BundleContextImpl.createFilter(BundleContextImpl.java:102)
> at 
> org.apache.felix.bundlerepository.RequirementImpl.setFilter(RequirementImpl.java:57)
> at sun.reflect.GeneratedMethodAccessor11.invoke(Unknown Source)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at 
> org.apache.felix.bundlerepository.metadataparser.XmlCommonHandler.startElement(XmlCommonHandler.java:490)
> at 
> org.apache.felix.bundlerepository.metadataparser.kxmlsax.KXml2SAXParser.parseXML(KXml2SAXParser.java:67)
> at 
> org.apache.felix.bundlerepository.RepositoryImpl.parseRepositoryFile(RepositoryImpl.java:256)
> at 
> org.apache.felix.bundlerepository.RepositoryImpl.access$000(RepositoryImpl.java:44)
> at 
> org.apache.felix.bundlerepository.RepositoryImpl$1.run(RepositoryImpl.java:75)
> at java.security.AccessController.doPrivileged(Native Method)
> at 
> org.apache.felix.bundlerepository.RepositoryImpl.(RepositoryImpl.java:71)
> at 
> org.apache.felix.bundlerepository.RepositoryImpl.(RepositoryImpl.java:60)
> at 
> org.apache.felix.bundlerepository.RepositoryAdminImpl.initialize(RepositoryAdminImpl.java:206)
> at 
> org.apache.felix.bundlerepository.RepositoryAdminImpl.discoverResources(RepositoryAdminImpl.java:126)
> at 
> org.apache.felix.bundlerepository.ObrCommandImpl.list(ObrCommandImpl.java:210)
> at 
> org.apache.felix.bundlerepository.ObrCommandImpl.execute(ObrCommandImpl.java:104)
> at 
> org.apache.felix.shell.impl.Activator$ShellServiceImpl.executeCommand(Activator.java:276)
> at 
> org.apache.felix.shell.tui.Activator$ShellTuiRunnable.run(Activator.java:167)
> at java.lang.Thread.run(Thread.java:619)
> WARNING: RepositoryAdminImpl: Exception creating repository 
> file:/home/kkoehler/repository.xml. Repository is skipped.
> java.lang.reflect.InvocationTargetException
> at sun.reflect.GeneratedMethodAccessor11.invoke(Unknown Source)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at 
> org.apache.felix.bundlerepository.metadataparser.XmlCommonHandler.startElement(XmlCommonHandler.java:490)
> at 
> org.apache.felix.bundlerepository.metadataparser.kxmlsax.KXml2SAXParser.parseXML(KXml2SAXParser.java:67)
> at 
> org.apache.felix.bundlerepository.RepositoryImpl.parseRepositoryFile(RepositoryImpl.java:256)
> at 
> org.apache.felix.bundlerepository.RepositoryImpl.access$000(RepositoryImpl.java:44)
> at 
> org.apache.felix.bundlerepository.RepositoryImpl$1.run(RepositoryImpl.java:75)
> at java.security.AccessController.doPrivileged(Native Method)
> at 
> org.apache.felix.bundlerepository.RepositoryImpl.(RepositoryImpl.java:71)
> at 
> org.apache.felix.bundlerepository.RepositoryImpl.(RepositoryImpl.java:60)
> at 
> org.apache.felix.bundlerepository.RepositoryAdminImpl.initialize(RepositoryAdminImpl.java:206)
> at 
> org.apache.felix.bundlerepository.RepositoryAdminImpl.discoverResources(RepositoryAdminImpl.java:126)
> at 
> org.apache.felix.bundlerepository.ObrCommandImpl.list(ObrCommandImpl.java:210)
> at 
> org.apache.felix.bundlerepository.ObrCommandImpl.execute(ObrCommandImpl.java:104)
> at 
> org.apache.felix.shell.impl.Activator$ShellServiceImpl.executeCommand(Activator.java:276)
> at 
> org.apache.felix.shell.tui.Activator$ShellTuiRunnable.run(Activator.java:167)
> at java.lang.Thread.ru

Re: [Vote] Release Felix Log Service 1.0.0

[Clement Escoffier]

Hi,


On 31.03.2009, at 08:06, Felix Meschberger wrote:


Hi,

Stuart McCulloch schrieb:

also I think we should add a "log" command to the shell otherwise you
can't retrieve the log events (unless you add your own log reader...)


How about implementing this in the shell service bundle itself or in a
standalone bundle. I assume, such a command would only rely on the
LogReader service and not any implementation details.

As such it would be of use for other LogService implementations.

WDYT ?


I agree, this should rely only on a log reader regardless the log  
service implementation.

But, I also agree that it will be useful.

Regards,

Clement




Regards
Felix





Regards,
Clement

Re: [Vote] Release Felix Log Service 1.0.0

[Rob Walker]

+1 from me

--


Ascert - Taking systems to the Edge
r...@ascert.com
+44 (0)20 7488 3470
www.ascert.com

Re: [Vote] Release Felix Log Service 1.0.0

[Felix Meschberger]

Hi,

Stuart McCulloch schrieb:
> also I think we should add a "log" command to the shell otherwise you
> can't retrieve the log events (unless you add your own log reader...)

How about implementing this in the shell service bundle itself or in a
standalone bundle. I assume, such a command would only rely on the
LogReader service and not any implementation details.

As such it would be of use for other LogService implementations.

WDYT ?

Regards
Felix

> 
> 
>> Regards,
>> Clement
>>
> 

Re: [Vote] Release Felix Log Service 1.0.0

[Stuart McCulloch]

2009/3/30 Clement Escoffier 

> Hi all,
>
> I cut a release of the Felix log service. This service implementation was
> developed and but never released.
> It's a simple implementation, but can be useful.
>
> The source and binary release archives, signature files, SHA and MD5
> message digests for each are available as zip and tar.gz here:
>
>
> http://people.apache.org/~clement/releases/org/apache/felix/org.apache.felix.log/1.0.0/
>
> Please vote to approve these release archives:
>
> [ ] +1 Yes, release it now
> [ ] -1 No, don't release now (please provide specific comments)
>

+1

also I think we should add a "log" command to the shell otherwise you
can't retrieve the log events (unless you add your own log reader...)


> Regards,
> Clement
>

-- 
Cheers, Stuart

Re: [DISCUSS] Move ServiceMix Kernel into Felix as a subproject

[Kristian Köhler]

+1 from me too. This sounds great!

Kristian

Freeman Fang wrote:

+1 for this idea.
Freeman

Guillaume Nodet wrote:

During ApacheCon last week, there has been some discussions around
moving ServiceMix Kernel as a subproject of Felix.
ServiceMix Kernel is a packaged distribution of Felix designed for
server side applications (see http://servicemix.apache.org/kernel/ for
more informations).

I think this would be beneficial for this project as it would enable
to build a much bigger community around it, increase the visibility
and the awareness around it. Of course, it would need a new name, but
that's another problem.
Another area that could be included in this move is the ServiceMix
specs (OSGi enhanced versions of Java EE specifications from Geronimo)
and ServiceMix bundles (we've released a bunch of bundles already, see
http://servicemix.apache.org/smx4/bundles-repository.html).

I'd like to have feedback from both communities (and any other
interested parties) to gauge the interest in such a move.

  

Re: [DISCUSS] Move ServiceMix Kernel into Felix as a subproject

[Lars Heinemann]

-- Forwarded message --
From: Lars Heinemann 
Date: 2009/3/30
Subject: Re: [DISCUSS] Move ServiceMix Kernel into Felix as a subproject
To: d...@servicemix.apache.org


+1 for moving it to Felix as sub project. Already discussed that a bit
at ApacheCon.
I think everything is already said with the given answers.

For the name...Karaf makes me think nothing at all...sorry for that ;)
But on the other handside I have no better name ready to push in.

Regards,
Lars



Guillaume Nodet schrieb:
> During ApacheCon last week, there has been some discussions around
> moving ServiceMix Kernel as a subproject of Felix.
> ServiceMix Kernel is a packaged distribution of Felix designed for
> server side applications (see http://servicemix.apache.org/kernel/ for
> more informations).
>
> I think this would be beneficial for this project as it would enable
> to build a much bigger community around it, increase the visibility
> and the awareness around it. Of course, it would need a new name, but
> that's another problem.
> Another area that could be included in this move is the ServiceMix
> specs (OSGi enhanced versions of Java EE specifications from Geronimo)
> and ServiceMix bundles (we've released a bunch of bundles already, see
> http://servicemix.apache.org/smx4/bundles-repository.html).
>
> I'd like to have feedback from both communities (and any other
> interested parties) to gauge the interest in such a move.
>
>




-- 
http://lhein.blogspot.com

Re: [Vote] Release Felix Log Service 1.0.0

[Richard S. Hall]

+1

I see you removed the LICENSE and NOTICE files from src/main/resources, 
but I think you can also remove the Include-Resource instruction from 
the pom file, since the default value will include them. We can fix that 
in trunk.


-> richard

On 3/30/09 7:48 AM, Clement Escoffier wrote:

Hi all,

I cut a release of the Felix log service. This service implementation 
was developed and but never released.

It's a simple implementation, but can be useful.

The source and binary release archives, signature files, SHA and MD5
message digests for each are available as zip and tar.gz here:

http://people.apache.org/~clement/releases/org/apache/felix/org.apache.felix.log/1.0.0/ 



Please vote to approve these release archives:

[ ] +1 Yes, release it now
[ ] -1 No, don't release now (please provide specific comments)

Regards,
Clement

Re: [VOTE] Release of the dependency manager 2.0.1

[Richard S. Hall]

p.s. Your KEYS file was not included, but I grabbed it from the last 
release...if you haven't done so, it should also be appended here, I 
believe:


http://svn.apache.org/repos/asf/felix/KEYS

On 3/30/09 11:22 PM, Richard S. Hall wrote:

+1

Technically, dependencymanager.shell also "uses" software developed at 
Apache (i.e., Felix' shell), but this is not a big deal and can be 
updated in trunk.


-> richard

On 3/30/09 3:59 PM, Marcel Offermans wrote:

Hello all,

I'm opening a vote for the 2.0.1 release candidate of the dependency 
manager and its optional shell command bundle. I've compiled 
everything and put it up for testing and checking here:


http://people.apache.org/~marrs/dependencymanager-2.0.1/

The KEYS file for verifying the signature is also in this directory 
and the checksum files should have the correct format.


Please check the release and cast your votes, the vote will be open 
for at least 72 hours:


[ ] +1 Approve the release
[ ] -1 Veto the release (please provide specific comments)

Greetings, Marcel

Re: [VOTE] Release of the dependency manager 2.0.1

[Richard S. Hall]

+1

Technically, dependencymanager.shell also "uses" software developed at 
Apache (i.e., Felix' shell), but this is not a big deal and can be 
updated in trunk.


-> richard

On 3/30/09 3:59 PM, Marcel Offermans wrote:

Hello all,

I'm opening a vote for the 2.0.1 release candidate of the dependency 
manager and its optional shell command bundle. I've compiled 
everything and put it up for testing and checking here:


http://people.apache.org/~marrs/dependencymanager-2.0.1/

The KEYS file for verifying the signature is also in this directory 
and the checksum files should have the correct format.


Please check the release and cast your votes, the vote will be open 
for at least 72 hours:


[ ] +1 Approve the release
[ ] -1 Veto the release (please provide specific comments)

Greetings, Marcel

Re: [DISCUSS] Move ServiceMix Kernel into Felix as a subproject

[Freeman Fang]

+1 for this idea.
Freeman

Guillaume Nodet wrote:

During ApacheCon last week, there has been some discussions around
moving ServiceMix Kernel as a subproject of Felix.
ServiceMix Kernel is a packaged distribution of Felix designed for
server side applications (see http://servicemix.apache.org/kernel/ for
more informations).

I think this would be beneficial for this project as it would enable
to build a much bigger community around it, increase the visibility
and the awareness around it. Of course, it would need a new name, but
that's another problem.
Another area that could be included in this move is the ServiceMix
specs (OSGi enhanced versions of Java EE specifications from Geronimo)
and ServiceMix bundles (we've released a bunch of bundles already, see
http://servicemix.apache.org/smx4/bundles-repository.html).

I'd like to have feedback from both communities (and any other
interested parties) to gauge the interest in such a move.

  

[jira] Resolved: (FELIX-973) FilterImpl from Felix Framework does not support none LDAP operators

[Richard S. Hall (JIRA)]

 [ 
https://issues.apache.org/jira/browse/FELIX-973?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Richard S. Hall resolved FELIX-973.
---

Resolution: Fixed

Ok, I applied this. Please close if you are satisfied and thanks a lot!

> FilterImpl from Felix Framework does not support none LDAP operators
> 
>
> Key: FELIX-973
> URL: https://issues.apache.org/jira/browse/FELIX-973
> Project: Felix
>  Issue Type: Bug
>  Components: Bundle Repository (OBR)
>Affects Versions: bundlerepository-1.2.1
>Reporter: Kristian Koehler
>Assignee: Richard S. Hall
> Fix For: bundlerepository-1.4.0
>
> Attachments: filter.patch, filter.patch, new_patch.txt, patch.txt
>
>
> Hi
> as discussed on the user mailing list 
> (http://www.mail-archive.com/us...@felix.apache.org/msg03402.html) the 
> framework doesn't support none standard LDAP operators (see also the RFC-0112 
> Bundle Repository). 
> The filter impl throws an exception while parsing a repository file 
> containing filters with this syntax.
> Kristian
> sample stack trace
> --- 8< ---
> ERROR: Error parsing repository metadata
> org.osgi.framework.InvalidSyntaxException: expected ~=|>=|<=
> at org.apache.felix.framework.FilterImpl.(FilterImpl.java:81)
> at 
> org.apache.felix.framework.BundleContextImpl.createFilter(BundleContextImpl.java:102)
> at 
> org.apache.felix.bundlerepository.RequirementImpl.setFilter(RequirementImpl.java:57)
> at sun.reflect.GeneratedMethodAccessor11.invoke(Unknown Source)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at 
> org.apache.felix.bundlerepository.metadataparser.XmlCommonHandler.startElement(XmlCommonHandler.java:490)
> at 
> org.apache.felix.bundlerepository.metadataparser.kxmlsax.KXml2SAXParser.parseXML(KXml2SAXParser.java:67)
> at 
> org.apache.felix.bundlerepository.RepositoryImpl.parseRepositoryFile(RepositoryImpl.java:256)
> at 
> org.apache.felix.bundlerepository.RepositoryImpl.access$000(RepositoryImpl.java:44)
> at 
> org.apache.felix.bundlerepository.RepositoryImpl$1.run(RepositoryImpl.java:75)
> at java.security.AccessController.doPrivileged(Native Method)
> at 
> org.apache.felix.bundlerepository.RepositoryImpl.(RepositoryImpl.java:71)
> at 
> org.apache.felix.bundlerepository.RepositoryImpl.(RepositoryImpl.java:60)
> at 
> org.apache.felix.bundlerepository.RepositoryAdminImpl.initialize(RepositoryAdminImpl.java:206)
> at 
> org.apache.felix.bundlerepository.RepositoryAdminImpl.discoverResources(RepositoryAdminImpl.java:126)
> at 
> org.apache.felix.bundlerepository.ObrCommandImpl.list(ObrCommandImpl.java:210)
> at 
> org.apache.felix.bundlerepository.ObrCommandImpl.execute(ObrCommandImpl.java:104)
> at 
> org.apache.felix.shell.impl.Activator$ShellServiceImpl.executeCommand(Activator.java:276)
> at 
> org.apache.felix.shell.tui.Activator$ShellTuiRunnable.run(Activator.java:167)
> at java.lang.Thread.run(Thread.java:619)
> WARNING: RepositoryAdminImpl: Exception creating repository 
> file:/home/kkoehler/repository.xml. Repository is skipped.
> java.lang.reflect.InvocationTargetException
> at sun.reflect.GeneratedMethodAccessor11.invoke(Unknown Source)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at 
> org.apache.felix.bundlerepository.metadataparser.XmlCommonHandler.startElement(XmlCommonHandler.java:490)
> at 
> org.apache.felix.bundlerepository.metadataparser.kxmlsax.KXml2SAXParser.parseXML(KXml2SAXParser.java:67)
> at 
> org.apache.felix.bundlerepository.RepositoryImpl.parseRepositoryFile(RepositoryImpl.java:256)
> at 
> org.apache.felix.bundlerepository.RepositoryImpl.access$000(RepositoryImpl.java:44)
> at 
> org.apache.felix.bundlerepository.RepositoryImpl$1.run(RepositoryImpl.java:75)
> at java.security.AccessController.doPrivileged(Native Method)
> at 
> org.apache.felix.bundlerepository.RepositoryImpl.(RepositoryImpl.java:71)
> at 
> org.apache.felix.bundlerepository.RepositoryImpl.(RepositoryImpl.java:60)
> at 
> org.apache.felix.bundlerepository.RepositoryAdminImpl.initialize(RepositoryAdminImpl.java:206)
> at 
> org.apache.felix.bundlerepository.RepositoryAdminImpl.discoverResources(RepositoryAdminImpl.java:126)
> at 
> org.apache.felix.bundlerepository.ObrCommandImpl.list(ObrCommandImpl.java:210)
> at 
> org.apache.felix.bundlerepository.ObrCommandImpl.execute(ObrCommandImpl.java:104)
> at 
> org.apache.felix.shell.impl.Activator$ShellServiceImpl.executeCommand(Activator.java:276)
> at 
> org.apache.felix.shell.tui.A

[jira] Updated: (FELIX-973) FilterImpl from Felix Framework does not support none LDAP operators

[Richard S. Hall (JIRA)]

 [ 
https://issues.apache.org/jira/browse/FELIX-973?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Richard S. Hall updated FELIX-973:
--

Fix Version/s: bundlerepository-1.4.0
 Assignee: Richard S. Hall

> FilterImpl from Felix Framework does not support none LDAP operators
> 
>
> Key: FELIX-973
> URL: https://issues.apache.org/jira/browse/FELIX-973
> Project: Felix
>  Issue Type: Bug
>  Components: Bundle Repository (OBR)
>Affects Versions: bundlerepository-1.2.1
>Reporter: Kristian Koehler
>Assignee: Richard S. Hall
> Fix For: bundlerepository-1.4.0
>
> Attachments: filter.patch, filter.patch, new_patch.txt, patch.txt
>
>
> Hi
> as discussed on the user mailing list 
> (http://www.mail-archive.com/us...@felix.apache.org/msg03402.html) the 
> framework doesn't support none standard LDAP operators (see also the RFC-0112 
> Bundle Repository). 
> The filter impl throws an exception while parsing a repository file 
> containing filters with this syntax.
> Kristian
> sample stack trace
> --- 8< ---
> ERROR: Error parsing repository metadata
> org.osgi.framework.InvalidSyntaxException: expected ~=|>=|<=
> at org.apache.felix.framework.FilterImpl.(FilterImpl.java:81)
> at 
> org.apache.felix.framework.BundleContextImpl.createFilter(BundleContextImpl.java:102)
> at 
> org.apache.felix.bundlerepository.RequirementImpl.setFilter(RequirementImpl.java:57)
> at sun.reflect.GeneratedMethodAccessor11.invoke(Unknown Source)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at 
> org.apache.felix.bundlerepository.metadataparser.XmlCommonHandler.startElement(XmlCommonHandler.java:490)
> at 
> org.apache.felix.bundlerepository.metadataparser.kxmlsax.KXml2SAXParser.parseXML(KXml2SAXParser.java:67)
> at 
> org.apache.felix.bundlerepository.RepositoryImpl.parseRepositoryFile(RepositoryImpl.java:256)
> at 
> org.apache.felix.bundlerepository.RepositoryImpl.access$000(RepositoryImpl.java:44)
> at 
> org.apache.felix.bundlerepository.RepositoryImpl$1.run(RepositoryImpl.java:75)
> at java.security.AccessController.doPrivileged(Native Method)
> at 
> org.apache.felix.bundlerepository.RepositoryImpl.(RepositoryImpl.java:71)
> at 
> org.apache.felix.bundlerepository.RepositoryImpl.(RepositoryImpl.java:60)
> at 
> org.apache.felix.bundlerepository.RepositoryAdminImpl.initialize(RepositoryAdminImpl.java:206)
> at 
> org.apache.felix.bundlerepository.RepositoryAdminImpl.discoverResources(RepositoryAdminImpl.java:126)
> at 
> org.apache.felix.bundlerepository.ObrCommandImpl.list(ObrCommandImpl.java:210)
> at 
> org.apache.felix.bundlerepository.ObrCommandImpl.execute(ObrCommandImpl.java:104)
> at 
> org.apache.felix.shell.impl.Activator$ShellServiceImpl.executeCommand(Activator.java:276)
> at 
> org.apache.felix.shell.tui.Activator$ShellTuiRunnable.run(Activator.java:167)
> at java.lang.Thread.run(Thread.java:619)
> WARNING: RepositoryAdminImpl: Exception creating repository 
> file:/home/kkoehler/repository.xml. Repository is skipped.
> java.lang.reflect.InvocationTargetException
> at sun.reflect.GeneratedMethodAccessor11.invoke(Unknown Source)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at 
> org.apache.felix.bundlerepository.metadataparser.XmlCommonHandler.startElement(XmlCommonHandler.java:490)
> at 
> org.apache.felix.bundlerepository.metadataparser.kxmlsax.KXml2SAXParser.parseXML(KXml2SAXParser.java:67)
> at 
> org.apache.felix.bundlerepository.RepositoryImpl.parseRepositoryFile(RepositoryImpl.java:256)
> at 
> org.apache.felix.bundlerepository.RepositoryImpl.access$000(RepositoryImpl.java:44)
> at 
> org.apache.felix.bundlerepository.RepositoryImpl$1.run(RepositoryImpl.java:75)
> at java.security.AccessController.doPrivileged(Native Method)
> at 
> org.apache.felix.bundlerepository.RepositoryImpl.(RepositoryImpl.java:71)
> at 
> org.apache.felix.bundlerepository.RepositoryImpl.(RepositoryImpl.java:60)
> at 
> org.apache.felix.bundlerepository.RepositoryAdminImpl.initialize(RepositoryAdminImpl.java:206)
> at 
> org.apache.felix.bundlerepository.RepositoryAdminImpl.discoverResources(RepositoryAdminImpl.java:126)
> at 
> org.apache.felix.bundlerepository.ObrCommandImpl.list(ObrCommandImpl.java:210)
> at 
> org.apache.felix.bundlerepository.ObrCommandImpl.execute(ObrCommandImpl.java:104)
> at 
> org.apache.felix.shell.impl.Activator$ShellServiceImpl.executeCommand(Activator.java:276)
> at 
> org.apache.felix.shell.tui.Activator$ShellTuiRun

Re: [DISCUSS] Move ServiceMix Kernel into Felix as a subproject

[Robert Burrell Donkin]

On Mon, Mar 30, 2009 at 5:23 PM, James Strachan
 wrote:
> If the Felix folks are happy I see it as a win-win really. This could
> be a good way to help build the ServiceMix Kernel community - which is
> mostly to do with OSGi and little to do with ESBs and JBI and so forth
> - as well as building a stronger community of folks from both
> ServiceMix and Felix. Am sure parts of ServiceMix kernel could be used
> by Felix folks and vice versa.

there's a ton of interest in using the ServiceMix kernel over in James

this would have the pleasent side effect of making available fully
OSGi tooled mail protocol services (POP3, SMTP, IMAP, NNTP, FetchPop)

- robert

[VOTE] Release of the dependency manager 2.0.1

[Marcel Offermans]

Hello all,

I'm opening a vote for the 2.0.1 release candidate of the dependency  
manager and its optional shell command bundle. I've compiled  
everything and put it up for testing and checking here:


http://people.apache.org/~marrs/dependencymanager-2.0.1/

The KEYS file for verifying the signature is also in this directory  
and the checksum files should have the correct format.


Please check the release and cast your votes, the vote will be open  
for at least 72 hours:


[ ] +1 Approve the release
[ ] -1 Veto the release (please provide specific comments)

Greetings, Marcel

Re: [DISCUSS] Move ServiceMix Kernel into Felix as a subproject

[Gert Vanthienen]

Yes, it sounds like an excellent idea to me as well.  Let's do it...

Regards,

Gert Vanthienen

Open Source SOA: http://fusesource.com
Blog: http://gertvanthienen.blogspot.com/



2009/3/30 Karl Pauls :
> Sounds good to me!
>
> regards,
>
> Karl
>
> On Mon, Mar 30, 2009 at 7:44 PM, Richard S. Hall  wrote:
>> I think this sounds interesting. If it helps server-based projects move to
>> OSGi, then I think it is a good thing.
>>
>> -> richard
>>
>> On 3/30/09 12:03 PM, Guillaume Nodet wrote:
>>>
>>> During ApacheCon last week, there has been some discussions around
>>> moving ServiceMix Kernel as a subproject of Felix.
>>> ServiceMix Kernel is a packaged distribution of Felix designed for
>>> server side applications (see http://servicemix.apache.org/kernel/ for
>>> more informations).
>>>
>>> I think this would be beneficial for this project as it would enable
>>> to build a much bigger community around it, increase the visibility
>>> and the awareness around it. Of course, it would need a new name, but
>>> that's another problem.
>>> Another area that could be included in this move is the ServiceMix
>>> specs (OSGi enhanced versions of Java EE specifications from Geronimo)
>>> and ServiceMix bundles (we've released a bunch of bundles already, see
>>> http://servicemix.apache.org/smx4/bundles-repository.html).
>>>
>>> I'd like to have feedback from both communities (and any other
>>> interested parties) to gauge the interest in such a move.
>>>
>>>
>>
>
>
>
> --
> Karl Pauls
> karlpa...@gmail.com
>

Re: [Vote] Release Felix Log Service 1.0.0

[Marcel Offermans]

+1

Re: [DISCUSS] Move ServiceMix Kernel into Felix as a subproject

[Jean-Baptiste Onofré]

I think that moving SMX Kernel as a subproject of Felix is a good idea from
the two points of view :
- increase the community around Kernel and provide a great OSGi framework by
  gathering both Felix and Kernel
- for the ServiceMix community, we can focus on the first purpose of 
  ServiceMix : provide a great ESB. So we can focus on the ServiceMix NMR,
  bundles and components.

Regards
JB

On Monday 30 March 2009 - 18:03, Guillaume Nodet wrote:
> During ApacheCon last week, there has been some discussions around
> moving ServiceMix Kernel as a subproject of Felix.
> ServiceMix Kernel is a packaged distribution of Felix designed for
> server side applications (see http://servicemix.apache.org/kernel/ for
> more informations).
> 
> I think this would be beneficial for this project as it would enable
> to build a much bigger community around it, increase the visibility
> and the awareness around it. Of course, it would need a new name, but
> that's another problem.
> Another area that could be included in this move is the ServiceMix
> specs (OSGi enhanced versions of Java EE specifications from Geronimo)
> and ServiceMix bundles (we've released a bunch of bundles already, see
> http://servicemix.apache.org/smx4/bundles-repository.html).
> 
> I'd like to have feedback from both communities (and any other
> interested parties) to gauge the interest in such a move.
> 
> -- 
> Cheers,
> Guillaume Nodet
> 
> Blog: http://gnodet.blogspot.com/
> 
> Open Source SOA
> http://fusesource.com

-- 
Jean-Baptiste Onofré
-
 HomePage
http://www.nanthrax.net
-
 Contacts
jbono...@apache.org
j...@nanthrax.net
-
 OpenSource
BuildProcess/AutoDeploy
http://buildprocess.sourceforge.net
Apache ServiceMix
http://servicemix.apache.org
---
PGP : 17D4F086

Re: [DISCUSS] Move ServiceMix Kernel into Felix as a subproject

[Stuart McCulloch]

2009/3/30 Guillaume Nodet 

> On Mon, Mar 30, 2009 at 19:49, Jamie G.  wrote:
> > I agree, this sounds like a win-win for all involved (as per James /
> > Guillaume's post).
> >
> > As a name submission I'd like Carafe (pronounced "karaf"). A carafe is
> > a small container used for serving wine and other drinks
> > (http://en.wikipedia.org/wiki/Carafe). In similarity to the name the
> > Kernel allows applications to be more easily handled, and improves
> > their characteristics (much like a bottle of wine left to breath in a
> > decanter) :)
>
> What about Karaf to lower the google hit counts and still preserve the
> nice semantic ...
>  ... and eventually fill the "K" hole of the Apache TLP names list (in
> case it ever becomes a TLP later).
>

+1 for the name, and the idea of moving it over to Felix :)


> >
> > Jamie
> >
> > On Mon, Mar 30, 2009 at 2:46 PM, James Strachan
> >  wrote:
> >> Agreed. If this does happen - we'll need a cool name (which doesn't
> >> have ServiceMix in the title :).
> >>
> >> Anyone any suggestions? Naming is super hard!
> >>
> >> 2009/3/30 Chris Custine :
> >>> I think this would be a great move, and like Guillaume said, would
> increase
> >>> the visibility substantially.  I think a few Apache projects have
> started
> >>> tracking ServiceMix Kernel and might be using it as the basis for their
> OSGi
> >>> based projects.  However, when most people see the ServiceMix moniker,
> they
> >>> don't realize that it is really a generic OSGi base application.
> >>>
> >>> So I am +1 on this idea.
> >>>
> >>> Chris
> >>>
> >>> --
> >>> Chris Custine
> >>> FUSESource :: http://fusesource.com
> >>> My Blog :: http://blog.organicelement.com
> >>> Apache ServiceMix :: http://servicemix.apache.org
> >>> Apache Directory Server :: http://directory.apache.org
> >>>
> >>>
> >>> On Mon, Mar 30, 2009 at 10:03 AM, Guillaume Nodet 
> wrote:
> >>>
>  During ApacheCon last week, there has been some discussions around
>  moving ServiceMix Kernel as a subproject of Felix.
>  ServiceMix Kernel is a packaged distribution of Felix designed for
>  server side applications (see http://servicemix.apache.org/kernel/for
>  more informations).
> 
>  I think this would be beneficial for this project as it would enable
>  to build a much bigger community around it, increase the visibility
>  and the awareness around it. Of course, it would need a new name, but
>  that's another problem.
>  Another area that could be included in this move is the ServiceMix
>  specs (OSGi enhanced versions of Java EE specifications from Geronimo)
>  and ServiceMix bundles (we've released a bunch of bundles already, see
>  http://servicemix.apache.org/smx4/bundles-repository.html).
> 
>  I'd like to have feedback from both communities (and any other
>  interested parties) to gauge the interest in such a move.
> 
>  --
>  Cheers,
>  Guillaume Nodet
>  
>  Blog: http://gnodet.blogspot.com/
>  
>  Open Source SOA
>  http://fusesource.com
> 
> >>>
> >>
> >>
> >>
> >> --
> >> James
> >> ---
> >> http://macstrac.blogspot.com/
> >>
> >> Open Source Integration
> >> http://fusesource.com/
> >>
> >
>
> --
> Cheers,
> Guillaume Nodet
> 
> Blog: http://gnodet.blogspot.com/
> 
> Open Source SOA
> http://fusesource.com
>

-- 
Cheers, Stuart

Re: [DISCUSS] Move ServiceMix Kernel into Felix as a subproject

[Mike McGrady]

Carafe is a container whereas OSGi is an organizer.

How about Obama?  :-) Or, Diorganos?


On Mar 30, 2009, at 12:15 PM, Rob Davies wrote:


like the name!
On 30 Mar 2009, at 18:49, Jamie G. wrote:


I agree, this sounds like a win-win for all involved (as per James /
Guillaume's post).

As a name submission I'd like Carafe (pronounced "karaf"). A carafe  
is

a small container used for serving wine and other drinks
(http://en.wikipedia.org/wiki/Carafe). In similarity to the name the
Kernel allows applications to be more easily handled, and improves
their characteristics (much like a bottle of wine left to breath in a
decanter) :)

Jamie


Mike McGrady
Senior Engineer
Topia Technology, Inc.
1.253.720.3365
mmcgr...@topiatechnology.com

Re: [DISCUSS] Move ServiceMix Kernel into Felix as a subproject

[Karl Pauls]

Sounds good to me!

regards,

Karl

On Mon, Mar 30, 2009 at 7:44 PM, Richard S. Hall  wrote:
> I think this sounds interesting. If it helps server-based projects move to
> OSGi, then I think it is a good thing.
>
> -> richard
>
> On 3/30/09 12:03 PM, Guillaume Nodet wrote:
>>
>> During ApacheCon last week, there has been some discussions around
>> moving ServiceMix Kernel as a subproject of Felix.
>> ServiceMix Kernel is a packaged distribution of Felix designed for
>> server side applications (see http://servicemix.apache.org/kernel/ for
>> more informations).
>>
>> I think this would be beneficial for this project as it would enable
>> to build a much bigger community around it, increase the visibility
>> and the awareness around it. Of course, it would need a new name, but
>> that's another problem.
>> Another area that could be included in this move is the ServiceMix
>> specs (OSGi enhanced versions of Java EE specifications from Geronimo)
>> and ServiceMix bundles (we've released a bunch of bundles already, see
>> http://servicemix.apache.org/smx4/bundles-repository.html).
>>
>> I'd like to have feedback from both communities (and any other
>> interested parties) to gauge the interest in such a move.
>>
>>
>



-- 
Karl Pauls
karlpa...@gmail.com

Re: [DISCUSS] Move ServiceMix Kernel into Felix as a subproject

[Guillaume Nodet]

On Mon, Mar 30, 2009 at 19:49, Jamie G.  wrote:
> I agree, this sounds like a win-win for all involved (as per James /
> Guillaume's post).
>
> As a name submission I'd like Carafe (pronounced "karaf"). A carafe is
> a small container used for serving wine and other drinks
> (http://en.wikipedia.org/wiki/Carafe). In similarity to the name the
> Kernel allows applications to be more easily handled, and improves
> their characteristics (much like a bottle of wine left to breath in a
> decanter) :)

What about Karaf to lower the google hit counts and still preserve the
nice semantic ...
 ... and eventually fill the "K" hole of the Apache TLP names list (in
case it ever becomes a TLP later).

>
> Jamie
>
> On Mon, Mar 30, 2009 at 2:46 PM, James Strachan
>  wrote:
>> Agreed. If this does happen - we'll need a cool name (which doesn't
>> have ServiceMix in the title :).
>>
>> Anyone any suggestions? Naming is super hard!
>>
>> 2009/3/30 Chris Custine :
>>> I think this would be a great move, and like Guillaume said, would increase
>>> the visibility substantially.  I think a few Apache projects have started
>>> tracking ServiceMix Kernel and might be using it as the basis for their OSGi
>>> based projects.  However, when most people see the ServiceMix moniker, they
>>> don't realize that it is really a generic OSGi base application.
>>>
>>> So I am +1 on this idea.
>>>
>>> Chris
>>>
>>> --
>>> Chris Custine
>>> FUSESource :: http://fusesource.com
>>> My Blog :: http://blog.organicelement.com
>>> Apache ServiceMix :: http://servicemix.apache.org
>>> Apache Directory Server :: http://directory.apache.org
>>>
>>>
>>> On Mon, Mar 30, 2009 at 10:03 AM, Guillaume Nodet  wrote:
>>>
 During ApacheCon last week, there has been some discussions around
 moving ServiceMix Kernel as a subproject of Felix.
 ServiceMix Kernel is a packaged distribution of Felix designed for
 server side applications (see http://servicemix.apache.org/kernel/ for
 more informations).

 I think this would be beneficial for this project as it would enable
 to build a much bigger community around it, increase the visibility
 and the awareness around it. Of course, it would need a new name, but
 that's another problem.
 Another area that could be included in this move is the ServiceMix
 specs (OSGi enhanced versions of Java EE specifications from Geronimo)
 and ServiceMix bundles (we've released a bunch of bundles already, see
 http://servicemix.apache.org/smx4/bundles-repository.html).

 I'd like to have feedback from both communities (and any other
 interested parties) to gauge the interest in such a move.

 --
 Cheers,
 Guillaume Nodet
 
 Blog: http://gnodet.blogspot.com/
 
 Open Source SOA
 http://fusesource.com

>>>
>>
>>
>>
>> --
>> James
>> ---
>> http://macstrac.blogspot.com/
>>
>> Open Source Integration
>> http://fusesource.com/
>>
>



-- 
Cheers,
Guillaume Nodet

Blog: http://gnodet.blogspot.com/

Open Source SOA
http://fusesource.com

Re: [DISCUSS] Move ServiceMix Kernel into Felix as a subproject

[Rob Davies]

like the name!
On 30 Mar 2009, at 18:49, Jamie G. wrote:


I agree, this sounds like a win-win for all involved (as per James /
Guillaume's post).

As a name submission I'd like Carafe (pronounced "karaf"). A carafe is
a small container used for serving wine and other drinks
(http://en.wikipedia.org/wiki/Carafe). In similarity to the name the
Kernel allows applications to be more easily handled, and improves
their characteristics (much like a bottle of wine left to breath in a
decanter) :)

Jamie

On Mon, Mar 30, 2009 at 2:46 PM, James Strachan
 wrote:

Agreed. If this does happen - we'll need a cool name (which doesn't
have ServiceMix in the title :).

Anyone any suggestions? Naming is super hard!

2009/3/30 Chris Custine :
I think this would be a great move, and like Guillaume said, would  
increase
the visibility substantially.  I think a few Apache projects have  
started
tracking ServiceMix Kernel and might be using it as the basis for  
their OSGi
based projects.  However, when most people see the ServiceMix  
moniker, they

don't realize that it is really a generic OSGi base application.

So I am +1 on this idea.

Chris

--
Chris Custine
FUSESource :: http://fusesource.com
My Blog :: http://blog.organicelement.com
Apache ServiceMix :: http://servicemix.apache.org
Apache Directory Server :: http://directory.apache.org


On Mon, Mar 30, 2009 at 10:03 AM, Guillaume Nodet  
 wrote:



During ApacheCon last week, there has been some discussions around
moving ServiceMix Kernel as a subproject of Felix.
ServiceMix Kernel is a packaged distribution of Felix designed for
server side applications (see http://servicemix.apache.org/ 
kernel/ for

more informations).

I think this would be beneficial for this project as it would  
enable

to build a much bigger community around it, increase the visibility
and the awareness around it. Of course, it would need a new name,  
but

that's another problem.
Another area that could be included in this move is the ServiceMix
specs (OSGi enhanced versions of Java EE specifications from  
Geronimo)
and ServiceMix bundles (we've released a bunch of bundles  
already, see

http://servicemix.apache.org/smx4/bundles-repository.html).

I'd like to have feedback from both communities (and any other
interested parties) to gauge the interest in such a move.

--
Cheers,
Guillaume Nodet

Blog: http://gnodet.blogspot.com/

Open Source SOA
http://fusesource.com







--
James
---
http://macstrac.blogspot.com/

Open Source Integration
http://fusesource.com/

Re: [DISCUSS] Move ServiceMix Kernel into Felix as a subproject

[James Strachan]

Agreed. If this does happen - we'll need a cool name (which doesn't
have ServiceMix in the title :).

Anyone any suggestions? Naming is super hard!

2009/3/30 Chris Custine :
> I think this would be a great move, and like Guillaume said, would increase
> the visibility substantially.  I think a few Apache projects have started
> tracking ServiceMix Kernel and might be using it as the basis for their OSGi
> based projects.  However, when most people see the ServiceMix moniker, they
> don't realize that it is really a generic OSGi base application.
>
> So I am +1 on this idea.
>
> Chris
>
> --
> Chris Custine
> FUSESource :: http://fusesource.com
> My Blog :: http://blog.organicelement.com
> Apache ServiceMix :: http://servicemix.apache.org
> Apache Directory Server :: http://directory.apache.org
>
>
> On Mon, Mar 30, 2009 at 10:03 AM, Guillaume Nodet  wrote:
>
>> During ApacheCon last week, there has been some discussions around
>> moving ServiceMix Kernel as a subproject of Felix.
>> ServiceMix Kernel is a packaged distribution of Felix designed for
>> server side applications (see http://servicemix.apache.org/kernel/ for
>> more informations).
>>
>> I think this would be beneficial for this project as it would enable
>> to build a much bigger community around it, increase the visibility
>> and the awareness around it. Of course, it would need a new name, but
>> that's another problem.
>> Another area that could be included in this move is the ServiceMix
>> specs (OSGi enhanced versions of Java EE specifications from Geronimo)
>> and ServiceMix bundles (we've released a bunch of bundles already, see
>> http://servicemix.apache.org/smx4/bundles-repository.html).
>>
>> I'd like to have feedback from both communities (and any other
>> interested parties) to gauge the interest in such a move.
>>
>> --
>> Cheers,
>> Guillaume Nodet
>> 
>> Blog: http://gnodet.blogspot.com/
>> 
>> Open Source SOA
>> http://fusesource.com
>>
>



-- 
James
---
http://macstrac.blogspot.com/

Open Source Integration
http://fusesource.com/

Re: [DISCUSS] Move ServiceMix Kernel into Felix as a subproject

[James Strachan]

2009/3/30 Alex Karasulu :
> On Mon, Mar 30, 2009 at 6:03 PM, Guillaume Nodet  wrote:
>
>> During ApacheCon last week, there has been some discussions around
>> moving ServiceMix Kernel as a subproject of Felix.
>> ServiceMix Kernel is a packaged distribution of Felix designed for
>> server side applications (see http://servicemix.apache.org/kernel/ for
>> more informations).
>>
>> I think this would be beneficial for this project as it would enable
>> to build a much bigger community around it, increase the visibility
>> and the awareness around it. Of course, it would need a new name, but
>> that's another problem.
>> Another area that could be included in this move is the ServiceMix
>> specs (OSGi enhanced versions of Java EE specifications from Geronimo)
>> and ServiceMix bundles (we've released a bunch of bundles already, see
>> http://servicemix.apache.org/smx4/bundles-repository.html).
>>
>> I'd like to have feedback from both communities (and any other
>> interested parties) to gauge the interest in such a move.
>
>
> We are very interested in the SM Kernel at several projects.   This in
> concert with JUnit OSGi will completely fullfil our dreams.  I had been
> playing around with the SM Kernel to take ApacheDS and other servers to OSGi
> and I was impressed.  Heck just the SSH based console with application
> commands and tab completion are cool in themselves.  Count me in for any
> support or help needed in getting this project over to the Felix community.

Awesome thanks Alex!

-- 
James
---
http://macstrac.blogspot.com/

Open Source Integration
http://fusesource.com/

Re: [DISCUSS] Move ServiceMix Kernel into Felix as a subproject

[James Strachan]

If the Felix folks are happy I see it as a win-win really. This could
be a good way to help build the ServiceMix Kernel community - which is
mostly to do with OSGi and little to do with ESBs and JBI and so forth
- as well as building a stronger community of folks from both
ServiceMix and Felix. Am sure parts of ServiceMix kernel could be used
by Felix folks and vice versa.

2009/3/30 Guillaume Nodet :
> During ApacheCon last week, there has been some discussions around
> moving ServiceMix Kernel as a subproject of Felix.
> ServiceMix Kernel is a packaged distribution of Felix designed for
> server side applications (see http://servicemix.apache.org/kernel/ for
> more informations).
>
> I think this would be beneficial for this project as it would enable
> to build a much bigger community around it, increase the visibility
> and the awareness around it. Of course, it would need a new name, but
> that's another problem.
> Another area that could be included in this move is the ServiceMix
> specs (OSGi enhanced versions of Java EE specifications from Geronimo)
> and ServiceMix bundles (we've released a bunch of bundles already, see
> http://servicemix.apache.org/smx4/bundles-repository.html).
>
> I'd like to have feedback from both communities (and any other
> interested parties) to gauge the interest in such a move.
>
> --
> Cheers,
> Guillaume Nodet
> 
> Blog: http://gnodet.blogspot.com/
> 
> Open Source SOA
> http://fusesource.com
>



-- 
James
---
http://macstrac.blogspot.com/

Open Source Integration
http://fusesource.com/

Re: [DISCUSS] Move ServiceMix Kernel into Felix as a subproject

[Richard S. Hall]

I think this sounds interesting. If it helps server-based projects move 
to OSGi, then I think it is a good thing.


-> richard

On 3/30/09 12:03 PM, Guillaume Nodet wrote:

During ApacheCon last week, there has been some discussions around
moving ServiceMix Kernel as a subproject of Felix.
ServiceMix Kernel is a packaged distribution of Felix designed for
server side applications (see http://servicemix.apache.org/kernel/ for
more informations).

I think this would be beneficial for this project as it would enable
to build a much bigger community around it, increase the visibility
and the awareness around it. Of course, it would need a new name, but
that's another problem.
Another area that could be included in this move is the ServiceMix
specs (OSGi enhanced versions of Java EE specifications from Geronimo)
and ServiceMix bundles (we've released a bunch of bundles already, see
http://servicemix.apache.org/smx4/bundles-repository.html).

I'd like to have feedback from both communities (and any other
interested parties) to gauge the interest in such a move.

   

Re: FELIX-1011 and FELIX-1012

[Stuart McCulloch]

2009/3/30 Richard S. Hall 

> Interesting. Good work.
>
> Did both of these come from ServiceMix, meaning they were developed at
> Apache? Just wondering with respect to IP.
>
> Both will become Felix subprojects it looks like. Are they ready for
> release "as is" or is more work needed?
>
> Thanks for the contribution.
>

yep +1 for contributing these bundles, looking forward to seeing them
released once the specs are finalized :)

-> richard
>
> On 3/30/09 11:41 AM, Guillaume Nodet wrote:
>
>> I have attached to the above issues two patches which consist of
>> implementations of RFC-0142 (JNDI integration) and RFC-98
>> (Transactions in OSGi).
>> I have refactored the implementations in ServiceMix NMR so that they
>> do not have any dependenies on Spring-DM and become standalone
>> bundles.
>> Feedback welcome!
>>
>
-- 
Cheers, Stuart

[jira] Commented: (FELIX-992) Allow DM to inject service properties using a Map

[Pierre De Rop (JIRA)]

[ 
https://issues.apache.org/jira/browse/FELIX-992?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12693870#action_12693870
 ] 

Pierre De Rop commented on FELIX-992:
-

I tested and it works fine. Thanks Marcel !

> Allow DM to inject service properties using a Map
> -
>
> Key: FELIX-992
> URL: https://issues.apache.org/jira/browse/FELIX-992
> Project: Felix
>  Issue Type: Improvement
>  Components: Dependency Manager
>Affects Versions: dependencymanager-2.0.0
> Environment: linux
>Reporter: Pierre De Rop
>Assignee: Marcel Offermans
>Priority: Minor
> Attachments: ServiceDependency.java
>
>
> We would like to improve DependencyManager in the following way:
> Currently, when injecting dependencies with callbacks, DM searches for method 
> signatures in this order:
>  1. ServiceReference, TheService
>  2. ServiceReference, Object
>  3. ServiceReference
>  4. TheService
>  5. Object
>  6. (void)
> I propose to add the following signature, which provides service properties 
> wrapped behing a basic Map:
>  7. (Map, TheService)
> The purpose of this modification is to be able to inject service properties 
> without coupling my POJOs
> with the OSGi API (that is: ServiceReference class, and 
> ServiceReference.getProperty method).
> I have attached to this issue a proposed patch, which concerns the 
> ServiceDependency.java file.
> Marcel, what do you think ?
> /pierre

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: [DISCUSS] Move ServiceMix Kernel into Felix as a subproject

[Jamie G.]

I agree, this sounds like a win-win for all involved (as per James /
Guillaume's post).

As a name submission I'd like Carafe (pronounced "karaf"). A carafe is
a small container used for serving wine and other drinks
(http://en.wikipedia.org/wiki/Carafe). In similarity to the name the
Kernel allows applications to be more easily handled, and improves
their characteristics (much like a bottle of wine left to breath in a
decanter) :)

Jamie

On Mon, Mar 30, 2009 at 2:46 PM, James Strachan
 wrote:
> Agreed. If this does happen - we'll need a cool name (which doesn't
> have ServiceMix in the title :).
>
> Anyone any suggestions? Naming is super hard!
>
> 2009/3/30 Chris Custine :
>> I think this would be a great move, and like Guillaume said, would increase
>> the visibility substantially.  I think a few Apache projects have started
>> tracking ServiceMix Kernel and might be using it as the basis for their OSGi
>> based projects.  However, when most people see the ServiceMix moniker, they
>> don't realize that it is really a generic OSGi base application.
>>
>> So I am +1 on this idea.
>>
>> Chris
>>
>> --
>> Chris Custine
>> FUSESource :: http://fusesource.com
>> My Blog :: http://blog.organicelement.com
>> Apache ServiceMix :: http://servicemix.apache.org
>> Apache Directory Server :: http://directory.apache.org
>>
>>
>> On Mon, Mar 30, 2009 at 10:03 AM, Guillaume Nodet  wrote:
>>
>>> During ApacheCon last week, there has been some discussions around
>>> moving ServiceMix Kernel as a subproject of Felix.
>>> ServiceMix Kernel is a packaged distribution of Felix designed for
>>> server side applications (see http://servicemix.apache.org/kernel/ for
>>> more informations).
>>>
>>> I think this would be beneficial for this project as it would enable
>>> to build a much bigger community around it, increase the visibility
>>> and the awareness around it. Of course, it would need a new name, but
>>> that's another problem.
>>> Another area that could be included in this move is the ServiceMix
>>> specs (OSGi enhanced versions of Java EE specifications from Geronimo)
>>> and ServiceMix bundles (we've released a bunch of bundles already, see
>>> http://servicemix.apache.org/smx4/bundles-repository.html).
>>>
>>> I'd like to have feedback from both communities (and any other
>>> interested parties) to gauge the interest in such a move.
>>>
>>> --
>>> Cheers,
>>> Guillaume Nodet
>>> 
>>> Blog: http://gnodet.blogspot.com/
>>> 
>>> Open Source SOA
>>> http://fusesource.com
>>>
>>
>
>
>
> --
> James
> ---
> http://macstrac.blogspot.com/
>
> Open Source Integration
> http://fusesource.com/
>

Re: [DISCUSS] Move ServiceMix Kernel into Felix as a subproject

[Alex Boisvert]

I also think it's a win-win (for the same reasons mentioned by
James/Guillaume)

alex


On Mon, Mar 30, 2009 at 9:23 AM, James Strachan wrote:

> If the Felix folks are happy I see it as a win-win really. This could
> be a good way to help build the ServiceMix Kernel community - which is
> mostly to do with OSGi and little to do with ESBs and JBI and so forth
> - as well as building a stronger community of folks from both
> ServiceMix and Felix. Am sure parts of ServiceMix kernel could be used
> by Felix folks and vice versa.
>
> 2009/3/30 Guillaume Nodet :
> > During ApacheCon last week, there has been some discussions around
> > moving ServiceMix Kernel as a subproject of Felix.
> > ServiceMix Kernel is a packaged distribution of Felix designed for
> > server side applications (see http://servicemix.apache.org/kernel/ for
> > more informations).
> >
> > I think this would be beneficial for this project as it would enable
> > to build a much bigger community around it, increase the visibility
> > and the awareness around it. Of course, it would need a new name, but
> > that's another problem.
> > Another area that could be included in this move is the ServiceMix
> > specs (OSGi enhanced versions of Java EE specifications from Geronimo)
> > and ServiceMix bundles (we've released a bunch of bundles already, see
> > http://servicemix.apache.org/smx4/bundles-repository.html).
> >
> > I'd like to have feedback from both communities (and any other
> > interested parties) to gauge the interest in such a move.
> >
> > --
> > Cheers,
> > Guillaume Nodet
> > 
> > Blog: http://gnodet.blogspot.com/
> > 
> > Open Source SOA
> > http://fusesource.com
> >
>
>
>
> --
> James
> ---
> http://macstrac.blogspot.com/
>
> Open Source Integration
> http://fusesource.com/
>

Re: [DISCUSS] Move ServiceMix Kernel into Felix as a subproject

[Chris Custine]

I think this would be a great move, and like Guillaume said, would increase
the visibility substantially.  I think a few Apache projects have started
tracking ServiceMix Kernel and might be using it as the basis for their OSGi
based projects.  However, when most people see the ServiceMix moniker, they
don't realize that it is really a generic OSGi base application.

So I am +1 on this idea.

Chris

--
Chris Custine
FUSESource :: http://fusesource.com
My Blog :: http://blog.organicelement.com
Apache ServiceMix :: http://servicemix.apache.org
Apache Directory Server :: http://directory.apache.org


On Mon, Mar 30, 2009 at 10:03 AM, Guillaume Nodet  wrote:

> During ApacheCon last week, there has been some discussions around
> moving ServiceMix Kernel as a subproject of Felix.
> ServiceMix Kernel is a packaged distribution of Felix designed for
> server side applications (see http://servicemix.apache.org/kernel/ for
> more informations).
>
> I think this would be beneficial for this project as it would enable
> to build a much bigger community around it, increase the visibility
> and the awareness around it. Of course, it would need a new name, but
> that's another problem.
> Another area that could be included in this move is the ServiceMix
> specs (OSGi enhanced versions of Java EE specifications from Geronimo)
> and ServiceMix bundles (we've released a bunch of bundles already, see
> http://servicemix.apache.org/smx4/bundles-repository.html).
>
> I'd like to have feedback from both communities (and any other
> interested parties) to gauge the interest in such a move.
>
> --
> Cheers,
> Guillaume Nodet
> 
> Blog: http://gnodet.blogspot.com/
> 
> Open Source SOA
> http://fusesource.com
>

Re: FELIX-1011 and FELIX-1012

[Clement Escoffier]

Hi,

I will look into it this week.

Thanks for the contributionS!

Regards,

Clement



On 30.03.2009, at 18:15, Guillaume Nodet wrote:

On Mon, Mar 30, 2009 at 17:56, Richard S. Hall  
 wrote:

Interesting. Good work.

Did both of these come from ServiceMix, meaning they were developed  
at

Apache? Just wondering with respect to IP.


I have developped both inside ServiceMix.
The original code is available at
 https://svn.apache.org/repos/asf/servicemix/smx4/nmr/trunk/naming/
 https://svn.apache.org/repos/asf/servicemix/smx4/nmr/trunk/transaction/
I've refactored both over the past days for this submision so there's
no IP issues.


Both will become Felix subprojects it looks like.


That was my thoughts too.


Are they ready for release "as is" or is more work needed?


The refactoring might have had some impacts, so I'll do more tests
this week on those.


Thanks for the contribution.


A pleasure :-)


-> richard

On 3/30/09 11:41 AM, Guillaume Nodet wrote:


I have attached to the above issues two patches which consist of
implementations of RFC-0142 (JNDI integration) and RFC-98
(Transactions in OSGi).
I have refactored the implementations in ServiceMix NMR so that they
do not have any dependenies on Spring-DM and become standalone
bundles.
Feedback welcome!








--
Cheers,
Guillaume Nodet

Blog: http://gnodet.blogspot.com/

Open Source SOA
http://fusesource.com

Re: [DISCUSS] Move ServiceMix Kernel into Felix as a subproject

[Alex Karasulu]

On Mon, Mar 30, 2009 at 6:03 PM, Guillaume Nodet  wrote:

> During ApacheCon last week, there has been some discussions around
> moving ServiceMix Kernel as a subproject of Felix.
> ServiceMix Kernel is a packaged distribution of Felix designed for
> server side applications (see http://servicemix.apache.org/kernel/ for
> more informations).
>
> I think this would be beneficial for this project as it would enable
> to build a much bigger community around it, increase the visibility
> and the awareness around it. Of course, it would need a new name, but
> that's another problem.
> Another area that could be included in this move is the ServiceMix
> specs (OSGi enhanced versions of Java EE specifications from Geronimo)
> and ServiceMix bundles (we've released a bunch of bundles already, see
> http://servicemix.apache.org/smx4/bundles-repository.html).
>
> I'd like to have feedback from both communities (and any other
> interested parties) to gauge the interest in such a move.


We are very interested in the SM Kernel at several projects.   This in
concert with JUnit OSGi will completely fullfil our dreams.  I had been
playing around with the SM Kernel to take ApacheDS and other servers to OSGi
and I was impressed.  Heck just the SSH based console with application
commands and tab completion are cool in themselves.  Count me in for any
support or help needed in getting this project over to the Felix community.

Thanks,
Alex

Re: FELIX-1011 and FELIX-1012

[Guillaume Nodet]

On Mon, Mar 30, 2009 at 17:56, Richard S. Hall  wrote:
> Interesting. Good work.
>
> Did both of these come from ServiceMix, meaning they were developed at
> Apache? Just wondering with respect to IP.

I have developped both inside ServiceMix.
The original code is available at
  https://svn.apache.org/repos/asf/servicemix/smx4/nmr/trunk/naming/
  https://svn.apache.org/repos/asf/servicemix/smx4/nmr/trunk/transaction/
I've refactored both over the past days for this submision so there's
no IP issues.

> Both will become Felix subprojects it looks like.

That was my thoughts too.

> Are they ready for release "as is" or is more work needed?

The refactoring might have had some impacts, so I'll do more tests
this week on those.

> Thanks for the contribution.

A pleasure :-)

> -> richard
>
> On 3/30/09 11:41 AM, Guillaume Nodet wrote:
>>
>> I have attached to the above issues two patches which consist of
>> implementations of RFC-0142 (JNDI integration) and RFC-98
>> (Transactions in OSGi).
>> I have refactored the implementations in ServiceMix NMR so that they
>> do not have any dependenies on Spring-DM and become standalone
>> bundles.
>> Feedback welcome!
>>
>>
>



-- 
Cheers,
Guillaume Nodet

Blog: http://gnodet.blogspot.com/

Open Source SOA
http://fusesource.com

[DISCUSS] Move ServiceMix Kernel into Felix as a subproject

[Guillaume Nodet]

During ApacheCon last week, there has been some discussions around
moving ServiceMix Kernel as a subproject of Felix.
ServiceMix Kernel is a packaged distribution of Felix designed for
server side applications (see http://servicemix.apache.org/kernel/ for
more informations).

I think this would be beneficial for this project as it would enable
to build a much bigger community around it, increase the visibility
and the awareness around it. Of course, it would need a new name, but
that's another problem.
Another area that could be included in this move is the ServiceMix
specs (OSGi enhanced versions of Java EE specifications from Geronimo)
and ServiceMix bundles (we've released a bunch of bundles already, see
http://servicemix.apache.org/smx4/bundles-repository.html).

I'd like to have feedback from both communities (and any other
interested parties) to gauge the interest in such a move.

-- 
Cheers,
Guillaume Nodet

Blog: http://gnodet.blogspot.com/

Open Source SOA
http://fusesource.com

Re: FELIX-1011 and FELIX-1012

[Richard S. Hall]

Interesting. Good work.

Did both of these come from ServiceMix, meaning they were developed at 
Apache? Just wondering with respect to IP.


Both will become Felix subprojects it looks like. Are they ready for 
release "as is" or is more work needed?


Thanks for the contribution.

-> richard

On 3/30/09 11:41 AM, Guillaume Nodet wrote:

I have attached to the above issues two patches which consist of
implementations of RFC-0142 (JNDI integration) and RFC-98
(Transactions in OSGi).
I have refactored the implementations in ServiceMix NMR so that they
do not have any dependenies on Spring-DM and become standalone
bundles.
Feedback welcome!

   

FELIX-1011 and FELIX-1012

[Guillaume Nodet]

I have attached to the above issues two patches which consist of
implementations of RFC-0142 (JNDI integration) and RFC-98
(Transactions in OSGi).
I have refactored the implementations in ServiceMix NMR so that they
do not have any dependenies on Spring-DM and become standalone
bundles.
Feedback welcome!

-- 
Cheers,
Guillaume Nodet

Blog: http://gnodet.blogspot.com/

Open Source SOA
http://fusesource.com

[jira] Closed: (FELIX-977) Bundle resolving runs extreme long

[Kristian Koehler (JIRA)]

 [ 
https://issues.apache.org/jira/browse/FELIX-977?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Kristian Koehler closed FELIX-977.
--


Thanks!

Kristian

> Bundle resolving runs extreme long
> --
>
> Key: FELIX-977
> URL: https://issues.apache.org/jira/browse/FELIX-977
> Project: Felix
>  Issue Type: Bug
>  Components: Bundle Repository (OBR)
>Reporter: Kristian Koehler
>Assignee: Richard S. Hall
> Fix For: bundlerepository-1.4.0
>
> Attachments: bundlerepo-patch-2009_03_26.txt, 
> FELIX-977-2009-03-30.txt, FELIX-977-new.txt, FELIX-977.txt, myrepo.xml
>
>
> Hi
> I encountered problems while resolving rependencies via the bundle repository.
> Here is the scenario:
> I have a simple obr file with a resource definition which has an unresolved 
> dependency. In this file the resource with the name 
> "org.springframework.core" has a requirement for the 
> "org.apache.commons.logging".
> When I start felix with the obr repository location poniting to that file and 
> type 'obr start com.kkoehler.osgi.repo-test' I'm gettiing the following:
> --- 8< ---
> Unsatisfied requirement(s):
> ---
>(&(package=org.springframework.context)(version>=2.5.0))
>   Unnamed - com.kkoehler.osgi:repo-test:bundle:1.0-SNAPSHOT
>(&(package=org.apache.commons.logging)(version>=1.0.4)(!(version>=2.0.0)))
>   Spring Context
>   Spring Beans
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Beans
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Beans
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Beans
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Beans
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Beans
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Beans
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Beans
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Beans
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Beans
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Beans
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
> --- 8< ---
> I seems to me that felix tries to resolve the bundle "Spring Core" more than 
> once ;-)
> The wrong unsatisfied dependency information can easily be fixed when 
> checking for existing information in the current list before added it 
> (org.apache.felix.bundlerepository.ResolverImpl). But I think this is only a 
> workaround for the problem of 'double resolving' (I also tried with a larger 
> project and the resolving seems to run 'endless').
> In the ResolverImpl I found a statement which 'causes' my problem but there 
> is also a comment for the code.
> --- 8< ---
> // If the resource did not resolve, then remove it from
> // the resolve set, since to keep it consistent for iterative
> // resolving, such as what happens when determining the best
> // available candidate.
> if (!result)
> {
> m_resolveSet.remove(resource);
> }
> --- 8< ---
> Removing the line solved my problem but I'm not sure if I'm running in new 
> ones...
> Thanks
> Kristian

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Resolved: (FELIX-977) Bundle resolving runs extreme long

[Richard S. Hall (JIRA)]

 [ 
https://issues.apache.org/jira/browse/FELIX-977?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Richard S. Hall resolved FELIX-977.
---

   Resolution: Fixed
Fix Version/s: bundlerepository-1.4.0
 Assignee: Richard S. Hall

I applied the patch. Thanks for helping with it. Please close if you are 
satisfied.

I will try look at the FilterImpl patch next.

> Bundle resolving runs extreme long
> --
>
> Key: FELIX-977
> URL: https://issues.apache.org/jira/browse/FELIX-977
> Project: Felix
>  Issue Type: Bug
>  Components: Bundle Repository (OBR)
>Reporter: Kristian Koehler
>Assignee: Richard S. Hall
> Fix For: bundlerepository-1.4.0
>
> Attachments: bundlerepo-patch-2009_03_26.txt, 
> FELIX-977-2009-03-30.txt, FELIX-977-new.txt, FELIX-977.txt, myrepo.xml
>
>
> Hi
> I encountered problems while resolving rependencies via the bundle repository.
> Here is the scenario:
> I have a simple obr file with a resource definition which has an unresolved 
> dependency. In this file the resource with the name 
> "org.springframework.core" has a requirement for the 
> "org.apache.commons.logging".
> When I start felix with the obr repository location poniting to that file and 
> type 'obr start com.kkoehler.osgi.repo-test' I'm gettiing the following:
> --- 8< ---
> Unsatisfied requirement(s):
> ---
>(&(package=org.springframework.context)(version>=2.5.0))
>   Unnamed - com.kkoehler.osgi:repo-test:bundle:1.0-SNAPSHOT
>(&(package=org.apache.commons.logging)(version>=1.0.4)(!(version>=2.0.0)))
>   Spring Context
>   Spring Beans
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Beans
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Beans
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Beans
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Beans
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Beans
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Beans
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Beans
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Beans
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Beans
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Beans
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
> --- 8< ---
> I seems to me that felix tries to resolve the bundle "Spring Core" more than 
> once ;-)
> The wrong unsatisfied dependency information can easily be fixed when 
> checking for existing information in the current list before added it 
> (org.apache.felix.bundlerepository.ResolverImpl). But I think this is only a 
> workaround for the problem of 'double resolving' (I also tried with a larger 
> project and the resolving seems to run 'endless').
> In the ResolverImpl I found a statement which 'causes' my problem but there 
> is also a comment for the code.
> --- 8< ---
> // If the resource did not resolve, then remove it from
> // the resolve set, since to keep it consistent for iterative
> // resolving, such as what happens when determining the best
> // available candidate.
> if (!result)
> {
> m_resolveSet.remove(resource);
> }
> --- 8< ---
> Removing the line solved my problem but I'm not sure if I'm running in new 
> ones...
> Thanks
> Kristian

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (FELIX-1012) Transactions in OSGi (RFC 98)

[Guillaume Nodet (JIRA)]

 [ 
https://issues.apache.org/jira/browse/FELIX-1012?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Guillaume Nodet updated FELIX-1012:
---

Attachment: FELIX-1012.patch

This implementation is a rewrite of the ServiceMix NMR transaction manager 
bundle, so that it can be used with no dependencies on Spring.
If spring bundles are deployed, the transaction manager also becomes a Spring 
PlatformTransactionManager.

> Transactions in OSGi (RFC 98)
> -
>
> Key: FELIX-1012
> URL: https://issues.apache.org/jira/browse/FELIX-1012
> Project: Felix
>  Issue Type: New Feature
>Reporter: Guillaume Nodet
> Attachments: FELIX-1012.patch
>
>


-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Created: (FELIX-1012) Transactions in OSGi (RFC 98)

[Guillaume Nodet (JIRA)]

Transactions in OSGi (RFC 98)
-

 Key: FELIX-1012
 URL: https://issues.apache.org/jira/browse/FELIX-1012
 Project: Felix
  Issue Type: New Feature
Reporter: Guillaume Nodet




-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (FELIX-977) Bundle resolving runs extreme long

[Kristian Koehler (JIRA)]

 [ 
https://issues.apache.org/jira/browse/FELIX-977?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Kristian Koehler updated FELIX-977:
---

Attachment: FELIX-977-2009-03-30.txt

Hi Richard

yes. works great. 

I modified your patch a bit because within the searchResolvingResources Method 
there was a array coping which is not neccessary IMO. 

I have also some Unit Tests for the resolver but they depend on the Filter 
patch ;-)
https://issues.apache.org/jira/browse/FELIX-973
Do I have a chance to get it in?

Kristian

> Bundle resolving runs extreme long
> --
>
> Key: FELIX-977
> URL: https://issues.apache.org/jira/browse/FELIX-977
> Project: Felix
>  Issue Type: Bug
>  Components: Bundle Repository (OBR)
>Reporter: Kristian Koehler
> Attachments: bundlerepo-patch-2009_03_26.txt, 
> FELIX-977-2009-03-30.txt, FELIX-977-new.txt, FELIX-977.txt, myrepo.xml
>
>
> Hi
> I encountered problems while resolving rependencies via the bundle repository.
> Here is the scenario:
> I have a simple obr file with a resource definition which has an unresolved 
> dependency. In this file the resource with the name 
> "org.springframework.core" has a requirement for the 
> "org.apache.commons.logging".
> When I start felix with the obr repository location poniting to that file and 
> type 'obr start com.kkoehler.osgi.repo-test' I'm gettiing the following:
> --- 8< ---
> Unsatisfied requirement(s):
> ---
>(&(package=org.springframework.context)(version>=2.5.0))
>   Unnamed - com.kkoehler.osgi:repo-test:bundle:1.0-SNAPSHOT
>(&(package=org.apache.commons.logging)(version>=1.0.4)(!(version>=2.0.0)))
>   Spring Context
>   Spring Beans
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Beans
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Beans
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Beans
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Beans
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Beans
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Beans
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Beans
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Beans
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Beans
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Beans
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
> --- 8< ---
> I seems to me that felix tries to resolve the bundle "Spring Core" more than 
> once ;-)
> The wrong unsatisfied dependency information can easily be fixed when 
> checking for existing information in the current list before added it 
> (org.apache.felix.bundlerepository.ResolverImpl). But I think this is only a 
> workaround for the problem of 'double resolving' (I also tried with a larger 
> project and the resolving seems to run 'endless').
> In the ResolverImpl I found a statement which 'causes' my problem but there 
> is also a comment for the code.
> --- 8< ---
> // If the resource did not resolve, then remove it from
> // the resolve set, since to keep it consistent for iterative
> // resolving, such as what happens when determining the best
> // available candidate.
> if (!result)
> {
> m_resolveSet.remove(resource);
> }
> --- 8< ---
> Removing the line solved my problem but I'm not sure if I'm running in new 
> ones...
> Thanks
> Kristian

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to th

Re: [jira] Updated: (FELIX-988) Upgrade Test dependencies to latest version.

[Dennis Geurts]

Hi all,

Would it be possible for someone to apply the attached patch ?

I have some tests available that depend on this patch.

When these test have been added we might also consider a first release  
for the device manager ;-)


regards, dennis


On 18 mrt 2009, at 11:37, Dennis Geurts (JIRA) wrote:



[ https://issues.apache.org/jira/browse/FELIX-988?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel 
 ]


Dennis Geurts updated FELIX-988:


   Attachment: (was: pom.xml.patch)


Upgrade Test dependencies to latest version.


   Key: FELIX-988
   URL: https://issues.apache.org/jira/browse/FELIX-988
   Project: Felix
Issue Type: Wish
  Affects Versions: felix-1.4.1
  Reporter: Dennis Geurts
  Priority: Minor
   Attachments: pom.xml.patch


I propose that we update the versions of the test jars used within  
Apache Felix:

junit 3.8.1 -> junit 4.0
easymock 1.2 -> easymock 2.4
I also propose we add the dependency to mockito (1.7)


--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (FELIX-977) Bundle resolving runs extreme long

[Richard S. Hall (JIRA)]

[ 
https://issues.apache.org/jira/browse/FELIX-977?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12693769#action_12693769
 ] 

Richard S. Hall commented on FELIX-977:
---

Ok, as far as I can see, I forgot to add the line to add a resource to the 
failed set when it is removed from the resolve set due to a resolution failure. 
I have attached a new patch that adds this line and I tested it locally again 
and it is still correctly resolving dependencies. Let me know if it works for 
you. Thanks.

> Bundle resolving runs extreme long
> --
>
> Key: FELIX-977
> URL: https://issues.apache.org/jira/browse/FELIX-977
> Project: Felix
>  Issue Type: Bug
>  Components: Bundle Repository (OBR)
>Reporter: Kristian Koehler
> Attachments: bundlerepo-patch-2009_03_26.txt, FELIX-977-new.txt, 
> FELIX-977.txt, myrepo.xml
>
>
> Hi
> I encountered problems while resolving rependencies via the bundle repository.
> Here is the scenario:
> I have a simple obr file with a resource definition which has an unresolved 
> dependency. In this file the resource with the name 
> "org.springframework.core" has a requirement for the 
> "org.apache.commons.logging".
> When I start felix with the obr repository location poniting to that file and 
> type 'obr start com.kkoehler.osgi.repo-test' I'm gettiing the following:
> --- 8< ---
> Unsatisfied requirement(s):
> ---
>(&(package=org.springframework.context)(version>=2.5.0))
>   Unnamed - com.kkoehler.osgi:repo-test:bundle:1.0-SNAPSHOT
>(&(package=org.apache.commons.logging)(version>=1.0.4)(!(version>=2.0.0)))
>   Spring Context
>   Spring Beans
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Beans
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Beans
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Beans
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Beans
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Beans
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Beans
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Beans
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Beans
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Beans
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Beans
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
> --- 8< ---
> I seems to me that felix tries to resolve the bundle "Spring Core" more than 
> once ;-)
> The wrong unsatisfied dependency information can easily be fixed when 
> checking for existing information in the current list before added it 
> (org.apache.felix.bundlerepository.ResolverImpl). But I think this is only a 
> workaround for the problem of 'double resolving' (I also tried with a larger 
> project and the resolving seems to run 'endless').
> In the ResolverImpl I found a statement which 'causes' my problem but there 
> is also a comment for the code.
> --- 8< ---
> // If the resource did not resolve, then remove it from
> // the resolve set, since to keep it consistent for iterative
> // resolving, such as what happens when determining the best
> // available candidate.
> if (!result)
> {
> m_resolveSet.remove(resource);
> }
> --- 8< ---
> Removing the line solved my problem but I'm not sure if I'm running in new 
> ones...
> Thanks
> Kristian

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (FELIX-977) Bundle resolving runs extreme long

[Richard S. Hall (JIRA)]

 [ 
https://issues.apache.org/jira/browse/FELIX-977?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Richard S. Hall updated FELIX-977:
--

Attachment: FELIX-977-new.txt

> Bundle resolving runs extreme long
> --
>
> Key: FELIX-977
> URL: https://issues.apache.org/jira/browse/FELIX-977
> Project: Felix
>  Issue Type: Bug
>  Components: Bundle Repository (OBR)
>Reporter: Kristian Koehler
> Attachments: bundlerepo-patch-2009_03_26.txt, FELIX-977-new.txt, 
> FELIX-977.txt, myrepo.xml
>
>
> Hi
> I encountered problems while resolving rependencies via the bundle repository.
> Here is the scenario:
> I have a simple obr file with a resource definition which has an unresolved 
> dependency. In this file the resource with the name 
> "org.springframework.core" has a requirement for the 
> "org.apache.commons.logging".
> When I start felix with the obr repository location poniting to that file and 
> type 'obr start com.kkoehler.osgi.repo-test' I'm gettiing the following:
> --- 8< ---
> Unsatisfied requirement(s):
> ---
>(&(package=org.springframework.context)(version>=2.5.0))
>   Unnamed - com.kkoehler.osgi:repo-test:bundle:1.0-SNAPSHOT
>(&(package=org.apache.commons.logging)(version>=1.0.4)(!(version>=2.0.0)))
>   Spring Context
>   Spring Beans
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Beans
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Beans
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Beans
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Beans
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Beans
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Beans
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Beans
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Beans
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Beans
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Beans
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
> --- 8< ---
> I seems to me that felix tries to resolve the bundle "Spring Core" more than 
> once ;-)
> The wrong unsatisfied dependency information can easily be fixed when 
> checking for existing information in the current list before added it 
> (org.apache.felix.bundlerepository.ResolverImpl). But I think this is only a 
> workaround for the problem of 'double resolving' (I also tried with a larger 
> project and the resolving seems to run 'endless').
> In the ResolverImpl I found a statement which 'causes' my problem but there 
> is also a comment for the code.
> --- 8< ---
> // If the resource did not resolve, then remove it from
> // the resolve set, since to keep it consistent for iterative
> // resolving, such as what happens when determining the best
> // available candidate.
> if (!result)
> {
> m_resolveSet.remove(resource);
> }
> --- 8< ---
> Removing the line solved my problem but I'm not sure if I'm running in new 
> ones...
> Thanks
> Kristian

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (FELIX-977) Bundle resolving runs extreme long

[Richard S. Hall (JIRA)]

[ 
https://issues.apache.org/jira/browse/FELIX-977?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12693760#action_12693760
 ] 

Richard S. Hall commented on FELIX-977:
---

Yeah, I think my changes are incomplete. I had modified it, but broke things, 
which eventually led me to revert and start over with a different approach, but 
apparently I didn't actually complete it. I will look into it again.

> Bundle resolving runs extreme long
> --
>
> Key: FELIX-977
> URL: https://issues.apache.org/jira/browse/FELIX-977
> Project: Felix
>  Issue Type: Bug
>  Components: Bundle Repository (OBR)
>Reporter: Kristian Koehler
> Attachments: bundlerepo-patch-2009_03_26.txt, FELIX-977.txt, 
> myrepo.xml
>
>
> Hi
> I encountered problems while resolving rependencies via the bundle repository.
> Here is the scenario:
> I have a simple obr file with a resource definition which has an unresolved 
> dependency. In this file the resource with the name 
> "org.springframework.core" has a requirement for the 
> "org.apache.commons.logging".
> When I start felix with the obr repository location poniting to that file and 
> type 'obr start com.kkoehler.osgi.repo-test' I'm gettiing the following:
> --- 8< ---
> Unsatisfied requirement(s):
> ---
>(&(package=org.springframework.context)(version>=2.5.0))
>   Unnamed - com.kkoehler.osgi:repo-test:bundle:1.0-SNAPSHOT
>(&(package=org.apache.commons.logging)(version>=1.0.4)(!(version>=2.0.0)))
>   Spring Context
>   Spring Beans
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Beans
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Beans
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Beans
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Beans
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Beans
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Beans
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Beans
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Beans
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Beans
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Beans
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
> --- 8< ---
> I seems to me that felix tries to resolve the bundle "Spring Core" more than 
> once ;-)
> The wrong unsatisfied dependency information can easily be fixed when 
> checking for existing information in the current list before added it 
> (org.apache.felix.bundlerepository.ResolverImpl). But I think this is only a 
> workaround for the problem of 'double resolving' (I also tried with a larger 
> project and the resolving seems to run 'endless').
> In the ResolverImpl I found a statement which 'causes' my problem but there 
> is also a comment for the code.
> --- 8< ---
> // If the resource did not resolve, then remove it from
> // the resolve set, since to keep it consistent for iterative
> // resolving, such as what happens when determining the best
> // available candidate.
> if (!result)
> {
> m_resolveSet.remove(resource);
> }
> --- 8< ---
> Removing the line solved my problem but I'm not sure if I'm running in new 
> ones...
> Thanks
> Kristian

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: [Vote] Release Felix Log Service 1.0.0

[Felix Meschberger]

+1

Regards
Felix

Clement Escoffier schrieb:
> Hi all,
> 
> I cut a release of the Felix log service. This service implementation
> was developed and but never released.
> It's a simple implementation, but can be useful.
> 
> The source and binary release archives, signature files, SHA and MD5
> message digests for each are available as zip and tar.gz here:
> 
> http://people.apache.org/~clement/releases/org/apache/felix/org.apache.felix.log/1.0.0/
> 
> 
> Please vote to approve these release archives:
> 
> [ ] +1 Yes, release it now
> [ ] -1 No, don't release now (please provide specific comments)
> 
> Regards,
> Clement
> 

[Vote] Release Felix Log Service 1.0.0

[Clement Escoffier]

Hi all,

I cut a release of the Felix log service. This service implementation  
was developed and but never released.

It's a simple implementation, but can be useful.

The source and binary release archives, signature files, SHA and MD5
message digests for each are available as zip and tar.gz here:

http://people.apache.org/~clement/releases/org/apache/felix/org.apache.felix.log/1.0.0/

Please vote to approve these release archives:

[ ] +1 Yes, release it now
[ ] -1 No, don't release now (please provide specific comments)

Regards,
Clement

[jira] Commented: (FELIX-977) Bundle resolving runs extreme long

[Kristian Koehler (JIRA)]

[ 
https://issues.apache.org/jira/browse/FELIX-977?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12693691#action_12693691
 ] 

Kristian Koehler commented on FELIX-977:


I'm not sure but... where do you add entries to the failed set?

Kristian

> Bundle resolving runs extreme long
> --
>
> Key: FELIX-977
> URL: https://issues.apache.org/jira/browse/FELIX-977
> Project: Felix
>  Issue Type: Bug
>  Components: Bundle Repository (OBR)
>Reporter: Kristian Koehler
> Attachments: bundlerepo-patch-2009_03_26.txt, FELIX-977.txt, 
> myrepo.xml
>
>
> Hi
> I encountered problems while resolving rependencies via the bundle repository.
> Here is the scenario:
> I have a simple obr file with a resource definition which has an unresolved 
> dependency. In this file the resource with the name 
> "org.springframework.core" has a requirement for the 
> "org.apache.commons.logging".
> When I start felix with the obr repository location poniting to that file and 
> type 'obr start com.kkoehler.osgi.repo-test' I'm gettiing the following:
> --- 8< ---
> Unsatisfied requirement(s):
> ---
>(&(package=org.springframework.context)(version>=2.5.0))
>   Unnamed - com.kkoehler.osgi:repo-test:bundle:1.0-SNAPSHOT
>(&(package=org.apache.commons.logging)(version>=1.0.4)(!(version>=2.0.0)))
>   Spring Context
>   Spring Beans
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Beans
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Beans
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Beans
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Beans
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Beans
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Beans
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Beans
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Beans
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Beans
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Beans
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
>   Spring Core
> --- 8< ---
> I seems to me that felix tries to resolve the bundle "Spring Core" more than 
> once ;-)
> The wrong unsatisfied dependency information can easily be fixed when 
> checking for existing information in the current list before added it 
> (org.apache.felix.bundlerepository.ResolverImpl). But I think this is only a 
> workaround for the problem of 'double resolving' (I also tried with a larger 
> project and the resolving seems to run 'endless').
> In the ResolverImpl I found a statement which 'causes' my problem but there 
> is also a comment for the code.
> --- 8< ---
> // If the resource did not resolve, then remove it from
> // the resolve set, since to keep it consistent for iterative
> // resolving, such as what happens when determining the best
> // available candidate.
> if (!result)
> {
> m_resolveSet.remove(resource);
> }
> --- 8< ---
> Removing the line solved my problem but I'm not sure if I'm running in new 
> ones...
> Thanks
> Kristian

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: ApacheCon EU Felix BOF

[Felix Meschberger]

Hi,

Marcel Offermans schrieb:
>> as well as propose an Apache project for a
>> provisioning server.
> 
> We had very positive feedback from the community at ApacheCon about
> this, so I'm going to submit a proposal on this to the incubator in a
> week or two. Feel free to express your interest if you want to participate.

I would like to join, too.

Like others, I would think that putting this into the Incubator first is
the best option, since it also allows to more easily add people not
currently being ASF committers. In addition trasnferring IP is probably
also simpler.

Regards
Felix

Re: ApacheCon EU Felix BOF

[Carsten Ziegeler]

Guillaume Nodet wrote:
> This project could also start as a subproject of felix and if there is
> sufficient momentum around it, become a TLP later.  I think it is an
> easier process ...
> 
I guess you're refering to the distribution idea here, so a big +1 for
this approach. Starting at Felix should be easy and if we get enough
momentum, creating an own TLP should be easy as well. But starting with
a TLP right from the begin is not that easy :)

Carsten

-- 
Carsten Ziegeler
cziege...@apache.org

[jira] Updated: (FELIX-1011) JNDI / OSGi integation (RFC 0142)

[Guillaume Nodet (JIRA)]

 [ 
https://issues.apache.org/jira/browse/FELIX-1011?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Guillaume Nodet updated FELIX-1011:
---

Attachment: FELIX-1011.patch

This patch includes a simple (and incomplete) implementation of JNDI / OSGi 
integration as described by RFC 0142.

> JNDI / OSGi integation (RFC 0142)
> -
>
> Key: FELIX-1011
> URL: https://issues.apache.org/jira/browse/FELIX-1011
> Project: Felix
>  Issue Type: New Feature
>Reporter: Guillaume Nodet
> Attachments: FELIX-1011.patch
>
>


-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Created: (FELIX-1011) JNDI / OSGi integation (RFC 0142)

[Guillaume Nodet (JIRA)]

JNDI / OSGi integation (RFC 0142)
-

 Key: FELIX-1011
 URL: https://issues.apache.org/jira/browse/FELIX-1011
 Project: Felix
  Issue Type: New Feature
Reporter: Guillaume Nodet




-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: Cutting an HTTP Service (Jetty) release

[Clement Escoffier]

On 30.03.2009, at 08:04, Rob Walker wrote:

Certainly has been stable our side with the fixes a couple of months  
back.

I'll do an update this week and check the trunk version is still ok


Great, keep me posted.
I will look at License/Notice/Header file today.

Clement




- Rob

Clement Escoffier wrote:

Hi,

The HTTP Service was never released. However, it sounds to be quite  
stable (we use it successfully). So, I think it could be released  
like this. It will be a simple (in the sense that it does not  
provide advanced features such as War support..), but from my point  
of view, it makes its share. If everybody is ok, I can cut a  
release this week (0.9.0 or 1.0.0).


Regards,

Clement


--


Ascert - Taking systems to the Edge
r...@ascert.com
+44 (0)20 7488 3470
www.ascert.com

Re: ApacheCon EU Felix BOF

[Robert Burrell Donkin]

On Mon, Mar 30, 2009 at 7:42 AM, Guillaume Nodet  wrote:
> Sorry, I think I misread your proposition.  I thought it was referring
> to the "distribution" for an OSGi framework (such as ServiceMix
> Kernel).
> Given the size of the donation, the incubator could be a good target.

+1

- robert