[jira] [Commented] (FELIX-4923) SslFilterResponse doesn 't take in account ssl-forward.header property
[
https://issues.apache.org/jira/browse/FELIX-4923?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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)
[jira] [Commented] (FELIX-3104) Registering/unregistering HttpService with CometdServiceImpl repeatedly causes ClassCastException
[ https://issues.apache.org/jira/browse/FELIX-3104?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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-4706) Provide way to override Jetty's error pages for status other than 200
[ https://issues.apache.org/jira/browse/FELIX-4706?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[
https://issues.apache.org/jira/browse/FELIX-4923?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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-1963) Add possibility to share ServletContext between bundles
[ https://issues.apache.org/jira/browse/FELIX-1963?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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] [Resolved] (FELIX-4415) Cannot associate HttpService instance with ServletContext
[
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] [Resolved] (FELIX-4589) Problem with forwarding from one servlet to another
[
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-4645) Service already unregistered exception from HttpServicePlugin
[
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-4744) RequestDispatchTest Failure
[
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&quu"));
> 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 -
> link:classpath:META-INF/links/org.ops4j.pax
[jira] [Resolved] (FELIX-4946) Updates in service ranking not picked up by filters
[ 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-5059) Embedd http api bundle in jetty bundle
[ 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] [Created] (FELIX-5059) Embedd http api bundle in jetty bundle
Carsten Ziegeler created FELIX-5059: --- Summary: 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)
Re: Cometd and http bundle
Am 01.10.15 um 18:52 schrieb Sten Roger Sandvik: > I am looking at the http bundle which contains jetty, bridge, cometd and > whiteboard. Have some questions regarding that. > > 1) It includes the whiteboard bundle, but I see that the new whiteboard > stuff is implemented in http.base. Should we still include the old > whiteboard jar or should we just remove it? If we do a http bundle, I guess we should include it for some time for compatibility. > > 2) I think that cometd is a little troublesome in the http.bundle. First, > it's bringing in SLF4J dependency. And second, it seems to me that this > cometd support is really optional and should just be provided on-top of the > bundle. > The idea of the http bundle is to have a single bundle that contains everything. > Or, maybe the http.bundle shoud not be there at all? Maybe we should just > have api, base, bridge, jetty and cometd bundles? > I think removing the http bundle but including the http api in the http jetty bundle is the better option. Users can then install the jetty bundle and if they want cometd they add that one, same with the felix whiteboard support etc. Carsten -- Carsten Ziegeler Adobe Research Switzerland cziege...@apache.org
Re: [VOTE] Release Apache Felix Gogo Shell 0.12.0 and Command 0.16.0
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
Thanks for releasing; +1 /Pierre On Thu, Oct 1, 2015 at 6:19 PM, 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 > >
Cometd and http bundle
I am looking at the http bundle which contains jetty, bridge, cometd and whiteboard. Have some questions regarding that. 1) It includes the whiteboard bundle, but I see that the new whiteboard stuff is implemented in http.base. Should we still include the old whiteboard jar or should we just remove it? 2) I think that cometd is a little troublesome in the http.bundle. First, it's bringing in SLF4J dependency. And second, it seems to me that this cometd support is really optional and should just be provided on-top of the bundle. Or, maybe the http.bundle shoud not be there at all? Maybe we should just have api, base, bridge, jetty and cometd bundles?
Re: [http] Should we include the api bundle in the jetty one?
Yeah! Providers of an API should provide their API since they have a very small import range anyway. Kind regards, Peter Kriens > On 1 okt. 2015, at 17:44, Carsten Ziegeler wrote: > > I think we're making the use of our standard http implementation based > on jetty too complicated: it requires to install the api and the jetty > bundle, although without the api bundle, the jetty one is totally > useless. And as the jetty bundle implements the api bundle, it's tied to > a specific version. > > Therefore I think we should simply include the api bundle in the jetty > bundle. > > If no one objects, I'll do the changes. > > Thanks > Carsten > -- > Carsten Ziegeler > Adobe Research Switzerland > cziege...@apache.org
Re: [VOTE] Release Apache Felix Gogo Shell 0.12.0 and Command 0.16.0
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: [http] Should we include the api bundle in the jetty one?
Sounds good to me. 2015-10-01 17:44 GMT+02:00 Carsten Ziegeler : > I think we're making the use of our standard http implementation based > on jetty too complicated: it requires to install the api and the jetty > bundle, although without the api bundle, the jetty one is totally > useless. And as the jetty bundle implements the api bundle, it's tied to > a specific version. > > Therefore I think we should simply include the api bundle in the jetty > bundle. > > If no one objects, I'll do the changes. > > Thanks > Carsten > -- > Carsten Ziegeler > Adobe Research Switzerland > cziege...@apache.org >
[http] Should we include the api bundle in the jetty one?
I think we're making the use of our standard http implementation based on jetty too complicated: it requires to install the api and the jetty bundle, although without the api bundle, the jetty one is totally useless. And as the jetty bundle implements the api bundle, it's tied to a specific version. Therefore I think we should simply include the api bundle in the jetty bundle. If no one objects, I'll do the changes. Thanks Carsten -- Carsten Ziegeler Adobe Research Switzerland cziege...@apache.org
Re: Release schedule of http?
Good. Will try to fix one issue and then call for a release. Probably within the weekend. 2015-10-01 13:48 GMT+02:00 Carsten Ziegeler : > Am 01.10.15 um 10:14 schrieb Sten Roger Sandvik: >> Hi. >> >> I'm just wondering on when it's appropriate to call out for a release? >> I have some "blockers" for the http bundles that I need really soon >> :-) >> > There is no fixed schedule, in theory we can simply release whenever a > single issue is fixed. > Feel free to call for a release whenever you think it makes sense. > > You can either do the release yourself or I can do it, if you want. > > Regards > Carsten > -- > Carsten Ziegeler > Adobe Research Switzerland > cziege...@apache.org
Re: [VOTE] Release Apache Felix Gogo Shell 0.12.0 and Command 0.16.0
+1 -- Carsten Ziegeler Adobe Research Switzerland cziege...@apache.org
Re: Release schedule of http?
Am 01.10.15 um 10:14 schrieb Sten Roger Sandvik: > Hi. > > I'm just wondering on when it's appropriate to call out for a release? > I have some "blockers" for the http bundles that I need really soon > :-) > There is no fixed schedule, in theory we can simply release whenever a single issue is fixed. Feel free to call for a release whenever you think it makes sense. You can either do the release yourself or I can do it, if you want. Regards Carsten -- Carsten Ziegeler Adobe Research Switzerland cziege...@apache.org
[VOTE] Release Apache Felix Gogo Shell 0.12.0 and Command 0.16.0
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: Release schedule of http?
I have an action to update the HTTP version used in our app, so happy my side to get a new version out so it's on latest greatest when I do the testing work -- Rob On 01/10/2015 10:14, Sten Roger Sandvik wrote: Hi. I'm just wondering on when it's appropriate to call out for a release? I have some "blockers" for the http bundles that I need really soon :-) BR, Sten Roger -- Ascert - Taking systems to the edge r...@ascert.com SA +27 21 300 2028 UK +44 20 7488 3470 ext 5119 www.ascert.com
Re: Release of Gogo Shell (for Java8) ?
+1 2015-09-30 23:28 GMT+02:00 David Jencks : > Could you please release gogo commands as well? There have been some bug > fixes and improvements there too. I’m hoping the result will run on at least > java 7 if not 6 (6?? yes, 6 :-) > > many thanks > david jencks > >> On Sep 30, 2015, at 4:18 PM, David Bosschaert >> wrote: >> >> I guess that component hasn't been released for a long time. If nobody >> objects I can kick off a release tomorrow. >> >> Cheers, >> >> David >> >> On 29 September 2015 at 23:16, Arjun Panday wrote: >>> Hi, >>> >>> I recently bumped into this issue: >>> https://issues.apache.org/jira/browse/FELIX-4425 >>> >>> Apparently the issue was fixed a year and half ago, but I can't find the >>> corresponding release anywhere. >>> As Java7 is now officially deprecated and more and more projects will move >>> to Java8, it would be great to make this fix publicly available. >>> >>> Is there something currently preventing the release? >>> >>> Thanks, >>> Arjun >
Release schedule of http?
Hi. I'm just wondering on when it's appropriate to call out for a release? I have some "blockers" for the http bundles that I need really soon :-) BR, Sten Roger
[jira] [Closed] (FELIX-5053) IllegalArgumentException when forwarding request
[
https://issues.apache.org/jira/browse/FELIX-5053?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sten Roger Sandvik closed FELIX-5053.
-
Resolution: Fixed
Fix Version/s: http.base-3.0.2
> IllegalArgumentException when forwarding request
>
>
> Key: FELIX-5053
> URL: https://issues.apache.org/jira/browse/FELIX-5053
> Project: Felix
> Issue Type: Bug
> Components: HTTP Service
>Affects Versions: http.base-3.0.0
>Reporter: Sten Roger Sandvik
>Assignee: Sten Roger Sandvik
> Fix For: http.base-3.0.2
>
>
> It seems to be a problem with forwarding requests in certain cases. I have
> the following setup:
> * Servlet A forwards the request to Servlet 2 (using RequestDispatcher).
> * Servlet B writes to the response using an output stream
> (HttpServletResponse.getOutputStream()).
> When this happens I get an IllegalStateException from Jetty that basically
> saying that the Writer cannot be closed since I have already used an
> OutputStream.
> The code that I think is wrong (or possibly not robust enough) is in
> RequestDispatcherImp line 84.
> {code}
> if (!request.isAsyncStarted())
> {
> response.flushBuffer();
> response.getWriter().close();
> }
> {code}
> The line that causes trouble is:
> {code}
> response.getWriter().close();
> {code}
> We should probably check if we can actually close this writer or just ignore
> the potential exception.
> In my setup I have one servlet that writes to OutputStream using
> HttpServletResponse.getOutputStream(). Then I have another servlet that
> forwards the request to the first servlet.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (FELIX-5053) IllegalArgumentException when forwarding request
[
https://issues.apache.org/jira/browse/FELIX-5053?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14939481#comment-14939481
]
Sten Roger Sandvik commented on FELIX-5053:
---
I removed the response.getWriter().close() line. It works for me and it should
not be there.
> IllegalArgumentException when forwarding request
>
>
> Key: FELIX-5053
> URL: https://issues.apache.org/jira/browse/FELIX-5053
> Project: Felix
> Issue Type: Bug
> Components: HTTP Service
>Affects Versions: http.base-3.0.0
>Reporter: Sten Roger Sandvik
>Assignee: Sten Roger Sandvik
>
> It seems to be a problem with forwarding requests in certain cases. I have
> the following setup:
> * Servlet A forwards the request to Servlet 2 (using RequestDispatcher).
> * Servlet B writes to the response using an output stream
> (HttpServletResponse.getOutputStream()).
> When this happens I get an IllegalStateException from Jetty that basically
> saying that the Writer cannot be closed since I have already used an
> OutputStream.
> The code that I think is wrong (or possibly not robust enough) is in
> RequestDispatcherImp line 84.
> {code}
> if (!request.isAsyncStarted())
> {
> response.flushBuffer();
> response.getWriter().close();
> }
> {code}
> The line that causes trouble is:
> {code}
> response.getWriter().close();
> {code}
> We should probably check if we can actually close this writer or just ignore
> the potential exception.
> In my setup I have one servlet that writes to OutputStream using
> HttpServletResponse.getOutputStream(). Then I have another servlet that
> forwards the request to the first servlet.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (FELIX-5053) IllegalArgumentException when forwarding request
[
https://issues.apache.org/jira/browse/FELIX-5053?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sten Roger Sandvik reassigned FELIX-5053:
-
Assignee: Sten Roger Sandvik
> IllegalArgumentException when forwarding request
>
>
> Key: FELIX-5053
> URL: https://issues.apache.org/jira/browse/FELIX-5053
> Project: Felix
> Issue Type: Bug
> Components: HTTP Service
>Affects Versions: http.base-3.0.0
>Reporter: Sten Roger Sandvik
>Assignee: Sten Roger Sandvik
>
> It seems to be a problem with forwarding requests in certain cases. I have
> the following setup:
> * Servlet A forwards the request to Servlet 2 (using RequestDispatcher).
> * Servlet B writes to the response using an output stream
> (HttpServletResponse.getOutputStream()).
> When this happens I get an IllegalStateException from Jetty that basically
> saying that the Writer cannot be closed since I have already used an
> OutputStream.
> The code that I think is wrong (or possibly not robust enough) is in
> RequestDispatcherImp line 84.
> {code}
> if (!request.isAsyncStarted())
> {
> response.flushBuffer();
> response.getWriter().close();
> }
> {code}
> The line that causes trouble is:
> {code}
> response.getWriter().close();
> {code}
> We should probably check if we can actually close this writer or just ignore
> the potential exception.
> In my setup I have one servlet that writes to OutputStream using
> HttpServletResponse.getOutputStream(). Then I have another servlet that
> forwards the request to the first servlet.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
