[jira] [Commented] (FELIX-5094) Make Jetty thread pool, acceptors and selectors configurable

[Sten Roger Sandvik (JIRA)]

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

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

Thanks. Was actually needing to tune this myself. Will look at the patch 
tomorrow if nobody else does it before me.

> Make Jetty thread pool, acceptors and selectors configurable
> 
>
> Key: FELIX-5094
> URL: https://issues.apache.org/jira/browse/FELIX-5094
> Project: Felix
>  Issue Type: Improvement
>  Components: HTTP Service
>Reporter: Alexander Klimetschek
> Attachments: FELIX-5094.patch
>
>
> Currently the jetty http service bundle does not expose configuration for 
> Jetty's maximum thread pool size, number of acceptor and number of selector 
> threads. It always uses Jetty's defaults.
> For tuning production machines these can be important settings that should be 
> available.



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

[jira] [Commented] (FELIX-5053) IllegalArgumentException when forwarding request

[Sten Roger Sandvik (JIRA)]

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

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

Looks good. I think this will do it. Tested it agaist my setup and everything 
works perfectly.

> 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)

Re: [VOTE] Release Apache Felix Http Base 3.0.2, Http Bridge 3.0.2, and Http Jetty 3.1.2

[Sten Roger Sandvik]

+1
fre. 9. okt. 2015 kl. 17.43 skrev David Bosschaert <
david.bosscha...@gmail.com>:

> +1
>
> David
>
> On 9 October 2015 at 16:15, Carsten Ziegeler  wrote:
> > I would like to call a vote on the following subproject releases:
> >
> > Http Base 3.0.2 - 4 issues solved
> > https://issues.apache.org/jira/browse/FELIX/fixforversion/12333076
> >
> > Http Bridge 3.0.2 - 4 issues solved
> > https://issues.apache.org/jira/browse/FELIX/fixforversion/12333282
> >
> > Http Jetty 3.1.2 - 5 issues solved
> > https://issues.apache.org/jira/browse/FELIX/fixforversion/12333135
> >
> > Staging repositories:
> > https://repository.apache.org/content/repositories/orgapachefelix-1098/
> >
> > 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 1098 /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
>

[jira] [Commented] (FELIX-5053) IllegalArgumentException when forwarding request

[Sten Roger Sandvik (JIRA)]

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

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

Sorry, did not notice that. Probably the best thing for now is to ignore any 
exceptions from the "getWriter().close()" operation?

> 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)

Re: Release schedule of http?

[Sten Roger Sandvik]

The weekend went fast and I did not manage to get the time to read up on
the release procedures. It's been a  long time since I did this in the
Felix project. If you are tired of waiting, then just release and I will
probably be up to speed on the next releases :-)


2015-10-01 16:27 GMT+02:00 Sten Roger Sandvik <ste...@gmail.com>:

> 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 <cziege...@apache.org>:
> > 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: Release schedule of http?

[Sten Roger Sandvik]

Great. Thanks!


2015-10-07 8:17 GMT+02:00 Carsten Ziegeler <cziege...@apache.org>:

> I'll start the release either tomorrow or Friday - definitely before the
> weekend :)
>
> Regards
> Carsten
>
> Am 07.10.15 um 11:41 schrieb Sten Roger Sandvik:
> > The weekend went fast and I did not manage to get the time to read up on
> > the release procedures. It's been a  long time since I did this in the
> > Felix project. If you are tired of waiting, then just release and I will
> > probably be up to speed on the next releases :-)
> >
> >
> > 2015-10-01 16:27 GMT+02:00 Sten Roger Sandvik <ste...@gmail.com>:
> >
> >> 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 <cziege...@apache.org>:
> >>> 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
> >>
> >
>
>
> --
> Carsten Ziegeler
> Adobe Research Switzerland
> cziege...@apache.org
>

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

[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

[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-5053) IllegalArgumentException when forwarding request

[Sten Roger Sandvik (JIRA)]

[ 
https://issues.apache.org/jira/browse/FELIX-5053?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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)

Release schedule of http?

[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
:-)

BR,
Sten Roger

[jira] [Closed] (FELIX-5053) IllegalArgumentException when forwarding request

[Sten Roger Sandvik (JIRA)]

 [ 
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)

Re: Release schedule of http?

[Sten Roger Sandvik]

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 <cziege...@apache.org>:
> 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: [http] Should we include the api bundle in the jetty one?

[Sten Roger Sandvik]

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
>

Cometd and http bundle

[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?

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?

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

[Sten Roger Sandvik (JIRA)]

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

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

It does not seems that this is a problem anymore. I build using Java 1.7 on OSX 
and it's running the tests without failure. 

Do you know if this is still a problem in your environment?

> 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
>
> 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.exa

[jira] [Commented] (FELIX-5015) NPE in ResolverImpl

[Sten Roger Sandvik (JIRA)]

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

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

I have also tested the patch and it looks good. I can apply the patch if nobody 
has any objections.


> NPE in ResolverImpl
> ---
>
> Key: FELIX-5015
> URL: https://issues.apache.org/jira/browse/FELIX-5015
> Project: Felix
>  Issue Type: Bug
>  Components: Resolver
>Affects Versions: resolver-1.6.0
>Reporter: Alexandre Roman
> Attachments: FELIX-5015.patch.gz
>
>
> The method getPackageSources in ResolverImpl.java returns a Set.
> This collection is used in mergeUses (line 1039) in a foreach loop.
> A null value may be returned by getPackageSources, as a result of querying a 
> Map. In this case, the foreach loop in mergeUses will trigger a NPE.
> The method getPackageSources should return an empty Set when there is no 
> result.



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

[jira] [Commented] (FELIX-5053) IllegalArgumentException when forwarding request

[Sten Roger Sandvik (JIRA)]

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

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

Yes, that was my initial tought too. Have tried a lot of cases without that 
statement there and it seems to work just fine.

> 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
>
> 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] [Comment Edited] (FELIX-5053) IllegalArgumentException when forwarding request

[Sten Roger Sandvik (JIRA)]

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

Sten Roger Sandvik edited comment on FELIX-5053 at 9/25/15 6:16 AM:


Yes, that was my initial tought too, but was a little bit afraid to remove it 
(in case it's a really good reason). But, have tried a lot of cases without 
that statement and it seems to work just fine.


was (Author: srs):
Yes, that was my initial tought too. Have tried a lot of cases without that 
statement there and it seems to work just fine.

> 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
>
> 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] [Created] (FELIX-5053) IllegalArgumentException when forwarding request

[Sten Roger Sandvik (JIRA)]

Sten Roger Sandvik created FELIX-5053:
-

 Summary: 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


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)

Bug fixes - commit to repo or patch?

[Sten Roger Sandvik]

Hi.

I have been contributing to Apache Felix earlier (some years ago), but
I'm back to see how I can contribute further :-)

I know I still have write access to the repository, but I need to be
sure how the contribution flow should be done. Should I add a patch or
commit directly to the repository?

It's mainly bug-fixes that I am thinking of right now.

BR,
Sten Roger

[jira] [Created] (FELIX-5052) Annoying System.out in RequestDispatcherImpl

[Sten Roger Sandvik (JIRA)]

Sten Roger Sandvik created FELIX-5052:
-

 Summary: Annoying System.out in RequestDispatcherImpl
 Key: FELIX-5052
 URL: https://issues.apache.org/jira/browse/FELIX-5052
 Project: Felix
  Issue Type: Bug
  Components: HTTP Service
Affects Versions: http.base-3.0.0
Reporter: Sten Roger Sandvik


There's an annoying System.out in RequestDispatcherImpl's constructor. 



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

Re: Bug fixes - commit to repo or patch?

[Sten Roger Sandvik]

Thanks, will do that.

2015-09-24 21:54 GMT+02:00 Richard S. Hall <he...@ungoverned.org>:
> If you are uncertain about your patch or just want to find a second pair of
> eyes, you can always open an issue (or an existing one) in the tracker and
> attach your patch to it to solicit feedback. If you don't hear any
> objections after a few days, just go ahead and commit it.
>
> -> richard
>
>
> On 9/24/15 15:28 , Sten Roger Sandvik wrote:
>>
>> Hi.
>>
>> I have been contributing to Apache Felix earlier (some years ago), but
>> I'm back to see how I can contribute further :-)
>>
>> I know I still have write access to the repository, but I need to be
>> sure how the contribution flow should be done. Should I add a patch or
>> commit directly to the repository?
>>
>> It's mainly bug-fixes that I am thinking of right now.
>>
>> BR,
>> Sten Roger
>
>

Re: Coding standards?

[Sten Roger Sandvik]

Thanks Pierre!



2015-09-24 23:55 GMT+02:00 Pierre De Rop <pierre.de...@gmail.com>:
> Hi Sten Roger;
>
> For the coding standards, I think it's described in [1] (see the eclipse
> formatting template at the end of the page).
>
> With regard to test coverage, I'm not currently aware of  any rules or
> reusable poms that could be used to run test coverages.
>
>
> [1] http://felix.apache.org/documentation/development/coding-standards.html
>
> cheers;
> /Pierre
>
> On Thu, Sep 24, 2015 at 11:01 PM, Sten Roger Sandvik <ste...@gmail.com>
> wrote:
>
>> Hi.
>>
>> Do we have any coding standards for Felix project? And, an unrelated
>> question, do we have some sort of test coverage reports?
>>
>> BR,
>> Sten Roger
>>

Coding standards?

[Sten Roger Sandvik]

Hi.

Do we have any coding standards for Felix project? And, an unrelated
question, do we have some sort of test coverage reports?

BR,
Sten Roger

[jira] [Updated] (FELIX-5052) Annoying System.out in RequestDispatcherImpl

[Sten Roger Sandvik (JIRA)]

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

Sten Roger Sandvik updated FELIX-5052:
--
Fix Version/s: http.base-3.0.2

> Annoying System.out in RequestDispatcherImpl
> 
>
> Key: FELIX-5052
> URL: https://issues.apache.org/jira/browse/FELIX-5052
> 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
>
>
> There's an annoying System.out in RequestDispatcherImpl's constructor. 



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

[jira] [Resolved] (FELIX-5052) Annoying System.out in RequestDispatcherImpl

[Sten Roger Sandvik (JIRA)]

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

Sten Roger Sandvik resolved FELIX-5052.
---
Resolution: Fixed

> Annoying System.out in RequestDispatcherImpl
> 
>
> Key: FELIX-5052
> URL: https://issues.apache.org/jira/browse/FELIX-5052
> 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
>
>
> There's an annoying System.out in RequestDispatcherImpl's constructor. 



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

[jira] [Commented] (FELIX-5053) IllegalArgumentException when forwarding request

[Sten Roger Sandvik (JIRA)]

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

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

I propose that we just ignore any exceptions comming from closing the writer. 
Like this:

{code}
if (!request.isAsyncStarted())
{
  response.flushBuffer();
  
  try {
response.getWriter().close();
  } catch (final Exception e) {
// Ignore any exception. See FELIX-5053.
  }
}
{code}

Any comments?

> 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
>
> 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-5052) Annoying System.out in RequestDispatcherImpl

[Sten Roger Sandvik (JIRA)]

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

Sten Roger Sandvik reassigned FELIX-5052:
-

Assignee: Sten Roger Sandvik

> Annoying System.out in RequestDispatcherImpl
> 
>
> Key: FELIX-5052
> URL: https://issues.apache.org/jira/browse/FELIX-5052
> Project: Felix
>  Issue Type: Bug
>  Components: HTTP Service
>Affects Versions: http.base-3.0.0
>        Reporter: Sten Roger Sandvik
>    Assignee: Sten Roger Sandvik
>
> There's an annoying System.out in RequestDispatcherImpl's constructor. 



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

[jira] [Commented] (FELIX-4991) http bundle fails with IncompatibleClassChangeError

[Sten Roger Sandvik (JIRA)]

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

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

Yes. Looks like it's the same.

> http bundle fails with IncompatibleClassChangeError
> ---
>
> Key: FELIX-4991
> URL: https://issues.apache.org/jira/browse/FELIX-4991
> Project: Felix
>  Issue Type: Bug
>  Components: HTTP Service
>Affects Versions: http.bundle-3.0.0
> Environment: linux amd64 openjdk/oracle/ibm 1.7/1.8 framework 5.0.1
>Reporter: Ed Schaller
> Fix For: http.bundle-3.1.0
>
>
> Jetty fails to load with an IncompatibleClassChangeException.
> ERROR: Bundle org.apache.felix.http.bundle [8] Error starting 
> file:.../felix-framework-5.0.1/bundle/org.apache.felix.http.bundle-3.0.0.jar 
> (org.osgi.framework.BundleException: Activator start error in bundle 
> org.apache.felix.http.bundle [8].)
> java.lang.IncompatibleClassChangeError: Implementing class
> at java.lang.ClassLoader.defineClass1(Native Method)
> at java.lang.ClassLoader.defineClass(ClassLoader.java:760)
> at 
> org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.defineClass(BundleWiringImpl.java:2350)
> at 
> org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.findClass(BundleWiringImpl.java:2134)
> at 
> org.apache.felix.framework.BundleWiringImpl.findClassOrResourceByDelegation(BundleWiringImpl.java:1526)
> at 
> org.apache.felix.framework.BundleWiringImpl.access$400(BundleWiringImpl.java:79)
> at 
> org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.loadClass(BundleWiringImpl.java:1998)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
> at java.lang.ClassLoader.defineClass1(Native Method)
> at java.lang.ClassLoader.defineClass(ClassLoader.java:760)
> at 
> org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.defineClass(BundleWiringImpl.java:2350)
> at 
> org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.findClass(BundleWiringImpl.java:2134)
> at 
> org.apache.felix.framework.BundleWiringImpl.findClassOrResourceByDelegation(BundleWiringImpl.java:1526)
> at 
> org.apache.felix.framework.BundleWiringImpl.access$400(BundleWiringImpl.java:79)
> at 
> org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.loadClass(BundleWiringImpl.java:1998)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
> at java.lang.ClassLoader.defineClass1(Native Method)
> at java.lang.ClassLoader.defineClass(ClassLoader.java:760)
> at 
> org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.defineClass(BundleWiringImpl.java:2350)
> at 
> org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.findClass(BundleWiringImpl.java:2134)
> at 
> org.apache.felix.framework.BundleWiringImpl.findClassOrResourceByDelegation(BundleWiringImpl.java:1526)
> at 
> org.apache.felix.framework.BundleWiringImpl.access$400(BundleWiringImpl.java:79)
> at 
> org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.loadClass(BundleWiringImpl.java:1998)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
> at java.lang.ClassLoader.defineClass1(Native Method)
> at java.lang.ClassLoader.defineClass(ClassLoader.java:760)
> at 
> org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.defineClass(BundleWiringImpl.java:2350)
> at 
> org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.findClass(BundleWiringImpl.java:2134)
> at 
> org.apache.felix.framework.BundleWiringImpl.findClassOrResourceByDelegation(BundleWiringImpl.java:1526)
> at 
> org.apache.felix.framework.BundleWiringImpl.access$400(BundleWiringImpl.java:79)
> at 
> org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.loadClass(BundleWiringImpl.java:1998)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
> at java.lang.ClassLoader.defineClass1(Native Method)
> at java.lang.ClassLoader.defineClass(ClassLoader.java:760)
> at 
> org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.defineClass(BundleWiringImpl.java:2350)
> at 
> org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.findClass(BundleWiringImpl.java:2134)
> at 
> org.apache.felix.framework.BundleWiringImpl.findClassOrResourceByDelegation(BundleWiringImpl.java:1526)
> at 
> org.apache.felix

[jira] [Issue Comment Deleted] (FELIX-4991) http bundle fails with IncompatibleClassChangeError

[Sten Roger Sandvik (JIRA)]

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

Sten Roger Sandvik updated FELIX-4991:
--
Comment: was deleted

(was: Yes. Looks like it's the same.)

> http bundle fails with IncompatibleClassChangeError
> ---
>
> Key: FELIX-4991
> URL: https://issues.apache.org/jira/browse/FELIX-4991
> Project: Felix
>  Issue Type: Bug
>  Components: HTTP Service
>Affects Versions: http.bundle-3.0.0
> Environment: linux amd64 openjdk/oracle/ibm 1.7/1.8 framework 5.0.1
>Reporter: Ed Schaller
> Fix For: http.bundle-3.1.0
>
>
> Jetty fails to load with an IncompatibleClassChangeException.
> ERROR: Bundle org.apache.felix.http.bundle [8] Error starting 
> file:.../felix-framework-5.0.1/bundle/org.apache.felix.http.bundle-3.0.0.jar 
> (org.osgi.framework.BundleException: Activator start error in bundle 
> org.apache.felix.http.bundle [8].)
> java.lang.IncompatibleClassChangeError: Implementing class
> at java.lang.ClassLoader.defineClass1(Native Method)
> at java.lang.ClassLoader.defineClass(ClassLoader.java:760)
> at 
> org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.defineClass(BundleWiringImpl.java:2350)
> at 
> org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.findClass(BundleWiringImpl.java:2134)
> at 
> org.apache.felix.framework.BundleWiringImpl.findClassOrResourceByDelegation(BundleWiringImpl.java:1526)
> at 
> org.apache.felix.framework.BundleWiringImpl.access$400(BundleWiringImpl.java:79)
> at 
> org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.loadClass(BundleWiringImpl.java:1998)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
> at java.lang.ClassLoader.defineClass1(Native Method)
> at java.lang.ClassLoader.defineClass(ClassLoader.java:760)
> at 
> org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.defineClass(BundleWiringImpl.java:2350)
> at 
> org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.findClass(BundleWiringImpl.java:2134)
> at 
> org.apache.felix.framework.BundleWiringImpl.findClassOrResourceByDelegation(BundleWiringImpl.java:1526)
> at 
> org.apache.felix.framework.BundleWiringImpl.access$400(BundleWiringImpl.java:79)
> at 
> org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.loadClass(BundleWiringImpl.java:1998)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
> at java.lang.ClassLoader.defineClass1(Native Method)
> at java.lang.ClassLoader.defineClass(ClassLoader.java:760)
> at 
> org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.defineClass(BundleWiringImpl.java:2350)
> at 
> org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.findClass(BundleWiringImpl.java:2134)
> at 
> org.apache.felix.framework.BundleWiringImpl.findClassOrResourceByDelegation(BundleWiringImpl.java:1526)
> at 
> org.apache.felix.framework.BundleWiringImpl.access$400(BundleWiringImpl.java:79)
> at 
> org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.loadClass(BundleWiringImpl.java:1998)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
> at java.lang.ClassLoader.defineClass1(Native Method)
> at java.lang.ClassLoader.defineClass(ClassLoader.java:760)
> at 
> org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.defineClass(BundleWiringImpl.java:2350)
> at 
> org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.findClass(BundleWiringImpl.java:2134)
> at 
> org.apache.felix.framework.BundleWiringImpl.findClassOrResourceByDelegation(BundleWiringImpl.java:1526)
> at 
> org.apache.felix.framework.BundleWiringImpl.access$400(BundleWiringImpl.java:79)
> at 
> org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.loadClass(BundleWiringImpl.java:1998)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
> at java.lang.ClassLoader.defineClass1(Native Method)
> at java.lang.ClassLoader.defineClass(ClassLoader.java:760)
> at 
> org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.defineClass(BundleWiringImpl.java:2350)
> at 
> org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.findClass(BundleWiringImpl.java:2134)
> at 
> org.apache.felix.framework.BundleWiringImpl.findClassOrResourceByDelegation(BundleWiringImpl.java:1526)
> at 
> org.apache.felix

[jira] [Commented] (FELIX-4991) http bundle fails with IncompatibleClassChangeError

[Sten Roger Sandvik (JIRA)]

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

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

I have also the same problem with the same bundles. Using the following 
versions:

{noformat}
OSX 10.11
Felix Framework 5.2.0

java version "1.8.0_40"
Java(TM) SE Runtime Environment (build 1.8.0_40-b26)
Java HotSpot(TM) 64-Bit Server VM (build 25.40-b25, mixed mode)
{noformat}

Tested also using Java 1.7 with same exception.

{noformat}
java version "1.7.0_40"
Java(TM) SE Runtime Environment (build 1.7.0_40-b43)
Java HotSpot(TM) 64-Bit Server VM (build 24.0-b56, mixed mode)
{noformat}

Will try to see if I can find the error. Seems to be with the Http Bundle. If I 
use seperate bundles (api, base, jetty, whiteboard) it seems to work.



> http bundle fails with IncompatibleClassChangeError
> ---
>
> Key: FELIX-4991
> URL: https://issues.apache.org/jira/browse/FELIX-4991
> Project: Felix
>  Issue Type: Bug
>  Components: HTTP Service
>Affects Versions: http.bundle-3.0.0
> Environment: linux amd64 openjdk/oracle/ibm 1.7/1.8 framework 5.0.1
>Reporter: Ed Schaller
> Fix For: http.bundle-3.1.0
>
>
> Jetty fails to load with an IncompatibleClassChangeException.
> ERROR: Bundle org.apache.felix.http.bundle [8] Error starting 
> file:.../felix-framework-5.0.1/bundle/org.apache.felix.http.bundle-3.0.0.jar 
> (org.osgi.framework.BundleException: Activator start error in bundle 
> org.apache.felix.http.bundle [8].)
> java.lang.IncompatibleClassChangeError: Implementing class
> at java.lang.ClassLoader.defineClass1(Native Method)
> at java.lang.ClassLoader.defineClass(ClassLoader.java:760)
> at 
> org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.defineClass(BundleWiringImpl.java:2350)
> at 
> org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.findClass(BundleWiringImpl.java:2134)
> at 
> org.apache.felix.framework.BundleWiringImpl.findClassOrResourceByDelegation(BundleWiringImpl.java:1526)
> at 
> org.apache.felix.framework.BundleWiringImpl.access$400(BundleWiringImpl.java:79)
> at 
> org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.loadClass(BundleWiringImpl.java:1998)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
> at java.lang.ClassLoader.defineClass1(Native Method)
> at java.lang.ClassLoader.defineClass(ClassLoader.java:760)
> at 
> org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.defineClass(BundleWiringImpl.java:2350)
> at 
> org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.findClass(BundleWiringImpl.java:2134)
> at 
> org.apache.felix.framework.BundleWiringImpl.findClassOrResourceByDelegation(BundleWiringImpl.java:1526)
> at 
> org.apache.felix.framework.BundleWiringImpl.access$400(BundleWiringImpl.java:79)
> at 
> org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.loadClass(BundleWiringImpl.java:1998)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
> at java.lang.ClassLoader.defineClass1(Native Method)
> at java.lang.ClassLoader.defineClass(ClassLoader.java:760)
> at 
> org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.defineClass(BundleWiringImpl.java:2350)
> at 
> org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.findClass(BundleWiringImpl.java:2134)
> at 
> org.apache.felix.framework.BundleWiringImpl.findClassOrResourceByDelegation(BundleWiringImpl.java:1526)
> at 
> org.apache.felix.framework.BundleWiringImpl.access$400(BundleWiringImpl.java:79)
> at 
> org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.loadClass(BundleWiringImpl.java:1998)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
> at java.lang.ClassLoader.defineClass1(Native Method)
> at java.lang.ClassLoader.defineClass(ClassLoader.java:760)
> at 
> org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.defineClass(BundleWiringImpl.java:2350)
> at 
> org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.findClass(BundleWiringImpl.java:2134)
> at 
> org.apache.felix.framework.BundleWiringImpl.findClassOrResourceByDelegation(BundleWiringImpl.java:1526)
> at 
> org.apache.felix.framework.BundleWiringImpl.access$400(BundleWiringImpl.java:79)
> at 
> org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.lo

hi

[Sten Roger Sandvik]

Hey , what is up ?
I got my laptop this morning , I ordered it from a Chinese site (the
site is :  www.0lcekn.com) . Now I am surfing the Internet with it ,
really good qulity . I want to share this good news with you . You can
search the site yourself for the goods you want . The OLCEKN company
sell many kinds of goods , like mobile phones , TV , Games , and so on
. It only takes one week to reach me . Really fast and good quality
with such a low price . Hope you can have a look when you have time .
Best regards.

Re: [jira] Commented: (FELIX-2284) Add common utility method for converting object (array) to string

[Sten Roger Sandvik]

2010/6/5 Peter Kriens peter.kri...@aqute.biz

 What is wrong with Arrays.toString(...) ? Been there since 1.2?


No, since Java 1.5 i think.

[jira] Commented: (FELIX-2387) registerServlet() throws NPE

[Sten Roger Sandvik (JIRA)]

[ 
https://issues.apache.org/jira/browse/FELIX-2387?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12875709#action_12875709
 ] 

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

This will probably be true for registerFilter too. Will put this to fix in 
2.0.6.

 registerServlet() throws NPE
 

 Key: FELIX-2387
 URL: https://issues.apache.org/jira/browse/FELIX-2387
 Project: Felix
  Issue Type: Bug
  Components: HTTP Service
Affects Versions: http-2.0.4
Reporter: Alan Cabrera
 Fix For: http-2.0.6


 registerServlet() throws NPE when passed a null for servlet.  It should throw 
 an IllegalArgumentException.
 java.lang.NullPointerException
   at 
 org.apache.felix.http.base.internal.handler.ServletHandler.init(ServletHandler.java:55)
   at 
 org.apache.felix.http.base.internal.handler.HandlerRegistry.addServlet(HandlerRegistry.java:65)
   at 
 org.apache.felix.http.base.internal.service.HttpServiceImpl.registerServlet(HttpServiceImpl.java:97)
   at 
 org.papoose.tck.http.BaseHttpServiceImplTest.testRegisterNullServlet(BaseHttpServiceImplTest.java:110)
   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
   at 
 sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
   at 
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
   at 
 org.ops4j.pax.exam.junit.extender.impl.internal.CallableTestMethodImpl.injectContextAndInvoke(CallableTestMethodImpl.java:143)
   at 
 org.ops4j.pax.exam.junit.extender.impl.internal.CallableTestMethodImpl.call(CallableTestMethodImpl.java:105)
   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
   at 
 sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
   at 
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
   at 
 org.ops4j.pax.exam.rbc.internal.RemoteBundleContextImpl.remoteCall(RemoteBundleContextImpl.java:80)
   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
   at 
 sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
   at 
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
   at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:305)
   at sun.rmi.transport.Transport$1.run(Transport.java:159)
   at java.security.AccessController.doPrivileged(Native Method)
   at sun.rmi.transport.Transport.serviceCall(Transport.java:155)
   at 
 sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:535)
   at 
 sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TCPTransport.java:790)
   at 
 sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:649)
   at 
 java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
   at 
 java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
   at java.lang.Thread.run(Thread.java:637)

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

[jira] Updated: (FELIX-2387) registerServlet() throws NPE

[Sten Roger Sandvik (JIRA)]

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

Sten Roger Sandvik updated FELIX-2387:
--

Fix Version/s: http-2.0.6

 registerServlet() throws NPE
 

 Key: FELIX-2387
 URL: https://issues.apache.org/jira/browse/FELIX-2387
 Project: Felix
  Issue Type: Bug
  Components: HTTP Service
Affects Versions: http-2.0.4
Reporter: Alan Cabrera
 Fix For: http-2.0.6


 registerServlet() throws NPE when passed a null for servlet.  It should throw 
 an IllegalArgumentException.
 java.lang.NullPointerException
   at 
 org.apache.felix.http.base.internal.handler.ServletHandler.init(ServletHandler.java:55)
   at 
 org.apache.felix.http.base.internal.handler.HandlerRegistry.addServlet(HandlerRegistry.java:65)
   at 
 org.apache.felix.http.base.internal.service.HttpServiceImpl.registerServlet(HttpServiceImpl.java:97)
   at 
 org.papoose.tck.http.BaseHttpServiceImplTest.testRegisterNullServlet(BaseHttpServiceImplTest.java:110)
   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
   at 
 sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
   at 
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
   at 
 org.ops4j.pax.exam.junit.extender.impl.internal.CallableTestMethodImpl.injectContextAndInvoke(CallableTestMethodImpl.java:143)
   at 
 org.ops4j.pax.exam.junit.extender.impl.internal.CallableTestMethodImpl.call(CallableTestMethodImpl.java:105)
   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
   at 
 sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
   at 
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
   at 
 org.ops4j.pax.exam.rbc.internal.RemoteBundleContextImpl.remoteCall(RemoteBundleContextImpl.java:80)
   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
   at 
 sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
   at 
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
   at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:305)
   at sun.rmi.transport.Transport$1.run(Transport.java:159)
   at java.security.AccessController.doPrivileged(Native Method)
   at sun.rmi.transport.Transport.serviceCall(Transport.java:155)
   at 
 sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:535)
   at 
 sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TCPTransport.java:790)
   at 
 sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:649)
   at 
 java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
   at 
 java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
   at java.lang.Thread.run(Thread.java:637)

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

[jira] Commented: (FELIX-2386) Registering a resource w/ an absolute internal name should result in an absolute name passed to getResource()

[Sten Roger Sandvik (JIRA)]

[ 
https://issues.apache.org/jira/browse/FELIX-2386?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12875714#action_12875714
 ] 

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

When you put in /org/papoose/tck will the parameter in getResource be 
org/papoose/tck (without slash)? If so, this is probably a bug. Not sure if 
fixing this will break other code. Anyone?


 Registering a resource w/ an absolute internal name should result in an 
 absolute name passed to getResource()
 -

 Key: FELIX-2386
 URL: https://issues.apache.org/jira/browse/FELIX-2386
 Project: Felix
  Issue Type: Bug
  Components: HTTP Service
Affects Versions: http-2.0.4
Reporter: Alan Cabrera

 I get 
 name: org/papoose/tck/http/BaseHttpServiceImplTest.class
 where I should get
 name: /org/papoose/tck/http/BaseHttpServiceImplTest.class
  
@Test
 public void testResourceAbsolute() throws Exception
 {
 ServiceReference sr = 
 bundleContext.getServiceReference(HttpService.class.getName());
 HttpService service = (HttpService) bundleContext.getService(sr);
 service.registerResources(/a/b, /org/papoose/tck, new 
 HttpContext()
 {
 public boolean handleSecurity(HttpServletRequest request, 
 HttpServletResponse response) throws IOException
 {
 return true;
 }
 public URL getResource(String name)
 {
 System.err.println(name:  + name);
 return BaseHttpServiceImplTest.class.getResource(name);
 }
 public String getMimeType(String name)
 {
 return null;
 }
 });
 URL url = new 
 URL(http://localhost:8080/a/b/http/BaseHttpServiceImplTest.class;);
 DataInputStream reader = new DataInputStream(url.openStream());
 assertEquals((byte) 0xca, reader.readByte());
 assertEquals((byte) 0xfe, reader.readByte());
 assertEquals((byte) 0xba, reader.readByte());
 assertEquals((byte) 0xbe, reader.readByte());
 service.unregister(/a/b);
 try
 {
 HttpURLConnection conn = (HttpURLConnection) url.openConnection();
 if (conn.getResponseCode() == HttpURLConnection.HTTP_NOT_FOUND) 
 throw new IOException(404);
 fail(Simple servlet improperly available);
 }
 catch (IOException e)
 {
 }
 }

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

[jira] Updated: (FELIX-2292) Uprage to jetty 7.0 (org.eclipse.jetty 7.0.2v20100331)

[Sten Roger Sandvik (JIRA)]

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

Sten Roger Sandvik updated FELIX-2292:
--

Fix Version/s: http-2.1.0

 Uprage to jetty 7.0 (org.eclipse.jetty 7.0.2v20100331)
 --

 Key: FELIX-2292
 URL: https://issues.apache.org/jira/browse/FELIX-2292
 Project: Felix
  Issue Type: Improvement
  Components: HTTP Service
Reporter: Jonathan Bardin
 Fix For: http-2.1.0

 Attachments: jetty7.patch, jetty7GoodFormat.patch


 Hi, 
 This is a small improvement of the Http Service in order to use jetty 7.0.2 
 (org.eclipse.jetty 7.0.2v20100331).
 The patch is following.
 Regards, 
 Jonathan

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

Re: Http service and servlet name

[Sten Roger Sandvik]

2010/4/22 Sahoo sa...@sun.com

 How does that work? The HTTP service implementation is supposed to call
 Servlet.init(ServletConfig) and Servlet.getServletConfig() must return the
 same ServletConfig back. User does not create ServletConfig object and pass
 to HTTP service. The javadoc for getServletConfig says the following:

 /Returns a servlet config object, which contains any initialization
 parameters and startup configuration for this servlet. This is the
 ServletConfig object passed to the init method; the init method should have
 stored this object so that this method could return it.
 /
 Sahoo


What I did is something like this: http://pastebin.com/cPqE1Eec

BR,
Sten Roger Sandvik

[jira] Commented: (FELIX-2292) Uprage to jetty 7.0 (org.eclipse.jetty 7.0.2v20100331)

[Sten Roger Sandvik (JIRA)]

[ 
https://issues.apache.org/jira/browse/FELIX-2292?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12859545#action_12859545
 ] 

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

Thanks for the patch. Should this patch be applied to a major (2.1.0) or minor 
(2.0.6) version of the service? What do you guys think?

 Uprage to jetty 7.0 (org.eclipse.jetty 7.0.2v20100331)
 --

 Key: FELIX-2292
 URL: https://issues.apache.org/jira/browse/FELIX-2292
 Project: Felix
  Issue Type: Improvement
  Components: HTTP Service
Reporter: Jonathan Bardin
 Attachments: jetty7.patch, jetty7GoodFormat.patch


 Hi, 
 This is a small improvement of the Http Service in order to use jetty 7.0.2 
 (org.eclipse.jetty 7.0.2v20100331).
 The patch is following.
 Regards, 
 Jonathan

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

[jira] Created: (FELIX-2137) Make it possible to set servlet/filter name

[Sten Roger Sandvik (JIRA)]

Make it possible to set servlet/filter name
---

 Key: FELIX-2137
 URL: https://issues.apache.org/jira/browse/FELIX-2137
 Project: Felix
  Issue Type: Improvement
  Components: HTTP Service
Affects Versions: http-2.0.4
Reporter: Sten Roger Sandvik
Assignee: Sten Roger Sandvik
 Fix For: http-2.0.6


Setting the name of a servlet is useful in some cases. Right now it is setting 
the servlet name as servlet-# where # is a instance number. The same as 
filter. Setting the name of a servlet/filter could be done in two ways:

* Setting a service property (lile name) - only possible when using 
whiteboard implementation.
* Setting it as a special init property - can be done either using whiteboard 
or HttpService. Probably the best approach.

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

Re: Felix under 1.5 and Jetty

[Sten Roger Sandvik]

On Fri, Jan 22, 2010 at 6:20 PM, Jackson, Bruce bru...@qualcomm.com wrote:
 I've stuck that in the pom.xml for http.jetty (i.e.
 felix/http.jetty/pom.xml) in the place you suggest, and rebuilt using

 mvn clean:clean
 mvn -Dpackaging=plugins install
 mvn -Dpackaging=bundle install

 and I still see the same thing. Have I missed something in forcing a rebuild
 of the jetty jar?


Just so you know. felix/http.jetty is the old jetty bundle
(1.1.0-SNAPSHOT) and felix/http/jetty is the new (2.0.5-SNAPSHOT). The
old one (felix/http.jetty directory) is not in the master pom module
list - only the new one. felix/http/jetty is dependent on the http
master pom under felix/http/pom.xml.


 Thanks

 Bruce


 On 22/01/2010 16:48, Chris Custine chris.cust...@gmail.com wrote:

 Just add this to the plugins section of the pom.xml:

       plugin
         groupIdorg.apache.maven.plugins/groupId
         artifactIdmaven-compiler-plugin/artifactId
         configuration
           source1.5/source
           target1.5/target
         /configuration
       /plugin

 Looks like almost all modules already do this individually, so this should
 probably be moved to the parent at some point.

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


 On Fri, Jan 22, 2010 at 9:41 AM, Jackson, Bruce bru...@qualcomm.com wrote:

 Hi All

 I've just checked out and built the latest version of Felix from svn as per
 the instructions at:

 http://felix.apache.org/site/building-felix.html

 When I look at the final compiled
 org.apache.felix.http.jetty-2.0.5-SNAPSHOT.jar with javap, I see that this
 has been compiled with the 1.4 compiler i.e. javap -verbose gives me:

 minor version: 0
 major version: 48

 I've tried to locate where this is set in the POM files, but does anyone
 happen to know how I can change this to compile under 1.5/1.6?

 Thanks

 Bruce

[jira] Commented: (FELIX-1979) ServletHandlerRequest.getPathInfo() returns undecoded string

[Sten Roger Sandvik (JIRA)]

[ 
https://issues.apache.org/jira/browse/FELIX-1979?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12800128#action_12800128
 ] 

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

Yes. That would be another approach. URLDecode approach is atleast 
server-container neutral (if for some reason some servlet containers do this 
differently).


 ServletHandlerRequest.getPathInfo() returns undecoded string
 

 Key: FELIX-1979
 URL: https://issues.apache.org/jira/browse/FELIX-1979
 Project: Felix
  Issue Type: Bug
  Components: HTTP Service
Affects Versions: http-2.0.4
Reporter: Felix Meschberger
Assignee: Felix Meschberger
 Fix For: http-2.0.6

 Attachments: FELIX-1979.patch


 The Servlet API specifies the HttpServletRequest.getPathInfo() to return a 
 decoded path string.
 The current implementation just cuts off the servlet context and servlet 
 alias from the request URL (retrieved from 
 HttpServletRequest.getRequestURI()), which is not decoded. Therefore the 
 resulting path info is also not decoded and needs decoding.

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

[jira] Commented: (FELIX-1962) Add support for (select) Servlet API listeners

[Sten Roger Sandvik (JIRA)]

[ 
https://issues.apache.org/jira/browse/FELIX-1962?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12795900#action_12795900
 ] 

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

Cool. Was thinking of supporting this in both ExtHttpService and whiteboard. 
Will check out your patch. Also support for HttpSession*Listeners should be 
possible. ServletContextListeners could be nice to have if you want to use 
unmodified code that depend on such startup mechanism.

 Add support for (select) Servlet API listeners
 --

 Key: FELIX-1962
 URL: https://issues.apache.org/jira/browse/FELIX-1962
 Project: Felix
  Issue Type: New Feature
  Components: HTTP Service
Affects Versions: http-2.0.4
Reporter: Felix Meschberger
 Attachments: FELIX-1962.patch


 The new Http Service implementation currently does not support any Servlet 
 API listeners at all. Support for some listeners can easily be implemented in 
 a transparent way: ServletContextAttributeListener, ServletRequestListener, 
 ServletRequestAttributeListener.
 The HttpSession listeners can probably not easily be implemented in such a 
 transparent way.
 The ServletContextListener is probably not worth it supporting. Most (if not 
 all) use cases for ServletContextListeners in traditional web applications 
 can be solved in better ways in an OSGi framework.

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

[jira] Updated: (FELIX-1962) Add support for (select) Servlet API listeners

[Sten Roger Sandvik (JIRA)]

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

Sten Roger Sandvik updated FELIX-1962:
--

Fix Version/s: http-2.0.6

Moving this to version 2.0.6.

 Add support for (select) Servlet API listeners
 --

 Key: FELIX-1962
 URL: https://issues.apache.org/jira/browse/FELIX-1962
 Project: Felix
  Issue Type: New Feature
  Components: HTTP Service
Affects Versions: http-2.0.4
Reporter: Felix Meschberger
 Fix For: http-2.0.6

 Attachments: FELIX-1962.patch


 The new Http Service implementation currently does not support any Servlet 
 API listeners at all. Support for some listeners can easily be implemented in 
 a transparent way: ServletContextAttributeListener, ServletRequestListener, 
 ServletRequestAttributeListener.
 The HttpSession listeners can probably not easily be implemented in such a 
 transparent way.
 The ServletContextListener is probably not worth it supporting. Most (if not 
 all) use cases for ServletContextListeners in traditional web applications 
 can be solved in better ways in an OSGi framework.

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

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

[Sten Roger Sandvik (JIRA)]

Add possibility to share ServletContext between bundles
---

 Key: FELIX-1963
 URL: https://issues.apache.org/jira/browse/FELIX-1963
 Project: Felix
  Issue Type: Bug
  Components: HTTP Service
Affects Versions: http-2.0.4
Reporter: Sten Roger Sandvik
Assignee: Sten Roger Sandvik
 Fix For: http-2.0.6


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 is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

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

[Sten Roger Sandvik (JIRA)]

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

Sten Roger Sandvik updated FELIX-1963:
--

Issue Type: New Feature  (was: Bug)

 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
 Fix For: http-2.0.6


 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 is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (FELIX-1946) jetty http service issues 'started' message when disabled

[Sten Roger Sandvik (JIRA)]

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

Sten Roger Sandvik updated FELIX-1946:
--

Fix Version/s: http-2.0.6
 Assignee: Sten Roger Sandvik

 jetty http service issues 'started' message when disabled
 -

 Key: FELIX-1946
 URL: https://issues.apache.org/jira/browse/FELIX-1946
 Project: Felix
  Issue Type: Bug
  Components: HTTP Service
Affects Versions: http-2.0.4
Reporter: Derek Baum
Assignee: Sten Roger Sandvik
Priority: Minor
 Fix For: http-2.0.6


 I want to configure the felix jetty http service using config admin, so I set 
 the following properties to stop it from starting automatically:
 org.osgi.service.http.port = -1
 org.apache.felix.http.enable = false
 However, when the bundle is activated, it still reports that it has started:
 % [INFO] Started jetty 6.1.x at port -1
 A 'Jetty HTTP Service' thread is actually started, but as http is not 
 enabled, no http server connector is created.
 The above 'Started' message should not appear when http (and https) are 
 disabled, and it would be good if the 'Jetty HTTP Service' was not created 
 until the service is enabled using config admin, for example:
 % setpid org.apache.felix.http org.osgi.service.http.port==1234 
 org.apache.felix.http.enable==true
 % [INFO] Started jetty 6.1.x at port 1234

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

[jira] Commented: (FELIX-1946) jetty http service issues 'started' message when disabled

[Sten Roger Sandvik (JIRA)]

[ 
https://issues.apache.org/jira/browse/FELIX-1946?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12795903#action_12795903
 ] 

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


You are right. The message appears always. Will schedule this fix for version 
2.0.6.

 jetty http service issues 'started' message when disabled
 -

 Key: FELIX-1946
 URL: https://issues.apache.org/jira/browse/FELIX-1946
 Project: Felix
  Issue Type: Bug
  Components: HTTP Service
Affects Versions: http-2.0.4
Reporter: Derek Baum
Priority: Minor
 Fix For: http-2.0.6


 I want to configure the felix jetty http service using config admin, so I set 
 the following properties to stop it from starting automatically:
 org.osgi.service.http.port = -1
 org.apache.felix.http.enable = false
 However, when the bundle is activated, it still reports that it has started:
 % [INFO] Started jetty 6.1.x at port -1
 A 'Jetty HTTP Service' thread is actually started, but as http is not 
 enabled, no http server connector is created.
 The above 'Started' message should not appear when http (and https) are 
 disabled, and it would be good if the 'Jetty HTTP Service' was not created 
 until the service is enabled using config admin, for example:
 % setpid org.apache.felix.http org.osgi.service.http.port==1234 
 org.apache.felix.http.enable==true
 % [INFO] Started jetty 6.1.x at port 1234

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

[jira] Commented: (FELIX-1955) Possibility to configure keystore type (Currently only JKS is available)

[Sten Roger Sandvik (JIRA)]

[ 
https://issues.apache.org/jira/browse/FELIX-1955?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12795905#action_12795905
 ] 

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

Will investigate this and find a way to support other keystore's.

 Possibility to configure keystore type (Currently only JKS is available)
 

 Key: FELIX-1955
 URL: https://issues.apache.org/jira/browse/FELIX-1955
 Project: Felix
  Issue Type: Improvement
  Components: HTTP Service
Affects Versions: http-2.0.4
Reporter: Boris Toninski

 There should be a way to configure the keystore type to be used for SSL 
 comunication. Currently as I can see JKS is used as default in 
 org.mortbay.jetty.security.SslSocketConnector.
 The problem with this is that there are classpath implementations that do not 
 support JKS keystore algorithm.  We develop a project which runs on such 
 classpath and this is a real stopper for us.

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

Regarding broken Http Service links...

[Sten Roger Sandvik]

Hi.

The issue with the broken Http Service links and news section seems
strange. I swear I updated the news section, download section and even
the Http Service documentation when releasing 2.0.4. But it seems no
changes is there in the history either. Any backup/restore that was
going on around 27. november? Anyway, will update the news section and
http service documentation again.

Regards,
Sten Roger Sandvik

Re: Regarding broken Http Service links...

[Sten Roger Sandvik]

Also I noticed on the 27. november when I edited the news section that
the Gogo release bullet was there. I even fixed a spelling mistake in
the news announcement. I bet something fishy was going on the 27th :-)

On Fri, Dec 11, 2009 at 9:03 AM, Sten Roger Sandvik s...@x3m.com wrote:
 Hi.

 The issue with the broken Http Service links and news section seems
 strange. I swear I updated the news section, download section and even
 the Http Service documentation when releasing 2.0.4. But it seems no
 changes is there in the history either. Any backup/restore that was
 going on around 27. november? Anyway, will update the news section and
 http service documentation again.

 Regards,
 Sten Roger Sandvik

Re: Board report due

[Sten Roger Sandvik]

Yes,

HTTP Service (2.0.2) ... and 2.0.4 :-)

On Tue, Dec 8, 2009 at 10:00 PM, Richard S. Hall he...@ungoverned.org wrote:
 Ok, here is my first pass at the board report for this quarter:


  http://cwiki.apache.org/confluence/display/FELIX/Board+Report+%282009-12%29

 Please help me remember what I am missing by adding it. Thanks.

 - richard

[RESULT] [VOTE] Release Felix Http Service version 2.0.4

[Sten Roger Sandvik]

Hi.

The vote has passed (+3 binding/+1 non-binding) with the following result:

+1 binding votes: Rob Walker, Guillaume Nodet and Felix Meschberger.
+1 non-binding votes: Charles Moulliard

No other votes was cast.

Will copy the relese and promote artifacts later today.

Regards,
Sten Roger Sandvik

[VOTE] Release Felix Http Service version 2.0.4

[Sten Roger Sandvik]

Hi,

This is a vote for releasing Felix Http Service 2.0.4.

We solved 7 issues in this release:
https://issues.apache.org/jira/browse/FELIX/fixforversion/12314280

There is still outstanding issues:
https://issues.apache.org/jira/browse/FELIX/component/12310340

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

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 006 /tmp/felix-staging

Please vote to approve this release:

[ ] +1 Approve the release
[ ] -1 Don't the release (please provide specific comments)

This vote will be open for 72 hours.

Regards,
Sten Roger Sandvik

[jira] Created: (FELIX-1872) NPE while setting attribute on ServletContext

[Sten Roger Sandvik (JIRA)]

NPE while setting attribute on ServletContext
-

 Key: FELIX-1872
 URL: https://issues.apache.org/jira/browse/FELIX-1872
 Project: Felix
  Issue Type: Bug
  Components: HTTP Service
Affects Versions: http-2.0.2
Reporter: Sten Roger Sandvik
Assignee: Sten Roger Sandvik
 Fix For: http-2.0.4


NPE inside ServletContextImpl.setAttribute(..) when setting with null key 
and/or null value. Should be failsafe.

java.lang.NullPointerException
at 
java.util.concurrent.ConcurrentHashMap.put(ConcurrentHashMap.java:881)
at 
org.apache.felix.http.base.internal.context.ServletContextImpl.setAttribute(ServletContextImpl.java:152)


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

[jira] Created: (FELIX-1873) Wrong default HttpContext in Whiteboard

[Sten Roger Sandvik (JIRA)]

Wrong default HttpContext in Whiteboard
---

 Key: FELIX-1873
 URL: https://issues.apache.org/jira/browse/FELIX-1873
 Project: Felix
  Issue Type: Bug
  Components: HTTP Service
Affects Versions: http-2.0.2
Reporter: Sten Roger Sandvik
Assignee: Sten Roger Sandvik
 Fix For: http-2.0.4


When a whiteboard registration is used with no httpcontext it should be using a 
default. This default should be associated with the right bundle (bundle which 
registered the service) so that ServletContext.getResource(..) methods will 
work correctly. Right now it is not using the right bundle - it's using the 
whiteboard extender itself.

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

[jira] Updated: (FELIX-1860) HttpServletRequest objects passed through HttpService don't respond to getAuthType() and getRemoteUser() properly

[Sten Roger Sandvik (JIRA)]

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

Sten Roger Sandvik updated FELIX-1860:
--

Fix Version/s: http-2.0.4

 HttpServletRequest objects passed through HttpService don't respond to 
 getAuthType() and getRemoteUser() properly
 -

 Key: FELIX-1860
 URL: https://issues.apache.org/jira/browse/FELIX-1860
 Project: Felix
  Issue Type: Bug
  Components: HTTP Service
Affects Versions: http-2.0.2
Reporter: Justin Edelson
 Fix For: http-2.0.4

 Attachments: FELIX-1860.patch


 According to the JavaDoc for org.osgi.service.http.HttpContext, the 
 authentication type and remote user should be accessible via the standard 
 getAuthType() and getRemoteUser() methods of HttpServletRequest. However, 
 Felix HttpService's ServletHandlerRequest class does *not* do this.
 patch to follow shortly...

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

[jira] Commented: (FELIX-1860) HttpServletRequest objects passed through HttpService don't respond to getAuthType() and getRemoteUser() properly

[Sten Roger Sandvik (JIRA)]

[ 
https://issues.apache.org/jira/browse/FELIX-1860?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12778644#action_12778644
 ] 

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

Thanks for the patch. Will apply it shortly and test it locally.

 HttpServletRequest objects passed through HttpService don't respond to 
 getAuthType() and getRemoteUser() properly
 -

 Key: FELIX-1860
 URL: https://issues.apache.org/jira/browse/FELIX-1860
 Project: Felix
  Issue Type: Bug
  Components: HTTP Service
Affects Versions: http-2.0.2
Reporter: Justin Edelson
 Fix For: http-2.0.4

 Attachments: FELIX-1860.patch


 According to the JavaDoc for org.osgi.service.http.HttpContext, the 
 authentication type and remote user should be accessible via the standard 
 getAuthType() and getRemoteUser() methods of HttpServletRequest. However, 
 Felix HttpService's ServletHandlerRequest class does *not* do this.
 patch to follow shortly...

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

[jira] Updated: (FELIX-1863) getServletPath() should return when alias is /

[Sten Roger Sandvik (JIRA)]

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

Sten Roger Sandvik updated FELIX-1863:
--

Fix Version/s: http-2.0.4

Thanks for the patch. Will apply it shortly and get it included in 2.0.4.

 getServletPath() should return  when alias is /
 -

 Key: FELIX-1863
 URL: https://issues.apache.org/jira/browse/FELIX-1863
 Project: Felix
  Issue Type: Bug
  Components: HTTP Service
Affects Versions: http-2.0.2
Reporter: Justin Edelson
 Fix For: http-2.0.4

 Attachments: FELIX-1863.patch


 When a servlet is registered with HttpService with an alias of /, 
 getServletPath() should return . Currently it returns /.

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

[jira] Closed: (FELIX-1863) getServletPath() should return when alias is /

[Sten Roger Sandvik (JIRA)]

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

Sten Roger Sandvik closed FELIX-1863.
-

Resolution: Fixed
  Assignee: Sten Roger Sandvik

Applied the patch. 

 getServletPath() should return  when alias is /
 -

 Key: FELIX-1863
 URL: https://issues.apache.org/jira/browse/FELIX-1863
 Project: Felix
  Issue Type: Bug
  Components: HTTP Service
Affects Versions: http-2.0.2
Reporter: Justin Edelson
Assignee: Sten Roger Sandvik
 Fix For: http-2.0.4

 Attachments: FELIX-1863.patch


 When a servlet is registered with HttpService with an alias of /, 
 getServletPath() should return . Currently it returns /.

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

[jira] Closed: (FELIX-1860) HttpServletRequest objects passed through HttpService don't respond to getAuthType() and getRemoteUser() properly

[Sten Roger Sandvik (JIRA)]

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

Sten Roger Sandvik closed FELIX-1860.
-

Resolution: Fixed
  Assignee: Sten Roger Sandvik

Applied the patch.

 HttpServletRequest objects passed through HttpService don't respond to 
 getAuthType() and getRemoteUser() properly
 -

 Key: FELIX-1860
 URL: https://issues.apache.org/jira/browse/FELIX-1860
 Project: Felix
  Issue Type: Bug
  Components: HTTP Service
Affects Versions: http-2.0.2
Reporter: Justin Edelson
Assignee: Sten Roger Sandvik
 Fix For: http-2.0.4

 Attachments: FELIX-1860.patch


 According to the JavaDoc for org.osgi.service.http.HttpContext, the 
 authentication type and remote user should be accessible via the standard 
 getAuthType() and getRemoteUser() methods of HttpServletRequest. However, 
 Felix HttpService's ServletHandlerRequest class does *not* do this.
 patch to follow shortly...

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

[jira] Commented: (FELIX-1873) Wrong default HttpContext in Whiteboard

[Sten Roger Sandvik (JIRA)]

[ 
https://issues.apache.org/jira/browse/FELIX-1873?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12778655#action_12778655
 ] 

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

Fixed the code, but need to test with my apps before closing. 

 Wrong default HttpContext in Whiteboard
 ---

 Key: FELIX-1873
 URL: https://issues.apache.org/jira/browse/FELIX-1873
 Project: Felix
  Issue Type: Bug
  Components: HTTP Service
Affects Versions: http-2.0.2
Reporter: Sten Roger Sandvik
Assignee: Sten Roger Sandvik
 Fix For: http-2.0.4


 When a whiteboard registration is used with no httpcontext it should be using 
 a default. This default should be associated with the right bundle (bundle 
 which registered the service) so that ServletContext.getResource(..) methods 
 will work correctly. Right now it is not using the right bundle - it's using 
 the whiteboard extender itself.

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

[jira] Closed: (FELIX-1872) NPE while setting attribute on ServletContext

[Sten Roger Sandvik (JIRA)]

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

Sten Roger Sandvik closed FELIX-1872.
-

Resolution: Fixed

 NPE while setting attribute on ServletContext
 -

 Key: FELIX-1872
 URL: https://issues.apache.org/jira/browse/FELIX-1872
 Project: Felix
  Issue Type: Bug
  Components: HTTP Service
Affects Versions: http-2.0.2
Reporter: Sten Roger Sandvik
Assignee: Sten Roger Sandvik
 Fix For: http-2.0.4


 NPE inside ServletContextImpl.setAttribute(..) when setting with null key 
 and/or null value. Should be failsafe.
 java.lang.NullPointerException
   at 
 java.util.concurrent.ConcurrentHashMap.put(ConcurrentHashMap.java:881)
   at 
 org.apache.felix.http.base.internal.context.ServletContextImpl.setAttribute(ServletContextImpl.java:152)

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

[jira] Closed: (FELIX-1873) Wrong default HttpContext in Whiteboard

[Sten Roger Sandvik (JIRA)]

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

Sten Roger Sandvik closed FELIX-1873.
-

Resolution: Fixed

 Wrong default HttpContext in Whiteboard
 ---

 Key: FELIX-1873
 URL: https://issues.apache.org/jira/browse/FELIX-1873
 Project: Felix
  Issue Type: Bug
  Components: HTTP Service
Affects Versions: http-2.0.2
Reporter: Sten Roger Sandvik
Assignee: Sten Roger Sandvik
 Fix For: http-2.0.4


 When a whiteboard registration is used with no httpcontext it should be using 
 a default. This default should be associated with the right bundle (bundle 
 which registered the service) so that ServletContext.getResource(..) methods 
 will work correctly. Right now it is not using the right bundle - it's using 
 the whiteboard extender itself.

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

[jira] Commented: (FELIX-1796) Add cometd/bayeux support to HTTP Service

[Sten Roger Sandvik (JIRA)]

[ 
https://issues.apache.org/jira/browse/FELIX-1796?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12771410#action_12771410
 ] 

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

I do not know that much about cometd. Anyone else has some opinions here?

 Add cometd/bayeux support to HTTP Service
 -

 Key: FELIX-1796
 URL: https://issues.apache.org/jira/browse/FELIX-1796
 Project: Felix
  Issue Type: New Feature
  Components: HTTP Service
Reporter: Tim Moloney
 Attachments: FELIX-1796-AddCometdBayeuxSupport.patch




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

[jira] Created: (FELIX-1821) Unstable logging when restarting bundle

[Sten Roger Sandvik (JIRA)]

Unstable logging when restarting bundle
---

 Key: FELIX-1821
 URL: https://issues.apache.org/jira/browse/FELIX-1821
 Project: Felix
  Issue Type: Bug
  Components: HTTP Service
Affects Versions: http-2.0.2
Reporter: Sten Roger Sandvik
Assignee: Sten Roger Sandvik
 Fix For: http-2.0.4


Seems that when restarting the bundle (tested with 
org.apache.felix.http.bundle) the logging (if you have a LogService available) 
is going into stdout instead of the LogService.

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

[jira] Resolved: (FELIX-1821) Unstable logging when restarting bundle

[Sten Roger Sandvik (JIRA)]

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

Sten Roger Sandvik resolved FELIX-1821.
---

Resolution: Fixed

 Unstable logging when restarting bundle
 ---

 Key: FELIX-1821
 URL: https://issues.apache.org/jira/browse/FELIX-1821
 Project: Felix
  Issue Type: Bug
  Components: HTTP Service
Affects Versions: http-2.0.2
Reporter: Sten Roger Sandvik
Assignee: Sten Roger Sandvik
 Fix For: http-2.0.4


 Seems that when restarting the bundle (tested with 
 org.apache.felix.http.bundle) the logging (if you have a LogService 
 available) is going into stdout instead of the LogService.

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

[jira] Resolved: (FELIX-1704) Support for port as service properties

[Sten Roger Sandvik (JIRA)]

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

Sten Roger Sandvik resolved FELIX-1704.
---

Resolution: Fixed

Some properties are now exported with the HttpService when running Jetty. 
Here's an example of what is exported now:

org.apache.felix.http.enable = true
org.apache.felix.https.enable = false
org.osgi.service.http.port = 8080
org.osgi.service.http.port.secure = 433



 Support for port as service properties
 --

 Key: FELIX-1704
 URL: https://issues.apache.org/jira/browse/FELIX-1704
 Project: Felix
  Issue Type: Improvement
  Components: HTTP Service
Affects Versions: http-2.0.2
Reporter: Sten Roger Sandvik
Assignee: Sten Roger Sandvik
 Fix For: http-2.0.4


 Support assigned port in Jetty as service property. Both secure and non 
 secure. Use the same logic as in old Jetty http service 1.0.1.
 * org.apache.felix.http.svcprop.port
 * org.apache.felix.http.svcprop.port.secure

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

[jira] Commented: (FELIX-1796) Add cometd/bayeux support to HTTP Service

[Sten Roger Sandvik (JIRA)]

[ 
https://issues.apache.org/jira/browse/FELIX-1796?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12771164#action_12771164
 ] 

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

Any luck with this yet? I have no experience with cometd, but the 
implementation you have done here seems to fit nicely into the packages. Too 
bad it does not seem to work. Will try to look into this.

 Add cometd/bayeux support to HTTP Service
 -

 Key: FELIX-1796
 URL: https://issues.apache.org/jira/browse/FELIX-1796
 Project: Felix
  Issue Type: New Feature
  Components: HTTP Service
Reporter: Tim Moloney
 Attachments: FELIX-1796-AddCometdBayeuxSupport.patch




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

[jira] Commented: (FELIX-1796) Add cometd/bayeux support to HTTP Service

[Sten Roger Sandvik (JIRA)]

[ 
https://issues.apache.org/jira/browse/FELIX-1796?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12771187#action_12771187
 ] 

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

Have investigated this and it seems that you are using ServletContext 
attributes. The servlet context is not shared between the two bundles so the 
Bayeux cannot be shared this way. 

I see that applications exists when you want to share context state this way. 
Will think about how we can solve this in the future. But right now, maybe the 
Boyeux should be shared in a different way? By exposing it as a service maybe?

 Add cometd/bayeux support to HTTP Service
 -

 Key: FELIX-1796
 URL: https://issues.apache.org/jira/browse/FELIX-1796
 Project: Felix
  Issue Type: New Feature
  Components: HTTP Service
Reporter: Tim Moloney
 Attachments: FELIX-1796-AddCometdBayeuxSupport.patch




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

[jira] Commented: (FELIX-1796) Add cometd/bayeux support to HTTP Service

[Sten Roger Sandvik (JIRA)]

[ 
https://issues.apache.org/jira/browse/FELIX-1796?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12771302#action_12771302
 ] 

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

Even if you register it with the whiteboard implementation the httpcontext is 
keyed with originating bundle + contextId. Another problem is that the 
order of servlet initialization is not guaranteed with the whiteboard.

 Add cometd/bayeux support to HTTP Service
 -

 Key: FELIX-1796
 URL: https://issues.apache.org/jira/browse/FELIX-1796
 Project: Felix
  Issue Type: New Feature
  Components: HTTP Service
Reporter: Tim Moloney
 Attachments: FELIX-1796-AddCometdBayeuxSupport.patch




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

[jira] Issue Comment Edited: (FELIX-1796) Add cometd/bayeux support to HTTP Service

[Sten Roger Sandvik (JIRA)]

[ 
https://issues.apache.org/jira/browse/FELIX-1796?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12771302#action_12771302
 ] 

Sten Roger Sandvik edited comment on FELIX-1796 at 10/29/09 5:49 AM:
-

Even if you register it with the whiteboard implementation the resuting 
servletcontext is keyed with originating bundle + contextId. Another 
problem is that the order of servlet initialization is not guaranteed with the 
whiteboard.

  was (Author: srs):
Even if you register it with the whiteboard implementation the httpcontext 
is keyed with originating bundle + contextId. Another problem is that the 
order of servlet initialization is not guaranteed with the whiteboard.
  
 Add cometd/bayeux support to HTTP Service
 -

 Key: FELIX-1796
 URL: https://issues.apache.org/jira/browse/FELIX-1796
 Project: Felix
  Issue Type: New Feature
  Components: HTTP Service
Reporter: Tim Moloney
 Attachments: FELIX-1796-AddCometdBayeuxSupport.patch




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

[jira] Commented: (FELIX-1712) CLONE -Support for port as service properties

[Sten Roger Sandvik (JIRA)]

[ 
https://issues.apache.org/jira/browse/FELIX-1712?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12762758#action_12762758
 ] 

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

Not sure why this is affecting dependencymanager-shell?

 CLONE -Support for port as service properties
 -

 Key: FELIX-1712
 URL: https://issues.apache.org/jira/browse/FELIX-1712
 Project: Felix
  Issue Type: Improvement
  Components: Installer
Affects Versions: dependencymanager.shell-2.0.1
Reporter: andre payne
Assignee: Sten Roger Sandvik
 Fix For: maven-bundle-plugin-2.1.0


 Support assigned port in Jetty as service property. Both secure and non 
 secure. Use the same logic as in old Jetty http service 1.0.1.
 * org.apache.felix.http.svcprop.port
 * org.apache.felix.http.svcprop.port.secure

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

[jira] Assigned: (FELIX-1713) getPathInfo wrongly returns path containing semicolon-separated attributes like ;jsessionid

[Sten Roger Sandvik (JIRA)]

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

Sten Roger Sandvik reassigned FELIX-1713:
-

Assignee: Sten Roger Sandvik

 getPathInfo wrongly returns path containing semicolon-separated attributes 
 like ;jsessionid
 -

 Key: FELIX-1713
 URL: https://issues.apache.org/jira/browse/FELIX-1713
 Project: Felix
  Issue Type: Bug
  Components: HTTP Service
Affects Versions: http-2.0.2
Reporter: Sid Fischer
Assignee: Sten Roger Sandvik
 Fix For: http-2.0.4


 Since org.apache.felix.http.jetty-2.0.2/ org.apache.felix.http.base-2.0.2 
 calling HttpServletRequest.getPathInfo() not only returns the raw path but 
 additionally the semicolon-separated attributes, like ;jsessionid.
 Example (version 1.0.1):
 getRequestURI(): /test/foo;bar=baz
 getPathInfo(): /foo
 Example (version 2.0.2):
 getRequestURI(): /test/foo;bar=baz
 getPathInfo(): /foo;bar=baz
 Looks like in 
 org/apache/felix/http/base/internal/handler/ServletHandler$RequestWrapper the 
 original HttpServletRequest is wrapped and getPathInfo() is overwritten using 
 the String retrieved from getRequestURI() including the attributes.
 This behaviour will break a lot of applications which rely on 
 urlrewriting-based session handling.

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

[jira] Commented: (FELIX-1713) getPathInfo wrongly returns path containing semicolon-separated attributes like ;jsessionid

[Sten Roger Sandvik (JIRA)]

[ 
https://issues.apache.org/jira/browse/FELIX-1713?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12762781#action_12762781
 ] 

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

Added fix for this in trunk. Need a little more testing, but I am pretty sure 
this will fix getPathinfo() problem.

 getPathInfo wrongly returns path containing semicolon-separated attributes 
 like ;jsessionid
 -

 Key: FELIX-1713
 URL: https://issues.apache.org/jira/browse/FELIX-1713
 Project: Felix
  Issue Type: Bug
  Components: HTTP Service
Affects Versions: http-2.0.2
Reporter: Sid Fischer
Assignee: Sten Roger Sandvik
 Fix For: http-2.0.4


 Since org.apache.felix.http.jetty-2.0.2/ org.apache.felix.http.base-2.0.2 
 calling HttpServletRequest.getPathInfo() not only returns the raw path but 
 additionally the semicolon-separated attributes, like ;jsessionid.
 Example (version 1.0.1):
 getRequestURI(): /test/foo;bar=baz
 getPathInfo(): /foo
 Example (version 2.0.2):
 getRequestURI(): /test/foo;bar=baz
 getPathInfo(): /foo;bar=baz
 Looks like in 
 org/apache/felix/http/base/internal/handler/ServletHandler$RequestWrapper the 
 original HttpServletRequest is wrapped and getPathInfo() is overwritten using 
 the String retrieved from getRequestURI() including the attributes.
 This behaviour will break a lot of applications which rely on 
 urlrewriting-based session handling.

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

[jira] Work started: (FELIX-1713) getPathInfo wrongly returns path containing semicolon-separated attributes like ;jsessionid

[Sten Roger Sandvik (JIRA)]

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

Work on FELIX-1713 started by Sten Roger Sandvik.

 getPathInfo wrongly returns path containing semicolon-separated attributes 
 like ;jsessionid
 -

 Key: FELIX-1713
 URL: https://issues.apache.org/jira/browse/FELIX-1713
 Project: Felix
  Issue Type: Bug
  Components: HTTP Service
Affects Versions: http-2.0.2
Reporter: Sid Fischer
Assignee: Sten Roger Sandvik
 Fix For: http-2.0.4


 Since org.apache.felix.http.jetty-2.0.2/ org.apache.felix.http.base-2.0.2 
 calling HttpServletRequest.getPathInfo() not only returns the raw path but 
 additionally the semicolon-separated attributes, like ;jsessionid.
 Example (version 1.0.1):
 getRequestURI(): /test/foo;bar=baz
 getPathInfo(): /foo
 Example (version 2.0.2):
 getRequestURI(): /test/foo;bar=baz
 getPathInfo(): /foo;bar=baz
 Looks like in 
 org/apache/felix/http/base/internal/handler/ServletHandler$RequestWrapper the 
 original HttpServletRequest is wrapped and getPathInfo() is overwritten using 
 the String retrieved from getRequestURI() including the attributes.
 This behaviour will break a lot of applications which rely on 
 urlrewriting-based session handling.

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

[jira] Closed: (FELIX-1713) getPathInfo wrongly returns path containing semicolon-separated attributes like ;jsessionid

[Sten Roger Sandvik (JIRA)]

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

Sten Roger Sandvik closed FELIX-1713.
-

Resolution: Fixed

Verified with my local installation. Fix is ok.

 getPathInfo wrongly returns path containing semicolon-separated attributes 
 like ;jsessionid
 -

 Key: FELIX-1713
 URL: https://issues.apache.org/jira/browse/FELIX-1713
 Project: Felix
  Issue Type: Bug
  Components: HTTP Service
Affects Versions: http-2.0.2
Reporter: Sid Fischer
Assignee: Sten Roger Sandvik
 Fix For: http-2.0.4


 Since org.apache.felix.http.jetty-2.0.2/ org.apache.felix.http.base-2.0.2 
 calling HttpServletRequest.getPathInfo() not only returns the raw path but 
 additionally the semicolon-separated attributes, like ;jsessionid.
 Example (version 1.0.1):
 getRequestURI(): /test/foo;bar=baz
 getPathInfo(): /foo
 Example (version 2.0.2):
 getRequestURI(): /test/foo;bar=baz
 getPathInfo(): /foo;bar=baz
 Looks like in 
 org/apache/felix/http/base/internal/handler/ServletHandler$RequestWrapper the 
 original HttpServletRequest is wrapped and getPathInfo() is overwritten using 
 the String retrieved from getRequestURI() including the attributes.
 This behaviour will break a lot of applications which rely on 
 urlrewriting-based session handling.

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

[jira] Reopened: (FELIX-1713) getPathInfo wrongly returns path containing semicolon-separated attributes like ;jsessionid

[Sten Roger Sandvik (JIRA)]

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

Sten Roger Sandvik reopened FELIX-1713:
---


Actually. Need to check this a little bit more.

 getPathInfo wrongly returns path containing semicolon-separated attributes 
 like ;jsessionid
 -

 Key: FELIX-1713
 URL: https://issues.apache.org/jira/browse/FELIX-1713
 Project: Felix
  Issue Type: Bug
  Components: HTTP Service
Affects Versions: http-2.0.2
Reporter: Sid Fischer
Assignee: Sten Roger Sandvik
 Fix For: http-2.0.4


 Since org.apache.felix.http.jetty-2.0.2/ org.apache.felix.http.base-2.0.2 
 calling HttpServletRequest.getPathInfo() not only returns the raw path but 
 additionally the semicolon-separated attributes, like ;jsessionid.
 Example (version 1.0.1):
 getRequestURI(): /test/foo;bar=baz
 getPathInfo(): /foo
 Example (version 2.0.2):
 getRequestURI(): /test/foo;bar=baz
 getPathInfo(): /foo;bar=baz
 Looks like in 
 org/apache/felix/http/base/internal/handler/ServletHandler$RequestWrapper the 
 original HttpServletRequest is wrapped and getPathInfo() is overwritten using 
 the String retrieved from getRequestURI() including the attributes.
 This behaviour will break a lot of applications which rely on 
 urlrewriting-based session handling.

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

[jira] Closed: (FELIX-1713) getPathInfo wrongly returns path containing semicolon-separated attributes like ;jsessionid

[Sten Roger Sandvik (JIRA)]

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

Sten Roger Sandvik closed FELIX-1713.
-

Resolution: Fixed

Now it seems to be fixed in trunk. Request attributes on URI is not longer 
returned in getPathInfo().

 getPathInfo wrongly returns path containing semicolon-separated attributes 
 like ;jsessionid
 -

 Key: FELIX-1713
 URL: https://issues.apache.org/jira/browse/FELIX-1713
 Project: Felix
  Issue Type: Bug
  Components: HTTP Service
Affects Versions: http-2.0.2
Reporter: Sid Fischer
Assignee: Sten Roger Sandvik
 Fix For: http-2.0.4


 Since org.apache.felix.http.jetty-2.0.2/ org.apache.felix.http.base-2.0.2 
 calling HttpServletRequest.getPathInfo() not only returns the raw path but 
 additionally the semicolon-separated attributes, like ;jsessionid.
 Example (version 1.0.1):
 getRequestURI(): /test/foo;bar=baz
 getPathInfo(): /foo
 Example (version 2.0.2):
 getRequestURI(): /test/foo;bar=baz
 getPathInfo(): /foo;bar=baz
 Looks like in 
 org/apache/felix/http/base/internal/handler/ServletHandler$RequestWrapper the 
 original HttpServletRequest is wrapped and getPathInfo() is overwritten using 
 the String retrieved from getRequestURI() including the attributes.
 This behaviour will break a lot of applications which rely on 
 urlrewriting-based session handling.

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

Re: [VOTE] Release Felix Http Service version 2.0.2

[Sten Roger Sandvik]

Great!

On Fri, Oct 2, 2009 at 3:58 PM, Rob Walker r...@ascert.com wrote:

 Sten

 As before - I'm happy to add my +1 if others have had a chance to try and
 are good with this. Certainly seems like the latest round between 2.0.0 and
 2.0.2 got some very useful feedback.

 Soon as my current project task is out the way, I'm hoping to get a chance
 to move our app onto the new http service as first part of my next piece of
 work. Very confident this will be fine, but happy just to raise JIRA issues
 and look into any issues we find along the way.

 -- Rob


 Sten Roger Sandvik wrote:

 Hi.

 The first release I prepared failed since it was some issues regarding
 NOTICE files. Have now fixed the issues and tries the release again.
 Hopefully it will go trough this time :-)

 We solved 9 issues in this release:
 https://issues.apache.org/jira/browse/FELIX/fixforversion/12314224

 There are 8 outstanding issues:
 https://issues.apache.org/jira/browse/FELIX/component/12310340

 Staging repository:
 https://repository.apache.org/content/repositories/felix-staging-001/

 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 001 /tmp/felix-staging

 Please vote to approve this release:

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

 This vote will be open for 72 hours.

 Regards,
 Sten Roger Sandvik




 --


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

Re: [VOTE] Release Felix Http Service version 2.0.2

[Sten Roger Sandvik]

Hi.

The vote to release the Apache Felix Http Service 2.0.2 passed successfully
with tree binding +1 votes from:

* Rob Walker
* Richard S. Hall
* Guillaume Nodet

No other votes have been casted. I'll continue with the release process now.

Thanks for voting!

Regards,
Sten Roger Sandvik

On Thu, Oct 1, 2009 at 10:50 PM, Sten Roger Sandvik s...@x3m.com wrote:

 Hi.

 The first release I prepared failed since it was some issues regarding
 NOTICE files. Have now fixed the issues and tries the release again.
 Hopefully it will go trough this time :-)

 We solved 9 issues in this release:
 https://issues.apache.org/jira/browse/FELIX/fixforversion/12314224

 There are 8 outstanding issues:
 https://issues.apache.org/jira/browse/FELIX/component/12310340

 Staging repository:
 https://repository.apache.org/content/repositories/felix-staging-001/

 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 001 /tmp/felix-staging

 Please vote to approve this release:

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

 This vote will be open for 72 hours.

 Regards,
 Sten Roger Sandvik

Http Service documentaiton available...

[Sten Roger Sandvik]

Hi.

First version of the new Http Service documentation is now available. Read
it here:
http://felix.apache.org/site/apache-felix-http-service.html

Regards,
Sten Roger Sandvik

Re: Remote shell port number

[Sten Roger Sandvik]

Good you asked about this. I totally forgot to include this functionality in
the new Http Service. Added as a Jira task now. Yes, it was in 1.0.1 of
Jetty Http service.

On Mon, Oct 5, 2009 at 9:25 PM, Richard S. Hall he...@ungoverned.orgwrote:

 So, is there any way to discover on which port number the remote shell is
 listening for connections? If the port is configured to 0, then it will
 choose an open port, but how do we know which it is?

 In the HTTP Service impl, I believe we attach a service property indicating
 the port, but in this case there is no associated service to which we could
 attach properties.

 This seems like it would be worthwhile. Thoughts?

 - richard

[jira] Commented: (FELIX-1704) Support for port as service properties

[Sten Roger Sandvik (JIRA)]

[ 
https://issues.apache.org/jira/browse/FELIX-1704?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12762350#action_12762350
 ] 

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

Version 1.0.1 (and 1.0.0) has two properties to be able to set which properties 
should be exported. This has default values:

org.apache.felix.http.svcprop.port = org.osgi.service.http.port
org.apache.felix.http.svcprop.port.secure = org.osgi.service.http.port.secure

This is probably not necessary. Maybe it's better to just hardcode what 
properties are exported with the service so it's a well known name. Example:

org.osgi.service.http.port = 8080
org.osgi.service.http.port.secure = 4040


 Support for port as service properties
 --

 Key: FELIX-1704
 URL: https://issues.apache.org/jira/browse/FELIX-1704
 Project: Felix
  Issue Type: Improvement
  Components: HTTP Service
Affects Versions: http-2.0.2
Reporter: Sten Roger Sandvik
Assignee: Sten Roger Sandvik
 Fix For: http-2.0.4


 Support assigned port in Jetty as service property. Both secure and non 
 secure. Use the same logic as in old Jetty http service 1.0.1.
 * org.apache.felix.http.svcprop.port
 * org.apache.felix.http.svcprop.port.secure

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

[jira] Commented: (FELIX-1704) Support for port as service properties

[Sten Roger Sandvik (JIRA)]

[ 
https://issues.apache.org/jira/browse/FELIX-1704?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12762373#action_12762373
 ] 

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

Yes, it should reflect the confguration properties. I do not know why it's 
configured. Let's just reflect the configuration properties for now if no one 
has any good reasons for doing otherwise. So, the port properties should then 
be: org.osgi.service.http.port, org.osgi.service.http.port.secure.


 Support for port as service properties
 --

 Key: FELIX-1704
 URL: https://issues.apache.org/jira/browse/FELIX-1704
 Project: Felix
  Issue Type: Improvement
  Components: HTTP Service
Affects Versions: http-2.0.2
Reporter: Sten Roger Sandvik
Assignee: Sten Roger Sandvik
 Fix For: http-2.0.4


 Support assigned port in Jetty as service property. Both secure and non 
 secure. Use the same logic as in old Jetty http service 1.0.1.
 * org.apache.felix.http.svcprop.port
 * org.apache.felix.http.svcprop.port.secure

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

[jira] Issue Comment Edited: (FELIX-1704) Support for port as service properties

[Sten Roger Sandvik (JIRA)]

[ 
https://issues.apache.org/jira/browse/FELIX-1704?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12762373#action_12762373
 ] 

Sten Roger Sandvik edited comment on FELIX-1704 at 10/5/09 2:08 PM:


Yes, it should reflect the confguration properties. I do not know why it's 
configured. Let's just reflect the configuration properties for now if no one 
has any good reasons for doing otherwise. So, should we use:

org.osgi.service.http.port
org.osgi.service.http.port.secure

Or?

org.apache.felix.http.port
org.apache.felix.http.port.secure




  was (Author: srs):
Yes, it should reflect the confguration properties. I do not know why it's 
configured. Let's just reflect the configuration properties for now if no one 
has any good reasons for doing otherwise. So, the port properties should then 
be: org.osgi.service.http.port, org.osgi.service.http.port.secure.

  
 Support for port as service properties
 --

 Key: FELIX-1704
 URL: https://issues.apache.org/jira/browse/FELIX-1704
 Project: Felix
  Issue Type: Improvement
  Components: HTTP Service
Affects Versions: http-2.0.2
Reporter: Sten Roger Sandvik
Assignee: Sten Roger Sandvik
 Fix For: http-2.0.4


 Support assigned port in Jetty as service property. Both secure and non 
 secure. Use the same logic as in old Jetty http service 1.0.1.
 * org.apache.felix.http.svcprop.port
 * org.apache.felix.http.svcprop.port.secure

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

Re: svn commit: r820480 - /felix/trunk/http/pom.xml

[Sten Roger Sandvik]

Thanks. I was actually going to ask about that. Nice to be able to use
official OSGi modules rather than the felix ones.

BR,
Sten Roger Sandvik

On Thu, Oct 1, 2009 at 10:57 AM, Richard S. Hall he...@ungoverned.orgwrote:

 Sten,

 I modified the pom files to use the official OSGi JAR files from the maven
 repo...we don't want to use our OSGi JAR files at all any more.

 I also had to add core API dependencies to many of the pom files since the
 official compendium JAR does not have a dependency on core. Regardless, all
 explicit dependencies should be listed in the pom file of a given...Maven is
 not very modular in this regard, since it allows projects to inherit
 visibility to all transitive dependencies.

 So, I think the dependencies are ok now, but please check my changes.

 - richard

 On 10/1/09 0:26, s...@apache.org wrote:

 Author: srs
 Date: Wed Sep 30 22:26:18 2009
 New Revision: 820480

 URL: http://svn.apache.org/viewvc?rev=820480view=rev
 Log:
 FELIX-1668: Uses OSGi 1.0.0 libs instead of 1.2.0.

 Modified:
 felix/trunk/http/pom.xml

 Modified: felix/trunk/http/pom.xml
 URL:
 http://svn.apache.org/viewvc/felix/trunk/http/pom.xml?rev=820480r1=820479r2=820480view=diff

 ==
 --- felix/trunk/http/pom.xml (original)
 +++ felix/trunk/http/pom.xml Wed Sep 30 22:26:18 2009
 @@ -36,7 +36,7 @@
  prerequisites
  maven2.0.7/maven
  /prerequisites
 -ï
 +�
  properties

  project.build.sourceEncodingUTF-8/project.build.sourceEncoding
  /properties
 @@ -116,17 +116,17 @@
  dependency
  groupIdorg.apache.felix/groupId
  artifactIdorg.osgi.core/artifactId
 -version1.2.0/version
 +version1.0.0/version
  /dependency
  dependency
  groupIdorg.apache.felix/groupId
  artifactIdorg.osgi.foundation/artifactId
 -version1.2.0/version
 +version1.0.0/version
  /dependency
  dependency
  groupIdorg.apache.felix/groupId
  artifactIdorg.osgi.compendium/artifactId
 -version1.2.0/version
 +version1.0.0/version
  exclusions
  exclusion
  groupIdorg.apache.felix/groupId

Re: [VOTE] Release Felix Http Service version 2.0.0

[Sten Roger Sandvik]

I noticed that I was not running the absolute last version. Will upgrade to
2.2.1...

On Thu, Oct 1, 2009 at 11:32 AM, Richard S. Hall he...@ungoverned.orgwrote:

 On 10/1/09 11:16, Sten Roger Sandvik wrote:

 Used version 2.2.0 on Mac (OSX 10.6).



 Well, you can always try to update to 2.2.1...

  On Thu, Oct 1, 2009 at 11:12 AM, Karl Paulskarlpa...@gmail.com  wrote:



 what version of maven did you use?

 regards,

 Karl

 On Thu, Oct 1, 2009 at 11:05 AM, Richard S. Hallhe...@ungoverned.org
 wrote:


 On 9/30/09 23:31, Sten Roger Sandvik wrote:


 Thanks for the feedback. I will check out the MD5 and SHA1 digests.
 Also
 will fix the issues that you are listing here. Was not sure how to do


 the


 NOTICE file so it was just a copy from something else :-) Do it need to


 be


 a
 2.0.1 release? Could I just rollback the release by rolling back the


 pom's


 and delete the tag?



 For me, personally, I don't care. However, officially, the issue is
 since


 it


 was a failed release, we shouldn't release it all, because some people


 might


 have grabbed the last JARs and are treating them as the official release
 knowingly or not. So, the only way to prevent that is to not have that
 release version at all, which means we do 2.0.1 instead.

 As for why the digests failed in the first place, I don't really know. I
 thought Maven just did this automatically. I am a release newbie myself,


 so


 maybe someone else has some advice.

 -  richard



 BR,
 Sten Roger Sandvik

 On Wed, Sep 30, 2009 at 11:16 PM, Richard S.
 Hallhe...@ungoverned.orgwrote:




 -1

 There are quite a few issues, but it is really not all that
 bad...actually,
 there is only one issue that is causing me to give a -1, which is the
 fact
 that the MD5 and SHA1 digests don't appear to match for me. Not sure


 why


 that would be the case.

 There are also a raft of other more minor issues that would not have
 caused
 a -1 necessarily, but now we can fix those too. They are:

   * The dependencies on OSGi should be on the official JARs at the
 appropriate version level needed (i.e., lowest acceptable
 version).
   * It appears that all NOTICE use the same name (Apache Felix HTTP
 Service), but it should be different for each subproject module.
 For example, the bridge module should be Apache Felix HTTP
 Service Bridge.
   * NOTICE file for api says it includes OSGi code, but it doesn't.
 Should also include Apache under uses.
   * NOTICE file for base says it includes OSGi code, but it doesn't.
 Should also include Apache under uses.
   * NOTICE file for bridge should include Apache under uses.
   * NOTICE file for bundle should include Apache under uses.
   * NOTICE file for jetty should include Apache under uses.
   * NOTICE file for proxy says it includes OSGi, but it only uses.
 Also should include Apache in uses.
   * NOTICE for samples bridge WAR file is not in META-INF directory,
 neither are LICENSE files. Should verify dependencies listed in
 NOTICE file.
   * NOTICE for samples filter says it includes OSGi, but it only uses.
 Also should include Apache in uses.
   * NOTICE for samples whiteboard says it includes OSGi, but it only
 uses. Also should include Apache in uses.
   * NOTICE for whiteboard says it includes OSGi, but it only uses.
 Also should include Apache in uses.

 Note that if we have dependencies on Apache software, we still list


 them


 in
 the uses section of the NOTICE file...this is overly cautious, but


 not


 a
 big deal if we already have to keep track of third-party dependencies.

 Doing a release is difficult, so trying it as a newbie is to be
 commended.
 :-) At this point, we will need to scrap this release and do a 2.0.1
 release
 with fixes for all of the above. Still, the main issue was the
 digests.

 Sorry, but good work none the less. Let me know if you have any
 questions.

 -   richard


 On 9/28/09 22:59, Sten Roger Sandvik wrote:




 Hi.

 I have prepared a release candidate for the improved http service
 that


 I


 contributed earlier (FELIX-1456). It is versioned 2.0.0 since it's a
 major
 refactoring and includes much more functionality than the original
 http.jetty module. Docs will be available on wiki very soon.

 This is my first release ever so hopefully I have done all the things
 right
 :-)

 We solved 7 issues in this release:
 https://issues.apache.org/jira/browse/FELIX/fixforversion/12314224

 There are 8 outstanding issues:
 https://issues.apache.org/jira/browse/FELIX/component/12310340

 Staging repository:
 https://repository.apache.org/content/repositories/felix-staging-007/

 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 007 /tmp/felix-staging

 Please vote to approve this release:

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

Re: [VOTE] Release Felix Http Service version 2.0.0

[Sten Roger Sandvik]

So, what you guys are saying is...

* Keep trunk as a major release, ex 2.1.0-SNAPSHOT.
* Release minor releases 2.0.1 and still keep trunk as 2.1.0-SNAPSHOT.
* When 2.1.0 is released, update trunk to 2.2.0-SNAPSHOT.

Right?

/srs

On Thu, Oct 1, 2009 at 4:43 PM, Richard S. Hall he...@ungoverned.orgwrote:

 On 10/1/09 16:36, Felix Meschberger wrote:

 Hi,

 Sten Roger Sandvik schrieb:


 You are right. We should probably skip version 2.0.0 and go ahead to do a
 version 2.0.1. I do not tag 2.0.0 since it's a failed release.


 Or brather 2.0.2 because this is bundle release. The reason has been
 outline before but basically it is because Maven thinks 2.0.1 is more
 recent than 2.0.1-SNAPSHOT while OSGi thinks 2.0.1-SNAPSHOT is more
 recent.

 For this reason we reserve odd numbers for SNAPSHOTs and even numbers
 for releases. [This rule only applies for bundles and not for maven
 bundles were we just increment as usual]



 While this is true, it really depends when it comes to micro releases.

 For the framework we are typically working toward the next minor release,
 e.g., 2.1.0-SNAPSHOT in trunk. However, when we go to cut the release, if it
 is only a maintenance release, then we release it as 2.0.1 and there never
 was a 2.0.1-SNAPSHOT. Then trunk stays at 2.1.0-SNAPSHOT. In other words,
 our trunk is never a micro release, it is always a minor (or major) release.

 On the other hand, if a subproject operates as a micro release in trunk,
 then yes they should likely follow the even/odd numbering strategy to avoid
 version number inversion like you suggest.

 - richard


  Regards
 Felix



 / srs

 On Thu, Oct 1, 2009 at 11:05 AM, Richard S. Hallhe...@ungoverned.org
 wrote:



 On 9/30/09 23:31, Sten Roger Sandvik wrote:



 Thanks for the feedback. I will check out the MD5 and SHA1 digests.
 Also
 will fix the issues that you are listing here. Was not sure how to do
 the
 NOTICE file so it was just a copy from something else :-) Do it need to
 be
 a
 2.0.1 release? Could I just rollback the release by rolling back the
 pom's
 and delete the tag?




 For me, personally, I don't care. However, officially, the issue is
 since
 it was a failed release, we shouldn't release it all, because some
 people
 might have grabbed the last JARs and are treating them as the official
 release knowingly or not. So, the only way to prevent that is to not
 have
 that release version at all, which means we do 2.0.1 instead.

 As for why the digests failed in the first place, I don't really know. I
 thought Maven just did this automatically. I am a release newbie myself,
 so
 maybe someone else has some advice.

 -  richard


  BR,


 Sten Roger Sandvik

 On Wed, Sep 30, 2009 at 11:16 PM, Richard S. Hallhe...@ungoverned.org


 wrote:





 -1

 There are quite a few issues, but it is really not all that
 bad...actually,
 there is only one issue that is causing me to give a -1, which is the
 fact
 that the MD5 and SHA1 digests don't appear to match for me. Not sure
 why
 that would be the case.

 There are also a raft of other more minor issues that would not have
 caused
 a -1 necessarily, but now we can fix those too. They are:

   * The dependencies on OSGi should be on the official JARs at the
 appropriate version level needed (i.e., lowest acceptable
 version).
   * It appears that all NOTICE use the same name (Apache Felix HTTP
 Service), but it should be different for each subproject module.
 For example, the bridge module should be Apache Felix HTTP
 Service Bridge.
   * NOTICE file for api says it includes OSGi code, but it doesn't.
 Should also include Apache under uses.
   * NOTICE file for base says it includes OSGi code, but it doesn't.
 Should also include Apache under uses.
   * NOTICE file for bridge should include Apache under uses.
   * NOTICE file for bundle should include Apache under uses.
   * NOTICE file for jetty should include Apache under uses.
   * NOTICE file for proxy says it includes OSGi, but it only uses.
 Also should include Apache in uses.
   * NOTICE for samples bridge WAR file is not in META-INF directory,
 neither are LICENSE files. Should verify dependencies listed in
 NOTICE file.
   * NOTICE for samples filter says it includes OSGi, but it only uses.
 Also should include Apache in uses.
   * NOTICE for samples whiteboard says it includes OSGi, but it only
 uses. Also should include Apache in uses.
   * NOTICE for whiteboard says it includes OSGi, but it only uses.
 Also should include Apache in uses.

 Note that if we have dependencies on Apache software, we still list
 them
 in
 the uses section of the NOTICE file...this is overly cautious, but
 not
 a
 big deal if we already have to keep track of third-party dependencies.

 Doing a release is difficult, so trying it as a newbie is to be
 commended.
 :-) At this point, we will need to scrap this release and do a 2.0.1
 release
 with fixes for all of the above. Still, the main issue

Re: [VOTE] Release Felix Http Service version 2.0.0

[Sten Roger Sandvik]

Oh. Right. Now I see. You and Felix has actually the same method, except one
uses minor odd/even strategy vs major odd/even strategy?

On Thu, Oct 1, 2009 at 5:15 PM, Richard S. Hall he...@ungoverned.orgwrote:

 On 10/1/09 17:01, Sten Roger Sandvik wrote:

 So, what you guys are saying is...

 * Keep trunk as a major release, ex 2.1.0-SNAPSHOT.
 * Release minor releases 2.0.1 and still keep trunk as 2.1.0-SNAPSHOT.



 Yes, this part would be ok, but...

  * When 2.1.0 is released, update trunk to 2.2.0-SNAPSHOT.



 No, in this case there will never be a 2.1.0 release, since 2.1.0-SNAPSHOT
 would be greater. Here, you'd follow the odd/even strategy, so
 2.1.0-SNAPSHOT would be the development version and when you cut a release
 for 2.1.0-SNAPSHOT, it would be released as 2.2.0 and the trunk would become
 2.3.0-SNAPSHOT. Make sense?

 - richard


  Right?

 /srs

 On Thu, Oct 1, 2009 at 4:43 PM, Richard S. Hallhe...@ungoverned.org
 wrote:



 On 10/1/09 16:36, Felix Meschberger wrote:



 Hi,

 Sten Roger Sandvik schrieb:




 You are right. We should probably skip version 2.0.0 and go ahead to do
 a
 version 2.0.1. I do not tag 2.0.0 since it's a failed release.




 Or brather 2.0.2 because this is bundle release. The reason has been
 outline before but basically it is because Maven thinks 2.0.1 is more
 recent than 2.0.1-SNAPSHOT while OSGi thinks 2.0.1-SNAPSHOT is more
 recent.

 For this reason we reserve odd numbers for SNAPSHOTs and even numbers
 for releases. [This rule only applies for bundles and not for maven
 bundles were we just increment as usual]




 While this is true, it really depends when it comes to micro releases.

 For the framework we are typically working toward the next minor release,
 e.g., 2.1.0-SNAPSHOT in trunk. However, when we go to cut the release, if
 it
 is only a maintenance release, then we release it as 2.0.1 and there
 never
 was a 2.0.1-SNAPSHOT. Then trunk stays at 2.1.0-SNAPSHOT. In other words,
 our trunk is never a micro release, it is always a minor (or major)
 release.

 On the other hand, if a subproject operates as a micro release in trunk,
 then yes they should likely follow the even/odd numbering strategy to
 avoid
 version number inversion like you suggest.

 -  richard


  Regards


 Felix





 / srs

 On Thu, Oct 1, 2009 at 11:05 AM, Richard S. Hallhe...@ungoverned.org


 wrote:






 On 9/30/09 23:31, Sten Roger Sandvik wrote:





 Thanks for the feedback. I will check out the MD5 and SHA1 digests.
 Also
 will fix the issues that you are listing here. Was not sure how to do
 the
 NOTICE file so it was just a copy from something else :-) Do it need
 to
 be
 a
 2.0.1 release? Could I just rollback the release by rolling back the
 pom's
 and delete the tag?






 For me, personally, I don't care. However, officially, the issue is
 since
 it was a failed release, we shouldn't release it all, because some
 people
 might have grabbed the last JARs and are treating them as the official
 release knowingly or not. So, the only way to prevent that is to not
 have
 that release version at all, which means we do 2.0.1 instead.

 As for why the digests failed in the first place, I don't really know.
 I
 thought Maven just did this automatically. I am a release newbie
 myself,
 so
 maybe someone else has some advice.

 -   richard


  BR,




 Sten Roger Sandvik

 On Wed, Sep 30, 2009 at 11:16 PM, Richard S. Hall
 he...@ungoverned.org




 wrote:








 -1

 There are quite a few issues, but it is really not all that
 bad...actually,
 there is only one issue that is causing me to give a -1, which is
 the
 fact
 that the MD5 and SHA1 digests don't appear to match for me. Not sure
 why
 that would be the case.

 There are also a raft of other more minor issues that would not have
 caused
 a -1 necessarily, but now we can fix those too. They are:

   * The dependencies on OSGi should be on the official JARs at the
 appropriate version level needed (i.e., lowest acceptable
 version).
   * It appears that all NOTICE use the same name (Apache Felix HTTP
 Service), but it should be different for each subproject module.
 For example, the bridge module should be Apache Felix HTTP
 Service Bridge.
   * NOTICE file for api says it includes OSGi code, but it doesn't.
 Should also include Apache under uses.
   * NOTICE file for base says it includes OSGi code, but it doesn't.
 Should also include Apache under uses.
   * NOTICE file for bridge should include Apache under uses.
   * NOTICE file for bundle should include Apache under uses.
   * NOTICE file for jetty should include Apache under uses.
   * NOTICE file for proxy says it includes OSGi, but it only uses.
 Also should include Apache in uses.
   * NOTICE for samples bridge WAR file is not in META-INF directory,
 neither are LICENSE files. Should verify dependencies listed in
 NOTICE file.
   * NOTICE for samples filter says it includes OSGi, but it only
 uses.
 Also should

Re: [VOTE] Release Felix Http Service version 2.0.0

[Sten Roger Sandvik]

Sorry. Yes.

On Thu, Oct 1, 2009 at 5:22 PM, Richard S. Hall he...@ungoverned.orgwrote:

 On 10/1/09 17:17, Sten Roger Sandvik wrote:

 Oh. Right. Now I see. You and Felix has actually the same method, except
 one
 uses minor odd/even strategy vs major odd/even strategy?



 Micro and minor, but yes.

 - richard


  On Thu, Oct 1, 2009 at 5:15 PM, Richard S. Hallhe...@ungoverned.org
 wrote:



 On 10/1/09 17:01, Sten Roger Sandvik wrote:



 So, what you guys are saying is...

 * Keep trunk as a major release, ex 2.1.0-SNAPSHOT.
 * Release minor releases 2.0.1 and still keep trunk as 2.1.0-SNAPSHOT.




 Yes, this part would be ok, but...

  * When 2.1.0 is released, update trunk to 2.2.0-SNAPSHOT.





 No, in this case there will never be a 2.1.0 release, since
 2.1.0-SNAPSHOT
 would be greater. Here, you'd follow the odd/even strategy, so
 2.1.0-SNAPSHOT would be the development version and when you cut a
 release
 for 2.1.0-SNAPSHOT, it would be released as 2.2.0 and the trunk would
 become
 2.3.0-SNAPSHOT. Make sense?

 -  richard


  Right?


 /srs

 On Thu, Oct 1, 2009 at 4:43 PM, Richard S. Hallhe...@ungoverned.org


 wrote:






 On 10/1/09 16:36, Felix Meschberger wrote:





 Hi,

 Sten Roger Sandvik schrieb:






 You are right. We should probably skip version 2.0.0 and go ahead to
 do
 a
 version 2.0.1. I do not tag 2.0.0 since it's a failed release.






 Or brather 2.0.2 because this is bundle release. The reason has been
 outline before but basically it is because Maven thinks 2.0.1 is more
 recent than 2.0.1-SNAPSHOT while OSGi thinks 2.0.1-SNAPSHOT is more
 recent.

 For this reason we reserve odd numbers for SNAPSHOTs and even numbers
 for releases. [This rule only applies for bundles and not for maven
 bundles were we just increment as usual]






 While this is true, it really depends when it comes to micro releases.

 For the framework we are typically working toward the next minor
 release,
 e.g., 2.1.0-SNAPSHOT in trunk. However, when we go to cut the release,
 if
 it
 is only a maintenance release, then we release it as 2.0.1 and there
 never
 was a 2.0.1-SNAPSHOT. Then trunk stays at 2.1.0-SNAPSHOT. In other
 words,
 our trunk is never a micro release, it is always a minor (or major)
 release.

 On the other hand, if a subproject operates as a micro release in
 trunk,
 then yes they should likely follow the even/odd numbering strategy to
 avoid
 version number inversion like you suggest.

 -   richard


  Regards




 Felix







 / srs

 On Thu, Oct 1, 2009 at 11:05 AM, Richard S. Hall
 he...@ungoverned.org




 wrote:









 On 9/30/09 23:31, Sten Roger Sandvik wrote:







 Thanks for the feedback. I will check out the MD5 and SHA1 digests.
 Also
 will fix the issues that you are listing here. Was not sure how to
 do
 the
 NOTICE file so it was just a copy from something else :-) Do it
 need
 to
 be
 a
 2.0.1 release? Could I just rollback the release by rolling back
 the
 pom's
 and delete the tag?








 For me, personally, I don't care. However, officially, the issue is
 since
 it was a failed release, we shouldn't release it all, because some
 people
 might have grabbed the last JARs and are treating them as the
 official
 release knowingly or not. So, the only way to prevent that is to not
 have
 that release version at all, which means we do 2.0.1 instead.

 As for why the digests failed in the first place, I don't really
 know.
 I
 thought Maven just did this automatically. I am a release newbie
 myself,
 so
 maybe someone else has some advice.

 -richard


  BR,






 Sten Roger Sandvik

 On Wed, Sep 30, 2009 at 11:16 PM, Richard S. Hall
 he...@ungoverned.org






 wrote:











 -1

 There are quite a few issues, but it is really not all that
 bad...actually,
 there is only one issue that is causing me to give a -1, which is
 the
 fact
 that the MD5 and SHA1 digests don't appear to match for me. Not
 sure
 why
 that would be the case.

 There are also a raft of other more minor issues that would not
 have
 caused
 a -1 necessarily, but now we can fix those too. They are:

   * The dependencies on OSGi should be on the official JARs at the
 appropriate version level needed (i.e., lowest acceptable
 version).
   * It appears that all NOTICE use the same name (Apache Felix
 HTTP
 Service), but it should be different for each subproject
 module.
 For example, the bridge module should be Apache Felix HTTP
 Service Bridge.
   * NOTICE file for api says it includes OSGi code, but it
 doesn't.
 Should also include Apache under uses.
   * NOTICE file for base says it includes OSGi code, but it
 doesn't.
 Should also include Apache under uses.
   * NOTICE file for bridge should include Apache under uses.
   * NOTICE file for bundle should include Apache under uses.
   * NOTICE file for jetty should include Apache under uses.
   * NOTICE file for proxy says it includes OSGi, but it only uses.
 Also should include Apache in uses

[VOTE] Release Felix Http Service version 2.0.2

[Sten Roger Sandvik]

Hi.

The first release I prepared failed since it was some issues regarding
NOTICE files. Have now fixed the issues and tries the release again.
Hopefully it will go trough this time :-)

We solved 9 issues in this release:
https://issues.apache.org/jira/browse/FELIX/fixforversion/12314224

There are 8 outstanding issues:
https://issues.apache.org/jira/browse/FELIX/component/12310340

Staging repository:
https://repository.apache.org/content/repositories/felix-staging-001/

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 001 /tmp/felix-staging

Please vote to approve this release:

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

This vote will be open for 72 hours.

Regards,
Sten Roger Sandvik

Re: [VOTE] Release Felix Http Service version 2.0.0

[Sten Roger Sandvik]

Not that many votes yet :-) Do people need more time to test the release?

BR,
Sten Roger Sandvik

On Tue, Sep 29, 2009 at 9:49 AM, Rob Walker r...@ascert.com wrote:

 Our release process has been delayed, so haven't had a chance to try the
 new Http in our environment.

 Happy to add my +1 though if others have and it's working well for them

 - R

Re: [VOTE] Release Felix Http Service version 2.0.0

[Sten Roger Sandvik]

Hehe. Not worried. Just... well... a little worried :-)

On Wed, Sep 30, 2009 at 5:39 PM, Richard S. Hall he...@ungoverned.orgwrote:

 Don't worry, I am sure people are just busy...I am.

 The vote needs to run for a minimum of 72 hours...that is not the
 deadline...

 - richard


 On 9/30/09 17:16, Sten Roger Sandvik wrote:

 Not that many votes yet :-) Do people need more time to test the release?

 BR,
 Sten Roger Sandvik

 On Tue, Sep 29, 2009 at 9:49 AM, Rob Walkerr...@ascert.com  wrote:



 Our release process has been delayed, so haven't had a chance to try the
 new Http in our environment.

 Happy to add my +1 though if others have and it's working well for them

 - R

Re: [VOTE] Release Felix Http Service version 2.0.0

[Sten Roger Sandvik]

Thanks for the feedback. I will check out the MD5 and SHA1 digests. Also
will fix the issues that you are listing here. Was not sure how to do the
NOTICE file so it was just a copy from something else :-) Do it need to be a
2.0.1 release? Could I just rollback the release by rolling back the pom's
and delete the tag?

BR,
Sten Roger Sandvik

On Wed, Sep 30, 2009 at 11:16 PM, Richard S. Hall he...@ungoverned.orgwrote:

 -1

 There are quite a few issues, but it is really not all that bad...actually,
 there is only one issue that is causing me to give a -1, which is the fact
 that the MD5 and SHA1 digests don't appear to match for me. Not sure why
 that would be the case.

 There are also a raft of other more minor issues that would not have caused
 a -1 necessarily, but now we can fix those too. They are:

   * The dependencies on OSGi should be on the official JARs at the
 appropriate version level needed (i.e., lowest acceptable version).
   * It appears that all NOTICE use the same name (Apache Felix HTTP
 Service), but it should be different for each subproject module.
 For example, the bridge module should be Apache Felix HTTP
 Service Bridge.
   * NOTICE file for api says it includes OSGi code, but it doesn't.
 Should also include Apache under uses.
   * NOTICE file for base says it includes OSGi code, but it doesn't.
 Should also include Apache under uses.
   * NOTICE file for bridge should include Apache under uses.
   * NOTICE file for bundle should include Apache under uses.
   * NOTICE file for jetty should include Apache under uses.
   * NOTICE file for proxy says it includes OSGi, but it only uses.
 Also should include Apache in uses.
   * NOTICE for samples bridge WAR file is not in META-INF directory,
 neither are LICENSE files. Should verify dependencies listed in
 NOTICE file.
   * NOTICE for samples filter says it includes OSGi, but it only uses.
 Also should include Apache in uses.
   * NOTICE for samples whiteboard says it includes OSGi, but it only
 uses. Also should include Apache in uses.
   * NOTICE for whiteboard says it includes OSGi, but it only uses.
 Also should include Apache in uses.

 Note that if we have dependencies on Apache software, we still list them in
 the uses section of the NOTICE file...this is overly cautious, but not a
 big deal if we already have to keep track of third-party dependencies.

 Doing a release is difficult, so trying it as a newbie is to be commended.
 :-) At this point, we will need to scrap this release and do a 2.0.1 release
 with fixes for all of the above. Still, the main issue was the digests.

 Sorry, but good work none the less. Let me know if you have any questions.

 - richard


 On 9/28/09 22:59, Sten Roger Sandvik wrote:

 Hi.

 I have prepared a release candidate for the improved http service that I
 contributed earlier (FELIX-1456). It is versioned 2.0.0 since it's a major
 refactoring and includes much more functionality than the original
 http.jetty module. Docs will be available on wiki very soon.

 This is my first release ever so hopefully I have done all the things
 right
 :-)

 We solved 7 issues in this release:
 https://issues.apache.org/jira/browse/FELIX/fixforversion/12314224

 There are 8 outstanding issues:
 https://issues.apache.org/jira/browse/FELIX/component/12310340

 Staging repository:
 https://repository.apache.org/content/repositories/felix-staging-007/

 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 007 /tmp/felix-staging

 Please vote to approve this release:

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

 This vote will be open for 72 hours.


 Best Regards,
 Sten Roger Sandvik

[jira] Created: (FELIX-1667) Fix NOTICE and LICENSE files

[Sten Roger Sandvik (JIRA)]

Fix NOTICE and LICENSE files


 Key: FELIX-1667
 URL: https://issues.apache.org/jira/browse/FELIX-1667
 Project: Felix
  Issue Type: Test
  Components: HTTP Service
Reporter: Sten Roger Sandvik
Assignee: Sten Roger Sandvik


Richard mentioned that there are several issues regarding LICENSE and NOTICE 
files. Fix this.

  * The dependencies on OSGi should be on the official JARs at the
appropriate version level needed (i.e., lowest acceptable version).
  * It appears that all NOTICE use the same name (Apache Felix HTTP
Service), but it should be different for each subproject module.
For example, the bridge module should be Apache Felix HTTP
Service Bridge.
  * NOTICE file for api says it includes OSGi code, but it doesn't.
Should also include Apache under uses.
  * NOTICE file for base says it includes OSGi code, but it doesn't.
Should also include Apache under uses.
  * NOTICE file for bridge should include Apache under uses.
  * NOTICE file for bundle should include Apache under uses.
  * NOTICE file for jetty should include Apache under uses.
  * NOTICE file for proxy says it includes OSGi, but it only uses.
Also should include Apache in uses.
  * NOTICE for samples bridge WAR file is not in META-INF directory,
neither are LICENSE files. Should verify dependencies listed in
NOTICE file.
  * NOTICE for samples filter says it includes OSGi, but it only uses.
Also should include Apache in uses.
  * NOTICE for samples whiteboard says it includes OSGi, but it only
uses. Also should include Apache in uses.
  * NOTICE for whiteboard says it includes OSGi, but it only uses.
Also should include Apache in uses.


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

[jira] Created: (FELIX-1668) Fix OSGi dependencies

[Sten Roger Sandvik (JIRA)]

Fix OSGi dependencies
-

 Key: FELIX-1668
 URL: https://issues.apache.org/jira/browse/FELIX-1668
 Project: Felix
  Issue Type: Task
  Components: HTTP Service
Reporter: Sten Roger Sandvik
Assignee: Sten Roger Sandvik


The dependencies on OSGi should be on the official JARs at the appropriate 
version level needed (i.e., lowest acceptable version).

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

[jira] Resolved: (FELIX-1668) Fix OSGi dependencies

[Sten Roger Sandvik (JIRA)]

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

Sten Roger Sandvik resolved FELIX-1668.
---

   Resolution: Fixed
Fix Version/s: http-2.0.0

Uses 1.0.0 osgi dependencies instead of 1.2.0.

 Fix OSGi dependencies
 -

 Key: FELIX-1668
 URL: https://issues.apache.org/jira/browse/FELIX-1668
 Project: Felix
  Issue Type: Task
  Components: HTTP Service
Reporter: Sten Roger Sandvik
Assignee: Sten Roger Sandvik
 Fix For: http-2.0.0


 The dependencies on OSGi should be on the official JARs at the appropriate 
 version level needed (i.e., lowest acceptable version).

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

Re: [VOTE] Release Felix Http Service version 2.0.0

[Sten Roger Sandvik]

Now all the issues that Richard noted is fixed. Verified it a couple of
times so I think it's right this time. Only issue that remains is MD5/SHA1
missmatch. When I have figured that out I will propose a new release
candidate 2.0.0.

Regards,
Sten Roger Sandvik

On Wed, Sep 30, 2009 at 11:55 PM, Sten Roger Sandvik s...@x3m.com wrote:

 Hi all.

 Sorry about problems with the release. I have now rolled back to before the
 release candidate preparation. Will fix the issues raies by Richard and try
 again. All artifacts is not available in the staging repository anymore, but
 can be accessed using apache.snapshot repository.

 BR,
 Sten Roger Sandvik


 On Wed, Sep 30, 2009 at 11:31 PM, Sten Roger Sandvik s...@x3m.com wrote:

 Thanks for the feedback. I will check out the MD5 and SHA1 digests. Also
 will fix the issues that you are listing here. Was not sure how to do the
 NOTICE file so it was just a copy from something else :-) Do it need to be a
 2.0.1 release? Could I just rollback the release by rolling back the pom's
 and delete the tag?

 BR,
 Sten Roger Sandvik


 On Wed, Sep 30, 2009 at 11:16 PM, Richard S. Hall 
 he...@ungoverned.orgwrote:

 -1

 There are quite a few issues, but it is really not all that
 bad...actually, there is only one issue that is causing me to give a -1,
 which is the fact that the MD5 and SHA1 digests don't appear to match for
 me. Not sure why that would be the case.

 There are also a raft of other more minor issues that would not have
 caused a -1 necessarily, but now we can fix those too. They are:

   * The dependencies on OSGi should be on the official JARs at the
 appropriate version level needed (i.e., lowest acceptable version).
   * It appears that all NOTICE use the same name (Apache Felix HTTP
 Service), but it should be different for each subproject module.
 For example, the bridge module should be Apache Felix HTTP
 Service Bridge.
   * NOTICE file for api says it includes OSGi code, but it doesn't.
 Should also include Apache under uses.
   * NOTICE file for base says it includes OSGi code, but it doesn't.
 Should also include Apache under uses.
   * NOTICE file for bridge should include Apache under uses.
   * NOTICE file for bundle should include Apache under uses.
   * NOTICE file for jetty should include Apache under uses.
   * NOTICE file for proxy says it includes OSGi, but it only uses.
 Also should include Apache in uses.
   * NOTICE for samples bridge WAR file is not in META-INF directory,
 neither are LICENSE files. Should verify dependencies listed in
 NOTICE file.
   * NOTICE for samples filter says it includes OSGi, but it only uses.
 Also should include Apache in uses.
   * NOTICE for samples whiteboard says it includes OSGi, but it only
 uses. Also should include Apache in uses.
   * NOTICE for whiteboard says it includes OSGi, but it only uses.
 Also should include Apache in uses.

 Note that if we have dependencies on Apache software, we still list them
 in the uses section of the NOTICE file...this is overly cautious, but not
 a big deal if we already have to keep track of third-party dependencies.

 Doing a release is difficult, so trying it as a newbie is to be
 commended. :-) At this point, we will need to scrap this release and do a
 2.0.1 release with fixes for all of the above. Still, the main issue was the
 digests.

 Sorry, but good work none the less. Let me know if you have any
 questions.

 - richard


 On 9/28/09 22:59, Sten Roger Sandvik wrote:

 Hi.

 I have prepared a release candidate for the improved http service that I
 contributed earlier (FELIX-1456). It is versioned 2.0.0 since it's a
 major
 refactoring and includes much more functionality than the original
 http.jetty module. Docs will be available on wiki very soon.

 This is my first release ever so hopefully I have done all the things
 right
 :-)

 We solved 7 issues in this release:
 https://issues.apache.org/jira/browse/FELIX/fixforversion/12314224

 There are 8 outstanding issues:
 https://issues.apache.org/jira/browse/FELIX/component/12310340

 Staging repository:
 https://repository.apache.org/content/repositories/felix-staging-007/

 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 007 /tmp/felix-staging

 Please vote to approve this release:

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

 This vote will be open for 72 hours.


 Best Regards,
 Sten Roger Sandvik

[VOTE] Release Felix Http Service version 2.0.0

[Sten Roger Sandvik]

Hi.

I have prepared a release candidate for the improved http service that I
contributed earlier (FELIX-1456). It is versioned 2.0.0 since it's a major
refactoring and includes much more functionality than the original
http.jetty module. Docs will be available on wiki very soon.

This is my first release ever so hopefully I have done all the things right
:-)

We solved 7 issues in this release:
https://issues.apache.org/jira/browse/FELIX/fixforversion/12314224

There are 8 outstanding issues:
https://issues.apache.org/jira/browse/FELIX/component/12310340

Staging repository:
https://repository.apache.org/content/repositories/felix-staging-007/

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 007 /tmp/felix-staging

Please vote to approve this release:

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

This vote will be open for 72 hours.


Best Regards,
Sten Roger Sandvik