[jira] [Resolved] (FELIX-5059) Embedd http api bundle in jetty bundle

2015-10-02 Thread Carsten Ziegeler (JIRA) 

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

Carsten Ziegeler resolved FELIX-5059.
-
Resolution: Fixed

Embedded the http.api in rev 1706350
Adjusted itest tests in rev 1706349

> Embedd http api bundle in jetty bundle
> --
>
> Key: FELIX-5059
> URL: https://issues.apache.org/jira/browse/FELIX-5059
> Project: Felix
>  Issue Type: Improvement
>  Components: HTTP Service
>Reporter: Carsten Ziegeler
>Assignee: Carsten Ziegeler
> Fix For: http.jetty-3.1.2
>
>
> As discussed in the mailing list, to make the usage of the http jetty bundle 
> easier and to provide a more consistent bundle, we should embedd the http.api 
> bundle in the http.jetty one.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (FELIX-4946) Updates in service ranking not picked up by filters

2015-10-02 Thread Carsten Ziegeler (JIRA) 

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

Carsten Ziegeler resolved FELIX-4946.
-
   Resolution: Fixed
Fix Version/s: http.jetty-3.1.0

> Updates in service ranking not picked up by filters
> ---
>
> Key: FELIX-4946
> URL: https://issues.apache.org/jira/browse/FELIX-4946
> Project: Felix
>  Issue Type: Bug
>  Components: HTTP Service
>Affects Versions: http-2.3.2, http.jetty-3.0.2
>Reporter: J.W. Janssen
> Fix For: http.jetty-3.1.0
>
>
> If I change the service ranking of a registered filter at runtime, it does 
> not change the order in which the filter chain is executed. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (FELIX-4744) RequestDispatchTest Failure

2015-10-02 Thread Carsten Ziegeler (JIRA) 

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

Carsten Ziegeler resolved FELIX-4744.
-
   Resolution: Fixed
Fix Version/s: http.base-3.0.0
   http.jetty-3.1.0

> RequestDispatchTest Failure
> ---
>
> Key: FELIX-4744
> URL: https://issues.apache.org/jira/browse/FELIX-4744
> Project: Felix
>  Issue Type: Bug
>  Components: HTTP Service
> Environment: source:  trunk branch
> git commit d591b70e9fe2f1441ee61776e49b94629f4c4f35
> $ mvn -version
> Apache Maven 3.2.5 (12a6b3acb947671f09b81f49094c53f426d8cea1; 
> 2014-12-14T12:29:23-05:00)
> Maven home: c:\tools\apache-maven-3.2.5
> Java version: 1.7.0_71, vendor: Oracle Corporation
> Java home: c:\tools\Java\jdk1.7.0_71\jre
> Default locale: en_US, platform encoding: Cp1252
> OS name: "windows vista", version: "6.0", arch: "x86", family: "windows"
>Reporter: Kenneth Freidank
> Fix For: http.jetty-3.1.0, http.base-3.0.0
>
>
> After building the plugins, the build of the bundle fails during the 
> integrated http tests.  There seems to be an added ctrl-M returned from this 
> line in the test RequestDispatchTest::testDispatchForwardToAbsoluteURIOk()
> assertContent("FORWARD\n", createURL("/test/foo?bar=qux"));
> BUILD COMMAND
> mvn -Dpackaging=bundle install
> FAILURE OUTPUT
> ...prior tests passing, then
> Running org.apache.felix.http.itest.RequestDispatchTest
> 37237 [main] INFO org.ops4j.pax.exam.spi.DefaultExamSystem - Pax Exam System 
> (Version: 2.6.0) created.
> 37303 [main] INFO org.ops4j.exec.DefaultJavaRunner - DefaultJavaRunner 
> completed successfully
> ...a few of theses 
> 39308 [main] INFO org.ops4j.exec.DefaultJavaRunner - Platform has been 
> shutdown.
> 39347 [main] INFO org.ops4j.exec.DefaultJavaRunner - DefaultJavaRunner 
> completed successfully
> ...then the failure
> 45428 [main] INFO org.ops4j.exec.DefaultJavaRunner - Platform has been 
> shutdown.
> 45464 [main] INFO org.ops4j.exec.DefaultJavaRunner - DefaultJavaRunner 
> completed successfully
> 45838 [main] INFO org.ops4j.pax.exam.forked.provision.StreamUtils - 
> link:classpath:META-INF/links/org.ops4j.pax.exam.link : downloading...
> 45838 [main] INFO org.ops4j.pax.exam.forked.provision.StreamUtils - 
> link:classpath:META-INF/links/org.ops4j.pax.exam.link : 76805 bytes @ [ 
> 76805kBps ]
> 45869 [main] INFO org.ops4j.pax.exam.forked.provision.StreamUtils - 
> link:classpath:META-INF/links/org.ops4j.pax.exam.rbc.link : downloading...
> 45869 [main] INFO org.ops4j.pax.exam.forked.provision.StreamUtils - 
> link:classpath:META-INF/links/org.ops4j.pax.exam.rbc.link : 46032 bytes @ [ 
> 46032kBps ]
> 45885 [main] INFO org.ops4j.pax.exam.forked.provision.StreamUtils - 
> link:classpath:META-INF/links/org.ops4j.pax.exam.inject.link : downloading...
> 45885 [main] INFO org.ops4j.pax.exam.forked.provision.StreamUtils - 
> link:classpath:META-INF/links/org.ops4j.pax.exam.inject.link : 5472 bytes @ [ 
> 5472kBps ]
> 45885 [main] INFO org.ops4j.pax.exam.forked.provision.StreamUtils - 
> link:classpath:META-INF/links/org.ops4j.pax.extender.service.link : 
> downloading...
> 45885 [main] INFO org.ops4j.pax.exam.forked.provision.StreamUtils - 
> link:classpath:META-INF/links/org.ops4j.pax.extender.service.link : 13016 
> bytes @ [ 13016kBps ]
> 45900 [main] INFO org.ops4j.pax.exam.forked.provision.StreamUtils - 
> link:classpath:META-INF/links/org.osgi.compendium.link : downloading...
> 45900 [main] INFO org.ops4j.pax.exam.forked.provision.StreamUtils - 
> link:classpath:META-INF/links/org.osgi.compendium.link : 614152 bytes @ [ 
> 614152kBps ]
> 45916 [main] INFO org.ops4j.pax.exam.forked.provision.StreamUtils - 
> link:classpath:META-INF/links/org.ops4j.pax.logging.api.link : downloading...
> 45916 [main] INFO org.ops4j.pax.exam.forked.provision.StreamUtils - 
> link:classpath:META-INF/links/org.ops4j.pax.logging.api.link : 96728 bytes @ 
> [ 96728kBps ]
> 45932 [main] INFO org.ops4j.pax.exam.forked.provision.StreamUtils - 
> link:classpath:META-INF/links/org.ops4j.base.link : downloading...
> 45932 [main] INFO org.ops4j.pax.exam.forked.provision.StreamUtils - 
> link:classpath:META-INF/links/org.ops4j.base.link : 97938 bytes @ [ 97938kBps 
> ]
> 45932 [main] INFO org.ops4j.pax.exam.forked.provision.StreamUtils - 
> link:classpath:META-INF/links/org.ops4j.pax.swissbox.core.link : 
> downloading...
> 45932 [main] INFO org.ops4j.pax.exam.forked.provision.StreamUtils - 
> link:classpath:META-INF/links/org.ops4j.pax.swissbox.core.link : 8749 bytes @ 
> [ 8749kBps ]
> 45947 [main] INFO org.ops4j.pax.exam.forked.provision.StreamUtils - 
> link:classpath:META-INF/links/org.ops4j.pax.swissbox.extender.link : 
> downloading...
> 45947 [main] INFO org.ops4j.pax.exam.forked.provision.StreamUtils - 
>

[jira] [Resolved] (FELIX-4645) Service already unregistered exception from HttpServicePlugin

2015-10-02 Thread Carsten Ziegeler (JIRA) 

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

Carsten Ziegeler resolved FELIX-4645.
-
   Resolution: Fixed
Fix Version/s: http.jetty-3.1.0

> Service already unregistered exception from HttpServicePlugin
> -
>
> Key: FELIX-4645
> URL: https://issues.apache.org/jira/browse/FELIX-4645
> Project: Felix
>  Issue Type: Bug
>  Components: HTTP Service
>Reporter: Arjan Schaaf
> Fix For: http.jetty-3.1.0
>
>
> Running into the following stacktrace after the Felix target received an 
> update from its Apache ACE server (stopunaffectedbundles is set to true)
> http.jetty 2.2.2 bundle
> {code}
> 2014-09-17 20:19:34.973:WARN:oejs.ServletHolder:
> java.lang.IllegalStateException: Service already unregistered.
> at 
> org.apache.felix.framework.ServiceRegistrationImpl.unregister(ServiceRegistrationImpl.java:123)
> at 
> org.apache.felix.http.base.internal.handler.HttpServicePlugin.unregister(HttpServicePlugin.java:189)
> at 
> org.apache.felix.http.base.internal.HttpServiceController.unregister(HttpServiceController.java:153)
> at 
> org.apache.felix.http.base.internal.DispatcherServlet.destroy(DispatcherServlet.java:54)
> at 
> org.eclipse.jetty.servlet.ServletHolder.destroyInstance(ServletHolder.java:344)
> at 
> org.eclipse.jetty.servlet.ServletHolder.doStop(ServletHolder.java:317)
> at 
> org.eclipse.jetty.util.component.AbstractLifeCycle.stop(AbstractLifeCycle.java:89)
> at 
> org.eclipse.jetty.servlet.ServletHandler.doStop(ServletHandler.java:204)
> at 
> org.eclipse.jetty.util.component.AbstractLifeCycle.stop(AbstractLifeCycle.java:89)
> at 
> org.eclipse.jetty.server.handler.HandlerWrapper.doStop(HandlerWrapper.java:107)
> at 
> org.eclipse.jetty.server.session.SessionHandler.doStop(SessionHandler.java:132)
> at 
> org.eclipse.jetty.util.component.AbstractLifeCycle.stop(AbstractLifeCycle.java:89)
> at 
> org.eclipse.jetty.server.handler.HandlerWrapper.doStop(HandlerWrapper.java:107)
> at 
> org.eclipse.jetty.server.handler.ContextHandler.doStop(ContextHandler.java:777)
> at 
> org.eclipse.jetty.servlet.ServletContextHandler.doStop(ServletContextHandler.java:149)
> at 
> org.eclipse.jetty.util.component.AbstractLifeCycle.stop(AbstractLifeCycle.java:89)
> at 
> org.eclipse.jetty.server.handler.HandlerCollection.doStop(HandlerCollection.java:250)
> at 
> org.eclipse.jetty.util.component.AbstractLifeCycle.stop(AbstractLifeCycle.java:89)
> at 
> org.eclipse.jetty.server.handler.HandlerWrapper.doStop(HandlerWrapper.java:107)
> at org.eclipse.jetty.server.Server.doStop(Server.java:342)
> at 
> org.eclipse.jetty.util.component.AbstractLifeCycle.stop(AbstractLifeCycle.java:89)
> at 
> org.apache.felix.http.jetty.internal.JettyService.stopJetty(JettyService.java:228)
> at 
> org.apache.felix.http.jetty.internal.JettyService.access$100(JettyService.java:72)
> at 
> org.apache.felix.http.jetty.internal.JettyService$3.doExecute(JettyService.java:169)
> at 
> org.apache.felix.http.jetty.internal.JettyService$JettyOperation.call(JettyService.java:792)
> at 
> org.apache.felix.http.jetty.internal.JettyService$JettyOperation.call(JettyService.java:783)
> at java.util.concurrent.FutureTask.run(FutureTask.java:262)
> at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:745)
> 2014-09-17 20:19:34.974:INFO:oejsh.ContextHandler:stopped 
> o.e.j.s.ServletContextHandler{/,null}
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (FELIX-4589) Problem with forwarding from one servlet to another

2015-10-02 Thread Carsten Ziegeler (JIRA) 

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

Carsten Ziegeler resolved FELIX-4589.
-
Resolution: Won't Fix

> Problem with forwarding from one servlet to another
> ---
>
> Key: FELIX-4589
> URL: https://issues.apache.org/jira/browse/FELIX-4589
> Project: Felix
>  Issue Type: Bug
>  Components: HTTP Service
>Affects Versions: http-2.3.0
>Reporter: Victor Bashurov
>
> Like in an issue FELIX-2774 
> (https://issues.apache.org/jira/browse/FELIX-2774) I'd like to have a several 
> servlet bunles installed with embedded OSGI framework. I'm using servlet 
> bridge for request's management between sevlets bundles. In order to pass the 
> information between servlets I want to use request dispatcher to forward (or 
> include) http queries from one servlet to another. 
> Even when I have two servlets registered in one bundle I cannot make a 
> forwarding from one servlet to another.
> ServiceTracker
> httpService.registerServlet(TestServlet.SERVLET_ALIAS,new 
> TestServlet("Test servlet"), null, null);   
> httpService.registerServlet(ForwardServlet.SERVLET_ALIAS,   new 
> ForwardServlet("Forward servlet"), null, null);
> Trying to do the following in a TestServlet doGet method will cause error:
> RequestDispatcher rd = 
> getServletContext().getRequestDispatcher(ForwardServlet.SERVLET_ALIAS);
> rd.forward(req, res);
> For org.apache.felix.http.bridge-2.0.2.jar error will be NullPointerException 
> on 'rd' variable, for version 2.2.0 the same, but for version 2.3.0 it's 
> going to be endless loop and stackoverflow error.
> More code about the problem here: https://bitbucket.org/vbashur/diff/src 
> (servletbundle project)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (FELIX-4415) Cannot associate HttpService instance with ServletContext

2015-10-02 Thread Carsten Ziegeler (JIRA) 

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

Carsten Ziegeler resolved FELIX-4415.
-
Resolution: Implemented

The endpoint is mandatory and might also be relative, therefore resolving this 
issue

> Cannot associate HttpService instance with ServletContext
> -
>
> Key: FELIX-4415
> URL: https://issues.apache.org/jira/browse/FELIX-4415
> Project: Felix
>  Issue Type: Bug
>  Components: HTTP Service
>Affects Versions: http-2.2.1
>Reporter: Thomas Diesler
>
> A tracker like this
> {code}
> tracker = new ServiceTracker(context, 
> HttpService.class, null) {
> @Override
> public HttpService addingService(ServiceReference 
> sref) {
> httpService = super.addingService(sref);
> registerHttpServiceServlet();
> return httpService;
> }
> };
> tracker.open();
> {code}
> cannot associate an HttpService instance with the servlet context that 
> registered it. Adding the contextPath as service property would be a possible 
> solution.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (FELIX-3104) Registering/unregistering HttpService with CometdServiceImpl repeatedly causes ClassCastException

2015-10-02 Thread Carsten Ziegeler (JIRA) 

[ 
https://issues.apache.org/jira/browse/FELIX-3104?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14940829#comment-14940829
 ] 

Carsten Ziegeler commented on FELIX-3104:
-

[~jsedding] Is this still a problem with the latest version?

> Registering/unregistering HttpService with CometdServiceImpl repeatedly 
> causes ClassCastException
> -
>
> Key: FELIX-3104
> URL: https://issues.apache.org/jira/browse/FELIX-3104
> Project: Felix
>  Issue Type: Bug
>  Components: HTTP Service
>Affects Versions: http-2.2.0
>Reporter: Julian Sedding
>Assignee: Felix Meschberger
>Priority: Minor
> Attachments: FELIX-3104-fmeschbe.patch, FELIX-3104.patch
>
>
> CometdServiceImpl uses 
> org.mortbay.cometd.continuation.ContinuationCometdServlet in its 
> implementation, which in turn extends 
> org.mortbay.cometd.AbstractCometdServlet. AbstractCometdServlet places a 
> Bayeux object in a servlet context attribute in its init() method, but never 
> cleans it up on destroy(). This can lead to a ClassCastException if the 
> servlet's init() method is called repeatedly, and the ClassLoader used to 
> create the object stored in the servlet context attribute is not the same 
> that was used to load the AbstractCometdServlet class. However, this is what 
> seems to happen if the cometd bundle is restarted (may only be the case with 
> the patch from FELIX-3102 applied).



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (FELIX-1963) Add possibility to share ServletContext between bundles

2015-10-02 Thread Carsten Ziegeler (JIRA) 

[ 
https://issues.apache.org/jira/browse/FELIX-1963?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14940824#comment-14940824
 ] 

Carsten Ziegeler commented on FELIX-1963:
-

[~srs] Is this still an issue with the latest http whiteboard implementation?

> Add possibility to share ServletContext between bundles
> ---
>
> Key: FELIX-1963
> URL: https://issues.apache.org/jira/browse/FELIX-1963
> Project: Felix
>  Issue Type: New Feature
>  Components: HTTP Service
>Affects Versions: http-2.0.4
>Reporter: Sten Roger Sandvik
>Assignee: Sten Roger Sandvik
>
> Check out the possibility to share ServletContext between bundles. If 
> ServletContextManager is global instead of local to each bundle then it 
> chould be done. If you want to share ServletContext each HttpContext must 
> implement equals method that ensures equality.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (FELIX-4923) SslFilterResponse doesn 't take in account ssl-forward.header property

2015-10-02 Thread Carsten Ziegeler (JIRA) 

[ 
https://issues.apache.org/jira/browse/FELIX-4923?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14940826#comment-14940826
 ] 

Carsten Ziegeler commented on FELIX-4923:
-

[~asanso] Is this still an issue?

> SslFilterResponse doesn 't take in account ssl-forward.header property
> --
>
> Key: FELIX-4923
> URL: https://issues.apache.org/jira/browse/FELIX-4923
> Project: Felix
>  Issue Type: Bug
>  Components: HTTP Service
>Reporter: Antonio Sanso
>Priority: Minor
>
> {{SslFilterResponse}} doesn 't take in account {{ssl-forward}}.header 
> property.
> Indeed the {{SslFilterResponse}} constructor hardcodes 
> {{HDR_X_FORWARDED_PROTO}}.
> {code}
> ...
> request.getHeader(HDR_X_FORWARDED_PROTO);
> ...
> {code}
> the  {{ssl-forward}} osgin configuration should be taken in account IMHO. The 
> default is even different than {{HDR_X_FORWARDED_PROTO}} indeed is rather 
> {{X-Forwarded-SSL}}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (FELIX-4706) Provide way to override Jetty's error pages for status other than 200

2015-10-02 Thread Carsten Ziegeler (JIRA) 

[ 
https://issues.apache.org/jira/browse/FELIX-4706?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14940827#comment-14940827
 ] 

Carsten Ziegeler commented on FELIX-4706:
-

Error pages can be registered using the http whiteboard service (OSGi R6). I 
think this should solve this problem

> Provide way to override Jetty's error pages for status other than 200
> -
>
> Key: FELIX-4706
> URL: https://issues.apache.org/jira/browse/FELIX-4706
> Project: Felix
>  Issue Type: Wish
>  Components: HTTP Service
>Reporter: Sarwar Bhuiyan
>Priority: Minor
>
> I'm trying to use JAX-RS and Jackson in Felix and have so far been successful 
> in registering Resource classes which respond to requests but one problem I 
> have is that when the error response body needs to be set, Jetty is showing 
> its own error html pages and not the entity I'm setting in the body. Is there 
> a way of turning that off or overriding that behaviour?



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (FELIX-4923) SslFilterResponse doesn 't take in account ssl-forward.header property

2015-10-02 Thread Antonio Sanso (JIRA) 

[ 
https://issues.apache.org/jira/browse/FELIX-4923?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14940832#comment-14940832
 ] 

Antonio Sanso commented on FELIX-4923:
--

[~cziegeler] I'd say so

> SslFilterResponse doesn 't take in account ssl-forward.header property
> --
>
> Key: FELIX-4923
> URL: https://issues.apache.org/jira/browse/FELIX-4923
> Project: Felix
>  Issue Type: Bug
>  Components: HTTP Service
>Reporter: Antonio Sanso
>Priority: Minor
>
> {{SslFilterResponse}} doesn 't take in account {{ssl-forward}}.header 
> property.
> Indeed the {{SslFilterResponse}} constructor hardcodes 
> {{HDR_X_FORWARDED_PROTO}}.
> {code}
> ...
> request.getHeader(HDR_X_FORWARDED_PROTO);
> ...
> {code}
> the  {{ssl-forward}} osgin configuration should be taken in account IMHO. The 
> default is even different than {{HDR_X_FORWARDED_PROTO}} indeed is rather 
> {{X-Forwarded-SSL}}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: [VOTE] Release Apache Felix Gogo Shell 0.12.0 and Command 0.16.0

2015-10-02 Thread davidb 
Here's my +1

David

On 1 October 2015 at 10:42,   wrote:
> Hi all,
>
> I'm calling a vote on the following bundles:
>
> Felix Gogo Shell 0.12.0
> ** Improvement
> * FELIX-5021 [GOGO] Use system bundle to find bundles
> * FELIX-4529 [Gogo] Let gosh be configured by files contributed by
> a bundle fragment
> * FELIX-3341 Simple csh-like Command History
> * FELIX-3340 Allow the prompt to be a Function
>
> ** Bug
> * FELIX-4425 Short command in Gogo Shell not working with Java 8
> * FELIX-3706 gogo shell startup failure in busy system
> * FELIX-3703 Race condition in gogo runtime activator
>
> Felix Gogo Command 0.16.0
> ** Improvement
> * FELIX-5021 [GOGO] Use system bundle to find bundles
> * FELIX-5009 Relative URIs would be nice for install and update
> * FELIX-5008 gogo usage messages could be less confusing
> * FELIX-3499 felix:cd command works only with relative paths
>
> ** Bug
> * FELIX-4969 cd refuses to leave initial directory
>
> Note that not changes have been made to the Felix Gogo Runtime bundle
> since the last release.
>
> Staging repository:
> https://repository.apache.org/content/repositories/orgapachefelix-1096
>
> You can use this UNIX script to download the release and verify the 
> signatures:
> http://svn.apache.org/repos/asf/felix/trunk/check_staged_release.sh
>
> Usage:
> sh check_staged_release.sh 1096 /tmp/felix-gogo-check
>
> Please vote to approve this release:
>
> [ ] +1 Approve the release
> [ ] -1 Veto the release (please provide specific comments)
>
> This vote will remain open for at least 72 hours.
>
> Best regards,
>
> David Bosschaert

[jira] [Resolved] (FELIX-5060) Unnecessary import of org.osgi.service.component

2015-10-02 Thread Carsten Ziegeler (JIRA) 

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

Carsten Ziegeler resolved FELIX-5060.
-
Resolution: Fixed

Nothing to commit as the import is not there anymore. I assume something went 
wrong with the 4.2.12 release

> Unnecessary import of org.osgi.service.component
> 
>
> Key: FELIX-5060
> URL: https://issues.apache.org/jira/browse/FELIX-5060
> Project: Felix
>  Issue Type: Bug
>  Components: Web Console
>Affects Versions: webconsole-4.2.12
>Reporter: Carsten Ziegeler
>Assignee: Carsten Ziegeler
> Fix For: webconsole-4.2.14
>
>
> For an unknown reason the webconsole has an import to 
> org.osgi.service.component which it should not have as no code is using DS 
> within the webconsole



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[VOTE] Release Apache Felix WebConsole 4.2.14

2015-10-02 Thread Carsten Ziegeler 
I would like to call a vote for a new web console release:
We fixed two issues:
https://issues.apache.org/jira/browse/FELIX/fixforversion/12333546

Staging repositories:
https://repository.apache.org/content/repositories/orgapachefelix-1097/

You can use this UNIX script to download the release and verify the
signatures:
http://svn.apache.org/repos/asf/felix/trunk/check_staged_release.sh

Usage:
sh check_staged_release.sh 10697 /tmp/felix-staging

Please vote to approve this release:

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

Regards
Carsten
-- 
Carsten Ziegeler
Adobe Research Switzerland
cziege...@apache.org

Re: [VOTE] Release Apache Felix WebConsole 4.2.14

2015-10-02 Thread David Bosschaert 
+1

David

On 2 October 2015 at 16:28, Carsten Ziegeler  wrote:
> I would like to call a vote for a new web console release:
> We fixed two issues:
> https://issues.apache.org/jira/browse/FELIX/fixforversion/12333546
>
> Staging repositories:
> https://repository.apache.org/content/repositories/orgapachefelix-1097/
>
> You can use this UNIX script to download the release and verify the
> signatures:
> http://svn.apache.org/repos/asf/felix/trunk/check_staged_release.sh
>
> Usage:
> sh check_staged_release.sh 10697 /tmp/felix-staging
>
> Please vote to approve this release:
>
> [ ] +1 Approve the release
> [ ] -1 Veto the release (please provide specific comments)
>
> Regards
> Carsten
> --
> Carsten Ziegeler
> Adobe Research Switzerland
> cziege...@apache.org

Re: [VOTE] Release Apache Felix WebConsole 4.2.14

2015-10-02 Thread Carsten Ziegeler 
+1


-- 
Carsten Ziegeler
Adobe Research Switzerland
cziege...@apache.org

[jira] [Created] (FELIX-5060) Unnecessary import of org.osgi.service.component

2015-10-02 Thread Carsten Ziegeler (JIRA) 
Carsten Ziegeler created FELIX-5060:
---

 Summary: Unnecessary import of org.osgi.service.component
 Key: FELIX-5060
 URL: https://issues.apache.org/jira/browse/FELIX-5060
 Project: Felix
  Issue Type: Bug
  Components: Web Console
Affects Versions: webconsole-4.2.12
Reporter: Carsten Ziegeler
Assignee: Carsten Ziegeler
 Fix For: webconsole-4.2.14


For an unknown reason the webconsole has an import to 
org.osgi.service.component which it should not have as no code is using DS 
within the webconsole



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (FELIX-3104) Registering/unregistering HttpService with CometdServiceImpl repeatedly causes ClassCastException

2015-10-02 Thread Carsten Ziegeler (JIRA) 

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

Carsten Ziegeler resolved FELIX-3104.
-
Resolution: Won't Fix

> Registering/unregistering HttpService with CometdServiceImpl repeatedly 
> causes ClassCastException
> -
>
> Key: FELIX-3104
> URL: https://issues.apache.org/jira/browse/FELIX-3104
> Project: Felix
>  Issue Type: Bug
>  Components: HTTP Service
>Affects Versions: http-2.2.0
>Reporter: Julian Sedding
>Assignee: Felix Meschberger
>Priority: Minor
> Attachments: FELIX-3104-fmeschbe.patch, FELIX-3104.patch
>
>
> CometdServiceImpl uses 
> org.mortbay.cometd.continuation.ContinuationCometdServlet in its 
> implementation, which in turn extends 
> org.mortbay.cometd.AbstractCometdServlet. AbstractCometdServlet places a 
> Bayeux object in a servlet context attribute in its init() method, but never 
> cleans it up on destroy(). This can lead to a ClassCastException if the 
> servlet's init() method is called repeatedly, and the ClassLoader used to 
> create the object stored in the servlet context attribute is not the same 
> that was used to load the AbstractCometdServlet class. However, this is what 
> seems to happen if the cometd bundle is restarted (may only be the case with 
> the patch from FELIX-3102 applied).



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (FELIX-3104) Registering/unregistering HttpService with CometdServiceImpl repeatedly causes ClassCastException

2015-10-02 Thread Julian Sedding (JIRA) 

[ 
https://issues.apache.org/jira/browse/FELIX-3104?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14940943#comment-14940943
 ] 

Julian Sedding commented on FELIX-3104:
---

[~cziegeler] I don't know. I have not used Cometd since 2011. I'm fine with 
closing this issue. If someone stumbles over the same issue, it can always be 
re-opened.

> Registering/unregistering HttpService with CometdServiceImpl repeatedly 
> causes ClassCastException
> -
>
> Key: FELIX-3104
> URL: https://issues.apache.org/jira/browse/FELIX-3104
> Project: Felix
>  Issue Type: Bug
>  Components: HTTP Service
>Affects Versions: http-2.2.0
>Reporter: Julian Sedding
>Assignee: Felix Meschberger
>Priority: Minor
> Attachments: FELIX-3104-fmeschbe.patch, FELIX-3104.patch
>
>
> CometdServiceImpl uses 
> org.mortbay.cometd.continuation.ContinuationCometdServlet in its 
> implementation, which in turn extends 
> org.mortbay.cometd.AbstractCometdServlet. AbstractCometdServlet places a 
> Bayeux object in a servlet context attribute in its init() method, but never 
> cleans it up on destroy(). This can lead to a ClassCastException if the 
> servlet's init() method is called repeatedly, and the ClassLoader used to 
> create the object stored in the servlet context attribute is not the same 
> that was used to load the AbstractCometdServlet class. However, this is what 
> seems to happen if the cometd bundle is restarted (may only be the case with 
> the patch from FELIX-3102 applied).



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: [VOTE] Release Apache Felix WebConsole 4.2.14

2015-10-02 Thread Carsten Ziegeler 
Am 02.10.15 um 17:27 schrieb Pierre De Rop:
> Hello Carsten,
> 
> There is something that I don't understand regarding the FELIX-5060
>  issue:
> 
> Indeed, the org.osgi.service.component package is not imported anymore from
> the binary artifact (in
> /tmp/felix-staging/1097/org/apache/felix/org.apache.felix.webconsole/4.2.14/org.apache.felix.webconsole-4.2.14.jar).
> So, it's Ok for the binary artifact.
> 
> However, after rebuilding the binary from the sources, the package is again
> imported, and it is because the BundlesServlet class is importing the
> org.osgi.service.component.ComponentConstants).
> 
> So, shouldn't the BundlesServlet be modified in order to not depend anymore
> on the ComponentConstants from the DS API ?
> 
Thanks Pierre for finding this. Yes, we should remove it - I'll take
care of it.
I don't think we have to redo the 4.2.14 as the binary is fine. WDYT?

Interestingly, it seems to have to do with your build environment,
whether the import ends up in the manifest or not. If I build on my
machine, java 7, it's not there.

Carsten
-- 
Carsten Ziegeler
Adobe Research Switzerland
cziege...@apache.org

[jira] [Commented] (FELIX-5061) Optional resource fragment with requirements that cause class space consistency issues with the host export cause unexpected ResolutionExceptions

2015-10-02 Thread Thomas Watson (JIRA) 

[ 
https://issues.apache.org/jira/browse/FELIX-5061?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14941336#comment-14941336
 ] 

Thomas Watson commented on FELIX-5061:
--

I did add a new testcase to Equinox for this case.  You can find it in the 
twatson/newResolver branch as I described in FELIX-4987

> Optional resource fragment with requirements that cause class space 
> consistency issues with the host export cause unexpected ResolutionExceptions
> -
>
> Key: FELIX-5061
> URL: https://issues.apache.org/jira/browse/FELIX-5061
> Project: Felix
>  Issue Type: Bug
>  Components: Resolver
>Affects Versions: resolver-1.6.0
>Reporter: Thomas Watson
> Attachments: FELIX-5061.patch
>
>
> Not sure if this is actually a bug in version 1.6.0.  I am testing with the 
> latest out of trunk so it could be something after 1.6.0.
> If a fragment contains a requirement that ultimately causes a uses constraint 
> conflict with one of the hosts exported packages then the resolver will end 
> up throwing a ResolutionExceptoin even when the fragment and host are 
> considered to be optional resources by the ResolverContext.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (FELIX-5061) Optional resource fragment with requirements that cause class space consistency issues with the host export cause unexpected ResolutionExceptions

2015-10-02 Thread Thomas Watson (JIRA) 
Thomas Watson created FELIX-5061:


 Summary: Optional resource fragment with requirements that cause 
class space consistency issues with the host export cause unexpected 
ResolutionExceptions
 Key: FELIX-5061
 URL: https://issues.apache.org/jira/browse/FELIX-5061
 Project: Felix
  Issue Type: Bug
  Components: Resolver
Affects Versions: resolver-1.6.0
Reporter: Thomas Watson


Not sure if this is actually a bug in version 1.6.0.  I am testing with the 
latest out of trunk so it could be something after 1.6.0.

If a fragment contains a requirement that ultimately causes a uses constraint 
conflict with one of the hosts exported packages then the resolver will end up 
throwing a ResolutionExceptoin even when the fragment and host are considered 
to be optional resources by the ResolverContext.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: [VOTE] Release Apache Felix WebConsole 4.2.14

2015-10-02 Thread Pierre De Rop 
Hello Carsten,

There is something that I don't understand regarding the FELIX-5060
 issue:

Indeed, the org.osgi.service.component package is not imported anymore from
the binary artifact (in
/tmp/felix-staging/1097/org/apache/felix/org.apache.felix.webconsole/4.2.14/org.apache.felix.webconsole-4.2.14.jar).
So, it's Ok for the binary artifact.

However, after rebuilding the binary from the sources, the package is again
imported, and it is because the BundlesServlet class is importing the
org.osgi.service.component.ComponentConstants).

So, shouldn't the BundlesServlet be modified in order to not depend anymore
on the ComponentConstants from the DS API ?

thanks;


BR
/pierre



On Fri, Oct 2, 2015 at 4:37 PM, David Bosschaert  wrote:

> +1
>
> David
>
> On 2 October 2015 at 16:28, Carsten Ziegeler  wrote:
> > I would like to call a vote for a new web console release:
> > We fixed two issues:
> > https://issues.apache.org/jira/browse/FELIX/fixforversion/12333546
> >
> > Staging repositories:
> > https://repository.apache.org/content/repositories/orgapachefelix-1097/
> >
> > You can use this UNIX script to download the release and verify the
> > signatures:
> > http://svn.apache.org/repos/asf/felix/trunk/check_staged_release.sh
> >
> > Usage:
> > sh check_staged_release.sh 10697 /tmp/felix-staging
> >
> > Please vote to approve this release:
> >
> > [ ] +1 Approve the release
> > [ ] -1 Veto the release (please provide specific comments)
> >
> > Regards
> > Carsten
> > --
> > Carsten Ziegeler
> > Adobe Research Switzerland
> > cziege...@apache.org
>

Re: [VOTE] Release Apache Felix WebConsole 4.2.14

2015-10-02 Thread Carsten Ziegeler 
Am 02.10.15 um 17:38 schrieb Carsten Ziegeler:

> 
> Interestingly, it seems to have to do with your build environment,
> whether the import ends up in the manifest or not. If I build on my
> machine, java 7, it's not there.
> 
And with java 8 it is there, so it really depends on the java version
you build with :(

Regards
Carsten
-- 
Carsten Ziegeler
Adobe Research Switzerland
cziege...@apache.org

[jira] [Comment Edited] (FELIX-5061) Optional resource fragment with requirements that cause class space consistency issues with the host export cause unexpected ResolutionExceptions

2015-10-02 Thread Thomas Watson (JIRA) 

[ 
https://issues.apache.org/jira/browse/FELIX-5061?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14941302#comment-14941302
 ] 

Thomas Watson edited comment on FELIX-5061 at 10/2/15 4:08 PM:
---

Here is a possible fix.  The issue is the loop used to call  
ResolverImpl.checkPackageSpaceConsistency changed to only loop over host 
resources.  I like that change and do not suggest that we change that.

Before it used to loop over all the 'seed' resources and check their 
consistency.  This included any fragments that are mandatory or optional 
resources according to the ResolveContext.  When checking the consistency of 
the fragment the impl would first find its hosts and do the check on the host, 
but the original fragment resource was kept for the faulty resource and could 
therefore be optionally removed from the resolution and we would retry 
resolution without the fragment.

Now we have lost the context of the fragment seeds and only have their hosts 
and that causes the issues.  At first I was thinking we needed to somehow bring 
the context back for the fragment during the consistency check, but that proved 
to be overcomplicated.

Instead I decided to fix an issue with the UseConstraintError so that we report 
back the Requirement that is to blame for the conflict with the host export.  
That way the bit of code in ResolverImpl.checkConsistency that finds the faulty 
resource will correctly detect faultyReq is a WrappedRequirement from a 
fragment resource.

This also fixes an existing issue in the prior implementation that would end up 
throwing out the host as well even though it could have resolved the host once 
the fragment was removed from resolution.


was (Author: tjwatson):
Here is a possible fix.  The issue is the loop used to call  
ResolverImpl.checkPackageSpaceConsistency changed to only loop over host 
resources.  I like that change and do not suggest that we change that.

Before it use to loop over all the 'seed' resources and check their 
consistency.  This included any fragments that would mandatory or optional 
resources.  When checking the consistency of the fragment the impl would first 
find its hosts and do the check on the host, but the original fragment resource 
was kept for the faulty resource and could therefore be optionally removed from 
the resolution and we would retry.

Now we have lost the context of the fragment seeds and only have their hosts 
and that causes the issues.  At first I was thinking we needed to somehow bring 
the context back for the fragment during the consistency check, but that proved 
to be overcomplicated.

Instead I decided to fix an issue with the UseConstraintError so that we report 
back the Requirement that is to blame for the conflict with the host export.  
That way the bit of code ResolverImpl.checkConsistency the finds the faulty 
will correctly detect faultyReq is a WrappedRequirement from a fragment bundle.

> Optional resource fragment with requirements that cause class space 
> consistency issues with the host export cause unexpected ResolutionExceptions
> -
>
> Key: FELIX-5061
> URL: https://issues.apache.org/jira/browse/FELIX-5061
> Project: Felix
>  Issue Type: Bug
>  Components: Resolver
>Affects Versions: resolver-1.6.0
>Reporter: Thomas Watson
> Attachments: FELIX-5061.patch
>
>
> Not sure if this is actually a bug in version 1.6.0.  I am testing with the 
> latest out of trunk so it could be something after 1.6.0.
> If a fragment contains a requirement that ultimately causes a uses constraint 
> conflict with one of the hosts exported packages then the resolver will end 
> up throwing a ResolutionExceptoin even when the fragment and host are 
> considered to be optional resources by the ResolverContext.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (FELIX-5061) Optional resource fragment with requirements that cause class space consistency issues with the host export cause unexpected ResolutionExceptions

2015-10-02 Thread Thomas Watson (JIRA) 

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

Thomas Watson updated FELIX-5061:
-
Attachment: FELIX-5061.patch

Here is a possible fix.  The issue is the loop used to call  
ResolverImpl.checkPackageSpaceConsistency changed to only loop over host 
resources.  I like that change and do not suggest that we change that.

Before it use to loop over all the 'seed' resources and check their 
consistency.  This included any fragments that would mandatory or optional 
resources.  When checking the consistency of the fragment the impl would first 
find its hosts and do the check on the host, but the original fragment resource 
was kept for the faulty resource and could therefore be optionally removed from 
the resolution and we would retry.

Now we have lost the context of the fragment seeds and only have their hosts 
and that causes the issues.  At first I was thinking we needed to somehow bring 
the context back for the fragment during the consistency check, but that proved 
to be overcomplicated.

Instead I decided to fix an issue with the UseConstraintError so that we report 
back the Requirement that is to blame for the conflict with the host export.  
That way the bit of code ResolverImpl.checkConsistency the finds the faulty 
will correctly detect faultyReq is a WrappedRequirement from a fragment bundle.

> Optional resource fragment with requirements that cause class space 
> consistency issues with the host export cause unexpected ResolutionExceptions
> -
>
> Key: FELIX-5061
> URL: https://issues.apache.org/jira/browse/FELIX-5061
> Project: Felix
>  Issue Type: Bug
>  Components: Resolver
>Affects Versions: resolver-1.6.0
>Reporter: Thomas Watson
> Attachments: FELIX-5061.patch
>
>
> Not sure if this is actually a bug in version 1.6.0.  I am testing with the 
> latest out of trunk so it could be something after 1.6.0.
> If a fragment contains a requirement that ultimately causes a uses constraint 
> conflict with one of the hosts exported packages then the resolver will end 
> up throwing a ResolutionExceptoin even when the fragment and host are 
> considered to be optional resources by the ResolverContext.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: [VOTE] Release Apache Felix Gogo Shell 0.12.0 and Command 0.16.0

2015-10-02 Thread David Jencks 
Hi David,

Well, I was sort of hoping you’d figure out a way to release the sources bundle 
too :-).  However I can create my own for my needs.  I’ve now tested the fixes 
I added and they seem to work, so, at long last,

+1

thanks
david jencks


> On Oct 1, 2015, at 6:25 PM, dav...@apache.org wrote:
> 
> Hi David,
> 
> I didn't change the build process for these artifacts, so I guess they
> were released like this before. In any case, the important artifacts
> are there. We can change the produced artifacts for a future release,
> but I don't think this is important enough to cancel this one.
> 
> BTW I can't count your email as a +1 or -1, so please indicate how you
> actually vote here.
> 
> Thanks,
> 
> David
> 
> On 1 October 2015 at 18:19, David Jencks  
> wrote:
>> sigs look good, I can build the project tar.gzs.
>> 
>> The selection of artifacts looks a bit bizarre to me.  I don’t see a sources 
>> bundle for org.apache.felix.gogo.command-0.16.0 and I can’t imagine what the 
>> bin artifacts are for.  Is this all intentional?
>> I’d really prefer there be a org.apache.felix.gogo.command-0.16.0-sources.jar
>> 
>> thanks for undertaking this release :-)
>> 
>> david jencks
>> 
>>> On Oct 1, 2015, at 4:42 AM, dav...@apache.org wrote:
>>> 
>>> Hi all,
>>> 
>>> I'm calling a vote on the following bundles:
>>> 
>>> Felix Gogo Shell 0.12.0
>>> ** Improvement
>>>   * FELIX-5021 [GOGO] Use system bundle to find bundles
>>>   * FELIX-4529 [Gogo] Let gosh be configured by files contributed by
>>> a bundle fragment
>>>   * FELIX-3341 Simple csh-like Command History
>>>   * FELIX-3340 Allow the prompt to be a Function
>>> 
>>> ** Bug
>>>   * FELIX-4425 Short command in Gogo Shell not working with Java 8
>>>   * FELIX-3706 gogo shell startup failure in busy system
>>>   * FELIX-3703 Race condition in gogo runtime activator
>>> 
>>> Felix Gogo Command 0.16.0
>>> ** Improvement
>>>   * FELIX-5021 [GOGO] Use system bundle to find bundles
>>>   * FELIX-5009 Relative URIs would be nice for install and update
>>>   * FELIX-5008 gogo usage messages could be less confusing
>>>   * FELIX-3499 felix:cd command works only with relative paths
>>> 
>>> ** Bug
>>>   * FELIX-4969 cd refuses to leave initial directory
>>> 
>>> Note that not changes have been made to the Felix Gogo Runtime bundle
>>> since the last release.
>>> 
>>> Staging repository:
>>> https://repository.apache.org/content/repositories/orgapachefelix-1096
>>> 
>>> You can use this UNIX script to download the release and verify the 
>>> signatures:
>>> http://svn.apache.org/repos/asf/felix/trunk/check_staged_release.sh
>>> 
>>> Usage:
>>> sh check_staged_release.sh 1096 /tmp/felix-gogo-check
>>> 
>>> Please vote to approve this release:
>>> 
>>> [ ] +1 Approve the release
>>> [ ] -1 Veto the release (please provide specific comments)
>>> 
>>> This vote will remain open for at least 72 hours.
>>> 
>>> Best regards,
>>> 
>>> David Bosschaert
>>

Re: [VOTE] Release Apache Felix Gogo Shell 0.12.0 and Command 0.16.0

2015-10-02 Thread Benson Margulies 
I could take a look at this for the next iteration.


On Fri, Oct 2, 2015 at 12:41 PM, David Jencks
 wrote:
> Hi David,
>
> Well, I was sort of hoping you’d figure out a way to release the sources 
> bundle too :-).  However I can create my own for my needs.  I’ve now tested 
> the fixes I added and they seem to work, so, at long last,
>
> +1
>
> thanks
> david jencks
>
>
>> On Oct 1, 2015, at 6:25 PM, dav...@apache.org wrote:
>>
>> Hi David,
>>
>> I didn't change the build process for these artifacts, so I guess they
>> were released like this before. In any case, the important artifacts
>> are there. We can change the produced artifacts for a future release,
>> but I don't think this is important enough to cancel this one.
>>
>> BTW I can't count your email as a +1 or -1, so please indicate how you
>> actually vote here.
>>
>> Thanks,
>>
>> David
>>
>> On 1 October 2015 at 18:19, David Jencks  
>> wrote:
>>> sigs look good, I can build the project tar.gzs.
>>>
>>> The selection of artifacts looks a bit bizarre to me.  I don’t see a 
>>> sources bundle for org.apache.felix.gogo.command-0.16.0 and I can’t imagine 
>>> what the bin artifacts are for.  Is this all intentional?
>>> I’d really prefer there be a 
>>> org.apache.felix.gogo.command-0.16.0-sources.jar
>>>
>>> thanks for undertaking this release :-)
>>>
>>> david jencks
>>>
 On Oct 1, 2015, at 4:42 AM, dav...@apache.org wrote:

 Hi all,

 I'm calling a vote on the following bundles:

 Felix Gogo Shell 0.12.0
 ** Improvement
   * FELIX-5021 [GOGO] Use system bundle to find bundles
   * FELIX-4529 [Gogo] Let gosh be configured by files contributed by
 a bundle fragment
   * FELIX-3341 Simple csh-like Command History
   * FELIX-3340 Allow the prompt to be a Function

 ** Bug
   * FELIX-4425 Short command in Gogo Shell not working with Java 8
   * FELIX-3706 gogo shell startup failure in busy system
   * FELIX-3703 Race condition in gogo runtime activator

 Felix Gogo Command 0.16.0
 ** Improvement
   * FELIX-5021 [GOGO] Use system bundle to find bundles
   * FELIX-5009 Relative URIs would be nice for install and update
   * FELIX-5008 gogo usage messages could be less confusing
   * FELIX-3499 felix:cd command works only with relative paths

 ** Bug
   * FELIX-4969 cd refuses to leave initial directory

 Note that not changes have been made to the Felix Gogo Runtime bundle
 since the last release.

 Staging repository:
 https://repository.apache.org/content/repositories/orgapachefelix-1096

 You can use this UNIX script to download the release and verify the 
 signatures:
 http://svn.apache.org/repos/asf/felix/trunk/check_staged_release.sh

 Usage:
 sh check_staged_release.sh 1096 /tmp/felix-gogo-check

 Please vote to approve this release:

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

 This vote will remain open for at least 72 hours.

 Best regards,

 David Bosschaert
>>>
>

Re: [VOTE] Release Apache Felix Gogo Shell 0.12.0 and Command 0.16.0

2015-10-02 Thread David Jencks 
I’d vote for just moving to a gradle/bndtools build….

A little experimentation suggests that the maven-bundle-plugin 2.4.3 used in 
command can’t produce source jars whereas the 1.4.3 version used in shell can.  
the 2.4.3 version produces this output:

[INFO] --- maven-source-plugin:2.0.4:jar (default-cli) @ 
org.apache.felix.gogo.command ---
[WARNING] NOT adding sources to artifacts with classifier as Maven only 
supports one classifier per artifact. Current artifact 
[org.apache.felix:org.apache.felix.gogo.command:bundle:0.16.0] has a [] 
classifier.

instead of making the requested jar.

david jencks

> On Oct 2, 2015, at 12:42 PM, Benson Margulies  wrote:
> 
> I could take a look at this for the next iteration.
> 
> 
> On Fri, Oct 2, 2015 at 12:41 PM, David Jencks
>  wrote:
>> Hi David,
>> 
>> Well, I was sort of hoping you’d figure out a way to release the sources 
>> bundle too :-).  However I can create my own for my needs.  I’ve now tested 
>> the fixes I added and they seem to work, so, at long last,
>> 
>> +1
>> 
>> thanks
>> david jencks
>> 
>> 
>>> On Oct 1, 2015, at 6:25 PM, dav...@apache.org wrote:
>>> 
>>> Hi David,
>>> 
>>> I didn't change the build process for these artifacts, so I guess they
>>> were released like this before. In any case, the important artifacts
>>> are there. We can change the produced artifacts for a future release,
>>> but I don't think this is important enough to cancel this one.
>>> 
>>> BTW I can't count your email as a +1 or -1, so please indicate how you
>>> actually vote here.
>>> 
>>> Thanks,
>>> 
>>> David
>>> 
>>> On 1 October 2015 at 18:19, David Jencks  
>>> wrote:
 sigs look good, I can build the project tar.gzs.
 
 The selection of artifacts looks a bit bizarre to me.  I don’t see a 
 sources bundle for org.apache.felix.gogo.command-0.16.0 and I can’t 
 imagine what the bin artifacts are for.  Is this all intentional?
 I’d really prefer there be a 
 org.apache.felix.gogo.command-0.16.0-sources.jar
 
 thanks for undertaking this release :-)
 
 david jencks
 
> On Oct 1, 2015, at 4:42 AM, dav...@apache.org wrote:
> 
> Hi all,
> 
> I'm calling a vote on the following bundles:
> 
> Felix Gogo Shell 0.12.0
> ** Improvement
>  * FELIX-5021 [GOGO] Use system bundle to find bundles
>  * FELIX-4529 [Gogo] Let gosh be configured by files contributed by
> a bundle fragment
>  * FELIX-3341 Simple csh-like Command History
>  * FELIX-3340 Allow the prompt to be a Function
> 
> ** Bug
>  * FELIX-4425 Short command in Gogo Shell not working with Java 8
>  * FELIX-3706 gogo shell startup failure in busy system
>  * FELIX-3703 Race condition in gogo runtime activator
> 
> Felix Gogo Command 0.16.0
> ** Improvement
>  * FELIX-5021 [GOGO] Use system bundle to find bundles
>  * FELIX-5009 Relative URIs would be nice for install and update
>  * FELIX-5008 gogo usage messages could be less confusing
>  * FELIX-3499 felix:cd command works only with relative paths
> 
> ** Bug
>  * FELIX-4969 cd refuses to leave initial directory
> 
> Note that not changes have been made to the Felix Gogo Runtime bundle
> since the last release.
> 
> Staging repository:
> https://repository.apache.org/content/repositories/orgapachefelix-1096
> 
> You can use this UNIX script to download the release and verify the 
> signatures:
> http://svn.apache.org/repos/asf/felix/trunk/check_staged_release.sh
> 
> Usage:
> sh check_staged_release.sh 1096 /tmp/felix-gogo-check
> 
> Please vote to approve this release:
> 
> [ ] +1 Approve the release
> [ ] -1 Veto the release (please provide specific comments)
> 
> This vote will remain open for at least 72 hours.
> 
> Best regards,
> 
> David Bosschaert
 
>>

[jira] [Commented] (FELIX-1963) Add possibility to share ServletContext between bundles

2015-10-02 Thread Sten Roger Sandvik (JIRA) 

[ 
https://issues.apache.org/jira/browse/FELIX-1963?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14940839#comment-14940839
 ] 

Sten Roger Sandvik commented on FELIX-1963:
---

No, it seems to be working with the new whiteboard implementation. We can close 
this one.

> Add possibility to share ServletContext between bundles
> ---
>
> Key: FELIX-1963
> URL: https://issues.apache.org/jira/browse/FELIX-1963
> Project: Felix
>  Issue Type: New Feature
>  Components: HTTP Service
>Affects Versions: http-2.0.4
>Reporter: Sten Roger Sandvik
>Assignee: Sten Roger Sandvik
>
> Check out the possibility to share ServletContext between bundles. If 
> ServletContextManager is global instead of local to each bundle then it 
> chould be done. If you want to share ServletContext each HttpContext must 
> implement equals method that ensures equality.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (FELIX-1963) Add possibility to share ServletContext between bundles

2015-10-02 Thread Sten Roger Sandvik (JIRA) 

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

Sten Roger Sandvik closed FELIX-1963.
-
Resolution: Fixed

> Add possibility to share ServletContext between bundles
> ---
>
> Key: FELIX-1963
> URL: https://issues.apache.org/jira/browse/FELIX-1963
> Project: Felix
>  Issue Type: New Feature
>  Components: HTTP Service
>Affects Versions: http-2.0.4
>Reporter: Sten Roger Sandvik
>Assignee: Sten Roger Sandvik
>
> Check out the possibility to share ServletContext between bundles. If 
> ServletContextManager is global instead of local to each bundle then it 
> chould be done. If you want to share ServletContext each HttpContext must 
> implement equals method that ensures equality.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (FELIX-4923) SslFilterResponse doesn 't take in account ssl-forward.header property

2015-10-02 Thread Carsten Ziegeler (JIRA) 

[ 
https://issues.apache.org/jira/browse/FELIX-4923?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14940851#comment-14940851
 ] 

Carsten Ziegeler commented on FELIX-4923:
-

[~asanso] If I understand the code correctly, X-Forwaded-SSL is checked to see 
whether the filter should run at all, and then the harded headers are used to 
get the protocol and the port. Not sure if that makes sense or not. In any 
case, care to make a patch?

> SslFilterResponse doesn 't take in account ssl-forward.header property
> --
>
> Key: FELIX-4923
> URL: https://issues.apache.org/jira/browse/FELIX-4923
> Project: Felix
>  Issue Type: Bug
>  Components: HTTP Service
>Reporter: Antonio Sanso
>Priority: Minor
>
> {{SslFilterResponse}} doesn 't take in account {{ssl-forward}}.header 
> property.
> Indeed the {{SslFilterResponse}} constructor hardcodes 
> {{HDR_X_FORWARDED_PROTO}}.
> {code}
> ...
> request.getHeader(HDR_X_FORWARDED_PROTO);
> ...
> {code}
> the  {{ssl-forward}} osgin configuration should be taken in account IMHO. The 
> default is even different than {{HDR_X_FORWARDED_PROTO}} indeed is rather 
> {{X-Forwarded-SSL}}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (FELIX-4923) SslFilterResponse doesn 't take in account ssl-forward.header property

2015-10-02 Thread Antonio Sanso (JIRA) 

[ 
https://issues.apache.org/jira/browse/FELIX-4923?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14940863#comment-14940863
 ] 

Antonio Sanso commented on FELIX-4923:
--

Sure. I'll propose a patch...

> SslFilterResponse doesn 't take in account ssl-forward.header property
> --
>
> Key: FELIX-4923
> URL: https://issues.apache.org/jira/browse/FELIX-4923
> Project: Felix
>  Issue Type: Bug
>  Components: HTTP Service
>Reporter: Antonio Sanso
>Priority: Minor
>
> {{SslFilterResponse}} doesn 't take in account {{ssl-forward}}.header 
> property.
> Indeed the {{SslFilterResponse}} constructor hardcodes 
> {{HDR_X_FORWARDED_PROTO}}.
> {code}
> ...
> request.getHeader(HDR_X_FORWARDED_PROTO);
> ...
> {code}
> the  {{ssl-forward}} osgin configuration should be taken in account IMHO. The 
> default is even different than {{HDR_X_FORWARDED_PROTO}} indeed is rather 
> {{X-Forwarded-SSL}}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: [VOTE] Release Apache Felix Gogo Shell 0.12.0 and Command 0.16.0

2015-10-02 Thread Carsten Ziegeler 
I assume this is due to a very old parent pom - or a misconfiguration in
that parent pom. Should really be easy to fix.

Carsten

Am 02.10.15 um 19:14 schrieb David Jencks:
> I’d vote for just moving to a gradle/bndtools build….
> 
> A little experimentation suggests that the maven-bundle-plugin 2.4.3 used in 
> command can’t produce source jars whereas the 1.4.3 version used in shell 
> can.  the 2.4.3 version produces this output:
> 
> [INFO] --- maven-source-plugin:2.0.4:jar (default-cli) @ 
> org.apache.felix.gogo.command ---
> [WARNING] NOT adding sources to artifacts with classifier as Maven only 
> supports one classifier per artifact. Current artifact 
> [org.apache.felix:org.apache.felix.gogo.command:bundle:0.16.0] has a [] 
> classifier.
> 
> instead of making the requested jar.
> 
> david jencks
> 
>> On Oct 2, 2015, at 12:42 PM, Benson Margulies  wrote:
>>
>> I could take a look at this for the next iteration.
>>
>>
>> On Fri, Oct 2, 2015 at 12:41 PM, David Jencks
>>  wrote:
>>> Hi David,
>>>
>>> Well, I was sort of hoping you’d figure out a way to release the sources 
>>> bundle too :-).  However I can create my own for my needs.  I’ve now tested 
>>> the fixes I added and they seem to work, so, at long last,
>>>
>>> +1
>>>
>>> thanks
>>> david jencks
>>>
>>>
 On Oct 1, 2015, at 6:25 PM, dav...@apache.org wrote:

 Hi David,

 I didn't change the build process for these artifacts, so I guess they
 were released like this before. In any case, the important artifacts
 are there. We can change the produced artifacts for a future release,
 but I don't think this is important enough to cancel this one.

 BTW I can't count your email as a +1 or -1, so please indicate how you
 actually vote here.

 Thanks,

 David

 On 1 October 2015 at 18:19, David Jencks  
 wrote:
> sigs look good, I can build the project tar.gzs.
>
> The selection of artifacts looks a bit bizarre to me.  I don’t see a 
> sources bundle for org.apache.felix.gogo.command-0.16.0 and I can’t 
> imagine what the bin artifacts are for.  Is this all intentional?
> I’d really prefer there be a 
> org.apache.felix.gogo.command-0.16.0-sources.jar
>
> thanks for undertaking this release :-)
>
> david jencks
>
>> On Oct 1, 2015, at 4:42 AM, dav...@apache.org wrote:
>>
>> Hi all,
>>
>> I'm calling a vote on the following bundles:
>>
>> Felix Gogo Shell 0.12.0
>> ** Improvement
>>  * FELIX-5021 [GOGO] Use system bundle to find bundles
>>  * FELIX-4529 [Gogo] Let gosh be configured by files contributed by
>> a bundle fragment
>>  * FELIX-3341 Simple csh-like Command History
>>  * FELIX-3340 Allow the prompt to be a Function
>>
>> ** Bug
>>  * FELIX-4425 Short command in Gogo Shell not working with Java 8
>>  * FELIX-3706 gogo shell startup failure in busy system
>>  * FELIX-3703 Race condition in gogo runtime activator
>>
>> Felix Gogo Command 0.16.0
>> ** Improvement
>>  * FELIX-5021 [GOGO] Use system bundle to find bundles
>>  * FELIX-5009 Relative URIs would be nice for install and update
>>  * FELIX-5008 gogo usage messages could be less confusing
>>  * FELIX-3499 felix:cd command works only with relative paths
>>
>> ** Bug
>>  * FELIX-4969 cd refuses to leave initial directory
>>
>> Note that not changes have been made to the Felix Gogo Runtime bundle
>> since the last release.
>>
>> Staging repository:
>> https://repository.apache.org/content/repositories/orgapachefelix-1096
>>
>> You can use this UNIX script to download the release and verify the 
>> signatures:
>> http://svn.apache.org/repos/asf/felix/trunk/check_staged_release.sh
>>
>> Usage:
>> sh check_staged_release.sh 1096 /tmp/felix-gogo-check
>>
>> Please vote to approve this release:
>>
>> [ ] +1 Approve the release
>> [ ] -1 Veto the release (please provide specific comments)
>>
>> This vote will remain open for at least 72 hours.
>>
>> Best regards,
>>
>> David Bosschaert
>
>>>
> 
> 


-- 
Carsten Ziegeler
Adobe Research Switzerland
cziege...@apache.org

Re: [VOTE] Release Apache Felix WebConsole 4.2.14

2015-10-02 Thread Pierre De Rop 
Indeed ! wow ! we only have the problem when building with java8; and not
with java7; that is odd.

+1

However, according to the apache release process, I think that binary
artifacts are only produced as convenience for users , and source artifacts
are more important than binaries; So, I think that when sending the
announce your should then mention the fact that the source release must be
only built using java7 and not java8.

cheers
/Pierre






On Fri, Oct 2, 2015 at 5:42 PM, Carsten Ziegeler 
wrote:

> Am 02.10.15 um 17:38 schrieb Carsten Ziegeler:
>
> >
> > Interestingly, it seems to have to do with your build environment,
> > whether the import ends up in the manifest or not. If I build on my
> > machine, java 7, it's not there.
> >
> And with java 8 it is there, so it really depends on the java version
> you build with :(
>
> Regards
> Carsten
> --
> Carsten Ziegeler
> Adobe Research Switzerland
> cziege...@apache.org
>