from:"Chetan Mehrotra"


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

Chetan Mehrotra commented on FELIX-:


bq. escaping of the writer is correct, a slash can be espaced - it's not a must 
though

http://stackoverflow.com/questions/1580647/json-why-are-forward-slashes-escaped 
also confirms that. FWIW org.json.JSONObject did not escaped the slash but its 
done by other libraries

> JSONParser is not handling escape char properly
> ---
>
> Key: FELIX-
> URL: https://issues.apache.org/jira/browse/FELIX-
> Project: Felix
>  Issue Type: Bug
>  Components: Utils
>Affects Versions: utils-1.9.0
>    Reporter: Chetan Mehrotra
> Fix For: utils-1.9.2
>
>
> {{JSONWriter}} currently adds an escape char for '/'. So "foo=/bar" is 
> rendered as 
> {noformat}
> {"foo":"\/bar"}
> {noformat}
> When such a json is read via {{JSONParser}} then the '\' is not removed
> Following test fails
> {code}
> @Test
> public void escapeChar() throws Exception{
> StringWriter sw = new StringWriter();
> JSONWriter js = new JSONWriter(sw);
> js.object().key("foo").value("/bar").endObject().flush();
> 
> JSONParser jp = new JSONParser(sw.toString());
> assertEquals("/bar", jp.getParsed().get("foo"));
> }
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (FELIX-5555) JSONParser is not handling escape char properly


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

Chetan Mehrotra commented on FELIX-:


Added ignored test in 1783740. 

> JSONParser is not handling escape char properly
> ---
>
> Key: FELIX-
> URL: https://issues.apache.org/jira/browse/FELIX-
> Project: Felix
>  Issue Type: Bug
>  Components: Utils
>Affects Versions: utils-1.9.0
>    Reporter: Chetan Mehrotra
> Fix For: utils-1.9.2
>
>
> {{JSONWriter}} currently adds an escape char for '/'. So "foo=/bar" is 
> rendered as 
> {noformat}
> {"foo":"\/bar"}
> {noformat}
> When such a json is read via {{JSONParser}} then the '\' is not removed
> Following test fails
> {code}
> @Test
> public void escapeChar() throws Exception{
> StringWriter sw = new StringWriter();
> JSONWriter js = new JSONWriter(sw);
> js.object().key("foo").value("/bar").endObject().flush();
> 
> JSONParser jp = new JSONParser(sw.toString());
> assertEquals("/bar", jp.getParsed().get("foo"));
> }
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (FELIX-5555) JSONParser is not handling escape char properly


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

Chetan Mehrotra updated FELIX-:
---
Summary: JSONParser is not handling escape char properly  (was: JSONParser 
is not removing escape char)

> JSONParser is not handling escape char properly
> ---
>
> Key: FELIX-
> URL: https://issues.apache.org/jira/browse/FELIX-
> Project: Felix
>  Issue Type: Bug
>  Components: Utils
>Affects Versions: utils-1.9.0
>    Reporter: Chetan Mehrotra
> Fix For: utils-1.9.2
>
>
> {{JSONWriter}} currently adds an escape char for '/'. So "foo=/bar" is 
> rendered as 
> {noformat}
> {"foo":"\/bar"}
> {noformat}
> When such a json is read via {{JSONParser}} then the '\' is not removed
> Following test fails
> {code}
> @Test
> public void escapeChar() throws Exception{
> StringWriter sw = new StringWriter();
> JSONWriter js = new JSONWriter(sw);
> js.object().key("foo").value("/bar").endObject().flush();
> 
> JSONParser jp = new JSONParser(sw.toString());
> assertEquals("/bar", jp.getParsed().get("foo"));
> }
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (FELIX-5555) JSONParser is not removing escape char

Chetan Mehrotra created FELIX-:
--

 Summary: JSONParser is not removing escape char
 Key: FELIX-
 URL: https://issues.apache.org/jira/browse/FELIX-
 Project: Felix
  Issue Type: Bug
  Components: Utils
Affects Versions: utils-1.9.0
Reporter: Chetan Mehrotra
 Fix For: utils-1.9.2


{{JSONWriter}} currently adds an escape char for '/'. So "foo=/bar" is rendered 
as 
{noformat}
{"foo":"\/bar"}
{noformat}

When such a json is read via {{JSONParser}} then the '\' is not removed

Following test fails
{code}
@Test
public void escapeChar() throws Exception{
StringWriter sw = new StringWriter();
JSONWriter js = new JSONWriter(sw);
js.object().key("foo").value("/bar").endObject().flush();

JSONParser jp = new JSONParser(sw.toString());
assertEquals("/bar", jp.getParsed().get("foo"));
}
{code}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

Re: [VOTE] Release Apache Felix JAAS 1.0.2

2017-02-15 Thread Chetan Mehrotra

The vote passed with 5 binding +1 votes. Would be helpful if a PMC
member can copy the released jars to dist directory. I would then
proceed with next steps.

Chetan Mehrotra

[VOTE] Release Apache Felix JAAS 1.0.2

2017-02-13 Thread Chetan Mehrotra

Hi,

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

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

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 1166 /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
Chetan Mehrotra

[jira] [Resolved] (FELIX-5537) ConfigSpiOsgi should not try to unregister provider if not registered


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

Chetan Mehrotra resolved FELIX-5537.

Resolution: Fixed

Done with 1782503

> ConfigSpiOsgi should not try to unregister provider if not registered
> -
>
> Key: FELIX-5537
> URL: https://issues.apache.org/jira/browse/FELIX-5537
> Project: Felix
>  Issue Type: Improvement
>  Components: JAAS
>    Reporter: Chetan Mehrotra
>    Assignee: Chetan Mehrotra
>Priority: Minor
> Fix For: jaas-1.0.2
>
>
> On startup following log is seen which indicates a provider with null name is 
> being unregistered. This should be avoided as when provider name is null then 
> it indicates that provider has not be regsitered
> {noformat}
> 10.02.2017 17:09:19.873 *INFO* [FelixStartLevel] org.apache.felix.jaas 
> Removed provider null type JavaLoginConfig from Security providers list
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (FELIX-5537) ConfigSpiOsgi should not try to unregister provider if not registered

Chetan Mehrotra created FELIX-5537:
--

 Summary: ConfigSpiOsgi should not try to unregister provider if 
not registered
 Key: FELIX-5537
 URL: https://issues.apache.org/jira/browse/FELIX-5537
 Project: Felix
  Issue Type: Improvement
  Components: JAAS
Reporter: Chetan Mehrotra
Assignee: Chetan Mehrotra
Priority: Minor
 Fix For: jaas-1.0.2


On startup following log is seen which indicates a provider with null name is 
being unregistered. This should be avoided as when provider name is null then 
it indicates that provider has not be regsitered

{noformat}
10.02.2017 17:09:19.873 *INFO* [FelixStartLevel] org.apache.felix.jaas Removed 
provider null type JavaLoginConfig from Security providers list
{noformat}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Resolved] (FELIX-5536) ConfigSpiOSGi may end with incomplete realm due to race conditions


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

Chetan Mehrotra resolved FELIX-5536.

Resolution: Fixed

Fixed with 1782501

> ConfigSpiOSGi may end with incomplete realm due to race conditions
> --
>
> Key: FELIX-5536
> URL: https://issues.apache.org/jira/browse/FELIX-5536
> Project: Felix
>  Issue Type: Bug
>  Components: JAAS
>    Reporter: Chetan Mehrotra
>    Assignee: Chetan Mehrotra
> Fix For: jaas-1.0.2
>
>
> Some race conditions around this have been fixed with FELIX-5505. However one 
> more case surfaced where {{ConfigSpiOsgi#recreateConfigs}} can be invoked 
> concurrently without lock from 
> # {{ConfigSpiOsgi#updated}} - When ConfigurationAdmin dispatches config 
> update for {{org.apache.felix.jaas.ConfigurationSpi}}
> # {{ConfigSpiOsgi#addingService}} - When some LoginModuleFactory is registered
> In such a case the setup may end up with incomplete realm where some 
> LoginModuleFactory are missed out



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (FELIX-5536) ConfigSpiOSGi may end with incomplete realm due to race conditions


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

Chetan Mehrotra commented on FELIX-5536:


Adding ignored test in 1782497

> ConfigSpiOSGi may end with incomplete realm due to race conditions
> --
>
> Key: FELIX-5536
> URL: https://issues.apache.org/jira/browse/FELIX-5536
> Project: Felix
>  Issue Type: Bug
>  Components: JAAS
>    Reporter: Chetan Mehrotra
>    Assignee: Chetan Mehrotra
> Fix For: jaas-1.0.2
>
>
> Some race conditions around this have been fixed with FELIX-5505. However one 
> more case surfaced where {{ConfigSpiOsgi#recreateConfigs}} can be invoked 
> concurrently without lock from 
> # {{ConfigSpiOsgi#updated}} - When ConfigurationAdmin dispatches config 
> update for {{org.apache.felix.jaas.ConfigurationSpi}}
> # {{ConfigSpiOsgi#addingService}} - When some LoginModuleFactory is registered
> In such a case the setup may end up with incomplete realm where some 
> LoginModuleFactory are missed out



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (FELIX-5536) ConfigSpiOSGi may end with incomplete realm due to race conditions


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

Chetan Mehrotra updated FELIX-5536:
---
Summary: ConfigSpiOSGi may end with incomplete realm due to race conditions 
 (was: ConfigSpiOSGi may end with in complete realm due to race conditions)

> ConfigSpiOSGi may end with incomplete realm due to race conditions
> --
>
> Key: FELIX-5536
> URL: https://issues.apache.org/jira/browse/FELIX-5536
> Project: Felix
>  Issue Type: Bug
>  Components: JAAS
>    Reporter: Chetan Mehrotra
>    Assignee: Chetan Mehrotra
> Fix For: jaas-1.0.2
>
>
> Some race conditions around this have been fixed with FELIX-5505. However one 
> more case surfaced where {{ConfigSpiOsgi#recreateConfigs}} can be invoked 
> concurrently without lock from 
> # {{ConfigSpiOsgi#updated}} - When ConfigurationAdmin dispatches config 
> update for {{org.apache.felix.jaas.ConfigurationSpi}}
> # {{ConfigSpiOsgi#addingService}} - When some LoginModuleFactory is registered
> In such a case the setup may end up with incomplete realm where some 
> LoginModuleFactory are missed out



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (FELIX-5536) ConfigSpiOSGi may end with in complete realm due to race conditions

Chetan Mehrotra created FELIX-5536:
--

 Summary: ConfigSpiOSGi may end with in complete realm due to race 
conditions
 Key: FELIX-5536
 URL: https://issues.apache.org/jira/browse/FELIX-5536
 Project: Felix
  Issue Type: Bug
  Components: JAAS
Reporter: Chetan Mehrotra
Assignee: Chetan Mehrotra
 Fix For: jaas-1.0.2


Some race conditions around this have been fixed with FELIX-5505. However one 
more case surfaced where {{ConfigSpiOsgi#recreateConfigs}} can be invoked 
concurrently without lock from 

# {{ConfigSpiOsgi#updated}} - When ConfigurationAdmin dispatches config update 
for {{org.apache.felix.jaas.ConfigurationSpi}}
# {{ConfigSpiOsgi#addingService}} - When some LoginModuleFactory is registered

In such a case the setup may end up with incomplete realm where some 
LoginModuleFactory are missed out



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

Re: [VOTE] Release Apache Felix JAAS 1.0.0

2017-01-24 Thread Chetan Mehrotra

+1 (non binding)
Chetan Mehrotra


On Tue, Jan 24, 2017 at 8:27 PM, David Bosschaert
<david.bosscha...@gmail.com> wrote:
> +1
>
> David
>
> On 24 January 2017 at 04:40, Carsten Ziegeler <cziege...@apache.org> wrote:
>
>> Hi,
>>
>> We solved 3 issues in this release
>> https://issues.apache.org/jira/browse/FELIX/fixforversion/12324254
>>
>>
>> Staging repository:
>> https://repository.apache.org/content/repositories/orgapachefelix-1163/
>>
>> 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 1163 /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
>> Carsten
>> --
>> Carsten Ziegeler
>> Adobe Research Switzerland
>> cziege...@apache.org
>>

[jira] [Resolved] (FELIX-5505) ConfigSpiOSGi may miss out on registering some LoginModuleFactory due to race condition


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

Chetan Mehrotra resolved FELIX-5505.

Resolution: Fixed

Thanks Carsten for the review

Took care of unregistering the spi in close

Applied the patch in 1779601

> ConfigSpiOSGi may miss out on registering some LoginModuleFactory due to race 
> condition
> ---
>
> Key: FELIX-5505
> URL: https://issues.apache.org/jira/browse/FELIX-5505
> Project: Felix
>  Issue Type: Bug
>  Components: JAAS
>    Reporter: Chetan Mehrotra
>Assignee: Chetan Mehrotra
>Priority: Critical
> Fix For: jaas-1.0.0
>
> Attachments: FELIX-5505-v1.patch
>
>
> {{ConfigSpiOsgi}} currently looks for {{LoginModuleFactory}} and upon 
> registration of any factory it recreates its {{Realm}} state. 
> This logic has a race condition where concurrent addition of 
> {{LoginModuleFactory}} may lead to some of them getting missed from getting 
> registered in the Realm



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

[jira] [Updated] (FELIX-5505) ConfigSpiOSGi may miss out on registering some LoginModuleFactory due to race condition


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

Chetan Mehrotra updated FELIX-5505:
---
Attachment: FELIX-5505-v1.patch

[patch|^FELIX-5505-v1.patch] for the same

[~cziegeler] [~bosschaert] Would be helpful if you can review the patch

> ConfigSpiOSGi may miss out on registering some LoginModuleFactory due to race 
> condition
> ---
>
> Key: FELIX-5505
> URL: https://issues.apache.org/jira/browse/FELIX-5505
> Project: Felix
>  Issue Type: Bug
>  Components: JAAS
>    Reporter: Chetan Mehrotra
>Assignee: Chetan Mehrotra
>Priority: Critical
> Fix For: jaas-1.0.0
>
> Attachments: FELIX-5505-v1.patch
>
>
> {{ConfigSpiOsgi}} currently looks for {{LoginModuleFactory}} and upon 
> registration of any factory it recreates its {{Realm}} state. 
> This logic has a race condition where concurrent addition of 
> {{LoginModuleFactory}} may lead to some of them getting missed from getting 
> registered in the Realm



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

[jira] [Resolved] (FELIX-5502) Startup logs from ConfigSpiOsgi may get dropped due to race condition


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

Chetan Mehrotra resolved FELIX-5502.

Resolution: Fixed

Fixed with 1779591

> Startup logs from ConfigSpiOsgi may get dropped due to race condition
> -
>
> Key: FELIX-5502
> URL: https://issues.apache.org/jira/browse/FELIX-5502
> Project: Felix
>  Issue Type: Bug
>  Components: JAAS
>    Reporter: Chetan Mehrotra
>    Assignee: Chetan Mehrotra
>Priority: Minor
> Fix For: jaas-1.0.0
>
>
> Felix JAAS bundle Activator [1] starts the Logger tracker *after* creating 
> {{ConfigSpiOsgi}} instance. Due to this some log statements may get missed 
> out if config admin invokes managed service update before logger tracker is 
> opened which would cause the logger to drop those messages
> [1] 
> https://github.com/apache/felix/blob/trunk/jaas/src/main/java/org/apache/felix/jaas/internal/Activator.java#L49



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

[jira] [Commented] (FELIX-5505) ConfigSpiOSGi may miss out on registering some LoginModuleFactory due to race condition


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

Chetan Mehrotra commented on FELIX-5505:


Added ignored test with 1779592

> ConfigSpiOSGi may miss out on registering some LoginModuleFactory due to race 
> condition
> ---
>
> Key: FELIX-5505
> URL: https://issues.apache.org/jira/browse/FELIX-5505
> Project: Felix
>  Issue Type: Bug
>  Components: JAAS
>    Reporter: Chetan Mehrotra
>Assignee: Chetan Mehrotra
>Priority: Critical
> Fix For: jaas-1.0.0
>
>
> {{ConfigSpiOsgi}} currently looks for {{LoginModuleFactory}} and upon 
> registration of any factory it recreates its {{Realm}} state. 
> This logic has a race condition where concurrent addition of 
> {{LoginModuleFactory}} may lead to some of them getting missed from getting 
> registered in the Realm



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

[jira] [Created] (FELIX-5505) ConfigSpiOSGi may miss out on registering some LoginModuleFactory due to race condition

Chetan Mehrotra created FELIX-5505:
--

 Summary: ConfigSpiOSGi may miss out on registering some 
LoginModuleFactory due to race condition
 Key: FELIX-5505
 URL: https://issues.apache.org/jira/browse/FELIX-5505
 Project: Felix
  Issue Type: Bug
  Components: JAAS
Reporter: Chetan Mehrotra
Assignee: Chetan Mehrotra
Priority: Critical
 Fix For: jaas-1.0.0


{{ConfigSpiOsgi}} currently looks for {{LoginModuleFactory}} and upon 
registration of any factory it recreates its {{Realm}} state. 

This logic has a race condition where concurrent addition of 
{{LoginModuleFactory}} may lead to some of them getting missed from getting 
registered in the Realm



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

[jira] [Created] (FELIX-5502) Startup logs from ConfigSpiOsgi may get dropped due to race condition

2017-01-19 Thread Chetan Mehrotra (JIRA)

Chetan Mehrotra created FELIX-5502:
--

 Summary: Startup logs from ConfigSpiOsgi may get dropped due to 
race condition
 Key: FELIX-5502
 URL: https://issues.apache.org/jira/browse/FELIX-5502
 Project: Felix
  Issue Type: Bug
  Components: JAAS
Reporter: Chetan Mehrotra
Assignee: Chetan Mehrotra
Priority: Minor
 Fix For: jaas-1.0.0


Felix JAAS bundle Activator [1] starts the Logger tracker *after* creating 
{{ConfigSpiOsgi}} instance. Due to this some log statements may get missed out 
if config admin invokes managed service update before logger tracker is opened 
which would cause the logger to drop those messages

[1] 
https://github.com/apache/felix/blob/trunk/jaas/src/main/java/org/apache/felix/jaas/internal/Activator.java#L49



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

[jira] [Created] (FELIX-5398) Inventory printer to dump all framework properties

2016-11-06 Thread Chetan Mehrotra (JIRA)

Chetan Mehrotra created FELIX-5398:
--

 Summary: Inventory printer to dump all framework properties
 Key: FELIX-5398
 URL: https://issues.apache.org/jira/browse/FELIX-5398
 Project: Felix
  Issue Type: Improvement
  Components: Web Console
Reporter: Chetan Mehrotra
Assignee: Chetan Mehrotra
Priority: Minor


Add a Inventory Status Printer to dump all Framework Property. This can use the 
approach suggested by [~tjwatson] at [1]

[1] https://mail.osgi.org/pipermail/osgi-dev/2016-November/005800.html



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

Re: svn commit: r1755500 - /felix/trunk/http/base/src/main/java/org/apache/felix/http/base/internal/console/HttpServicePlugin.java

2016-08-09 Thread Chetan Mehrotra

On Tue, Aug 9, 2016 at 1:54 PM, Carsten Ziegeler <cziege...@apache.org> wrote:
> There is no unget service reference, the code is just getting the
> reference, not the service

Ah missed that part. Makes sense

Chetan Mehrotra

Re: svn commit: r1755500 - /felix/trunk/http/base/src/main/java/org/apache/felix/http/base/internal/console/HttpServicePlugin.java

2016-08-09 Thread Chetan Mehrotra

On Mon, Aug 8, 2016 at 5:48 PM,  <cziege...@apache.org> wrote:
> +final ServiceReference ref = 
> this.getServiceReference(dto.serviceId);

Probably an unget would also need to be done?

Chetan Mehrotra

[jira] [Commented] (FELIX-5318) SCR causes startup to wait when bundle uninstall itself in activator

2016-08-03 Thread Chetan Mehrotra (JIRA)


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

Chetan Mehrotra commented on FELIX-5318:


Thanks to you David for fixing it so promptly :)

> SCR causes startup to wait when bundle uninstall itself in activator
> 
>
> Key: FELIX-5318
> URL: https://issues.apache.org/jira/browse/FELIX-5318
> Project: Felix
>  Issue Type: Bug
>  Components: Declarative Services (SCR)
>    Reporter: Chetan Mehrotra
>Assignee: David Jencks
>Priority: Minor
> Fix For: scr-2.0.6
>
> Attachments: FELIX-5318-v1.patch
>
>
> If a bundle which does not have any service component configured uninstall 
> itself upon activation then SCR waits for latch to timeout in 
> {{Activator$ScrExtension.destroy}}
> The threaddump indicate that FelixStartLevel thread is waiting for latch to 
> timeout
> {noformat}
> "FelixStartLevel" daemon prio=10 tid=0x7f4df45c5000 nid=0x65e6 waiting on 
> condition [0x7f4d92fcc000]
>java.lang.Thread.State: TIMED_WAITING (parking)
>   at sun.misc.Unsafe.park(Native Method)
>   - parking to wait for  <0x000783400420> (a 
> java.util.concurrent.CountDownLatch$Sync)
>   at 
> java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:226)
>   at 
> java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedNanos(AbstractQueuedSynchronizer.java:1033)
>   at 
> java.util.concurrent.locks.AbstractQueuedSynchronizer.tryAcquireSharedNanos(AbstractQueuedSynchronizer.java:1326)
>   at java.util.concurrent.CountDownLatch.await(CountDownLatch.java:282)
>   at 
> org.apache.felix.scr.impl.Activator$ScrExtension.destroy(Activator.java:268)
>   at 
> org.apache.felix.utils.extender.AbstractExtender$2.run(AbstractExtender.java:290)
>   at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
>   at java.util.concurrent.FutureTask.run(FutureTask.java:262)
>   at 
> org.apache.felix.utils.extender.AbstractExtender.destroyExtension(AbstractExtender.java:312)
>   at 
> org.apache.felix.utils.extender.AbstractExtender.bundleChanged(AbstractExtender.java:186)
>   at 
> org.apache.felix.framework.util.EventDispatcher.invokeBundleListenerCallback(EventDispatcher.java:916)
>   at 
> org.apache.felix.framework.util.EventDispatcher.fireEventImmediately(EventDispatcher.java:835)
>   at 
> org.apache.felix.framework.util.EventDispatcher.fireBundleEvent(EventDispatcher.java:517)
>   at org.apache.felix.framework.Felix.fireBundleEvent(Felix.java:4541)
>   at org.apache.felix.framework.Felix.stopBundle(Felix.java:2600)
>   at org.apache.felix.framework.Felix.uninstallBundle(Felix.java:2712)
>   at org.apache.felix.framework.BundleImpl.uninstall(BundleImpl.java:1055)
>   at com.foo.bar.Initializer.activate(Initializer.java:71)
> {noformat}
> This happens at [1] most likely because Framework has not invoked started yet 
> so latch is not changed. As a fix destroy method should check if the bundle 
> being stopped has any service component. If not it should then not wait on 
> the latch
> [1] 
> https://github.com/apache/felix/blob/trunk/scr/src/main/java/org/apache/felix/scr/impl/Activator.java#L280



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

[jira] [Commented] (FELIX-5318) SCR causes startup to wait when bundle uninstall itself in activator

2016-08-02 Thread Chetan Mehrotra (JIRA)


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

Chetan Mehrotra commented on FELIX-5318:


With latest trunk I do not see the pause post uninstall. So it works!

> SCR causes startup to wait when bundle uninstall itself in activator
> 
>
> Key: FELIX-5318
> URL: https://issues.apache.org/jira/browse/FELIX-5318
> Project: Felix
>  Issue Type: Bug
>  Components: Declarative Services (SCR)
>    Reporter: Chetan Mehrotra
>Assignee: David Jencks
>Priority: Minor
> Fix For: scr-2.0.6
>
> Attachments: FELIX-5318-v1.patch
>
>
> If a bundle which does not have any service component configured uninstall 
> itself upon activation then SCR waits for latch to timeout in 
> {{Activator$ScrExtension.destroy}}
> The threaddump indicate that FelixStartLevel thread is waiting for latch to 
> timeout
> {noformat}
> "FelixStartLevel" daemon prio=10 tid=0x7f4df45c5000 nid=0x65e6 waiting on 
> condition [0x7f4d92fcc000]
>java.lang.Thread.State: TIMED_WAITING (parking)
>   at sun.misc.Unsafe.park(Native Method)
>   - parking to wait for  <0x000783400420> (a 
> java.util.concurrent.CountDownLatch$Sync)
>   at 
> java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:226)
>   at 
> java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedNanos(AbstractQueuedSynchronizer.java:1033)
>   at 
> java.util.concurrent.locks.AbstractQueuedSynchronizer.tryAcquireSharedNanos(AbstractQueuedSynchronizer.java:1326)
>   at java.util.concurrent.CountDownLatch.await(CountDownLatch.java:282)
>   at 
> org.apache.felix.scr.impl.Activator$ScrExtension.destroy(Activator.java:268)
>   at 
> org.apache.felix.utils.extender.AbstractExtender$2.run(AbstractExtender.java:290)
>   at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
>   at java.util.concurrent.FutureTask.run(FutureTask.java:262)
>   at 
> org.apache.felix.utils.extender.AbstractExtender.destroyExtension(AbstractExtender.java:312)
>   at 
> org.apache.felix.utils.extender.AbstractExtender.bundleChanged(AbstractExtender.java:186)
>   at 
> org.apache.felix.framework.util.EventDispatcher.invokeBundleListenerCallback(EventDispatcher.java:916)
>   at 
> org.apache.felix.framework.util.EventDispatcher.fireEventImmediately(EventDispatcher.java:835)
>   at 
> org.apache.felix.framework.util.EventDispatcher.fireBundleEvent(EventDispatcher.java:517)
>   at org.apache.felix.framework.Felix.fireBundleEvent(Felix.java:4541)
>   at org.apache.felix.framework.Felix.stopBundle(Felix.java:2600)
>   at org.apache.felix.framework.Felix.uninstallBundle(Felix.java:2712)
>   at org.apache.felix.framework.BundleImpl.uninstall(BundleImpl.java:1055)
>   at com.foo.bar.Initializer.activate(Initializer.java:71)
> {noformat}
> This happens at [1] most likely because Framework has not invoked started yet 
> so latch is not changed. As a fix destroy method should check if the bundle 
> being stopped has any service component. If not it should then not wait on 
> the latch
> [1] 
> https://github.com/apache/felix/blob/trunk/scr/src/main/java/org/apache/felix/scr/impl/Activator.java#L280



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

[jira] [Updated] (FELIX-5318) SCR causes startup to wait when bundle uninstall itself in activator

2016-08-02 Thread Chetan Mehrotra (JIRA)


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

Chetan Mehrotra updated FELIX-5318:
---
Attachment: FELIX-5318-v1.patch

[possible patch|^FELIX-5318-v1.patch] this should fix the issue based on 
logical flow. Creating a testcase would take some time. May be logical fix is  
sufficient!! Otherwise would try to come up with test also

> SCR causes startup to wait when bundle uninstall itself in activator
> 
>
> Key: FELIX-5318
> URL: https://issues.apache.org/jira/browse/FELIX-5318
> Project: Felix
>  Issue Type: Bug
>  Components: Declarative Services (SCR)
>    Reporter: Chetan Mehrotra
>Priority: Minor
> Fix For: scr-2.0.6
>
> Attachments: FELIX-5318-v1.patch
>
>
> If a bundle which does not have any service component configured uninstall 
> itself upon activation then SCR waits for latch to timeout in 
> {{Activator$ScrExtension.destroy}}
> The threaddump indicate that FelixStartLevel thread is waiting for latch to 
> timeout
> {noformat}
> "FelixStartLevel" daemon prio=10 tid=0x7f4df45c5000 nid=0x65e6 waiting on 
> condition [0x7f4d92fcc000]
>java.lang.Thread.State: TIMED_WAITING (parking)
>   at sun.misc.Unsafe.park(Native Method)
>   - parking to wait for  <0x000783400420> (a 
> java.util.concurrent.CountDownLatch$Sync)
>   at 
> java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:226)
>   at 
> java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedNanos(AbstractQueuedSynchronizer.java:1033)
>   at 
> java.util.concurrent.locks.AbstractQueuedSynchronizer.tryAcquireSharedNanos(AbstractQueuedSynchronizer.java:1326)
>   at java.util.concurrent.CountDownLatch.await(CountDownLatch.java:282)
>   at 
> org.apache.felix.scr.impl.Activator$ScrExtension.destroy(Activator.java:268)
>   at 
> org.apache.felix.utils.extender.AbstractExtender$2.run(AbstractExtender.java:290)
>   at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
>   at java.util.concurrent.FutureTask.run(FutureTask.java:262)
>   at 
> org.apache.felix.utils.extender.AbstractExtender.destroyExtension(AbstractExtender.java:312)
>   at 
> org.apache.felix.utils.extender.AbstractExtender.bundleChanged(AbstractExtender.java:186)
>   at 
> org.apache.felix.framework.util.EventDispatcher.invokeBundleListenerCallback(EventDispatcher.java:916)
>   at 
> org.apache.felix.framework.util.EventDispatcher.fireEventImmediately(EventDispatcher.java:835)
>   at 
> org.apache.felix.framework.util.EventDispatcher.fireBundleEvent(EventDispatcher.java:517)
>   at org.apache.felix.framework.Felix.fireBundleEvent(Felix.java:4541)
>   at org.apache.felix.framework.Felix.stopBundle(Felix.java:2600)
>   at org.apache.felix.framework.Felix.uninstallBundle(Felix.java:2712)
>   at org.apache.felix.framework.BundleImpl.uninstall(BundleImpl.java:1055)
>   at com.foo.bar.Initializer.activate(Initializer.java:71)
> {noformat}
> This happens at [1] most likely because Framework has not invoked started yet 
> so latch is not changed. As a fix destroy method should check if the bundle 
> being stopped has any service component. If not it should then not wait on 
> the latch
> [1] 
> https://github.com/apache/felix/blob/trunk/scr/src/main/java/org/apache/felix/scr/impl/Activator.java#L280



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

[jira] [Created] (FELIX-5318) SCR causes startup to wait when bundle uninstall itself in activator

2016-08-02 Thread Chetan Mehrotra (JIRA)

Chetan Mehrotra created FELIX-5318:
--

 Summary: SCR causes startup to wait when bundle uninstall itself 
in activator
 Key: FELIX-5318
 URL: https://issues.apache.org/jira/browse/FELIX-5318
 Project: Felix
  Issue Type: Bug
  Components: Declarative Services (SCR)
Reporter: Chetan Mehrotra
Priority: Minor
 Fix For: scr-2.0.6


If a bundle which does not have any service component configured uninstall 
itself upon activation then SCR waits for latch to timeout in 
{{Activator$ScrExtension.destroy}}

The threaddump indicate that FelixStartLevel thread is waiting for latch to 
timeout
{noformat}
"FelixStartLevel" daemon prio=10 tid=0x7f4df45c5000 nid=0x65e6 waiting on 
condition [0x7f4d92fcc000]
   java.lang.Thread.State: TIMED_WAITING (parking)
at sun.misc.Unsafe.park(Native Method)
- parking to wait for  <0x000783400420> (a 
java.util.concurrent.CountDownLatch$Sync)
at 
java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:226)
at 
java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedNanos(AbstractQueuedSynchronizer.java:1033)
at 
java.util.concurrent.locks.AbstractQueuedSynchronizer.tryAcquireSharedNanos(AbstractQueuedSynchronizer.java:1326)
at java.util.concurrent.CountDownLatch.await(CountDownLatch.java:282)
at 
org.apache.felix.scr.impl.Activator$ScrExtension.destroy(Activator.java:268)
at 
org.apache.felix.utils.extender.AbstractExtender$2.run(AbstractExtender.java:290)
at 
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
at java.util.concurrent.FutureTask.run(FutureTask.java:262)
at 
org.apache.felix.utils.extender.AbstractExtender.destroyExtension(AbstractExtender.java:312)
at 
org.apache.felix.utils.extender.AbstractExtender.bundleChanged(AbstractExtender.java:186)
at 
org.apache.felix.framework.util.EventDispatcher.invokeBundleListenerCallback(EventDispatcher.java:916)
at 
org.apache.felix.framework.util.EventDispatcher.fireEventImmediately(EventDispatcher.java:835)
at 
org.apache.felix.framework.util.EventDispatcher.fireBundleEvent(EventDispatcher.java:517)
at org.apache.felix.framework.Felix.fireBundleEvent(Felix.java:4541)
at org.apache.felix.framework.Felix.stopBundle(Felix.java:2600)
at org.apache.felix.framework.Felix.uninstallBundle(Felix.java:2712)
at org.apache.felix.framework.BundleImpl.uninstall(BundleImpl.java:1055)
at com.foo.bar.Initializer.activate(Initializer.java:71)
{noformat}

This happens at [1] most likely because Framework has not invoked started yet 
so latch is not changed. As a fix destroy method should check if the bundle 
being stopped has any service component. If not it should then not wait on the 
latch

[1] 
https://github.com/apache/felix/blob/trunk/scr/src/main/java/org/apache/felix/scr/impl/Activator.java#L280



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

[jira] [Closed] (FELIX-5119) Jaas module build fails with JDK 8


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

Chetan Mehrotra closed FELIX-5119.
--

> Jaas module build fails with JDK 8
> --
>
> Key: FELIX-5119
> URL: https://issues.apache.org/jira/browse/FELIX-5119
> Project: Felix
>  Issue Type: Task
>  Components: JAAS
>    Reporter: Chetan Mehrotra
>    Assignee: Chetan Mehrotra
> Fix For: jaas-0.0.4
>
>
> Building trunk with JDK 8 fails with test failures
> See http://markmail.org/message/2dvzkkawoe26bw7w



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

[jira] [Closed] (FELIX-4827) Improve logging on LoginModule registration


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

Chetan Mehrotra closed FELIX-4827.
--

> Improve logging on LoginModule registration
> ---
>
> Key: FELIX-4827
> URL: https://issues.apache.org/jira/browse/FELIX-4827
> Project: Felix
>  Issue Type: Bug
>  Components: JAAS
>Reporter: Alex Parvulescu
>    Assignee: Chetan Mehrotra
>Priority: Minor
> Fix For: jaas-0.0.4
>
>
> There's a space missing in the log message when registering a new LoginModule 
> [0], currently the log looks like the following:
> {code}
> 22.02.2015 03:03:28.256 *INFO* [FelixStartLevel] org.apache.felix.jaas 
> Registering LoginModule class 
> [org.apache.jackrabbit.oak.security.authentication.token.TokenLoginModule] 
> from Bundleorg.apache.jackrabbit.oak-core [85]
> {code}
> _from Bundleorg.apache.jackrabbit.oak-core_ -> _from Bundle 
> org.apache.jackrabbit.oak-core_
> [0] 
> https://github.com/apache/felix/blob/33f093d4862955286c3a37b0b1a01153821c50f3/jaas/src/main/java/org/apache/felix/jaas/internal/BundleLoginModuleCreator.java#L151



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

[jira] [Closed] (FELIX-5083) Set webconsole.configurationFactory.nameHint for JAAS configurations


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

Chetan Mehrotra closed FELIX-5083.
--

> Set webconsole.configurationFactory.nameHint for JAAS configurations
> 
>
> Key: FELIX-5083
> URL: https://issues.apache.org/jira/browse/FELIX-5083
> Project: Felix
>  Issue Type: Improvement
>  Components: JAAS
>Affects Versions: jaas-0.0.2
>Reporter: Robert Munteanu
>Assignee: Chetan Mehrotra
>Priority: Minor
> Fix For: jaas-0.0.4
>
> Attachments: FELIX-5083.patch, FELIX-5083.png
>
>
> When working with multiple JAAS configuration in the Felix Web Console it's 
> hard to distinguish them.
> Setting the {{webconsole.configurationFactory.nameHint}} property to a 
> reasonable default removes this problem.



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

[RESULT] [VOTE] Apache Felix JAAS Support 0.0.4

2015-12-02 Thread Chetan Mehrotra

The vote has passed with three binding +1 votes and three non-binding:

  +1 (binding): Carsten Ziegeler, David Bosschaert, Pierre De Rop
  +1 (non binding): Jean-Baptiste Onofré, Raymond Auge,

I would ask a member of the Apache Felix PMC to promote the release and
upload artifacts to maven central.
(http://felix.apache.org/documentation/development/release-management-nexus.html#promoting-the-release)

Meanwhile, I'll fix the versions in the JIRA project.

Regards,
Chetan Mehrotra

[RESULT] [VOTE] Apache Felix Script Console Plugin 1.0.2

2015-12-02 Thread Chetan Mehrotra

The vote has passed with three binding +1 votes and three non-binding:

  +1 (binding): Carsten Ziegeler, David Bosschaert, Pierre De Rop
  +1 (non binding): Jamie G., Raymond Auge,

I would ask a member of the Apache Felix PMC to promote the release and
upload artifacts to maven central.
(http://felix.apache.org/documentation/development/release-management-nexus.html#promoting-the-release)

Meanwhile, I'll fix the versions in the JIRA project.

Regards,
Chetan Mehrotra

[jira] [Closed] (FELIX-5123) Script Console UI improvements


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

Chetan Mehrotra closed FELIX-5123.
--

> Script Console UI improvements
> --
>
> Key: FELIX-5123
> URL: https://issues.apache.org/jira/browse/FELIX-5123
> Project: Felix
>  Issue Type: Improvement
>  Components: Script Console Plugin
>Affects Versions: script-console-1.0.0
>    Reporter: Chetan Mehrotra
>Assignee: Chetan Mehrotra
>Priority: Minor
> Fix For: script-console-1.0.2
>
>
> Following improvements need to be done to script console UI
> # Remove timeout on executed command
> # Drop the Language button



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

[jira] [Closed] (FELIX-5122) Script console output cannot be copied


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

Chetan Mehrotra closed FELIX-5122.
--

> Script console output cannot be copied
> --
>
> Key: FELIX-5122
> URL: https://issues.apache.org/jira/browse/FELIX-5122
> Project: Felix
>  Issue Type: Bug
>  Components: Script Console Plugin
>Affects Versions: script-console-1.0.0
>    Reporter: Chetan Mehrotra
>Assignee: Chetan Mehrotra
> Fix For: script-console-1.0.2
>
>
> Script console output cannot be copied.



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

[jira] [Closed] (FELIX-5121) Script console build failing on latest trunk


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

Chetan Mehrotra closed FELIX-5121.
--

> Script console build failing on latest trunk
> 
>
> Key: FELIX-5121
> URL: https://issues.apache.org/jira/browse/FELIX-5121
> Project: Felix
>  Issue Type: Task
>  Components: Script Console Plugin
>    Reporter: Chetan Mehrotra
>    Assignee: Chetan Mehrotra
> Fix For: script-console-1.0.2
>
>
> Current trunk build is failing as exam-maven-plugin launch is not working 
> {noformat}
> [INFO] Failsafe report directory: 
> /home/chetanm/git/apache/felix/webconsole-plugins/script-console/target/failsafe-reports
> Error: Main method not found in class org.ops4j.pax.exam.spi.PaxExamRuntime, 
> please define the main method as:
>public static void main(String[] args)
> {noformat}
> Due to this the OSGi container is not launched



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

[jira] [Closed] (FELIX-5120) ScriptEngineManager not able to parse service file with comments at end of classname


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

Chetan Mehrotra closed FELIX-5120.
--

> ScriptEngineManager not able to parse service file with comments at end of 
> classname
> 
>
> Key: FELIX-5120
> URL: https://issues.apache.org/jira/browse/FELIX-5120
> Project: Felix
>  Issue Type: Bug
>  Components: Script Console Plugin
>Affects Versions: script-console-1.0.0
>Reporter: Chetan Mehrotra
>    Assignee: Chetan Mehrotra
>Priority: Minor
> Fix For: script-console-1.0.2
>
>
> A service file can also have a comment like below like
> {noformat}
> #script engines supported
> com.sun.script.javascript.RhinoScriptEngineFactory #javascript
> {noformat}
> Such a service file is not parsed properly and following exception is thrown
> {noformat}
> 2015-11-30 11:23:58.375 ERROR 23215 --- [ixDispatchQueue] 
> o.a.f.webconsole.plugins.scriptconsole   : Cannot register 
> ScriptEngineFactory com.sun.script.javascript.RhinoScriptEngineFactory 
> #javascript (java.lang.ClassNotFoundException: 
> com.sun.script.javascript.RhinoScriptEngineFactory #javascript)
> java.lang.ClassNotFoundException: 
> com.sun.script.javascript.RhinoScriptEngineFactory #javascript
> at java.net.URLClassLoader$1.run(URLClassLoader.java:366) 
> ~[na:1.7.0_55]
> at java.net.URLClassLoader$1.run(URLClassLoader.java:355) 
> ~[na:1.7.0_55]
> at java.security.AccessController.doPrivileged(Native Method) 
> ~[na:1.7.0_55]
> at java.net.URLClassLoader.findClass(URLClassLoader.java:354) 
> ~[na:1.7.0_55]
> at java.lang.ClassLoader.loadClass(ClassLoader.java:425) 
> ~[na:1.7.0_55]
> at java.lang.ClassLoader.loadClass(ClassLoader.java:358) 
> ~[na:1.7.0_55]
> at 
> org.apache.felix.connect.PojoSRBundle.loadClass(PojoSRBundle.java:451) 
> ~[org.apache.felix.connect-0.1.0.jar:na]
> at 
> org.apache.felix.webconsole.plugins.scriptconsole.internal.ScriptEngineManager.registerFactories(ScriptEngineManager.java:197)
>  [org.apache.felix.webconsole.plugins.scriptconsole-1.0.0.jar:na]
> at 
> org.apache.felix.webconsole.plugins.scriptconsole.internal.ScriptEngineManager.refreshScriptEngineManager(ScriptEngineManager.java:160)
>  [org.apache.felix.webconsole.plugins.scriptconsole-1.0.0.jar:na]
> at 
> org.apache.felix.webconsole.plugins.scriptconsole.internal.ScriptEngineManager.bundleChanged(ScriptEngineManager.java:111)
>  [org.apache.felix.webconsole.plugins.scriptconsole-1.0.0.jar:na]
> at 
> org.apache.felix.connect.felix.framework.util.EventDispatcher.invokeBundleListenerCallback(EventDispatcher.java:821)
>  [org.apache.felix.connect-0.1.0.jar:na]
> at 
> org.apache.felix.connect.felix.framework.util.EventDispatcher.fireEventImmediately(EventDispatcher.java:771)
>  [org.apache.felix.connect-0.1.0.jar:na]
> at 
> org.apache.felix.connect.felix.framework.util.EventDispatcher.run(EventDispatcher.java:993)
>  [org.apache.felix.connect-0.1.0.jar:na]
> at 
> org.apache.felix.connect.felix.framework.util.EventDispatcher.access$000(EventDispatcher.java:52)
>  [org.apache.felix.connect-0.1.0.jar:na]
> at 
> org.apache.felix.connect.felix.framework.util.EventDispatcher$1.run(EventDispatcher.java:94)
>  [org.apache.felix.connect-0.1.0.jar:na]
> at java.lang.Thread.run(Thread.java:745) [na:1.7.0_55]
> {noformat}



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

[jira] [Resolved] (FELIX-5121) Script console build failing on latest trunk


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

Chetan Mehrotra resolved FELIX-5121.

Resolution: Fixed

Done in 1717198 

> Script console build failing on latest trunk
> 
>
> Key: FELIX-5121
> URL: https://issues.apache.org/jira/browse/FELIX-5121
> Project: Felix
>  Issue Type: Task
>  Components: Script Console Plugin
>    Reporter: Chetan Mehrotra
>    Assignee: Chetan Mehrotra
> Fix For: script-console-1.0.2
>
>
> Current trunk build is failing as exam-maven-plugin launch is not working 
> {noformat}
> [INFO] Failsafe report directory: 
> /home/chetanm/git/apache/felix/webconsole-plugins/script-console/target/failsafe-reports
> Error: Main method not found in class org.ops4j.pax.exam.spi.PaxExamRuntime, 
> please define the main method as:
>public static void main(String[] args)
> {noformat}
> Due to this the OSGi container is not launched



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

[jira] [Created] (FELIX-5122) Script console output cannot be copied

Chetan Mehrotra created FELIX-5122:
--

 Summary: Script console output cannot be copied
 Key: FELIX-5122
 URL: https://issues.apache.org/jira/browse/FELIX-5122
 Project: Felix
  Issue Type: Bug
  Components: Script Console Plugin
Affects Versions: script-console-1.0.0
Reporter: Chetan Mehrotra
Assignee: Chetan Mehrotra
 Fix For: script-console-1.0.2


Script console output cannot be copied.





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

[jira] [Resolved] (FELIX-5122) Script console output cannot be copied


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

Chetan Mehrotra resolved FELIX-5122.

Resolution: Fixed

Done with 1717220

> Script console output cannot be copied
> --
>
> Key: FELIX-5122
> URL: https://issues.apache.org/jira/browse/FELIX-5122
> Project: Felix
>  Issue Type: Bug
>  Components: Script Console Plugin
>Affects Versions: script-console-1.0.0
>    Reporter: Chetan Mehrotra
>Assignee: Chetan Mehrotra
> Fix For: script-console-1.0.2
>
>
> Script console output cannot be copied.



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

[jira] [Created] (FELIX-5121) Script console build failing on latest trunk

Chetan Mehrotra created FELIX-5121:
--

 Summary: Script console build failing on latest trunk
 Key: FELIX-5121
 URL: https://issues.apache.org/jira/browse/FELIX-5121
 Project: Felix
  Issue Type: Task
  Components: Script Console Plugin
Reporter: Chetan Mehrotra
Assignee: Chetan Mehrotra
 Fix For: script-console-1.0.2


Current trunk build is failing as exam-maven-plugin launch is not working 
{noformat}
[INFO] Failsafe report directory: 
/home/chetanm/git/apache/felix/webconsole-plugins/script-console/target/failsafe-reports
Error: Main method not found in class org.ops4j.pax.exam.spi.PaxExamRuntime, 
please define the main method as:
   public static void main(String[] args)
{noformat}

Due to this the OSGi container is not launched



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

[jira] [Resolved] (FELIX-5123) Script Console UI improvements


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

Chetan Mehrotra resolved FELIX-5123.

Resolution: Fixed

Done with 1717221

> Script Console UI improvements
> --
>
> Key: FELIX-5123
> URL: https://issues.apache.org/jira/browse/FELIX-5123
> Project: Felix
>  Issue Type: Improvement
>  Components: Script Console Plugin
>Affects Versions: script-console-1.0.0
>    Reporter: Chetan Mehrotra
>Assignee: Chetan Mehrotra
>Priority: Minor
> Fix For: script-console-1.0.2
>
>
> Following improvements need to be done to script console UI
> # Remove timeout on executed command
> # Drop the Language button



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

[VOTE] Release Apache Felix Script Console Plugin 1.0.2

2015-11-30 Thread Chetan Mehrotra

I would like to call a vote for a new web console release:
We fixed four issues:
https://issues.apache.org/jira/browse/FELIX/fixforversion/12324783

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

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

Please vote to approve this release:

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

Regards
Chetan Mehrotra

Re: [VOTE] Release Apache Felix Script Console Plugin 1.0.2

2015-11-30 Thread Chetan Mehrotra

+1 (non binding)

Chetan Mehrotra

[jira] [Resolved] (FELIX-5120) ScriptEngineManager not able to parse service file with comments at end of classname


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

Chetan Mehrotra resolved FELIX-5120.

Resolution: Fixed

Fixed with 1717206

> ScriptEngineManager not able to parse service file with comments at end of 
> classname
> 
>
> Key: FELIX-5120
> URL: https://issues.apache.org/jira/browse/FELIX-5120
> Project: Felix
>  Issue Type: Bug
>  Components: Script Console Plugin
>Affects Versions: script-console-1.0.0
>Reporter: Chetan Mehrotra
>    Assignee: Chetan Mehrotra
>Priority: Minor
> Fix For: script-console-1.0.2
>
>
> A service file can also have a comment like below like
> {noformat}
> #script engines supported
> com.sun.script.javascript.RhinoScriptEngineFactory #javascript
> {noformat}
> Such a service file is not parsed properly and following exception is thrown
> {noformat}
> 2015-11-30 11:23:58.375 ERROR 23215 --- [ixDispatchQueue] 
> o.a.f.webconsole.plugins.scriptconsole   : Cannot register 
> ScriptEngineFactory com.sun.script.javascript.RhinoScriptEngineFactory 
> #javascript (java.lang.ClassNotFoundException: 
> com.sun.script.javascript.RhinoScriptEngineFactory #javascript)
> java.lang.ClassNotFoundException: 
> com.sun.script.javascript.RhinoScriptEngineFactory #javascript
> at java.net.URLClassLoader$1.run(URLClassLoader.java:366) 
> ~[na:1.7.0_55]
> at java.net.URLClassLoader$1.run(URLClassLoader.java:355) 
> ~[na:1.7.0_55]
> at java.security.AccessController.doPrivileged(Native Method) 
> ~[na:1.7.0_55]
> at java.net.URLClassLoader.findClass(URLClassLoader.java:354) 
> ~[na:1.7.0_55]
> at java.lang.ClassLoader.loadClass(ClassLoader.java:425) 
> ~[na:1.7.0_55]
> at java.lang.ClassLoader.loadClass(ClassLoader.java:358) 
> ~[na:1.7.0_55]
> at 
> org.apache.felix.connect.PojoSRBundle.loadClass(PojoSRBundle.java:451) 
> ~[org.apache.felix.connect-0.1.0.jar:na]
> at 
> org.apache.felix.webconsole.plugins.scriptconsole.internal.ScriptEngineManager.registerFactories(ScriptEngineManager.java:197)
>  [org.apache.felix.webconsole.plugins.scriptconsole-1.0.0.jar:na]
> at 
> org.apache.felix.webconsole.plugins.scriptconsole.internal.ScriptEngineManager.refreshScriptEngineManager(ScriptEngineManager.java:160)
>  [org.apache.felix.webconsole.plugins.scriptconsole-1.0.0.jar:na]
> at 
> org.apache.felix.webconsole.plugins.scriptconsole.internal.ScriptEngineManager.bundleChanged(ScriptEngineManager.java:111)
>  [org.apache.felix.webconsole.plugins.scriptconsole-1.0.0.jar:na]
> at 
> org.apache.felix.connect.felix.framework.util.EventDispatcher.invokeBundleListenerCallback(EventDispatcher.java:821)
>  [org.apache.felix.connect-0.1.0.jar:na]
> at 
> org.apache.felix.connect.felix.framework.util.EventDispatcher.fireEventImmediately(EventDispatcher.java:771)
>  [org.apache.felix.connect-0.1.0.jar:na]
> at 
> org.apache.felix.connect.felix.framework.util.EventDispatcher.run(EventDispatcher.java:993)
>  [org.apache.felix.connect-0.1.0.jar:na]
> at 
> org.apache.felix.connect.felix.framework.util.EventDispatcher.access$000(EventDispatcher.java:52)
>  [org.apache.felix.connect-0.1.0.jar:na]
> at 
> org.apache.felix.connect.felix.framework.util.EventDispatcher$1.run(EventDispatcher.java:94)
>  [org.apache.felix.connect-0.1.0.jar:na]
> at java.lang.Thread.run(Thread.java:745) [na:1.7.0_55]
> {noformat}



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

Re: [VOTE] Release Apache Felix JAAS Support 0.0.4

2015-11-30 Thread Chetan Mehrotra

+1 (non binding)
Chetan Mehrotra


On Mon, Nov 30, 2015 at 6:26 PM, Chetan Mehrotra <chet...@apache.org> wrote:
> I would like to call a vote for a new JAAS support release:
> We fixed three issues:
> https://issues.apache.org/jira/browse/FELIX/fixforversion/12333114
>
> Staging repositories:
> https://repository.apache.org/content/repositories/orgapachefelix-1107/
>
> 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 1107 /tmp/felix-staging
>
> Please vote to approve this release:
>
> [ ] +1 Approve the release
> [ ] -1 Veto the release (please provide specific comments)
>
> Regards
> Chetan Mehrotra

[jira] [Created] (FELIX-5123) Script Console UI improvements

Chetan Mehrotra created FELIX-5123:
--

 Summary: Script Console UI improvements
 Key: FELIX-5123
 URL: https://issues.apache.org/jira/browse/FELIX-5123
 Project: Felix
  Issue Type: Improvement
  Components: Script Console Plugin
Affects Versions: script-console-1.0.0
Reporter: Chetan Mehrotra
Assignee: Chetan Mehrotra
Priority: Minor
 Fix For: script-console-1.0.2


Following improvements need to be done to script console UI

# Remove timeout on executed command
# Drop the Language button



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

[VOTE] Release Apache Felix JAAS Support 0.0.4

2015-11-30 Thread Chetan Mehrotra

I would like to call a vote for a new JAAS support release:
We fixed three issues:
https://issues.apache.org/jira/browse/FELIX/fixforversion/12333114

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

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

Please vote to approve this release:

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

Regards
Chetan Mehrotra

[jira] [Resolved] (FELIX-3982) Allow usage of LoginModule present outside of OSGi space


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

Chetan Mehrotra resolved FELIX-3982.

Resolution: Later

Resolving for later for now as not seen need for such a feature for long time

> Allow usage of LoginModule present outside of OSGi space
> 
>
> Key: FELIX-3982
> URL: https://issues.apache.org/jira/browse/FELIX-3982
> Project: Felix
>  Issue Type: Improvement
>  Components: JAAS
>    Reporter: Chetan Mehrotra
>    Assignee: Chetan Mehrotra
>Priority: Minor
>
> The Sun JDK ships many LoginModule [1] out of the box. It should be possible 
> to use them within the OSGi
> [1] http://docs.oracle.com/javase/6/docs/jre/api/security/jaas/spec/index.html



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

[jira] [Resolved] (FELIX-4827) Improve logging on LoginModule registration


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

Chetan Mehrotra resolved FELIX-4827.

   Resolution: Fixed
Fix Version/s: jaas-0.0.4

Done in 1717186

> Improve logging on LoginModule registration
> ---
>
> Key: FELIX-4827
> URL: https://issues.apache.org/jira/browse/FELIX-4827
> Project: Felix
>  Issue Type: Bug
>  Components: JAAS
>Reporter: Alex Parvulescu
>    Assignee: Chetan Mehrotra
>Priority: Minor
> Fix For: jaas-0.0.4
>
>
> There's a space missing in the log message when registering a new LoginModule 
> [0], currently the log looks like the following:
> {code}
> 22.02.2015 03:03:28.256 *INFO* [FelixStartLevel] org.apache.felix.jaas 
> Registering LoginModule class 
> [org.apache.jackrabbit.oak.security.authentication.token.TokenLoginModule] 
> from Bundleorg.apache.jackrabbit.oak-core [85]
> {code}
> _from Bundleorg.apache.jackrabbit.oak-core_ -> _from Bundle 
> org.apache.jackrabbit.oak-core_
> [0] 
> https://github.com/apache/felix/blob/33f093d4862955286c3a37b0b1a01153821c50f3/jaas/src/main/java/org/apache/felix/jaas/internal/BundleLoginModuleCreator.java#L151



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

[jira] [Resolved] (FELIX-4978) Enable name hint for JAAS Config entries


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

Chetan Mehrotra resolved FELIX-4978.

Resolution: Duplicate

Resolving as duplicate for FELIX-5083 as that also has a patch provided

> Enable name hint for JAAS Config entries
> 
>
> Key: FELIX-4978
> URL: https://issues.apache.org/jira/browse/FELIX-4978
> Project: Felix
>  Issue Type: Improvement
>  Components: JAAS
>    Reporter: Chetan Mehrotra
>    Assignee: Chetan Mehrotra
>Priority: Minor
> Fix For: jaas-0.0.4
>
>
> the latest webconsole provides a feature to display name hints instead of 
> GUIDs for osgi factory configurations, which greatly enhances the usability 
> in the web console esp. when lots of factory configurations are defined 
> (FELIX-4710).
> for the JAAS we should define a name hint for the JAAS LoginModule Config



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

[jira] [Created] (FELIX-5120) ScriptEngineManager not able to parse service file with comments at end of classname

Chetan Mehrotra created FELIX-5120:
--

 Summary: ScriptEngineManager not able to parse service file with 
comments at end of classname
 Key: FELIX-5120
 URL: https://issues.apache.org/jira/browse/FELIX-5120
 Project: Felix
  Issue Type: Bug
  Components: Script Console Plugin
Affects Versions: script-console-1.0.0
Reporter: Chetan Mehrotra
Assignee: Chetan Mehrotra
Priority: Minor
 Fix For: script-console-1.0.2


A service file can also have a comment like below like

{noformat}
#script engines supported

com.sun.script.javascript.RhinoScriptEngineFactory #javascript
{noformat}

Such a service file is not parsed properly and following exception is thrown
{noformat}
2015-11-30 11:23:58.375 ERROR 23215 --- [ixDispatchQueue] 
o.a.f.webconsole.plugins.scriptconsole   : Cannot register ScriptEngineFactory 
com.sun.script.javascript.RhinoScriptEngineFactory #javascript 
(java.lang.ClassNotFoundException: 
com.sun.script.javascript.RhinoScriptEngineFactory #javascript)

java.lang.ClassNotFoundException: 
com.sun.script.javascript.RhinoScriptEngineFactory #javascript
at java.net.URLClassLoader$1.run(URLClassLoader.java:366) ~[na:1.7.0_55]
at java.net.URLClassLoader$1.run(URLClassLoader.java:355) ~[na:1.7.0_55]
at java.security.AccessController.doPrivileged(Native Method) 
~[na:1.7.0_55]
at java.net.URLClassLoader.findClass(URLClassLoader.java:354) 
~[na:1.7.0_55]
at java.lang.ClassLoader.loadClass(ClassLoader.java:425) ~[na:1.7.0_55]
at java.lang.ClassLoader.loadClass(ClassLoader.java:358) ~[na:1.7.0_55]
at 
org.apache.felix.connect.PojoSRBundle.loadClass(PojoSRBundle.java:451) 
~[org.apache.felix.connect-0.1.0.jar:na]
at 
org.apache.felix.webconsole.plugins.scriptconsole.internal.ScriptEngineManager.registerFactories(ScriptEngineManager.java:197)
 [org.apache.felix.webconsole.plugins.scriptconsole-1.0.0.jar:na]
at 
org.apache.felix.webconsole.plugins.scriptconsole.internal.ScriptEngineManager.refreshScriptEngineManager(ScriptEngineManager.java:160)
 [org.apache.felix.webconsole.plugins.scriptconsole-1.0.0.jar:na]
at 
org.apache.felix.webconsole.plugins.scriptconsole.internal.ScriptEngineManager.bundleChanged(ScriptEngineManager.java:111)
 [org.apache.felix.webconsole.plugins.scriptconsole-1.0.0.jar:na]
at 
org.apache.felix.connect.felix.framework.util.EventDispatcher.invokeBundleListenerCallback(EventDispatcher.java:821)
 [org.apache.felix.connect-0.1.0.jar:na]
at 
org.apache.felix.connect.felix.framework.util.EventDispatcher.fireEventImmediately(EventDispatcher.java:771)
 [org.apache.felix.connect-0.1.0.jar:na]
at 
org.apache.felix.connect.felix.framework.util.EventDispatcher.run(EventDispatcher.java:993)
 [org.apache.felix.connect-0.1.0.jar:na]
at 
org.apache.felix.connect.felix.framework.util.EventDispatcher.access$000(EventDispatcher.java:52)
 [org.apache.felix.connect-0.1.0.jar:na]
at 
org.apache.felix.connect.felix.framework.util.EventDispatcher$1.run(EventDispatcher.java:94)
 [org.apache.felix.connect-0.1.0.jar:na]
at java.lang.Thread.run(Thread.java:745) [na:1.7.0_55]
{noformat}



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

[jira] [Assigned] (FELIX-5083) Set webconsole.configurationFactory.nameHint for JAAS configurations


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

Chetan Mehrotra reassigned FELIX-5083:
--

Assignee: Chetan Mehrotra

> Set webconsole.configurationFactory.nameHint for JAAS configurations
> 
>
> Key: FELIX-5083
> URL: https://issues.apache.org/jira/browse/FELIX-5083
> Project: Felix
>  Issue Type: Improvement
>  Components: JAAS
>Affects Versions: jaas-0.0.2
>Reporter: Robert Munteanu
>Assignee: Chetan Mehrotra
>Priority: Minor
> Fix For: jaas-0.0.4
>
> Attachments: FELIX-5083.patch, FELIX-5083.png
>
>
> When working with multiple JAAS configuration in the Felix Web Console it's 
> hard to distinguish them.
> Setting the {{webconsole.configurationFactory.nameHint}} property to a 
> reasonable default removes this problem.



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

[jira] [Created] (FELIX-5119) Jaas module build fails with JDK 8

Chetan Mehrotra created FELIX-5119:
--

 Summary: Jaas module build fails with JDK 8
 Key: FELIX-5119
 URL: https://issues.apache.org/jira/browse/FELIX-5119
 Project: Felix
  Issue Type: Task
  Components: JAAS
Reporter: Chetan Mehrotra
Assignee: Chetan Mehrotra
 Fix For: jaas-0.0.4


Building trunk with JDK 8 fails with test failures

See http://markmail.org/message/2dvzkkawoe26bw7w



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

[jira] [Resolved] (FELIX-5083) Set webconsole.configurationFactory.nameHint for JAAS configurations


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

Chetan Mehrotra resolved FELIX-5083.

Resolution: Fixed

Thanks for the patch [~rombert]. Applied the part of patch related to 
{{JaasConfigFactory}} in 1717190

Opened FELIX-5119 to track build failure on JDK 1.8

> Set webconsole.configurationFactory.nameHint for JAAS configurations
> 
>
> Key: FELIX-5083
> URL: https://issues.apache.org/jira/browse/FELIX-5083
> Project: Felix
>  Issue Type: Improvement
>  Components: JAAS
>Affects Versions: jaas-0.0.2
>Reporter: Robert Munteanu
>Assignee: Chetan Mehrotra
>Priority: Minor
> Fix For: jaas-0.0.4
>
> Attachments: FELIX-5083.patch, FELIX-5083.png
>
>
> When working with multiple JAAS configuration in the Felix Web Console it's 
> hard to distinguish them.
> Setting the {{webconsole.configurationFactory.nameHint}} property to a 
> reasonable default removes this problem.



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

[jira] [Resolved] (FELIX-5119) Jaas module build fails with JDK 8


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

Chetan Mehrotra resolved FELIX-5119.

Resolution: Fixed

Updated the framework dependency to latest 5.4 so as to get test pass on JDK 
1.8 with 1717191. With this build passes for both JDK 1.7 and 1.8

[~rombert] Can you try again with latest trunk. For now I am resolving this 
issue. If some issue comes again it can be reopened

> Jaas module build fails with JDK 8
> --
>
> Key: FELIX-5119
> URL: https://issues.apache.org/jira/browse/FELIX-5119
> Project: Felix
>  Issue Type: Task
>  Components: JAAS
>    Reporter: Chetan Mehrotra
>    Assignee: Chetan Mehrotra
> Fix For: jaas-0.0.4
>
>
> Building trunk with JDK 8 fails with test failures
> See http://markmail.org/message/2dvzkkawoe26bw7w



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

Re: git?

2015-10-28 Thread Chetan Mehrotra

On Sat, Oct 24, 2015 at 11:50 PM, Marcel Offermans
 wrote:
> I’m +0 on making a switch because it’s also a lot of work and I don’t think 
> the benefits are huge. If it works, don’t fix it. :)

+1 to that. Side-line for me too.

SVN isn't that bad after all, and along with 'git svn' most of the
benefits of git (quick local branching/fast commit history etc) can be
realized locally by developers.

Not that imp but for me at times the linear progressing svn revision
feels more useful to determine if a particular CL made it to a
particular released.

Re: Building org.apache.felix.jaas fails

2015-10-25 Thread Chetan Mehrotra

Hi Robert,

Whats the mvn+java version you are using. I tried with latest trunk
and it build fine

mvn -v
Apache Maven 3.2.5 (12a6b3acb947671f09b81f49094c53f426d8cea1;
2014-12-14T22:59:23+05:30)
Maven home: xxx/apache-maven-3.2.5
Java version: 1.7.0_55, vendor: Oracle Corporation
Java home: xxx/jdk/jdk1.7.0_55/jre
Default locale: en_US, platform encoding: UTF-8
OS name: "linux", version: "3.13.0-37-generic", arch: "amd64", family: "unix"
Chetan Mehrotra


On Thu, Oct 22, 2015 at 2:58 PM, Robert Munteanu <romb...@apache.org> wrote:
> Hi,
>
> I tried to build the jaas module as of r1709963 . The build fails due
> to the animal-sniffer-maven-plugin:
>
> [INFO] Checking unresolved references to
> org.codehaus.mojo.signature:java15:1.0
> [ERROR]
> /home/robert/Documents/sources/apache/felix/jaas/src/main/java/org/apac
> he/felix/jaas/internal/ConfigSpiOsgi.java:117: Undefined reference:
> void javax.security.auth.login.ConfigurationSpi.()
> [ERROR]
> /home/robert/Documents/sources/apache/felix/jaas/src/main/java/org/apac
> he/felix/jaas/internal/ConfigSpiOsgi.java:147: Undefined reference:
> javax.security.auth.login.Configuration
> javax.security.auth.login.Configuration.getInstance(String,
> javax.security.auth.login.Configuration.Parameters, String)
>
> [ERROR]/home/robert/Documents/sources/apache/felix/jaas/src/main/java/o
> rg/apache/felix/jaas/internal/ConfigSpiOsgi.java:568: Undefined
> reference: Object[] java.util.Arrays.copyOf(Object[], int)
>
> I added the felix.java.version property with value 6 to the pom, and
> this allowed the build to progress. However, the Pax-Exam tests all
> fail, and the root error seems to be:
>
> ERROR: Bundle org.apache.felix.jaas.sample1 [21] Error starting
> file:/tmp/1445505936570-0/bundles/org.apache.felix.jaas.sample1_0.jar
>  (org.osgi.framework.BundleException: Unresolved constraint in bundle
> org.apache.felix.jaas.sample1 [21]: Unable to resolve 21.0: mis
> sing requirement [21.0] osgi.wiring.package;
> (osgi.wiring.package=javax.security.auth))
>
> org.osgi.framework.BundleException: Unresolved constraint in bundle
> org.apache.felix.jaas.sample1 [21]: Unable to resolve 21.0: missi
> ng requirement [21.0] osgi.wiring.package;
> (osgi.wiring.package=javax.security.auth)
> at
> org.apache.felix.framework.Felix.resolveBundleRevision(Felix.java:3826)
> at
> org.apache.felix.framework.Felix.startBundle(Felix.java:1868)
> at
> org.apache.felix.framework.Felix.setActiveStartLevel(Felix.java:1191)
> at
> org.apache.felix.framework.FrameworkStartLevelImpl.run(FrameworkStartLe
> velImpl.java:295)
> at java.lang.Thread.run(Thread.java:745)
>
> Is there anything more I should look into or is this a bug?
>
> Thanks,
>
> Robert
>

[jira] [Created] (FELIX-4978) Enable name hint for JAAS Config entries

2015-07-29 Thread Chetan Mehrotra (JIRA)

Chetan Mehrotra created FELIX-4978:
--

 Summary: Enable name hint for JAAS Config entries
 Key: FELIX-4978
 URL: https://issues.apache.org/jira/browse/FELIX-4978
 Project: Felix
  Issue Type: Improvement
  Components: JAAS
Reporter: Chetan Mehrotra
Assignee: Chetan Mehrotra
Priority: Minor
 Fix For: jaas-0.0.4


the latest webconsole provides a feature to display name hints instead of GUIDs 
for osgi factory configurations, which greatly enhances the usability in the 
web console esp. when lots of factory configurations are defined (FELIX-4710).

for the JAAS we should define a name hint for the JAAS LoginModule Config



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

Re: svn commit: r1691137 - in /felix/trunk/framework/src: main/java/org/apache/felix/framework/BundleRevisionImpl.java test/java/org/apache/felix/framework/BundleRevisionImplTest.java

2015-07-15 Thread Chetan Mehrotra

Hi David,

On Wed, Jul 15, 2015 at 1:14 PM,  dav...@apache.org wrote:
 +if (contentPath == null)
 +return Collections.emptyEnumeration();

This method is JDK 1.7+

Chetan Mehrotra

Re: [VOTE] Release Apache Felix Connect 0.1.0 (2nd cut)

2015-05-28 Thread Chetan Mehrotra

+1 (non-binding)

Chetan Mehrotra

On Fri, May 22, 2015 at 1:02 PM, Guillaume Nodet gno...@apache.org wrote:
 I've cut another release of Felix Connect 0.1.0
   http://svn.apache.org/repos/asf/felix/releases/org.apache.felix.connect
 -0.1.0/

 This new attempt fixes FELIX-4901 and FELIX-4903.

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

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

 Please vote to approve this release:

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

 Cheers,
 Guillaume Nodet

Re: [VOTE] Release Apache Felix Connect 0.1.0

2015-05-18 Thread Chetan Mehrotra

All checks passed
+1 (non binding)

Chetan Mehrotra

Re: Apache Felix Connect release

2015-05-18 Thread Chetan Mehrotra

Thanks Guillaume and Karl for looking into this!. Makes sense to do a
release now and then later do the enhancements
Chetan Mehrotra


On Mon, May 18, 2015 at 6:07 PM, Guillaume Nodet gno...@apache.org wrote:
 The Karaf team is is need for a release for a few tests, so I'll go ahead
 and do it today.

 2015-05-18 13:56 GMT+02:00 Karl Pauls karlpa...@gmail.com:

 Hi Chetan,

 I don't think we ended-up doing a release but probably should have. It
 looks like there is some renewed interested in PojoSR/connect so we
 probably should do a release now and then maybe look into updating to the
 latest OSGi APIs as well as maybe syncing with the latest service registry
 (as soon as development has stabilized in that area).

 Would you (or maybe somebody else) be interested in doing the release
 (Otherwise, I might try to get one done but i can't promise when)?

 regards,

 Karl

 p.s.: If you haven't done so, maybe you'd also like to apply your
 FELIX-4522
 https://issues.apache.org/jira/browse/FELIX-4522 patch.

 On Tue, May 12, 2015 at 5:36 PM, Chetan Mehrotra 
 chetan.mehro...@gmail.com
 wrote:

  Hi,
 
  Are there any plans to cut a release of Apache Felix Connect module?
  Anything in works or pending.
 
  In not then it would be good if we can have a first release done for
  this module!
 
  Chetan Mehrotra
  [1] https://github.com/apache/felix/blob/trunk/connect/
 



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

Apache Felix Connect release

2015-05-12 Thread Chetan Mehrotra

Hi,

Are there any plans to cut a release of Apache Felix Connect module?
Anything in works or pending.

In not then it would be good if we can have a first release done for
this module!

Chetan Mehrotra
[1] https://github.com/apache/felix/blob/trunk/connect/

[jira] [Assigned] (FELIX-4827) Improve logging on LoginModule registration

2015-03-09 Thread Chetan Mehrotra (JIRA)


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

Chetan Mehrotra reassigned FELIX-4827:
--

Assignee: Chetan Mehrotra

 Improve logging on LoginModule registration
 ---

 Key: FELIX-4827
 URL: https://issues.apache.org/jira/browse/FELIX-4827
 Project: Felix
  Issue Type: Bug
  Components: JAAS
Reporter: Alex Parvulescu
Assignee: Chetan Mehrotra
Priority: Minor

 There's a space missing in the log message when registering a new LoginModule 
 [0], currently the log looks like the following:
 {code}
 22.02.2015 03:03:28.256 *INFO* [FelixStartLevel] org.apache.felix.jaas 
 Registering LoginModule class 
 [org.apache.jackrabbit.oak.security.authentication.token.TokenLoginModule] 
 from Bundleorg.apache.jackrabbit.oak-core [85]
 {code}
 _from Bundleorg.apache.jackrabbit.oak-core_ - _from Bundle 
 org.apache.jackrabbit.oak-core_
 [0] 
 https://github.com/apache/felix/blob/33f093d4862955286c3a37b0b1a01153821c50f3/jaas/src/main/java/org/apache/felix/jaas/internal/BundleLoginModuleCreator.java#L151



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

[jira] [Commented] (FELIX-4599) Support Encryption Of Configuration Properties


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

Chetan Mehrotra commented on FELIX-4599:


Probably encryption part can be implemented via providing a ConfigurationPlugin 
[1]. However some API would still need to be defined which component can invoke 
to perform decryption

[1] 
http://www.osgi.org/javadoc/r4v42/org/osgi/service/cm/ConfigurationPlugin.html 

 Support Encryption Of Configuration Properties
 --

 Key: FELIX-4599
 URL: https://issues.apache.org/jira/browse/FELIX-4599
 Project: Felix
  Issue Type: New Feature
  Components: Configuration Admin
Reporter: Dominique Jäggi

 Currently it is not possible to define configuration properties, the contents 
 of which should be automatically encrypted upon save by the configuration 
 admin.
 An example would be a mail server configuration, where SMTP credentials must 
 specified and the password should be encrypted upon saving the configuration. 
 The encrypted password should then be accessible and decryptable in the 
 component to which the configuration is bound.



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

[jira] [Commented] (FELIX-4599) Support Encryption Of Configuration Properties


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

Chetan Mehrotra commented on FELIX-4599:


bq. The problem ConfigurationPlugin is that they only kick in when 
ConfigurationAdmin service is sending configuration ManagedService[Factory] 
services

Somehow I read it in reverse way i.e. its called when config is saved. In that 
case then probably some new extension points can be defined in Felix 
ConfigAdmin implementation (and possibly later added to actual spec!)

 Support Encryption Of Configuration Properties
 --

 Key: FELIX-4599
 URL: https://issues.apache.org/jira/browse/FELIX-4599
 Project: Felix
  Issue Type: New Feature
  Components: Configuration Admin
Reporter: Dominique Jäggi

 Currently it is not possible to define configuration properties, the contents 
 of which should be automatically encrypted upon save by the configuration 
 admin.
 An example would be a mail server configuration, where SMTP credentials must 
 specified and the password should be encrypted upon saving the configuration. 
 The encrypted password should then be accessible and decryptable in the 
 component to which the configuration is bound.



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

[jira] [Commented] (FELIX-4599) Support Encryption Of Configuration Properties


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

Chetan Mehrotra commented on FELIX-4599:


{quote}
From this I deduct two requirements:

# sensitive information should not be put in plain text to disk
# sensitive information should not be visible to any user in plain text (web 
console, JMX etc.)
{quote}

+1  probably we can support both. 

Requirement #1 is easy as that can be done in a central place by expose some 
extension point in {{FilePersistenceManager}} or providing an 
{{EncryptingPersistenceManager}} wrapper for 
[PersistenceManager|https://github.com/apache/felix/blob/trunk/configadmin/src/main/java/org/apache/felix/cm/PersistenceManager.java]

Requirement #2 is would involve new api and co-operation from client bundles 
who consume the config to make use of the API to decrypt config



 Support Encryption Of Configuration Properties
 --

 Key: FELIX-4599
 URL: https://issues.apache.org/jira/browse/FELIX-4599
 Project: Felix
  Issue Type: New Feature
  Components: Configuration Admin
Reporter: Dominique Jäggi

 Currently it is not possible to define configuration properties, the contents 
 of which should be automatically encrypted upon save by the configuration 
 admin.
 An example would be a mail server configuration, where SMTP credentials must 
 specified and the password should be encrypted upon saving the configuration. 
 The encrypted password should then be accessible and decryptable in the 
 component to which the configuration is bound.



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

[jira] [Commented] (FELIX-4599) Support Encryption Of Configuration Properties


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

Chetan Mehrotra commented on FELIX-4599:


bq. another option is that the config admin simply writes all properties 
encrypted to disk and decrypts on reading

One possible problem would be that components like Config WebConsole plugin or 
JMX Access can reveal the plain text secrets. We would need to have filtering 
applied at those layers. One can say that if someone has access to 
JMX/WebConsole then he can extract info via other means (deploy a custom 
bundle). However what i want to avoid is accedental leakage of such data by an 
administrator who can be asked to provide a dump of configuration status. As of 
now he cannot provide the dump without redacting sensitive config values

 Support Encryption Of Configuration Properties
 --

 Key: FELIX-4599
 URL: https://issues.apache.org/jira/browse/FELIX-4599
 Project: Felix
  Issue Type: New Feature
  Components: Configuration Admin
Reporter: Dominique Jäggi

 Currently it is not possible to define configuration properties, the contents 
 of which should be automatically encrypted upon save by the configuration 
 admin.
 An example would be a mail server configuration, where SMTP credentials must 
 specified and the password should be encrypted upon saving the configuration. 
 The encrypted password should then be accessible and decryptable in the 
 component to which the configuration is bound.



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

Re: [VOTE] Release Apache Felix Http 2.4.0

2015-02-01 Thread Chetan Mehrotra

+1 (non-binding)
Chetan Mehrotra


On Sun, Feb 1, 2015 at 9:55 PM, Pierre De Rop pierre.de...@gmail.com wrote:
 +1

 regards;
 /Pierre

 On Thu, Jan 29, 2015 at 1:51 PM, Carsten Ziegeler cziege...@apache.org
 wrote:

 Hi,

 We solved 3 issues in this release, the most important one is the update
 to Jetty 9

 https://issues.apache.org/jira/browse/FELIX/fixforversion/12327075

 This release includes only the changed modules compared to the 2.3.2
 release.

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

 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 1051 /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 at least 72 hours.

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

Re: Upgrading to Jetty 9

2014-07-28 Thread Chetan Mehrotra

Couple of points wrt Jetty 9 upgrade changes

- Jetty9 API Changes - Jetty 9 API has changed significantly from 8.x
hence it would not be possible to create two jars from same project
- Java 7 requirement - Jetty 9 requires Java 7 for compilation

Given that changing the symbolic name would cause extra work for users
when upgrading the HTTP bundle it would be helpful to retain the
bundle symbolic name. Based on suggestions above I think we can do
following

- Branch the current code in jetty module [1] at same level say
http://svn.apache.org/repos/asf/felix/trunk/http/jetty9. So kind of
branching but instead of branching to felix/branches we branch
locally. Otherwise we can also create a branch at [2].
- Retain the Bundle-SymbolicName but bump the major version to 3.0.x
- Future releases from current jetty module would stick to 2.x series
while from Jetty9 would be 3.x series
- Changes other than those in jetty and itest module can be done in
compatible way. So those module should be able to work with both
Jetty8 and Jetty9

If we have an agreement there I can rework the patch in FELIX-4550

Chetan Mehrotra
[1] http://svn.apache.org/repos/asf/felix/trunk/http/jetty/
[2] http://svn.apache.org/repos/asf/felix/branches/http/jetty


On Mon, Jul 28, 2014 at 4:30 PM, Marcel Offermans
marcel.offerm...@luminis.eu wrote:
 I agree with the general sentiment that we need to keep moving forward, 
 supporting the latest version of Jetty.

 Personally, I'm not sure if an open source project should keep maintaining 
 releases that run on Java versions that are no longer supported themselves, 
 but this is a broader discussion and I guess if there are enough people here 
 that care, then we have a good argument to do so.

 That said, if we keep two branches, I would like to suggest that we create 
 bundles with *different* symbolic names, instead of trying to maintain both 
 forks within the same bundle version range. Since the Jetty 9 effort is new, 
 I suggest we choose a new symbolic name for it and keep the existing one for 
 the Java 6 compatible fork.

 Greetings, Marcel

 
 From: paul.bakker...@gmail.com paul.bakker...@gmail.com on behalf of Paul 
 Bakker paul.bak...@luminis.eu
 Sent: Monday, July 28, 2014 9:16 AM
 To: dev@felix.apache.org
 Subject: Re: Upgrading to Jetty 9

 A major version bump is justified when the bundle doesn't work in
 environments that previously did work. Note that we're talking about the
 bundle version, not about package versions. Even the last release (2.3.0)
 should have been a major bump; it now requires extra bundles to be
 installed containing APIs, so existing configurations did not longer work.
 The version number should warn users if the update is a simple drop-in
 replacement or that other changes might be required.

 I would be in favour of branching. The Java 6 supported version only gets
 maintenance updates, while new development continues on Jetty 9. This way
 developers on Java 6 are not forced to upgrade, but new development is not
 complicated or limited by the fact that an older version still should be
 supported.

 Cheers,

 Paul


 On Mon, Jul 28, 2014 at 8:35 AM, Felix Meschberger fmesc...@adobe.com
 wrote:

 Hi

 The question really is whether the _internal_ upgrade of the Jetty bundle
 to Jetty 9 really is a major change for the Http Service functionality ?

 Backwards compatibility is not expected to be hampered. The only
 difference, apart from the new features offered potentially by Jetty 9,
 such as javax.websockets API support, is that the bundle now requires Java
 7. And I am not really sure, whether an updated requirement really warrants
 going to the next major version.

 I know dropping Java 6 support is a problem in some cases, but hey, the
 world keeps on spinning :-)

 If possible, I'd rather create two artifacts from the same project, if at
 all possible: One embedding Jetty 8 (supporting Java 6) and one embedding
 Jetty 9 (requiring Java 7).

 WDYT ?

 Regards
 Felix

 Am 25.07.2014 um 19:29 schrieb Tobias Bocanegra tri...@apache.org:

  Hi,
 
  there is an issue that deals with upgrading jetty to 9.x [0]. As it
  requires java 7, it is not a trivial update. basically the question
  is:
 
  - create 2 bundles: org.apache.felix.http.[jetty8|jetty9]
  - or update the maven artifact version to 3.0.0 (from 2.4.x)
 
  I would tend to the later
  regards, toby
 
  [0] https://issues.apache.org/jira/browse/FELIX-4550

Re: [patch] trivial typo in AbstractBaselinePlugin

2014-07-28 Thread Chetan Mehrotra

Thanks Bertrand. Applied with http://svn.apache.org/r1614256 (Reminder
for me - Need to be careful for imports reordering next time!)
Chetan Mehrotra


On Mon, Jul 28, 2014 at 7:34 PM, Bertrand Delacretaz
bdelacre...@apache.org wrote:
 Hi,

 I'm too lazy to create a jira on that one, find patch below.

 -Bertrand


 Index: 
 bundleplugin/src/main/java/org/apache/felix/bundleplugin/baseline/AbstractBaselinePlugin.java
 ===
 --- 
 bundleplugin/src/main/java/org/apache/felix/bundleplugin/baseline/AbstractBaselinePlugin.java
 (revision 1614033)
 +++ 
 bundleplugin/src/main/java/org/apache/felix/bundleplugin/baseline/AbstractBaselinePlugin.java
 (working copy)
 @@ -336,7 +336,7 @@
  }
  }

 -getLog().info( String.format( Baseline analisys complete, %s
 error(s), %s warning(s),
 +getLog().info( String.format( Baseline analysis complete, %s
 error(s), %s warning(s),
reporter.getErrors().size(),
reporter.getWarnings().size() ) );

Re: my first release ...

2014-07-12 Thread Chetan Mehrotra

On Sat, Jul 12, 2014 at 4:02 AM, Pierre De Rop pierre.de...@gmail.com
wrote:

 svn: E160006: No such revision 1609847


Have a look at [1] where Jan Willem Janssen also faced similar issue while
releasing Felix HTTP. Suggested solution was to wait for sometime and then
release again! Quoting from the thread

---

If you're located in Europe then release:prepare may fail with 'Unable to
tag SCM' and ' svn: No such revision X '. Wait 10 seconds and run mvn
release:prepare again.

Might be a svn lagging issue [0]. Try again ;)

---

Chetan Mehrotra
[1] http://markmail.org/message/gmin3n3bcddz2wlf

[jira] [Commented] (FELIX-4550) Upgrade embedded Jetty to version 9.2.x in Felix Http Jetty

2014-07-07 Thread Chetan Mehrotra (JIRA)


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

Chetan Mehrotra commented on FELIX-4550:


bq. I don't want to get into a long discussion, but what about making this a 
little bit pluggable, so we end up with two versions, one with Jetty8 and one 
with Jetty9?

Ack. Can rework the patch for that. So what should be the way? One way I can 
think of

* Create a new sibling module with artifactId org.apache.felix.http.jetty9
* Do not update the version in parent pom. Instead use separate profile where 
Jetty9 has to be used and tested
* ConnectorFactory - Instead of changing existing interface introduce a new one 
ConnectorFactory2 which takes Server instance such that same itest can be run 
against both
* For Servlet API bundle I think it would be fine to export it new 3.1 packages 
as I do not expect much change in previously released API bundle

Would that be ok?


 Upgrade embedded Jetty to version 9.2.x in Felix Http Jetty
 ---

 Key: FELIX-4550
 URL: https://issues.apache.org/jira/browse/FELIX-4550
 Project: Felix
  Issue Type: New Feature
  Components: HTTP Service
Reporter: Chetan Mehrotra
 Attachments: FELIX-4550.patch


 Currently HTTP Service embeds Jetty 8.1.14.v20131031 which supports Servlet 
 3.0. Current Jetty version 9.2.1.v20140609 supports Servlet 3.1 which 
 provided access to some new NIO based features. Further it also provides lots 
 of new features like Spdy support , Websocket support etc [1]
 [1] https://webtide.com/jetty-9-features/



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Created] (FELIX-4550) Upgrade embedded Jetty to version 9.2.x in Felix Http Jetty

2014-07-05 Thread Chetan Mehrotra (JIRA)

Chetan Mehrotra created FELIX-4550:
--

 Summary: Upgrade embedded Jetty to version 9.2.x in Felix Http 
Jetty
 Key: FELIX-4550
 URL: https://issues.apache.org/jira/browse/FELIX-4550
 Project: Felix
  Issue Type: New Feature
  Components: HTTP Service
Reporter: Chetan Mehrotra


Currently HTTP Service embeds Jetty 8.1.14.v20131031 which supports Servlet 
3.0. Current Jetty version 9.2.1.v20140609 supports Servlet 3.1 which provided 
access to some new NIO based features. Further it also provides lots of new 
features like Spdy support , Websocket support etc [1]

[1] https://webtide.com/jetty-9-features/





--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (FELIX-4550) Upgrade embedded Jetty to version 9.2.x in Felix Http Jetty

2014-07-05 Thread Chetan Mehrotra (JIRA)


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

Chetan Mehrotra updated FELIX-4550:
---

Attachment: FELIX-4550.patch

[patch|^FELIX-4550.patch] for the same. Following are some key points wrt patch

* Upgrade Jetty to 9.2.1.v20140609
* Changed the source and target compiler settings for jetty module to 1.7
* Updated the Servlet API to tomcat-servlet-api:8.0.9 to include 3.1. The 
org.apache.felix.http.servlet-api bundle now also export Servlet API at 3.1
* Some classes which implement servlet api modified to support new method
** SSLFilterResponseTest
** ServletContextImpl
** ServletContextImplTest
* FilterHandler - Had to change the if condition in doHandle as by default 
jetty does not set status to 200 at start 
([commit|http://dev.eclipse.org/mhonarc/lists/jetty-commit/msg05356.html]). 
Upto Jetty 8.x this was set to 200 at start of request itself but now it is 
being set at time of commit
* JettyService - The way jetty get configured now change quite a bit. Most of 
the previous config are mapped to new methods. One thing left out was support 
JMX registration

*Non Compatible Change*
* Jetty 9 requires JDK 7
* ConnectorFactory - Need to change the method createConnector() to 
createConnector(Server) as all Connector now require Server as part of 
Constructor argument. Anyways as the Connector classes itself have changed in 
non compatible way existing impls would not work

With this patch all existing test case pass. Also tried in some of our projects 
(Apache Sling) and server seem to work fine. 

 Upgrade embedded Jetty to version 9.2.x in Felix Http Jetty
 ---

 Key: FELIX-4550
 URL: https://issues.apache.org/jira/browse/FELIX-4550
 Project: Felix
  Issue Type: New Feature
  Components: HTTP Service
Reporter: Chetan Mehrotra
 Attachments: FELIX-4550.patch


 Currently HTTP Service embeds Jetty 8.1.14.v20131031 which supports Servlet 
 3.0. Current Jetty version 9.2.1.v20140609 supports Servlet 3.1 which 
 provided access to some new NIO based features. Further it also provides lots 
 of new features like Spdy support , Websocket support etc [1]
 [1] https://webtide.com/jetty-9-features/



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Comment Edited] (FELIX-4550) Upgrade embedded Jetty to version 9.2.x in Felix Http Jetty

2014-07-05 Thread Chetan Mehrotra (JIRA)

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

Chetan Mehrotra edited comment on FELIX-4550 at 7/5/14 9:16 AM:

[patch|^FELIX-4550.patch] for the same. Following are some key points wrt patch

* Upgrade Jetty to 9.2.1.v20140609
* Changed the source and target compiler settings for jetty module to 1.7
* Updated the Servlet API to tomcat-servlet-api:8.0.9 to include 3.1. The
org.apache.felix.http.servlet-api bundle now also export Servlet API at 3.1
* Some classes which implement servlet api modified to support new method
** SSLFilterResponseTest
** ServletContextImpl
** ServletContextImplTest
* FilterHandler - Had to change the if condition in doHandle as by default
jetty does not set status to 200 at start
([commit|http://dev.eclipse.org/mhonarc/lists/jetty-commit/msg05356.html]).
Upto Jetty 8.x this was set to 200 at start of request itself but now it is
being set at time of commit. Further the [Servet
API|http://download.oracle.com/javaee/6/api/javax/servlet/http/HttpServletResponse.html#getStatus%28%29]
does not say anything about the status code value
* JettyService - The way jetty get configured now change quite a bit. Most of
the previous config are mapped to new methods. One thing left out was making
JMX registration configurable. Currently JMX reg would be done always

*Non Compatible Change*
* Jetty 9 requires JDK 7
* ConnectorFactory - Need to change the method createConnector() to
createConnector(Server) as all Connector now require Server as part of
Constructor argument. Anyways as the Connector classes itself have changed in
non compatible way existing impls would not work

With this patch all existing test case pass. Also tried in some of our projects
(Apache Sling) and server seem to work fine.

was (Author: chetanm):
[patch|^FELIX-4550.patch] for the same. Following are some key points wrt patch

* Upgrade Jetty to 9.2.1.v20140609
* Changed the source and target compiler settings for jetty module to 1.7
* Updated the Servlet API to tomcat-servlet-api:8.0.9 to include 3.1. The
org.apache.felix.http.servlet-api bundle now also export Servlet API at 3.1
* Some classes which implement servlet api modified to support new method
** SSLFilterResponseTest
** ServletContextImpl
** ServletContextImplTest
* FilterHandler - Had to change the if condition in doHandle as by default
jetty does not set status to 200 at start
([commit|http://dev.eclipse.org/mhonarc/lists/jetty-commit/msg05356.html]).
Upto Jetty 8.x this was set to 200 at start of request itself but now it is
being set at time of commit
* JettyService - The way jetty get configured now change quite a bit. Most of
the previous config are mapped to new methods. One thing left out was support
JMX registration

With this patch all existing test case pass. Also tried in some of our projects
(Apache Sling) and server seem to work fine.

Upgrade embedded Jetty to version 9.2.x in Felix Http Jetty
---

Key: FELIX-4550
URL: https://issues.apache.org/jira/browse/FELIX-4550
Project: Felix
Issue Type: New Feature
Components: HTTP Service
Reporter: Chetan Mehrotra
Attachments: FELIX-4550.patch

Currently HTTP Service embeds Jetty 8.1.14.v20131031 which supports Servlet
3.0. Current Jetty version 9.2.1.v20140609 supports Servlet 3.1 which
provided access to some new NIO based features. Further it also provides lots
of new features like Spdy support , Websocket support etc [1]
[1] https://webtide.com/jetty-9-features/

--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (FELIX-4420) [HTTP SSLFilter] Implement sendRedirect

2014-06-26 Thread Chetan Mehrotra (JIRA)

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

Chetan Mehrotra commented on FELIX-4420:

bq. I'm not to sure about the suggested fix, as it tightly couples the
SslFilter to Jetty

Agreed. Note that Jetty usage is optional. Other features would work in non
Jetty case

bq. I think it can be solved in a generic way by going back to the original
proposed solution: override sendRedirect() (and possibly sendHeader() as well,
for implementations that directly try to set redirect locations) and change the
redirect URL on the fly

That would be the right way. The rational for suggesting the Jetty solution was

# The sendRedirect method does a bit of preprocessing as can be seen in case of
Jetty [1] and Tomcat [2] and they might differ. How it is done in other servers
like Websphere, Weblogic etc is not clear. Also one need to take care of
encoding etc. So we have to be careful there that required compatibility is
maintained
# Our primary requirement is while running with Jetty based Felix !!

Probably we can take a middle path. For the cases where we can use some native
support like Jetty we make use of that. Otherwise we fallback to creating
required url in SslResponse itself as you suggested.

[1]
https://github.com/eclipse/jetty.project/blob/master/jetty-server/src/main/java/org/eclipse/jetty/server/Response.java#L671
[2]
https://github.com/apache/tomcat/blob/trunk/java/org/apache/catalina/connector/Response.java#L1242-1274

[HTTP SSLFilter] Implement sendRedirect
---

Key: FELIX-4420
URL: https://issues.apache.org/jira/browse/FELIX-4420
Project: Felix
Issue Type: Improvement
Components: HTTP Service
Affects Versions: http-2.2.1, http-2.2.2
Reporter: Felix Meschberger
Assignee: J.W. Janssen
Fix For: http-next

Attachments: FELIX-4420-jetty.patch, FELIX-4420.patch

The HTTP SSL Filter service implemented in FELIX-3693 supports revealing the
actual protocol used by the client side browser by inspecting a request
header and exposing the proper scheme through its ServletRequest.getScheme()
implementation if the actual server is operated behind an SSL terminating
proxy (i.e. client connects with HTTPS to proxy, proxy forwards request to
server over plain HTTP)
The HttpServletRequest.sendRedirect() method is declared to set the Location
header to the absolute redirect URL which includes the scheme. In an SSL
terminating proxy situation, the servlet container does not know about this
fact and hence uses the actual server scheme (HTTP) for the redirect instead
of the scheme used by client.
To fix this situation the SSL filter response should implement the
HttpServletResponse.sendRedirect() method to use use the client side scheme
as extracted from the request instead of the actual server request.

--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (FELIX-4420) [HTTP SSLFilter] Implement sendRedirect

2014-06-25 Thread Chetan Mehrotra (JIRA)


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

Chetan Mehrotra commented on FELIX-4420:


Also I am not sure if the approach used would work. When using 
HttpServletResponseWrapper the original response is decorated. However if the 
actual  implementation of the HttpServletResponse internally invokes setHeader 
on sendRedirect that call would not be passed to the wrapper class. So probably 
setHeader would not be called in any case.

Now for Jetty case sendRedirect [1] internally calls setHeader(HttpHeader name, 
String value) so this solution would not work for Jetty case. The solution used 
are mostly server specific. For Jetty case [2] we can possibly do that via a 
custom HandlerCollection or 
org.eclipse.jetty.server.HttpConfiguration.Customizer.

[1] 
https://github.com/eclipse/jetty.project/blob/master/jetty-server/src/main/java/org/eclipse/jetty/server/Response.java#L671
[2] http://comments.gmane.org/gmane.comp.java.jetty.support/14561

 [HTTP SSLFilter] Implement sendRedirect
 ---

 Key: FELIX-4420
 URL: https://issues.apache.org/jira/browse/FELIX-4420
 Project: Felix
  Issue Type: Improvement
  Components: HTTP Service
Affects Versions: http-2.2.1, http-2.2.2
Reporter: Felix Meschberger
 Fix For: http-2.3.0, http-sslfilter-0.1.0

 Attachments: FELIX-4420.patch


 The HTTP SSL Filter service implemented in FELIX-3693 supports revealing the 
 actual protocol used by the client side browser by inspecting a request 
 header and exposing the proper scheme through its ServletRequest.getScheme() 
 implementation if the actual server is operated behind an SSL terminating 
 proxy (i.e. client connects with HTTPS to proxy, proxy forwards request to 
 server over plain HTTP)
 The HttpServletRequest.sendRedirect() method is declared to set the Location 
 header to the absolute redirect URL which includes the scheme. In an SSL 
 terminating proxy situation, the servlet container does not know about this 
 fact and hence uses the actual server scheme (HTTP) for the redirect instead 
 of the scheme used by client.
 To fix this situation the SSL filter response should implement the 
 HttpServletResponse.sendRedirect() method to use use the client side scheme 
 as extracted from the request instead of the actual server request.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (FELIX-4420) [HTTP SSLFilter] Implement sendRedirect

2014-06-25 Thread Chetan Mehrotra (JIRA)


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

Chetan Mehrotra updated FELIX-4420:
---

Attachment: FELIX-4420-jetty.patch

[~jajans] Testcase in attached patch fails if I comment out the new logic added 
in SslRequest.

SslRequest is updated with a possible fix for Jetty case where it checks if the 
underlying request is from Jetty then it changes the scheme. With that fix the 
testcase passes.

Kindly have a look at the patch!.

/cc [~fmeschbe]

 [HTTP SSLFilter] Implement sendRedirect
 ---

 Key: FELIX-4420
 URL: https://issues.apache.org/jira/browse/FELIX-4420
 Project: Felix
  Issue Type: Improvement
  Components: HTTP Service
Affects Versions: http-2.2.1, http-2.2.2
Reporter: Felix Meschberger
 Fix For: http-2.3.0, http-sslfilter-0.1.0

 Attachments: FELIX-4420-jetty.patch, FELIX-4420.patch


 The HTTP SSL Filter service implemented in FELIX-3693 supports revealing the 
 actual protocol used by the client side browser by inspecting a request 
 header and exposing the proper scheme through its ServletRequest.getScheme() 
 implementation if the actual server is operated behind an SSL terminating 
 proxy (i.e. client connects with HTTPS to proxy, proxy forwards request to 
 server over plain HTTP)
 The HttpServletRequest.sendRedirect() method is declared to set the Location 
 header to the absolute redirect URL which includes the scheme. In an SSL 
 terminating proxy situation, the servlet container does not know about this 
 fact and hence uses the actual server scheme (HTTP) for the redirect instead 
 of the scheme used by client.
 To fix this situation the SSL filter response should implement the 
 HttpServletResponse.sendRedirect() method to use use the client side scheme 
 as extracted from the request instead of the actual server request.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Created] (FELIX-4522) PojoSRBundleContext should read org.osgi.framework.storage property from Bundle config

2014-05-26 Thread Chetan Mehrotra (JIRA)

Chetan Mehrotra created FELIX-4522:
--

 Summary: PojoSRBundleContext should read 
org.osgi.framework.storage property from Bundle config
 Key: FELIX-4522
 URL: https://issues.apache.org/jira/browse/FELIX-4522
 Project: Felix
  Issue Type: Improvement
  Components: Connect
Reporter: Chetan Mehrotra
Assignee: Chetan Mehrotra
Priority: Minor
 Fix For: connect-0.1.0


{{PojoSRBundleContext}} currently read the value of 
{{org.osgi.framework.storage}} from system property. It would better (from 
isolation perspective) to read the value from the config map which is passed 
initially to {{PojoServiceRegistryFactory}}



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (FELIX-4522) PojoSRBundleContext should read org.osgi.framework.storage property from Bundle config

2014-05-26 Thread Chetan Mehrotra (JIRA)


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

Chetan Mehrotra updated FELIX-4522:
---

Attachment: FELIX-4522.patch

 PojoSRBundleContext should read org.osgi.framework.storage property from 
 Bundle config
 --

 Key: FELIX-4522
 URL: https://issues.apache.org/jira/browse/FELIX-4522
 Project: Felix
  Issue Type: Improvement
  Components: Connect
Reporter: Chetan Mehrotra
Assignee: Chetan Mehrotra
Priority: Minor
 Fix For: connect-0.1.0

 Attachments: FELIX-4522.patch


 {{PojoSRBundleContext}} currently read the value of 
 {{org.osgi.framework.storage}} from system property. It would better (from 
 isolation perspective) to read the value from the config map which is passed 
 initially to {{PojoServiceRegistryFactory}}



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (FELIX-4512) Add a new Mojo to invoke the BND Baseline tool

2014-05-11 Thread Chetan Mehrotra (JIRA)


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

Chetan Mehrotra commented on FELIX-4512:


[~jsedding] has dome something similar with the baselining-maven-plugin [1] 
which I came across with OAK-1536. Might be helpful in this context

[1] https://github.com/code-distillery/baselining-maven-plugin

 Add a new Mojo to invoke the BND Baseline tool
 --

 Key: FELIX-4512
 URL: https://issues.apache.org/jira/browse/FELIX-4512
 Project: Felix
  Issue Type: New Feature
  Components: Maven Bundle Plugin
Affects Versions: maven-bundle-plugin-2.4.0
Reporter: Simone Tripodi
 Fix For: maven-bundle-plugin-2.4.1

 Attachments: FELIX-4512.patch


 The BND 2.2.0 library contains an extraordinary tool called 
 [Baseline|http://www.aqute.biz/Bnd/Versioning] (see Baselining paragraph) 
 that compares the public API of a bundle with the public API of another 
 bundle.
 It would be really useful to have this tool in the {{maven-bundle-plugin}} in 
 order to keep track of APIs modifications during development time.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

Re: [HEADS UP] PojoSR in Felix

2014-03-31 Thread Chetan Mehrotra

Thanks Guillaume!

 FWIW, I think we should upgrade to OSGi 5.0 before releasing if it's not
 too much work.  Any volunteer ?

Probably we can do an interim dot release with new package name so
that existing users can migrate easily. I want to tweak/fix couple of
aspects and would try to provide patches.
Chetan Mehrotra


On Tue, Apr 1, 2014 at 1:20 AM, Karl Pauls karlpa...@gmail.com wrote:
 On Mon, Mar 31, 2014 at 9:28 PM, Guillaume Nodet gno...@apache.org wrote:

 Following up on the vote, I've done the IP clearance and committed PojoSR
 to the Felix trunk.
 I've also done a first pass on renaming it to Connect as discussed.
   http://svn.apache.org/repos/asf/felix/trunk/connect/


 Great - thanks for getting this done!



 I haven't done much testing after the refactoring of the packages, so it
 may have been broken while doing it.

 FWIW, I think we should upgrade to OSGi 5.0 before releasing if it's not
 too much work.  Any volunteer ?


 I probably will not find the time right now to look into doing the work
 myself - however, I'll try to answer questions if there are any.

 Furthermore, i think it will make sense to provide a bare version as well
 (i.e., one that doesn't bundle the osgi classes) - it is quite popular
 (about 50/50 in maven downloads).

 I'll wait a little to see if we get a release out quickly and then will put
 up an announcement on pojosr.googlecode.com that the project has moved.

 regards,

 Karl


 Happy hacking !

 Guillaume Nodet




 --
 Karl Pauls
 karlpa...@gmail.com
 http://twitter.com/karlpauls
 http://www.linkedin.com/in/karlpauls
 https://profiles.google.com/karlpauls

[jira] [Commented] (FELIX-4445) PojoSR donation

2014-03-30 Thread Chetan Mehrotra (JIRA)


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

Chetan Mehrotra commented on FELIX-4445:


Any update on the legal clearance. I see that LEGAL-194 is resolved and 
ip-clearence page refers to PojoSR [1] however the link points to Sling 
Replication one. The proper link I think is [2] which looks like the default 
template. 

[1] http://incubator.apache.org/ip-clearance/index.html
[2] http://incubator.apache.org/ip-clearance/felix-pojosr.html

 PojoSR donation
 ---

 Key: FELIX-4445
 URL: https://issues.apache.org/jira/browse/FELIX-4445
 Project: Felix
  Issue Type: Task
Reporter: Guillaume Nodet
Assignee: Guillaume Nodet
 Attachments: pojosr.zip






--
This message was sent by Atlassian JIRA
(v6.2#6252)

Re: Any plans to make PojoSR part of Apache Felix

2014-03-05 Thread Chetan Mehrotra

On Wed, Mar 5, 2014 at 6:13 PM, Karl Pauls karlpa...@gmail.com wrote:
 im more than willing to have PojoSR move to Felix - provided you (or
 somebody else) is willing to do the legwork. I guess we'll have to funnel it
 through the incubator ip clearance, rename the packages, and cut a release.
 If somebody volunteers to drive this then lets do it (and yes, I'm looking
 at you, Clement :-).

Thanks for the prompt response Karl ! The project is really useful for us.

As for the work involved I am willing to volunteer wherever possible. LGTM!!


Chetan Mehrotra

Re: [VOTE] Accept PojoSR code donation

2014-03-05 Thread Chetan Mehrotra

+1 (Non binding)

Chetan Mehrotra


On Wed, Mar 5, 2014 at 8:19 PM, Guillaume Nodet gno...@apache.org wrote:
 Karl Pauls is willing to donate PojoSR (https://code.google.com/p/pojosr/)
 to Felix.

 This vote is about officially accepting the donation.

 [ ] +1  Accept PojoSR code into Felix
 [ ] -1 Do not

 Cheers,
 Guillaume Nodet

Any plans to make PojoSR part of Apache Felix

2014-03-04 Thread Chetan Mehrotra

Hi,

Apologies for cross posting but as the subject is of common interest
to both group sending it to both groups

In Apache Jackrabbit Oak [1] we have inbuilt support for OSGi based
deployments. To reuse the logic for non OSGi env I was investigating
[2] PojoSR [3] and it looks pretty useful and most of the stuff works
out of the box without requiring any change.

Wanted to check if there were any thoughts on moving this project to
Apache Felix

Chetan Mehrotra
[1] http://jackrabbit.apache.org/oak/
[2] http://jackrabbit-oak.markmail.org/thread/7zpux64mj6vecwzf
[3] https://code.google.com/p/pojosr/

[VOTE RESULT] Release of Jaas Support Bundle 0.0.2

2014-02-16 Thread Chetan Mehrotra

The vote passed with

- three binding +1 votes from Felix Meschberger, Clement Escoffier,
Jan Willem Janssen
- one non-binding +1 votes from Tobias Bocanegra

Thanks everyone for voting

Regards
Chetan Mehrotra

[jira] [Closed] (FELIX-3984) Use default application/realm name of 'other' if none specified


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

Chetan Mehrotra closed FELIX-3984.
--


Closing the issue as 0.0.2 release is done

 Use default application/realm name of 'other' if none specified
 ---

 Key: FELIX-3984
 URL: https://issues.apache.org/jira/browse/FELIX-3984
 Project: Felix
  Issue Type: Improvement
  Components: JAAS
Affects Versions: jaas-0.0.2
Reporter: Chetan Mehrotra
Assignee: Chetan Mehrotra
Priority: Minor
 Fix For: jaas-0.0.2


 Any LoginModule registered via config or factory SHOULD provide a 
 realm/application name. However if none is specified then the realm name 
 should be assumed to be 'other'. 
 Following should be supported
 1. In case no realm name specified via 'jaas.realmName' the value should be 
 set to 'other'
 2. This default value can be changed by Admin via Configuration Spi settings 
 and set it to any other value
 The significance of using 'other' here is that LoginContext would first check 
 config entry for provided applicationName. If none is found then it looks for 
 config entry for an app name 'other'. So for default setup LoginModules which 
 does not have any appname specified would be considered as part of 'other'. 
 if the admin changes that then no such default logic would be used 



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Closed] (FELIX-3985) ConfigSpiOsgi should be registered by default


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

Chetan Mehrotra closed FELIX-3985.
--


Closing the issue as 0.0.2 release is done

 ConfigSpiOsgi should be registered by default 
 --

 Key: FELIX-3985
 URL: https://issues.apache.org/jira/browse/FELIX-3985
 Project: Felix
  Issue Type: Bug
  Components: JAAS
Reporter: Chetan Mehrotra
Assignee: Chetan Mehrotra
Priority: Minor
 Fix For: jaas-0.0.2


 ConfigSpiOsgi does not registers the Configuration unless a configuration is 
 explicitly provided for it. Instead it should register by default with a 
 default config. If config is updated it should update itself



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Closed] (FELIX-3705) Bundle to simplify JAAS usage in OSGi


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

Chetan Mehrotra closed FELIX-3705.
--


Closing the issue as 0.0.2 release is done

 Bundle to simplify JAAS usage in OSGi
 -

 Key: FELIX-3705
 URL: https://issues.apache.org/jira/browse/FELIX-3705
 Project: Felix
  Issue Type: New Feature
  Components: JAAS
Reporter: Chetan Mehrotra
Assignee: Felix Meschberger
Priority: Minor
 Fix For: jaas-0.0.2

 Attachments: org.apache.felix.jaas-0.0.1-SNAPSHOT-src.tar.gz, sha1.txt


 Bundle to simplify usage of JAAS within OSGi environment.
 It supports following features
 1. It can work both in Standalone and AppServer deployments i.e. in those 
 environment where global JAAS configuration might be used by other 
 applications and our usage of JAAS should not affect them 
 2. It enables usage of OSGi Configuration support to dynamically configure 
 the login modules. 
 3. It allows LoginModule instances to be created via factories registered in 
 OSGi Service Registry 
 4. It does not require the client to depend on any OSGi API 
 5. It works well with the dynamic nature of the OSGi env 6. Implementation 
 depends only on Core OSGi API and ConfigAdmin 
 Complete details are provided at [1]. Discussion thread on Felix dev mailing 
 list is at [2]
 [1] https://github.com/chetanmeh/c/wiki/JAAS-in-OSGi
 [2] http://markmail.org/thread/6k2lw6ieczyy5db2 



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Closed] (FELIX-3989) Add support for determining code coverage with integration testcases


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

Chetan Mehrotra closed FELIX-3989.
--


Closing the issue as 0.0.2 release is done

 Add support for determining code coverage with integration testcases
 

 Key: FELIX-3989
 URL: https://issues.apache.org/jira/browse/FELIX-3989
 Project: Felix
  Issue Type: Task
  Components: JAAS
Reporter: Chetan Mehrotra
Assignee: Chetan Mehrotra
Priority: Minor
 Fix For: jaas-0.0.2


 It would be good to have a report generated for determining the code coverage 
 of the integration test run by Pax Exam



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Closed] (FELIX-3983) Use inlined Sling commons PropertiesUtil for reading config values


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

Chetan Mehrotra closed FELIX-3983.
--


Closing the issue as 0.0.2 release is done

 Use inlined Sling commons PropertiesUtil for reading config values
 --

 Key: FELIX-3983
 URL: https://issues.apache.org/jira/browse/FELIX-3983
 Project: Felix
  Issue Type: Improvement
  Components: JAAS
Reporter: Chetan Mehrotra
Assignee: Chetan Mehrotra
Priority: Minor
 Fix For: jaas-0.0.2


 Currently the config processing logic uses copied code from Sling Commons 
 OSGi PropertiesUtils. Instead of that it should inline that class to avoid 
 copying and also avoid any dependency



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Closed] (FELIX-3998) Updating JAAS config leads to registration of duplicate LoginModules


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

Chetan Mehrotra closed FELIX-3998.
--


Closing the issue as 0.0.2 release is done

 Updating JAAS config leads to registration of duplicate LoginModules
 

 Key: FELIX-3998
 URL: https://issues.apache.org/jira/browse/FELIX-3998
 Project: Felix
  Issue Type: Bug
  Components: JAAS
Reporter: Chetan Mehrotra
Assignee: Chetan Mehrotra
 Fix For: jaas-0.0.2


 If the JAAS Config is updated then LoginModules backed by older config are 
 not deregistered. 



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Closed] (FELIX-3980) Add documentation related to usage of Felix JAAS Bundle


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

Chetan Mehrotra closed FELIX-3980.
--


Closing the issue as 0.0.2 release is done

 Add documentation related to usage of Felix JAAS Bundle
 ---

 Key: FELIX-3980
 URL: https://issues.apache.org/jira/browse/FELIX-3980
 Project: Felix
  Issue Type: Task
  Components: JAAS
Reporter: Chetan Mehrotra
Assignee: Chetan Mehrotra
 Fix For: jaas-0.0.2


 The documentation of the Felix JAAS Module currently is present at [1]. This 
 needs to be moved to Apache Felix website
 [1] https://github.com/chetanmeh/c/wiki/JAAS-in-OSGi



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

Re: [VOTE] Release of Jaas Support Bundle 0.0.2

2014-02-14 Thread Chetan Mehrotra

Thanks for the voting so far !.To push the release I require one more
binding vote.

Chetan Mehrotra


On Wed, Feb 12, 2014 at 1:20 AM, Clement Escoffier
clement.escoff...@gmail.com wrote:
 +1,

 Regards,

 Clement

 On 11 févr. 2014, at 11:36, Chetan Mehrotra chetan.mehro...@gmail.com wrote:

 I would like to call a vote on the initial release of the Apache Felix
 JAAS Support Bundle. For details on how to use it refer to
 http://felix.apache.org/documentation/subprojects/apache-felix-jaas.html

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

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

 Please vote to approve this release:

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

 Initial Release 0.0.2
 -

 ** Task
* [FELIX-3935] - Add testcases for validating the JAAS Feature
 implementation
* [FELIX-3980] - Add documentation related to usage of Felix JAAS Bundle
* [FELIX-3981] - Create a sample project for demonstrating Felix
 JAAS main features
* [FELIX-3989] - Add support for determining code coverage with
 integration testcases
* [FELIX-4318] - prepare for initial release of JAAS Bundle

 ** Bug
* [FELIX-3985] - ConfigSpiOsgi should be registered by default
* [FELIX-3998] - Updating JAAS config leads to registration of
 duplicate LoginModules
* [FELIX-4387] - JAAS config fields are initialized too late in
 the ConfigSpiOsgi constructor
* [FELIX-4390] - Login modules registered via LMF not updated if
 LMF service config changes

 ** Improvement
* [FELIX-3983] - Use inlined Sling commons PropertiesUtil for
 reading config values
* [FELIX-3984] - Use default application/realm name of 'other' if
 none specified
* [FELIX-4389] - Configuration ranking for LMF services should
 also use jaas.ranking property
* [FELIX-4414] - Empty string value in jaas.realm should also
 trigger default

 ** New Feature
* [FELIX-3705] - Bundle to simplify JAAS usage in OSGi

 Release notes also available at
 https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310100version=12323385

 Chetan Mehrotra

[jira] [Resolved] (FELIX-3935) Add testcases for validating the JAAS Feature implementation


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

Chetan Mehrotra resolved FELIX-3935.


Resolution: Fixed

Initial planned testcase have been made. More would be added by specific issues

 Add testcases for validating the JAAS Feature implementation
 

 Key: FELIX-3935
 URL: https://issues.apache.org/jira/browse/FELIX-3935
 Project: Felix
  Issue Type: Task
  Components: JAAS
Reporter: Chetan Mehrotra
Assignee: Chetan Mehrotra
 Fix For: jaas-0.0.2

   Original Estimate: 120h
  Remaining Estimate: 120h

 Need to add testcases to validate various scenarios supported by JAAS support 
 in OSGi env



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Resolved] (FELIX-3980) Add documentation related to usage of Felix JAAS Bundle


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

Chetan Mehrotra resolved FELIX-3980.


Resolution: Fixed

Relevant documentation is added to 
http://felix.apache.org/documentation/subprojects/apache-felix-jaas.html

 Add documentation related to usage of Felix JAAS Bundle
 ---

 Key: FELIX-3980
 URL: https://issues.apache.org/jira/browse/FELIX-3980
 Project: Felix
  Issue Type: Task
  Components: JAAS
Reporter: Chetan Mehrotra
Assignee: Chetan Mehrotra
 Fix For: jaas-0.0.2


 The documentation of the Felix JAAS Module currently is present at [1]. This 
 needs to be moved to Apache Felix website
 [1] https://github.com/chetanmeh/c/wiki/JAAS-in-OSGi



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Commented] (FELIX-3981) Create a sample project for demonstrating Felix JAAS main features


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

Chetan Mehrotra commented on FELIX-3981:


The examples have been ported to 
http://svn.apache.org/repos/asf/felix/trunk/examples/jaas/

Need to work on a readme to use these examples

 Create a sample project for demonstrating Felix JAAS main features
 --

 Key: FELIX-3981
 URL: https://issues.apache.org/jira/browse/FELIX-3981
 Project: Felix
  Issue Type: Task
  Components: JAAS
Affects Versions: jaas-0.0.2
Reporter: Chetan Mehrotra
Assignee: Chetan Mehrotra
 Fix For: jaas-0.0.2


 In addition to the documentation around JAAS support (FELIX-3980) it would be 
 helpful if sample projects can be provided which quickly demonstrate JAAS 
 usage. The sample code can live under [1]
 As of now one can get some details from wiki [2] and testcases [3]
 [1] http://svn.apache.org/repos/asf/felix/trunk/examples
 [2] https://github.com/chetanmeh/c/wiki/JAAS-in-OSGi
 [3] 
 http://svn.apache.org/repos/asf/felix/trunk/jaas/src/test/java/org/apache/felix/jaas/integration



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Updated] (FELIX-3981) Create a sample project for demonstrating Felix JAAS main features