[jira] Closed: (FELIX-1243) Change the default port for the OSGI HTTP Service from 8080 to 8181

2009-06-18 Thread Rob Walker (JIRA)

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

Rob Walker closed FELIX-1243.
-

Resolution: Fixed

Apologies - I see this change is specific to Karaf, and not a general Http 
service change

Ignore me!

- Rob

> Change the default port for the OSGI HTTP Service from 8080 to 8181
> ---
>
> Key: FELIX-1243
> URL: https://issues.apache.org/jira/browse/FELIX-1243
> Project: Felix
>  Issue Type: Bug
>  Components: Karaf
>Reporter: Edell Nolan
> Fix For: karaf-1.0.0
>
> Attachments: karaf-1243.patch
>
>
> Hi,
> I would like to change the default port for the OSGI HTTP Service by default 
> as it clashes with the default port of tomcat 8080 etc.

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



Re: Problem with http service

2009-06-18 Thread Rob Walker


Richard S. Hall wrote:

On 6/18/09 12:48 PM, Guillaume Nodet wrote:

My bad for not having checked the jira issues.
Does'nt this bug deserve a release ?
   


Probably. I am not the release manager. ;-)

If we do release it as is, we should probably downgrade the version to 
a micro bump.



Fine with me
- Rob

-> richard

On Thu, Jun 18, 2009 at 18:44, Richard S. Hall  
wrote:
  

http://issues.apache.org/jira/browse/FELIX-1236

On 6/18/09 12:40 PM, Guillaume Nodet wrote:


Did I miss something with the HTTP service ?
The headers looks like:

Import-Package =

javax.net.ssl;resolution:=optional,javax.security.cert;resolution:=optional,javax.servlet;version="2.5",javax.servlet.http;version="2.5",javax.xml.parsers;resolution:=optional,org.osgi.framework;version="1.3",org.osgi.service.cm;version="1.2",org.osgi.service.http;version="1.2",org.osgi.service.log;version="1.3",org.osgi.util.tracker;version="1.3",org.slf4j;resolution:=optional,org.xml.sax;resolution:=optional,org.xml.sax.helpers;resolution:=optional 



Export-Package =

org.osgi.service.http;uses:="javax.servlet.http,javax.servlet";version="1.1",javax.servlet;version="2.5",javax.servlet.http;uses:="javax.servlet";version="2.5" 



which means the http service is exporting the javax.servlet package
with version 1.1 but imports 1.2 ...

Thoughts ?


   




   




--


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



[jira] Reopened: (FELIX-1243) Change the default port for the OSGI HTTP Service from 8080 to 8181

2009-06-18 Thread Rob Walker (JIRA)

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

Rob Walker reopened FELIX-1243:
---


Not totally sure I agree with this one - many applications use default ports of 
8080, and other defaults, so trying to avoid any possible clash of default 
seems fruitless.

Also - 8080 is a very conventional "defauilt" - so shouldn't Felix also follow 
this convention?

If it clashes, it can be explicitly overridden easily, but changing the default 
to something non standard seems a little incorrect to me.

> Change the default port for the OSGI HTTP Service from 8080 to 8181
> ---
>
> Key: FELIX-1243
> URL: https://issues.apache.org/jira/browse/FELIX-1243
> Project: Felix
>  Issue Type: Bug
>  Components: Karaf
>Reporter: Edell Nolan
> Fix For: karaf-1.0.0
>
> Attachments: karaf-1243.patch
>
>
> Hi,
> I would like to change the default port for the OSGI HTTP Service by default 
> as it clashes with the default port of tomcat 8080 etc.

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



[jira] Closed: (FELIX-1252) NullPointerException in "scr list" command

2009-06-18 Thread Thilo Planz (JIRA)

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

Thilo Planz closed FELIX-1252.
--


Closed as duplicate.

I searched for duplicates before reporting this, but JIRA is kind of hard to 
use.
Appears I was only looking at the reports for 1.2.0, did not even know 1.0.10 
existed ...

> NullPointerException in "scr list" command
> --
>
> Key: FELIX-1252
> URL: https://issues.apache.org/jira/browse/FELIX-1252
> Project: Felix
>  Issue Type: Bug
>  Components: Declarative Services (SCR)
>Affects Versions: scr-1.0.8
> Environment: Felix 1.8.1   
> Shell Service 1.2.0 
> SCR 1.0.8
>Reporter: Thilo Planz
>Assignee: Felix Meschberger
>Priority: Minor
> Fix For: scr-1.0.10
>
>
> When no components are registered, the shell command fails:
> -> scr list
> No components registered
>Id   State  Name
> Unable to execute command: java.lang.NullPointerException
> java.lang.NullPointerException
>   at org.apache.felix.scr.impl.ScrCommand.list(ScrCommand.java:161)
>   at org.apache.felix.scr.impl.ScrCommand.execute(ScrCommand.java:102)
>   at 
> org.apache.felix.shell.impl.Activator$ShellServiceImpl.executeCommand(Activator.java:291)
>   at 
> org.apache.felix.shell.tui.Activator$ShellTuiRunnable.run(Activator.java:177)
>   at java.lang.Thread.run(Thread.java:595)

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



[jira] Resolved: (FELIX-1243) Change the default port for the OSGI HTTP Service from 8080 to 8181

2009-06-18 Thread Guillaume Nodet (JIRA)

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

Guillaume Nodet resolved FELIX-1243.


   Resolution: Fixed
Fix Version/s: karaf-1.0.0

> Change the default port for the OSGI HTTP Service from 8080 to 8181
> ---
>
> Key: FELIX-1243
> URL: https://issues.apache.org/jira/browse/FELIX-1243
> Project: Felix
>  Issue Type: Bug
>  Components: Karaf
>Reporter: Edell Nolan
> Fix For: karaf-1.0.0
>
> Attachments: karaf-1243.patch
>
>
> Hi,
> I would like to change the default port for the OSGI HTTP Service by default 
> as it clashes with the default port of tomcat 8080 etc.

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



[jira] Commented: (FELIX-1243) Change the default port for the OSGI HTTP Service from 8080 to 8181

2009-06-18 Thread Guillaume Nodet (JIRA)

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

Guillaume Nodet commented on FELIX-1243:


I think the port should be controlled inside the "http" feature configuration 
rather than through a global property.

> Change the default port for the OSGI HTTP Service from 8080 to 8181
> ---
>
> Key: FELIX-1243
> URL: https://issues.apache.org/jira/browse/FELIX-1243
> Project: Felix
>  Issue Type: Bug
>  Components: Karaf
>Reporter: Edell Nolan
> Attachments: karaf-1243.patch
>
>
> Hi,
> I would like to change the default port for the OSGI HTTP Service by default 
> as it clashes with the default port of tomcat 8080 etc.

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



[jira] Resolved: (FELIX-1087) Unable to log into ServiceMix Kernel using Windows putty SSH client

2009-06-18 Thread Guillaume Nodet (JIRA)

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

Guillaume Nodet resolved FELIX-1087.


   Resolution: Fixed
Fix Version/s: karaf-1.0.0
 Assignee: Guillaume Nodet

> Unable to log into ServiceMix Kernel using Windows putty SSH client
> ---
>
> Key: FELIX-1087
> URL: https://issues.apache.org/jira/browse/FELIX-1087
> Project: Felix
>  Issue Type: Bug
>  Components: Karaf
>Reporter: Guillaume Nodet
>Assignee: Guillaume Nodet
> Fix For: karaf-1.0.0
>
>
> See https://issues.apache.org/jira/browse/SSHD-15

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



[jira] Resolved: (FELIX-1092) The client jar / ssh deamon should support direct commands

2009-06-18 Thread Guillaume Nodet (JIRA)

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

Guillaume Nodet resolved FELIX-1092.


   Resolution: Fixed
Fix Version/s: karaf-1.0.0
 Assignee: Guillaume Nodet

> The client jar / ssh deamon should support direct commands
> --
>
> Key: FELIX-1092
> URL: https://issues.apache.org/jira/browse/FELIX-1092
> Project: Felix
>  Issue Type: Improvement
>  Components: Karaf
>Reporter: Guillaume Nodet
>Assignee: Guillaume Nodet
> Fix For: karaf-1.0.0
>
>
> The following should work:
> > java -jar lib/servicemix-client.jar osgi/shutdown

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



[jira] Resolved: (FELIX-1098) Switch from spring-dm to blueprint

2009-06-18 Thread Guillaume Nodet (JIRA)

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

Guillaume Nodet resolved FELIX-1098.


   Resolution: Fixed
Fix Version/s: karaf-1.0.0

> Switch from spring-dm to blueprint
> --
>
> Key: FELIX-1098
> URL: https://issues.apache.org/jira/browse/FELIX-1098
> Project: Felix
>  Issue Type: Task
>  Components: Karaf
>Reporter: Guillaume Nodet
>Assignee: Guillaume Nodet
> Fix For: karaf-1.0.0
>
>


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



[jira] Resolved: (FELIX-1161) Stange classloading issues when using compendium services

2009-06-18 Thread Guillaume Nodet (JIRA)

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

Guillaume Nodet resolved FELIX-1161.


   Resolution: Fixed
Fix Version/s: karaf-1.0.0
 Assignee: Guillaume Nodet

The compendium jar has been removed from the karaf distribution, so I think it 
should solve the problems.
Please reopen if needed.

> Stange classloading issues when using compendium services
> -
>
> Key: FELIX-1161
> URL: https://issues.apache.org/jira/browse/FELIX-1161
> Project: Felix
>  Issue Type: Bug
>  Components: Karaf
> Environment: karaf-1.2.0-SNAPSHOT, OSX, Java5
>Reporter: Dmitry Sklyut
>Assignee: Guillaume Nodet
> Fix For: karaf-1.0.0
>
> Attachments: karaf.issue.tgz
>
>
> Problem is discussed here: 
> http://www.nabble.com/-karaf--Equinox-integration-problem---and-possible-solution-to23559788.html
> Looks like an issues comes up when using compendium services with springDM 
> and equinox.

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



[jira] Resolved: (FELIX-1116) Rename to Apache Felix Karaf

2009-06-18 Thread Guillaume Nodet (JIRA)

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

Guillaume Nodet resolved FELIX-1116.


Resolution: Fixed

> Rename to Apache Felix Karaf
> 
>
> Key: FELIX-1116
> URL: https://issues.apache.org/jira/browse/FELIX-1116
> Project: Felix
>  Issue Type: Task
>  Components: Karaf
>Reporter: Gert Vanthienen
> Fix For: karaf-1.0.0
>
>
> Now that the ServiceMix Kernel sources have been copied to Felix, we need to 
> start renaming things:
> - package names should become org.apache.felix.karaf.*
> - POM group and artifact IDs should be changed

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



[jira] Resolved: (FELIX-1150) Upgrade to SpringDM and SpringFramework

2009-06-18 Thread Guillaume Nodet (JIRA)

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

Guillaume Nodet resolved FELIX-1150.


   Resolution: Fixed
Fix Version/s: karaf-1.0.0

Spring / Spring-DM have been upgrade to the latest versions.
Note that now they are not installed by default but are available as features.

> Upgrade to SpringDM and SpringFramework 
> 
>
> Key: FELIX-1150
> URL: https://issues.apache.org/jira/browse/FELIX-1150
> Project: Felix
>  Issue Type: Improvement
>  Components: Karaf
>Reporter: Dmitry Sklyut
> Fix For: karaf-1.0.0
>
> Attachments: upgrade_spring_and_spring-dm_versions.patch, 
> upgrade_spring_and_spring-dm_versions1.patch
>
>
> Patch to upgrade Karaf SpringDM from 1.2.0-rc1 to 1.2.0 final 
> Also upgrade SpringFramework from 2.5.6 to 2.5.6.SEC1 and use artifacts from 
> SpringSource Enterprise Bundle Repository

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



[Karaf] Switching to blueprint ...

2009-06-18 Thread Guillaume Nodet
As you may have noticed by the recent commits, I've just upgrade Karaf
to blueprint.
Spring and Spring-DM are now available as features to be installed,
but are not installed by default.

-- 
Cheers,
Guillaume Nodet

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

Open Source SOA
http://fusesource.com


[jira] Assigned: (FELIX-1201) Issue with DM and CM

2009-06-18 Thread Marcel Offermans (JIRA)

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

Marcel Offermans reassigned FELIX-1201:
---

Assignee: Marcel Offermans

> Issue with DM and CM
> 
>
> Key: FELIX-1201
> URL: https://issues.apache.org/jira/browse/FELIX-1201
> Project: Felix
>  Issue Type: Bug
>  Components: Dependency Manager
>Affects Versions: dependencymanager-2.0.1
> Environment: linux FC10, jdk 1.5, 1.6
>Reporter: Pierre De Rop
>Assignee: Marcel Offermans
> Attachments: ConfigurationDependency.java
>
>
> I am using DM for configuring my POJOs from Configuration Admin Service.
> This issue is actually about a bug, but also ask for a change request:.
> 1/ first, I think there are two bugs in ConfigurationDependency.java:
> - When the configuration is not currently available from CM, POJOs are 
> invoked in their "updated" method with a null Dictionary
> - Morover, DM requires POJO to implement the ManagedService interface, while 
> in the online doc, it is stated that POJOs just have 
>   to provide an "updated(Dictionary)" method signature.
> Concerning the null dictionary passed to my updated method: for example:
> dm.add(createService()
>.setImplementation(new Log4jConfigurator(property))
>.add(createConfigurationDependency()
> .setPid("log4j")));
> -> My Pojo "Log4jConfigurator" is invoked in its "updated" method with a null 
> Dictionary if the configuration is not yet available from CM.
> I have attached to this issue a proposed patch (in 
> ConfigurationDependency.java).
> I just check if CM provides a null Dictionary and I just don't activate the 
> dependencies ...
> 2/ Now, there is something I would like you to add concerning configuration 
> callbacks (I also have implemeted it in the proposed patch):
> Indeed, by default, DM assumes that the pojo implements the 
> org.osgi.service.cm.ManagedService interface.
> But the point is: I need my POJOs to be reused outside OSGi; and I don't want 
> to introduce a dependency over the OSGi CM managed service interface.
> Moreover, I need to get injected with several PIDS.
> That's why I would like to be able to invoke a method "setCallback" in the 
> ConfigurationDependency class (like in ServiceDependency.java).
> This callback would match a method which takes as parameter a Dictionary.
> So, adding such setCallback method would also let me listen to more than one 
> PID like this:
> For example:
> dm.add(createService()
>.setImplementation(new Log4jConfigurator(property))
>.add(createConfigurationDependency()
> .setPid("log4j")
> .setCallback("updateLog4jConfig"))
>.add(createConfigurationDependency()
> .setPid("system")
> .setCallback("updateSystemConfig")));
> The patch attached to this issue sounds like to work fine.
> Marcel, WDYT ? 
> Could you please commit this patch (and then make a new release of DM) ?
> Thanks a lot for your help;
> /pierre

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



Re: Problem with http service

2009-06-18 Thread Richard S. Hall

On 6/18/09 12:48 PM, Guillaume Nodet wrote:

My bad for not having checked the jira issues.
Does'nt this bug deserve a release ?
   


Probably. I am not the release manager. ;-)

If we do release it as is, we should probably downgrade the version to a 
micro bump.


-> richard


On Thu, Jun 18, 2009 at 18:44, Richard S. Hall  wrote:
   

http://issues.apache.org/jira/browse/FELIX-1236

On 6/18/09 12:40 PM, Guillaume Nodet wrote:
 

Did I miss something with the HTTP service ?
The headers looks like:

Import-Package =

javax.net.ssl;resolution:=optional,javax.security.cert;resolution:=optional,javax.servlet;version="2.5",javax.servlet.http;version="2.5",javax.xml.parsers;resolution:=optional,org.osgi.framework;version="1.3",org.osgi.service.cm;version="1.2",org.osgi.service.http;version="1.2",org.osgi.service.log;version="1.3",org.osgi.util.tracker;version="1.3",org.slf4j;resolution:=optional,org.xml.sax;resolution:=optional,org.xml.sax.helpers;resolution:=optional

Export-Package =

org.osgi.service.http;uses:="javax.servlet.http,javax.servlet";version="1.1",javax.servlet;version="2.5",javax.servlet.http;uses:="javax.servlet";version="2.5"

which means the http service is exporting the javax.servlet package
with version 1.1 but imports 1.2 ...

Thoughts ?


   




   


Re: Problem with http service

2009-06-18 Thread Guillaume Nodet
My bad for not having checked the jira issues.
Does'nt this bug deserve a release ?

On Thu, Jun 18, 2009 at 18:44, Richard S. Hall wrote:
> http://issues.apache.org/jira/browse/FELIX-1236
>
> On 6/18/09 12:40 PM, Guillaume Nodet wrote:
>>
>> Did I miss something with the HTTP service ?
>> The headers looks like:
>>
>> Import-Package =
>>
>> javax.net.ssl;resolution:=optional,javax.security.cert;resolution:=optional,javax.servlet;version="2.5",javax.servlet.http;version="2.5",javax.xml.parsers;resolution:=optional,org.osgi.framework;version="1.3",org.osgi.service.cm;version="1.2",org.osgi.service.http;version="1.2",org.osgi.service.log;version="1.3",org.osgi.util.tracker;version="1.3",org.slf4j;resolution:=optional,org.xml.sax;resolution:=optional,org.xml.sax.helpers;resolution:=optional
>>
>> Export-Package =
>>
>> org.osgi.service.http;uses:="javax.servlet.http,javax.servlet";version="1.1",javax.servlet;version="2.5",javax.servlet.http;uses:="javax.servlet";version="2.5"
>>
>> which means the http service is exporting the javax.servlet package
>> with version 1.1 but imports 1.2 ...
>>
>> Thoughts ?
>>
>>
>



-- 
Cheers,
Guillaume Nodet

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

Open Source SOA
http://fusesource.com


Re: Problem with http service

2009-06-18 Thread Richard S. Hall

http://issues.apache.org/jira/browse/FELIX-1236

On 6/18/09 12:40 PM, Guillaume Nodet wrote:

Did I miss something with the HTTP service ?
The headers looks like:

Import-Package =
javax.net.ssl;resolution:=optional,javax.security.cert;resolution:=optional,javax.servlet;version="2.5",javax.servlet.http;version="2.5",javax.xml.parsers;resolution:=optional,org.osgi.framework;version="1.3",org.osgi.service.cm;version="1.2",org.osgi.service.http;version="1.2",org.osgi.service.log;version="1.3",org.osgi.util.tracker;version="1.3",org.slf4j;resolution:=optional,org.xml.sax;resolution:=optional,org.xml.sax.helpers;resolution:=optional

Export-Package =
org.osgi.service.http;uses:="javax.servlet.http,javax.servlet";version="1.1",javax.servlet;version="2.5",javax.servlet.http;uses:="javax.servlet";version="2.5"

which means the http service is exporting the javax.servlet package
with version 1.1 but imports 1.2 ...

Thoughts ?

   


Problem with http service

2009-06-18 Thread Guillaume Nodet
Did I miss something with the HTTP service ?
The headers looks like:

Import-Package =
javax.net.ssl;resolution:=optional,javax.security.cert;resolution:=optional,javax.servlet;version="2.5",javax.servlet.http;version="2.5",javax.xml.parsers;resolution:=optional,org.osgi.framework;version="1.3",org.osgi.service.cm;version="1.2",org.osgi.service.http;version="1.2",org.osgi.service.log;version="1.3",org.osgi.util.tracker;version="1.3",org.slf4j;resolution:=optional,org.xml.sax;resolution:=optional,org.xml.sax.helpers;resolution:=optional

Export-Package =
org.osgi.service.http;uses:="javax.servlet.http,javax.servlet";version="1.1",javax.servlet;version="2.5",javax.servlet.http;uses:="javax.servlet";version="2.5"

which means the http service is exporting the javax.servlet package
with version 1.1 but imports 1.2 ...

Thoughts ?

-- 
Cheers,
Guillaume Nodet

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

Open Source SOA
http://fusesource.com


Re: NPE in Bundle#findEntries

2009-06-18 Thread Guillaume Nodet
It works, thx !

On Thu, Jun 18, 2009 at 16:27, Richard S. Hall wrote:
> Ok, it should be working now. I needed to special case the system bundle.
>
> -> richard
>
> On 6/18/09 10:18 AM, Richard S. Hall wrote:
>>
>> I just modified/added this code yesterday, so I likely introduced a
>> bug...I will check.
>>
>> -> richard
>>
>> On 6/18/09 10:08 AM, Guillaume Nodet wrote:
>>>
>>> I've just hit the following NPE while testing karaf with the latest
>>> felix framework:
>>>
>>> ERROR: Error starting
>>>
>>> mvn:org.apache.servicemix.specs/org.apache.servicemix.specs.jaxp-api-1.4/1.4-SNAPSHOT
>>> (org.osgi.framework.BundleException: Activator start error in bundle
>>> org.apache.servicemix.specs.jaxp-api-1.4 [1].)
>>> java.lang.NullPointerException
>>>    at
>>> org.apache.felix.framework.ModuleImpl.getEntries(ModuleImpl.java:437)
>>>    at
>>> org.apache.felix.framework.FindEntriesEnumeration.(FindEntriesEnumeration.java:37)
>>>    at org.apache.felix.framework.Felix.findBundleEntries(Felix.java:1307)
>>>    at
>>> org.apache.felix.framework.BundleImpl.findEntries(BundleImpl.java:238)
>>>    at
>>> org.apache.servicemix.specs.locator.Activator.register(Activator.java:97)
>>>    at
>>> org.apache.servicemix.specs.locator.Activator.start(Activator.java:70)
>>>    at
>>> org.apache.felix.framework.util.SecureAction.startActivator(SecureAction.java:589)
>>>    at org.apache.felix.framework.Felix.activateBundle(Felix.java:1602)
>>>    at org.apache.felix.framework.Felix.startBundle(Felix.java:1524)
>>>    at
>>> org.apache.felix.framework.Felix.setActiveStartLevel(Felix.java:991)
>>>    at
>>> org.apache.felix.framework.StartLevelImpl.run(StartLevelImpl.java:263)
>>>    at java.lang.Thread.run(Thread.java:613)
>>>
>>> Any ideas ?
>>>
>



-- 
Cheers,
Guillaume Nodet

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

Open Source SOA
http://fusesource.com


Re: NPE in Bundle#findEntries

2009-06-18 Thread Richard S. Hall

Ok, it should be working now. I needed to special case the system bundle.

-> richard

On 6/18/09 10:18 AM, Richard S. Hall wrote:
I just modified/added this code yesterday, so I likely introduced a 
bug...I will check.


-> richard

On 6/18/09 10:08 AM, Guillaume Nodet wrote:

I've just hit the following NPE while testing karaf with the latest
felix framework:

ERROR: Error starting
mvn:org.apache.servicemix.specs/org.apache.servicemix.specs.jaxp-api-1.4/1.4-SNAPSHOT 


(org.osgi.framework.BundleException: Activator start error in bundle
org.apache.servicemix.specs.jaxp-api-1.4 [1].)
java.lang.NullPointerException
at 
org.apache.felix.framework.ModuleImpl.getEntries(ModuleImpl.java:437)
at 
org.apache.felix.framework.FindEntriesEnumeration.(FindEntriesEnumeration.java:37) 

at 
org.apache.felix.framework.Felix.findBundleEntries(Felix.java:1307)
at 
org.apache.felix.framework.BundleImpl.findEntries(BundleImpl.java:238)
at 
org.apache.servicemix.specs.locator.Activator.register(Activator.java:97) 

at 
org.apache.servicemix.specs.locator.Activator.start(Activator.java:70)
at 
org.apache.felix.framework.util.SecureAction.startActivator(SecureAction.java:589) 


at org.apache.felix.framework.Felix.activateBundle(Felix.java:1602)
at org.apache.felix.framework.Felix.startBundle(Felix.java:1524)
at 
org.apache.felix.framework.Felix.setActiveStartLevel(Felix.java:991)
at 
org.apache.felix.framework.StartLevelImpl.run(StartLevelImpl.java:263)

at java.lang.Thread.run(Thread.java:613)

Any ideas ?



Re: NPE in Bundle#findEntries

2009-06-18 Thread Richard S. Hall
I just modified/added this code yesterday, so I likely introduced a 
bug...I will check.


-> richard

On 6/18/09 10:08 AM, Guillaume Nodet wrote:

I've just hit the following NPE while testing karaf with the latest
felix framework:

ERROR: Error starting
mvn:org.apache.servicemix.specs/org.apache.servicemix.specs.jaxp-api-1.4/1.4-SNAPSHOT
(org.osgi.framework.BundleException: Activator start error in bundle
org.apache.servicemix.specs.jaxp-api-1.4 [1].)
java.lang.NullPointerException
at org.apache.felix.framework.ModuleImpl.getEntries(ModuleImpl.java:437)
at 
org.apache.felix.framework.FindEntriesEnumeration.(FindEntriesEnumeration.java:37)
at org.apache.felix.framework.Felix.findBundleEntries(Felix.java:1307)
at 
org.apache.felix.framework.BundleImpl.findEntries(BundleImpl.java:238)
at 
org.apache.servicemix.specs.locator.Activator.register(Activator.java:97)
at 
org.apache.servicemix.specs.locator.Activator.start(Activator.java:70)
at 
org.apache.felix.framework.util.SecureAction.startActivator(SecureAction.java:589)
at org.apache.felix.framework.Felix.activateBundle(Felix.java:1602)
at org.apache.felix.framework.Felix.startBundle(Felix.java:1524)
at org.apache.felix.framework.Felix.setActiveStartLevel(Felix.java:991)
at 
org.apache.felix.framework.StartLevelImpl.run(StartLevelImpl.java:263)
at java.lang.Thread.run(Thread.java:613)

Any ideas ?

   


NPE in Bundle#findEntries

2009-06-18 Thread Guillaume Nodet
I've just hit the following NPE while testing karaf with the latest
felix framework:

ERROR: Error starting
mvn:org.apache.servicemix.specs/org.apache.servicemix.specs.jaxp-api-1.4/1.4-SNAPSHOT
(org.osgi.framework.BundleException: Activator start error in bundle
org.apache.servicemix.specs.jaxp-api-1.4 [1].)
java.lang.NullPointerException
at org.apache.felix.framework.ModuleImpl.getEntries(ModuleImpl.java:437)
at 
org.apache.felix.framework.FindEntriesEnumeration.(FindEntriesEnumeration.java:37)
at org.apache.felix.framework.Felix.findBundleEntries(Felix.java:1307)
at 
org.apache.felix.framework.BundleImpl.findEntries(BundleImpl.java:238)
at 
org.apache.servicemix.specs.locator.Activator.register(Activator.java:97)
at 
org.apache.servicemix.specs.locator.Activator.start(Activator.java:70)
at 
org.apache.felix.framework.util.SecureAction.startActivator(SecureAction.java:589)
at org.apache.felix.framework.Felix.activateBundle(Felix.java:1602)
at org.apache.felix.framework.Felix.startBundle(Felix.java:1524)
at org.apache.felix.framework.Felix.setActiveStartLevel(Felix.java:991)
at 
org.apache.felix.framework.StartLevelImpl.run(StartLevelImpl.java:263)
at java.lang.Thread.run(Thread.java:613)

Any ideas ?

-- 
Cheers,
Guillaume Nodet

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

Open Source SOA
http://fusesource.com


[jira] Commented: (FELIX-1202) Windows variable of servicemix/karaf debug not reseted !!!

2009-06-18 Thread Charles Moulliard (JIRA)

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

Charles Moulliard commented on FELIX-1202:
--

Hi Chris,

Yes. I have found that using under windows : 

set karaf_debug=

resolves the problem.

So, the issue can be closed

> Windows variable of servicemix/karaf debug not reseted !!!
> --
>
> Key: FELIX-1202
> URL: https://issues.apache.org/jira/browse/FELIX-1202
> Project: Felix
>  Issue Type: Bug
>  Components: Karaf
>Reporter: Charles Moulliard
>Assignee: Chris Custine
>
> It seems to have an issue on windows machine when we want to set the debug 
> mode :
> D:\Dvlpt\Java\workspace-ganymede\x3s\server\apache-felix-karaf-1.2.0-SNAPSHOT\bin>set
>  KARAF_DEBUG=true
> D:\Dvlpt\Java\workspace-ganymede\x3s\server\apache-felix-karaf-1.2.0-SNAPSHOT\bin>karaf
> karaf.bat: Enabling Java debug options: -Xdebug -Xnoagent 
> -Djava.compiler=NONE 
> -Xrunjdwp:transport=dt_socket,server=y,suspend=n,address=5005
> Listening for transport dt_socket at address: 5005
> __ __  
>/ //_/ __ _/ __/
>   / ,<  / __ `/ ___/ __ `/ /_
>  / /| |/ /_/ / /  / /_/ / __/
> /_/ |_|\__,_/_/   \__,_/_/
>  Apache Felix Karaf (1.2.0-SNAPSHOT)
> Type 'help' for more information.
> 
> ka...@root:/> exit
> Everything is ok
> Next we will try to reste the flag KARAF_DEBUG=false and we can see that 
> karaf (idem in servicemix) enables again the option even if we set 
> KARAF_DEBUG=false
> D:\Dvlpt\Java\workspace-ganymede\x3s\server\apache-felix-karaf-1.2.0-SNAPSHOT\bin>set
>  KARAF_DEBUG=false
> D:\Dvlpt\Java\workspace-ganymede\x3s\server\apache-felix-karaf-1.2.0-SNAPSHOT\bin>karaf
> karaf.bat: Enabling Java debug options: -Xdebug -Xnoagent 
> -Djava.compiler=NONE 
> -Xrunjdwp:transport=dt_socket,server=y,suspend=n,address=5005
> Listening for transport dt_socket at address: 5005
> Terminate batch job (Y/N)? y
> D:\Dvlpt\Java\workspace-ganymede\x3s\server\apache-felix-karaf-1.2.0-SNAPSHOT\bin>

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



[jira] Commented: (FELIX-1124) ResourceNotFoundException too verbose

2009-06-18 Thread Thomas Diesler (JIRA)

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

Thomas Diesler commented on FELIX-1124:
---

Yes, this should be place. I verified this with framework-1.8.0

Here a sample stacktrace

2009-06-18 13:19:45,074 DEBUG [org.jboss.osgi.felix.framework.FelixLogger] 
META-INF/services/org.apache.xerces.xni.parser.XMLParserConfiguration
org.apache.felix.moduleloader.ResourceNotFoundException: 
META-INF/services/org.apache.xerces.xni.parser.XMLParserConfiguration
at 
org.apache.felix.framework.searchpolicy.ModuleImpl.findClassOrResourceByDelegation(ModuleImpl.java:622)
at 
org.apache.felix.framework.searchpolicy.ModuleImpl.getResourceByDelegation(ModuleImpl.java:488)
at 
org.apache.felix.framework.searchpolicy.ModuleImpl$ModuleClassLoader.getResource(ModuleImpl.java:1631)
at java.lang.ClassLoader.getResourceAsStream(ClassLoader.java:1168)

> ResourceNotFoundException too verbose
> -
>
> Key: FELIX-1124
> URL: https://issues.apache.org/jira/browse/FELIX-1124
> Project: Felix
>  Issue Type: Bug
>  Components: Framework
>Affects Versions: felix-1.6.1, felix-1.8.0
>Reporter: Thomas Diesler
>
> ModuleImpl logs stack traces for every resource that cannot be found. Often 
> resources are optional or may be located at different locations. 
> public URL getResourceByDelegation(String name)
> {
> try
> {
> return (URL) findClassOrResourceByDelegation(name, false);
> }
> catch (ClassNotFoundException ex)
> {
> // This should never be thrown because we are loading resources.
> }
> catch (ResourceNotFoundException ex)
> {
> m_logger.log(
> Logger.LOG_DEBUG,
> ex.getMessage(),
> ex);
> }
> return null;
> }
> Please consider a log message without stack trace and leave it to the client 
> to be more verbose when appropriate. 
> To log no message at all and simply return null would also be consistent with 
> http://java.sun.com/javase/6/docs/api/java/lang/ClassLoader.html#getResource(java.lang.String)

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



[jira] Updated: (FELIX-1124) ResourceNotFoundException too verbose

2009-06-18 Thread Thomas Diesler (JIRA)

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

Thomas Diesler updated FELIX-1124:
--

Affects Version/s: felix-1.8.0

> ResourceNotFoundException too verbose
> -
>
> Key: FELIX-1124
> URL: https://issues.apache.org/jira/browse/FELIX-1124
> Project: Felix
>  Issue Type: Bug
>  Components: Framework
>Affects Versions: felix-1.6.1, felix-1.8.0
>Reporter: Thomas Diesler
>
> ModuleImpl logs stack traces for every resource that cannot be found. Often 
> resources are optional or may be located at different locations. 
> public URL getResourceByDelegation(String name)
> {
> try
> {
> return (URL) findClassOrResourceByDelegation(name, false);
> }
> catch (ClassNotFoundException ex)
> {
> // This should never be thrown because we are loading resources.
> }
> catch (ResourceNotFoundException ex)
> {
> m_logger.log(
> Logger.LOG_DEBUG,
> ex.getMessage(),
> ex);
> }
> return null;
> }
> Please consider a log message without stack trace and leave it to the client 
> to be more verbose when appropriate. 
> To log no message at all and simply return null would also be consistent with 
> http://java.sun.com/javase/6/docs/api/java/lang/ClassLoader.html#getResource(java.lang.String)

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



[jira] Updated: (FELIX-1251) Looping NullPointerException if the polled directory is removed after File Install registration

2009-06-18 Thread Guido Spadotto (JIRA)

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

Guido Spadotto updated FELIX-1251:
--

Attachment: patch-1251.txt

Candidate patch. Recreates the watched directory during the traverse method.

> Looping NullPointerException if the polled directory is removed after File 
> Install registration
> ---
>
> Key: FELIX-1251
> URL: https://issues.apache.org/jira/browse/FELIX-1251
> Project: Felix
>  Issue Type: Bug
>  Components: File Install
>Affects Versions:  fileinstall-1.0.0
> Environment: Windows Vista
>Reporter: Guido Spadotto
>Priority: Minor
> Attachments: patch-1251.txt
>
>
> If the directory being polled by File Install is removed while File Install 
> is running, 
> the method DirectoryWatcher.traverse will raise a NullPointerException
> when evaluating the condition for its "for" loop (the "list" variable  will 
> be null).

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



[jira] Updated: (FELIX-1251) Looping NullPointerException if the polled directory is removed after File Install registration

2009-06-18 Thread Guido Spadotto (JIRA)

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

Guido Spadotto updated FELIX-1251:
--

Description: 
If the directory being polled by File Install is removed while File Install is 
running, 
the method DirectoryWatcher.traverse will raise a NullPointerException
when evaluating the condition for its "for" loop (the "list" variable  will be 
null).



  was:
If the directory being polled by File Install is removed while File Install is 
running, 
the method DirectoryWatcher.traverse will raise a NullPointerException
when evaluating the condition for its "for" loop (the "list" variable  will be 
null).

This is a possible workaround:

void traverse(Map/*  */ jars, Set configs, File jardir)
{
String list[] = jardir.list();
if (list==null){
ConcurrentModificationException cme = new 
ConcurrentModificationException("Unable to list "
+this.watchedDirectory+ " contents. Has it been removed 
after " +
"File Install started?");
throw cme;
}
for (int i = 0; (list!=null) && i < list.length; i++)
{
...

This will not stop the outer loop from logging the Exception though, 
which might not be convenient for the end user.




> Looping NullPointerException if the polled directory is removed after File 
> Install registration
> ---
>
> Key: FELIX-1251
> URL: https://issues.apache.org/jira/browse/FELIX-1251
> Project: Felix
>  Issue Type: Bug
>  Components: File Install
>Affects Versions:  fileinstall-1.0.0
> Environment: Windows Vista
>Reporter: Guido Spadotto
>Priority: Minor
>
> If the directory being polled by File Install is removed while File Install 
> is running, 
> the method DirectoryWatcher.traverse will raise a NullPointerException
> when evaluating the condition for its "for" loop (the "list" variable  will 
> be null).

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



[jira] Created: (FELIX-1253) Cursor is blocked when the correct syntax is not displaed

2009-06-18 Thread Charles Moulliard (JIRA)
Cursor is blocked when the correct syntax is not displaed
-

 Key: FELIX-1253
 URL: https://issues.apache.org/jira/browse/FELIX-1253
 Project: Felix
  Issue Type: Bug
  Components: Karaf
 Environment: WINDOWS
Reporter: Charles Moulliard
 Fix For: karaf-1.0.0
 Attachments: update_screen_karaf.GIF

When I try to update one of the bundle on Apache Karaf Snapshot (running on a 
windows 2000 machine) where level is beside 60, a question is displayed on the 
screen :

You are about to access system bundle 44.  Do you want to continue (yes/no):

If you enter 'yes' or 'no', the cursor moves to the next line otherwise no and 
no error is reported on the screen (see attachment). You cannot use 'enter key' 
and the server is waiting that you enter 'yes or no' instead of y or n by 
example

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



[jira] Updated: (FELIX-1253) Cursor is blocked when the correct syntax is not displaed

2009-06-18 Thread Charles Moulliard (JIRA)

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

Charles Moulliard updated FELIX-1253:
-

Attachment: update_screen_karaf.GIF

> Cursor is blocked when the correct syntax is not displaed
> -
>
> Key: FELIX-1253
> URL: https://issues.apache.org/jira/browse/FELIX-1253
> Project: Felix
>  Issue Type: Bug
>  Components: Karaf
> Environment: WINDOWS
>Reporter: Charles Moulliard
> Fix For: karaf-1.0.0
>
> Attachments: update_screen_karaf.GIF
>
>
> When I try to update one of the bundle on Apache Karaf Snapshot (running on a 
> windows 2000 machine) where level is beside 60, a question is displayed on 
> the screen :
> You are about to access system bundle 44.  Do you want to continue (yes/no):
> If you enter 'yes' or 'no', the cursor moves to the next line otherwise no 
> and no error is reported on the screen (see attachment). You cannot use 
> 'enter key' and the server is waiting that you enter 'yes or no' instead of y 
> or n by example

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



[jira] Commented: (FELIX-1242) Annotation detection does not work when class contains only field-level annotations

2009-06-18 Thread Carsten Ziegeler (JIRA)

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

Carsten Ziegeler commented on FELIX-1242:
-

Yes, if we would do it this way it's maybe not a big deal. But I would like to 
go the other way and ignore the @scr tags if the class has no component tag.
Otherwise it's not possible to prevent a subclass to not inherit the stuff from 
a base class; I think when I added the support for abstract classes I forget 
about the check if the base class has the @scr.component tag. But if we change 
it this way now, this might break existing code.

> Annotation detection does not work when class contains only field-level 
> annotations
> ---
>
> Key: FELIX-1242
> URL: https://issues.apache.org/jira/browse/FELIX-1242
> Project: Felix
>  Issue Type: Bug
>  Components: Maven SCR Plugin
>Affects Versions: maven-scr-plugin-1.2.0
>Reporter: Stefan Seifert
>Priority: Trivial
> Fix For: maven-scr-plugin-1.4.0
>
> Attachments: 090616_detectannotationfix.patch
>
>
> in certain situations java classes contain only field-level SCR annotations 
> (i.e. abstract classes where the real @Component annotations is defined on 
> subclasses).
> in this case, the existing of annotations is not detecting in this class, 
> resulting in ignoring field-level annotations in this abstract class.
> the patch attached [^090616_detectannotationfix.patch] fixes this problem.

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