[jira] [Commented] (FELIX-1492) Add option to exclude optional dependencies during OBR deploy

2016-09-20 Thread Renato Athaydes (JIRA) 

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

Renato Athaydes commented on FELIX-1492:


This feature does not seem to be documented in the OBR command docs.
How can I deploy only mandatory dependencies of a bundle using the obr command?

> Add option to exclude optional dependencies during OBR deploy
> -
>
> Key: FELIX-1492
> URL: https://issues.apache.org/jira/browse/FELIX-1492
> Project: Felix
>  Issue Type: Improvement
>  Components: Bundle Repository (OBR)
>Reporter: Allen Lau
>Assignee: Guillaume Nodet
>Priority: Minor
> Fix For: bundlerepository-1.6.0
>
>
> Currently, OBR client will pull down all optional dependencies from the OBR 
> repository if found.  Sometimes this is not desirable for the end-user.  
> Would be nice to have an optional flag to the OBR "deploy" and "start" 
> commands to exclude optional dependencies.



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

[jira] [Commented] (FELIX-5332) Serializer

2016-09-20 Thread David Leangen (JIRA) 

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

David Leangen commented on FELIX-5332:
--

Hi [~bosschaert], yeah, it does make the code much less light-weight. It would 
appear to roughly double the size, so I think you are right that it should be 
separated out into a separate API/module. It would appear that I was completely 
mistaken when I originally assumed that it would overlap with the same code. It 
could, but it would make the code much more complex, which is not desirable. To 
keep it separate means that the codebase doubles in size, which is also not 
desirable. Sigh. :-(

I can make this change, but probably can't start until about next week or so. 
Is that ok?

I'm not entirely sure what you mean by withContext(Object obj), so I may need 
your help.

> Serializer
> --
>
> Key: FELIX-5332
> URL: https://issues.apache.org/jira/browse/FELIX-5332
> Project: Felix
>  Issue Type: New Feature
>  Components: Converter
>Reporter: David Leangen
>Assignee: David Bosschaert
> Attachments: patch.diff
>
>
> Test case and a bit of code to show how a Serializer could work.
> To work as a Serializer, the type information needs to be embedded into the 
> output.



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

[jira] [Commented] (FELIX-5332) Serializer

2016-09-20 Thread David Bosschaert (JIRA) 

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

David Bosschaert commented on FELIX-5332:
-

Hi [~dleangen], this is quite a substantial amount of functionality! :)

What I think might be a good idea is to isolate it out into its own module. 
Alongside converter and serializer, maybe something called 
'org.apache.felix.schematizer'. I think for the API we should probably use API 
in the org.apache.felix namespace for the moment. Then we can maybe add a 
withContext(Object obj) to the Serializer interface (or maybe to the 
Serializing/Deserializing ones). This could be a generic mechanism to provide 
implementation-specific context to the serializer, which could be the Schema in 
this case.

Reason for such an approach is that the converter is currently super-light. It 
would be nice to keep it light IMHO. Having it as a separate module means that 
only those who need this advanced feature get the complexity.

WDYT?

> Serializer
> --
>
> Key: FELIX-5332
> URL: https://issues.apache.org/jira/browse/FELIX-5332
> Project: Felix
>  Issue Type: New Feature
>  Components: Converter
>Reporter: David Leangen
>Assignee: David Bosschaert
> Attachments: patch.diff
>
>
> Test case and a bit of code to show how a Serializer could work.
> To work as a Serializer, the type information needs to be embedded into the 
> output.



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

[jira] [Updated] (FELIX-5355) Allow to use properties having dots with configuration proxies

2016-09-20 Thread Pierre De Rop (JIRA) 

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

Pierre De Rop updated FELIX-5355:
-
Attachment: FELIX-5355.patch

> Allow to use properties having dots with configuration proxies
> --
>
> Key: FELIX-5355
> URL: https://issues.apache.org/jira/browse/FELIX-5355
> Project: Felix
>  Issue Type: Improvement
>  Components: Dependency Manager
>Affects Versions: org.apache.felix.dependencymanager-r8
>Reporter: Pierre De Rop
>Assignee: Pierre De Rop
>Priority: Minor
> Fix For: org.apache.felix.dependencymanager-r9
>
> Attachments: FELIX-5355.patch
>
>
> Recently, a new feature has been introduced in DM to allow injecting 
> type-safe configuration proxies when a ConfigurationDependency is used (see 
> FELIX-5177).
> The principle is to deduce the name of a given property from a corresponding 
> method name of the configuration proxy interface.
> However, in some cases, you have some component depending on some 
> configuration with properties having some dots ("."), and this character 
> can't be used in java methods. Of course, the properties can be renamed to 
> new names without dots, but in some cases, when you want to use configuration 
> proxies on some legacy components, you often can't modify the existing 
> configuration properties.
> So, I would like to propose the attached patch which allows the support of 
> dots in properties. the patch does the same done by DS: it maps the "\_" 
> charater to ".". And if the property contains "\_\_" character, then you can 
> use a double "__" underscore:
> For example, assuming you have the two properties in the configuration:
> {code}
> foo.param1=123
> foo_param2=456
> {code}
> then you can use the following method names:
> {code}
> public interface MyConfig {
> public String getFoo_param1(); // maps to "foo.param1"
> public String getFoo__param2(); // maps to "foo_param2"
>}
> {code}
> Is there any objections if I commit the attached patch ?
> thanks.



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

[jira] [Created] (FELIX-5355) Allow to use properties having dots with configuration proxies

2016-09-20 Thread Pierre De Rop (JIRA) 
Pierre De Rop created FELIX-5355:


 Summary: Allow to use properties having dots with configuration 
proxies
 Key: FELIX-5355
 URL: https://issues.apache.org/jira/browse/FELIX-5355
 Project: Felix
  Issue Type: Improvement
  Components: Dependency Manager
Affects Versions: org.apache.felix.dependencymanager-r8
Reporter: Pierre De Rop
Assignee: Pierre De Rop
Priority: Minor
 Fix For: org.apache.felix.dependencymanager-r9


Recently, a new feature has been introduced in DM to allow injecting type-safe 
configuration proxies when a ConfigurationDependency is used (see FELIX-5177).

The principle is to deduce the name of a given property from a corresponding 
method name of the configuration proxy interface.

However, in some cases, you have some component depending on some configuration 
with properties having some dots ("."), and this character can't be used in 
java methods. Of course, the properties can be renamed to new names without 
dots, but in some cases, when you want to use configuration proxies on some 
legacy components, you often can't modify the existing configuration properties.

So, I would like to propose the attached patch which allows the support of dots 
in properties. the patch does the same done by DS: it maps the "\_" charater to 
".". And if the property contains "\_\_" character, then you can use a double 
"__" underscore:

For example, assuming you have the two properties in the configuration:

{code}
foo.param1=123
foo_param2=456
{code}

then you can use the following method names:

{code}
public interface MyConfig {
public String getFoo_param1(); // maps to "foo.param1"
public String getFoo__param2(); // maps to "foo_param2"
   }
{code}

Is there any objections if I commit the attached patch ?

thanks.




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

[jira] [Assigned] (FELIX-5332) Serializer

2016-09-20 Thread David Bosschaert (JIRA) 

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

David Bosschaert reassigned FELIX-5332:
---

Assignee: David Bosschaert

> Serializer
> --
>
> Key: FELIX-5332
> URL: https://issues.apache.org/jira/browse/FELIX-5332
> Project: Felix
>  Issue Type: New Feature
>  Components: Converter
>Reporter: David Leangen
>Assignee: David Bosschaert
> Attachments: patch.diff
>
>
> Test case and a bit of code to show how a Serializer could work.
> To work as a Serializer, the type information needs to be embedded into the 
> output.



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

Re: Heads-up: framework and resolver release

2016-09-20 Thread Jean-Baptiste Onofré 

+1

Regards
JB

On 09/20/2016 08:16 AM, Guillaume Nodet wrote:

+1
What are the bndtools issues exactly ? There are only a few minor changes
for those releases.

2016-09-19 21:21 GMT+02:00 Karl Pauls :


I think its time to release new framework and resolver releases (there are
some requests from e.g., bndtools).

Are there any reasons not to?

Otherwise, I'll go ahead and cut a release.

regards,

Karl

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







--
Jean-Baptiste Onofré
jbono...@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com

Re: Heads-up: framework and resolver release

2016-09-20 Thread Karl Pauls 
On Tue, Sep 20, 2016 at 8:16 AM, Guillaume Nodet  wrote:

> +1
> What are the bndtools issues exactly ? There are only a few minor changes
> for those releases.
>

https://github.com/bndtools/bnd/issues/1697

As I said, I don't think it is that important if it help solve their issue
or not. We have changes in the resolver and the framework for awhile now.

If there are no complains coming in soon I'll go and cut the release soon.

regards,

Karl


>
> 2016-09-19 21:21 GMT+02:00 Karl Pauls :
>
> > I think its time to release new framework and resolver releases (there
> are
> > some requests from e.g., bndtools).
> >
> > Are there any reasons not to?
> >
> > Otherwise, I'll go ahead and cut a release.
> >
> > regards,
> >
> > Karl
> >
> > --
> > Karl Pauls
> > karlpa...@gmail.com
> >
>
>
>
> --
> 
> Guillaume Nodet
> 
> Red Hat, Open Source Integration
>
> Email: gno...@redhat.com
> Web: http://fusesource.com
> Blog: http://gnodet.blogspot.com/
>



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

Re: Heads-up: framework and resolver release

2016-09-20 Thread Karl Pauls 
On Tue, Sep 20, 2016 at 4:49 AM, Thomas Watson  wrote:

> Fine with me.  I have integrated the latest resolver into the Equinox
> oxygen builds for the past two months. I have not found any issues so far.
> I will be surprised if the latest fixes the bnd tools issues though.
>

Yeah, well - thats up to them. I just think we are sitting on the changes
for long enough now :-)


> Tom
>
> On Sep 19, 2016 4:35 PM, "David Bosschaert" 
> wrote:
>
> > Sounds good to me! It's nearly a year since the last release, which I
> guess
> > has proven to be quite stable.
> >
> > Cheers,
> >
> > David
> >
> > On 19 September 2016 at 20:21, Karl Pauls  wrote:
> >
> > > I think its time to release new framework and resolver releases (there
> > are
> > > some requests from e.g., bndtools).
> > >
> > > Are there any reasons not to?
> > >
> > > Otherwise, I'll go ahead and cut a release.
> > >
> > > regards,
> > >
> > > Karl
> > >
> > > --
> > > Karl Pauls
> > > karlpa...@gmail.com
> > >
> >
>



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

[jira] [Comment Edited] (FELIX-4896) Jetty web server 'no cipher suites in common' bug

2016-09-20 Thread Carsten Ziegeler (JIRA) 

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

Carsten Ziegeler edited comment on FELIX-4896 at 9/20/16 8:12 AM:
--

not sure, maybe steps to reproduce? what configuration you use? I see a lot of 
people having similar questions/problems on stackoverflow. Maybe it is just a 
configuration problem?


was (Author: cziegeler):
not sure, maybe steps to reproduce? what configuration you use?

> Jetty web server 'no cipher suites in common' bug
> -
>
> Key: FELIX-4896
> URL: https://issues.apache.org/jira/browse/FELIX-4896
> Project: Felix
>  Issue Type: Bug
>  Components: HTTP Service
>Affects Versions: http.jetty-3.0.2
> Environment: Fedora 21 x64
>Reporter: Ferry Huberts
> Attachments: jetty-ssl-cipher-suite-error
>
>
> I can no longer connect to the webconsole.
> I'm using
> {noformat}
> ./org.apache.felix.configadmin/org.apache.felix.configadmin-1.8.2.jar
> ./org.apache.felix.eventadmin/org.apache.felix.eventadmin-1.4.2.jar
> ./org.apache.felix.fileinstall/org.apache.felix.fileinstall-3.5.0.jar
> ./org.apache.felix.framework/org.apache.felix.framework-4.6.1.jar
> ./org.apache.felix.gogo.command/org.apache.felix.gogo.command-0.14.0.jar
> ./org.apache.felix.gogo.runtime/org.apache.felix.gogo.runtime-0.16.2.jar
> ./org.apache.felix.gogo.shell/org.apache.felix.gogo.shell-0.10.0.jar
> ./org.apache.felix.http.api/org.apache.felix.http.api-2.3.2.jar
> ./org.apache.felix.http.jetty/org.apache.felix.http.jetty-3.0.2.jar
> ./org.apache.felix.http.servlet-api/org.apache.felix.http.servlet-api-1.1.0.jar
> ./org.apache.felix.metatype/org.apache.felix.metatype-1.0.12.jar
> ./org.apache.felix.scr/org.apache.felix.scr-1.8.2.jar
> ./org.apache.felix.webconsole/org.apache.felix.webconsole-4.2.8.jar
> {noformat}
> I will attach the DEBUG log on connection establishment.
> The relevant error is:
> {noformat}
> javax.net.ssl.SSLHandshakeException: no cipher suites in common
>   at sun.security.ssl.Handshaker.checkThrown(Handshaker.java:1431)
>   at 
> sun.security.ssl.SSLEngineImpl.checkTaskThrown(SSLEngineImpl.java:535)
>   at sun.security.ssl.SSLEngineImpl.readNetRecord(SSLEngineImpl.java:813)
>   at sun.security.ssl.SSLEngineImpl.unwrap(SSLEngineImpl.java:781)
>   at javax.net.ssl.SSLEngine.unwrap(SSLEngine.java:624)
>   at 
> org.eclipse.jetty.io.ssl.SslConnection$DecryptedEndPoint.fill(SslConnection.java:516)
>   at 
> org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:239)
>   at 
> org.eclipse.jetty.io.AbstractConnection$2.run(AbstractConnection.java:540)
>   at 
> org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:635)
>   at 
> org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:555)
>   at java.lang.Thread.run(Thread.java:745)
> Caused by: javax.net.ssl.SSLHandshakeException: no cipher suites in common
>   at sun.security.ssl.Alerts.getSSLException(Alerts.java:192)
>   at sun.security.ssl.SSLEngineImpl.fatal(SSLEngineImpl.java:1666)
>   at sun.security.ssl.Handshaker.fatalSE(Handshaker.java:304)
>   at sun.security.ssl.Handshaker.fatalSE(Handshaker.java:292)
>   at 
> sun.security.ssl.ServerHandshaker.chooseCipherSuite(ServerHandshaker.java:1014)
>   at 
> sun.security.ssl.ServerHandshaker.clientHello(ServerHandshaker.java:731)
>   at 
> sun.security.ssl.ServerHandshaker.processMessage(ServerHandshaker.java:213)
>   at sun.security.ssl.Handshaker.processLoop(Handshaker.java:979)
>   at sun.security.ssl.Handshaker$1.run(Handshaker.java:919)
>   at sun.security.ssl.Handshaker$1.run(Handshaker.java:916)
>   at java.security.AccessController.doPrivileged(Native Method)
>   at sun.security.ssl.Handshaker$DelegatedTask.run(Handshaker.java:1369)
>   at 
> org.eclipse.jetty.io.ssl.SslConnection$DecryptedEndPoint.fill(SslConnection.java:612)
>   ... 5 common frames omitted
> {noformat}



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

[jira] [Commented] (FELIX-4896) Jetty web server 'no cipher suites in common' bug

2016-09-20 Thread Carsten Ziegeler (JIRA) 

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

Carsten Ziegeler commented on FELIX-4896:
-

not sure, maybe steps to reproduce? what configuration you use?

> Jetty web server 'no cipher suites in common' bug
> -
>
> Key: FELIX-4896
> URL: https://issues.apache.org/jira/browse/FELIX-4896
> Project: Felix
>  Issue Type: Bug
>  Components: HTTP Service
>Affects Versions: http.jetty-3.0.2
> Environment: Fedora 21 x64
>Reporter: Ferry Huberts
> Attachments: jetty-ssl-cipher-suite-error
>
>
> I can no longer connect to the webconsole.
> I'm using
> {noformat}
> ./org.apache.felix.configadmin/org.apache.felix.configadmin-1.8.2.jar
> ./org.apache.felix.eventadmin/org.apache.felix.eventadmin-1.4.2.jar
> ./org.apache.felix.fileinstall/org.apache.felix.fileinstall-3.5.0.jar
> ./org.apache.felix.framework/org.apache.felix.framework-4.6.1.jar
> ./org.apache.felix.gogo.command/org.apache.felix.gogo.command-0.14.0.jar
> ./org.apache.felix.gogo.runtime/org.apache.felix.gogo.runtime-0.16.2.jar
> ./org.apache.felix.gogo.shell/org.apache.felix.gogo.shell-0.10.0.jar
> ./org.apache.felix.http.api/org.apache.felix.http.api-2.3.2.jar
> ./org.apache.felix.http.jetty/org.apache.felix.http.jetty-3.0.2.jar
> ./org.apache.felix.http.servlet-api/org.apache.felix.http.servlet-api-1.1.0.jar
> ./org.apache.felix.metatype/org.apache.felix.metatype-1.0.12.jar
> ./org.apache.felix.scr/org.apache.felix.scr-1.8.2.jar
> ./org.apache.felix.webconsole/org.apache.felix.webconsole-4.2.8.jar
> {noformat}
> I will attach the DEBUG log on connection establishment.
> The relevant error is:
> {noformat}
> javax.net.ssl.SSLHandshakeException: no cipher suites in common
>   at sun.security.ssl.Handshaker.checkThrown(Handshaker.java:1431)
>   at 
> sun.security.ssl.SSLEngineImpl.checkTaskThrown(SSLEngineImpl.java:535)
>   at sun.security.ssl.SSLEngineImpl.readNetRecord(SSLEngineImpl.java:813)
>   at sun.security.ssl.SSLEngineImpl.unwrap(SSLEngineImpl.java:781)
>   at javax.net.ssl.SSLEngine.unwrap(SSLEngine.java:624)
>   at 
> org.eclipse.jetty.io.ssl.SslConnection$DecryptedEndPoint.fill(SslConnection.java:516)
>   at 
> org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:239)
>   at 
> org.eclipse.jetty.io.AbstractConnection$2.run(AbstractConnection.java:540)
>   at 
> org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:635)
>   at 
> org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:555)
>   at java.lang.Thread.run(Thread.java:745)
> Caused by: javax.net.ssl.SSLHandshakeException: no cipher suites in common
>   at sun.security.ssl.Alerts.getSSLException(Alerts.java:192)
>   at sun.security.ssl.SSLEngineImpl.fatal(SSLEngineImpl.java:1666)
>   at sun.security.ssl.Handshaker.fatalSE(Handshaker.java:304)
>   at sun.security.ssl.Handshaker.fatalSE(Handshaker.java:292)
>   at 
> sun.security.ssl.ServerHandshaker.chooseCipherSuite(ServerHandshaker.java:1014)
>   at 
> sun.security.ssl.ServerHandshaker.clientHello(ServerHandshaker.java:731)
>   at 
> sun.security.ssl.ServerHandshaker.processMessage(ServerHandshaker.java:213)
>   at sun.security.ssl.Handshaker.processLoop(Handshaker.java:979)
>   at sun.security.ssl.Handshaker$1.run(Handshaker.java:919)
>   at sun.security.ssl.Handshaker$1.run(Handshaker.java:916)
>   at java.security.AccessController.doPrivileged(Native Method)
>   at sun.security.ssl.Handshaker$DelegatedTask.run(Handshaker.java:1369)
>   at 
> org.eclipse.jetty.io.ssl.SslConnection$DecryptedEndPoint.fill(SslConnection.java:612)
>   ... 5 common frames omitted
> {noformat}



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

[jira] [Commented] (FELIX-4896) Jetty web server 'no cipher suites in common' bug

2016-09-20 Thread Ferry Huberts (JIRA) 

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

Ferry Huberts commented on FELIX-4896:
--

Will have to check after my vacation.

What more information do you want?
The DEBUG log is already attached

> Jetty web server 'no cipher suites in common' bug
> -
>
> Key: FELIX-4896
> URL: https://issues.apache.org/jira/browse/FELIX-4896
> Project: Felix
>  Issue Type: Bug
>  Components: HTTP Service
>Affects Versions: http.jetty-3.0.2
> Environment: Fedora 21 x64
>Reporter: Ferry Huberts
> Attachments: jetty-ssl-cipher-suite-error
>
>
> I can no longer connect to the webconsole.
> I'm using
> {noformat}
> ./org.apache.felix.configadmin/org.apache.felix.configadmin-1.8.2.jar
> ./org.apache.felix.eventadmin/org.apache.felix.eventadmin-1.4.2.jar
> ./org.apache.felix.fileinstall/org.apache.felix.fileinstall-3.5.0.jar
> ./org.apache.felix.framework/org.apache.felix.framework-4.6.1.jar
> ./org.apache.felix.gogo.command/org.apache.felix.gogo.command-0.14.0.jar
> ./org.apache.felix.gogo.runtime/org.apache.felix.gogo.runtime-0.16.2.jar
> ./org.apache.felix.gogo.shell/org.apache.felix.gogo.shell-0.10.0.jar
> ./org.apache.felix.http.api/org.apache.felix.http.api-2.3.2.jar
> ./org.apache.felix.http.jetty/org.apache.felix.http.jetty-3.0.2.jar
> ./org.apache.felix.http.servlet-api/org.apache.felix.http.servlet-api-1.1.0.jar
> ./org.apache.felix.metatype/org.apache.felix.metatype-1.0.12.jar
> ./org.apache.felix.scr/org.apache.felix.scr-1.8.2.jar
> ./org.apache.felix.webconsole/org.apache.felix.webconsole-4.2.8.jar
> {noformat}
> I will attach the DEBUG log on connection establishment.
> The relevant error is:
> {noformat}
> javax.net.ssl.SSLHandshakeException: no cipher suites in common
>   at sun.security.ssl.Handshaker.checkThrown(Handshaker.java:1431)
>   at 
> sun.security.ssl.SSLEngineImpl.checkTaskThrown(SSLEngineImpl.java:535)
>   at sun.security.ssl.SSLEngineImpl.readNetRecord(SSLEngineImpl.java:813)
>   at sun.security.ssl.SSLEngineImpl.unwrap(SSLEngineImpl.java:781)
>   at javax.net.ssl.SSLEngine.unwrap(SSLEngine.java:624)
>   at 
> org.eclipse.jetty.io.ssl.SslConnection$DecryptedEndPoint.fill(SslConnection.java:516)
>   at 
> org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:239)
>   at 
> org.eclipse.jetty.io.AbstractConnection$2.run(AbstractConnection.java:540)
>   at 
> org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:635)
>   at 
> org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:555)
>   at java.lang.Thread.run(Thread.java:745)
> Caused by: javax.net.ssl.SSLHandshakeException: no cipher suites in common
>   at sun.security.ssl.Alerts.getSSLException(Alerts.java:192)
>   at sun.security.ssl.SSLEngineImpl.fatal(SSLEngineImpl.java:1666)
>   at sun.security.ssl.Handshaker.fatalSE(Handshaker.java:304)
>   at sun.security.ssl.Handshaker.fatalSE(Handshaker.java:292)
>   at 
> sun.security.ssl.ServerHandshaker.chooseCipherSuite(ServerHandshaker.java:1014)
>   at 
> sun.security.ssl.ServerHandshaker.clientHello(ServerHandshaker.java:731)
>   at 
> sun.security.ssl.ServerHandshaker.processMessage(ServerHandshaker.java:213)
>   at sun.security.ssl.Handshaker.processLoop(Handshaker.java:979)
>   at sun.security.ssl.Handshaker$1.run(Handshaker.java:919)
>   at sun.security.ssl.Handshaker$1.run(Handshaker.java:916)
>   at java.security.AccessController.doPrivileged(Native Method)
>   at sun.security.ssl.Handshaker$DelegatedTask.run(Handshaker.java:1369)
>   at 
> org.eclipse.jetty.io.ssl.SslConnection$DecryptedEndPoint.fill(SslConnection.java:612)
>   ... 5 common frames omitted
> {noformat}



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

[jira] [Assigned] (FELIX-5326) Add data structure descriptor

2016-09-20 Thread David Bosschaert (JIRA) 

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

David Bosschaert reassigned FELIX-5326:
---

Assignee: David Bosschaert

> Add data structure descriptor
> -
>
> Key: FELIX-5326
> URL: https://issues.apache.org/jira/browse/FELIX-5326
> Project: Felix
>  Issue Type: New Feature
>  Components: Converter
>Reporter: David Leangen
>Assignee: David Bosschaert
>
> The Converter service does a lot of introspection and parsing of the DTO data 
> structure. In many cases, a DTO is a very simple object structure. However, 
> it can also be a very complex structure, too.
> According to my understanding of the objectives of the Converter, one 
> important goal is to be able to persist data. The idea is that the DTO 
> describes the data structure. Thus, it is the ideal way to ship the state of 
> the system off to PersistenceLand.
> If we do buy into this vision, then we may be missing out on a few great 
> opportunities here. When data gets persisted, we often need to understand the 
> relationships between the embedded objects. Or, we may want to be able to 
> create an index on the data. These are a few of the reasons why we would want 
> to have some kind of x-ray vision on the data structure. Since we already go 
> through all the trouble of parsing the data structure in order to convert it, 
> and since this is ~95% of the work, it would be really nice to provide access 
> to this information in order to easily link in services that require this 
> intimate knowledge. Otherwise, all the parsing would have to be done over and 
> over again for each service.
> I believe that it would only take a few methods to be able to leverage all 
> the parsing work done by the Converter. I can think of:
>  DataTree Converter.toTree(DTO dto); // DataTre gives a tree view of the 
> structure
>  Object tree.valueAt(DTO dto, String path); // Dot-separated path value 
> within the tree structure
>  void tree.set(DTO dto, String path, Object value); // Set the value at the 
> given location in the tree structure
>  void process(DTO dto, Consumer function); // Visit each node for some 
> kind of processing
> Those are just some examples. Perhaps a new API would be necessary, but my 
> main point here is that since we are going through all this work of 
> implementing a parser, this is the IDEAL time to create this type of view on 
> the data.
> Also, one of the properties of DTOs is that the DTOs are really, in a way, 
> nothing more than schema. Because of this, it should be (and is) trivial to 
> convert to JSON, XML, YAML, or whatever. If the DTO *is* the data structure, 
> then it should also be trivial to convert the type descriptor (or tree, or 
> whatever) to some kind of schema, like JSON Schema, DTD, XML Schema, RDF…
> That fits well with one of the features of the Converter: codecs to convert
> to/from serialized types. RFC 215 defines two portable codecs: JSON and
> YAML but other implementations can add their own codecs too. We could do the 
> same not just for the live data instance, but for the data schema as well. 
> (Note that this schema generation is not required: we could decide only to 
> implement the data tree structure, and have an outside process generate the 
> scheme, but at least the data tree would enable this).
> I do understand that it is a step away from a simple “Converter”, but the 
> parsing is essentially the same. Since the hard work is already being done, 
> why not take advantage of it here? Even if this tree view ends up being a 
> completely different service, the same code base could easily serve the two.



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

Re: Heads-up: framework and resolver release

2016-09-20 Thread Guillaume Nodet 
+1
What are the bndtools issues exactly ? There are only a few minor changes
for those releases.

2016-09-19 21:21 GMT+02:00 Karl Pauls :

> I think its time to release new framework and resolver releases (there are
> some requests from e.g., bndtools).
>
> Are there any reasons not to?
>
> Otherwise, I'll go ahead and cut a release.
>
> regards,
>
> Karl
>
> --
> Karl Pauls
> karlpa...@gmail.com
>



-- 

Guillaume Nodet

Red Hat, Open Source Integration

Email: gno...@redhat.com
Web: http://fusesource.com
Blog: http://gnodet.blogspot.com/

[jira] [Closed] (FELIX-5349) Add ManagedServiceFactory to HTTP service

2016-09-20 Thread Derek Baum (JIRA) 

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

Derek Baum closed FELIX-5349.
-

Tested locally and works for me.

> Add ManagedServiceFactory to HTTP service
> -
>
> Key: FELIX-5349
> URL: https://issues.apache.org/jira/browse/FELIX-5349
> Project: Felix
>  Issue Type: New Feature
>  Components: HTTP Service
>Affects Versions: http.base-3.0.12, http.jetty-3.2.4
>Reporter: Derek Baum
>Assignee: Carsten Ziegeler
>Priority: Minor
> Fix For: http.base-3.0.14, http.jetty-3.2.6, http.bridge-3.0.14
>
> Attachments: factory.patch, factory2.patch
>
>
> I need to run multiple HTTP services, with different configurations.
> I was surprised to find that felix.http.jetty does not provide a 
> ManagedServiceFactory and so were others as indicated in this stack overflow 
> conversation: 
> http://stackoverflow.com/questions/20074211/osgi-http-bundle-bind-to-two-ports
> I have experimented with creating a ManagedServiceFactory for the HTTP 
> service myself. It is difficult to do externally to the http.jetty bundle, as 
> it requires access to internal packages.
> I have therefore created a small patch to revision 1760954 which adds a 
> ManagedServiceFactory, without changing any of the existing functionality of 
> the ManagedService. This allows multiple http.jetty instances to be 
> configured using WebConsole, fileinstall or other config admin clients.
> I have also added a new configuration property: org.apache.felix.http.name,
> which is added as a service property to the HTTP runtime instance. This makes 
> it easier to target a specific HTTP whiteboard service than filtering on the 
> port:
> HTTP_WHITEBOARD_TARGET + "=(org.apache.felix.http.name=web1)"
> I would be grateful if you would consider adding this functionality.



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

[jira] [Commented] (FELIX-4615) Re-enable ability to activate Jetty logging through HTTP service properties

2016-09-20 Thread Carsten Ziegeler (JIRA) 

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

Carsten Ziegeler commented on FELIX-4615:
-

[~walkerr] Is this still relevant? I cant find the property 
"org.apache.felix.http.debug" in the current code base at all

> Re-enable ability to activate Jetty logging through HTTP service properties
> ---
>
> Key: FELIX-4615
> URL: https://issues.apache.org/jira/browse/FELIX-4615
> Project: Felix
>  Issue Type: Improvement
>  Components: HTTP Service
>Reporter: Rob Walker
>Priority: Minor
>
> In older HTTP Service versions, Jetty's own internal logging could be enabled 
> either through direct control of Jetty properties, or via HTTP Service 
> properties. It looks like in recent versions this ability has been lost.
> The following debug flag does enable tracing of the service code itself:
> org.apache.felix.http.debug = true
> But this flag does not wire in a Logger for Jetty messages, or set it's level 
> to debug.
> It's possible that two flags/config approaches may be needed to allow fine 
> grained control: one for controlling service debug messages (as at present); 
> and an additional one to enable Jetty debug messages



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