[jira] [Commented] (FELIX-5573) Detect recursive class loads while invoking weaving hooks
[ https://issues.apache.org/jira/browse/FELIX-5573?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15889790#comment-15889790 ] Felix Meschberger commented on FELIX-5573: -- My understanding is like David's: I think Bundle.loadClass should not return null as this sounds unexpected, although the specification is not entirely clear. So I would sort this under the topic "managing expectations". How about throwing a new "ClassLoadingCircularityDetectedException extends ClassNotFoundException" ? This way callers get the "ClassNotFoundException" while internally you can differentiate between the cases. Plus logging the exception will properly indicate the actual problem: the circularity. > Detect recursive class loads while invoking weaving hooks > - > > Key: FELIX-5573 > URL: https://issues.apache.org/jira/browse/FELIX-5573 > Project: Felix > Issue Type: Bug > Components: Framework >Affects Versions: framework-5.6.2 >Reporter: Karl Pauls >Assignee: Karl Pauls > Fix For: framework-5.6.4 > > > We need to detect recursive class loads while invoking weaving hooks, if > recursion is detected for a class name then we want to simply ignore all > weave hooks for the recursive class load and allow it to proceed to define > class. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (FELIX-5507) ConfigurationAdmin not visible to bundles
[ https://issues.apache.org/jira/browse/FELIX-5507?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15839427#comment-15839427 ] Felix Meschberger commented on FELIX-5507: -- I tend to agree with [~djencks] here. IIRC the reason for using the extended bundle's context is to make sure the Configuration Admin service applies the correct permissions for the consuming bundle ! Using the system bundle completely breaks this assumption and I would even go as far as saying this is non-compliant behaviour. It really is important to find the real cause for the problem in this context. > ConfigurationAdmin not visible to bundles > - > > Key: FELIX-5507 > URL: https://issues.apache.org/jira/browse/FELIX-5507 > Project: Felix > Issue Type: Bug > Components: Declarative Services (SCR) >Affects Versions: scr-2.0.8 >Reporter: Carsten Ziegeler > Fix For: scr-2.1.0 > > > We have one case where the extended bundles do not see the configuration > admin service. Interestingly the same application runs fine everywhere else, > but just on a special environment (windows, ibm java inside Websphere) we > have this problem reproducibly. > Using the system bundle context instead of the bundle context of the extended > bundle in ConfigAdminTracker solves the problem. > Interestingly only the bundles started last (2 out of probably 80) see the > configuration admin. > It could also be that a faulty service hook is involved, although I'm not yet > aware of such a hook -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (FELIX-5446) Http Service ignores Whiteboard Servlet API Listeners
[
https://issues.apache.org/jira/browse/FELIX-5446?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15741687#comment-15741687
]
Felix Meschberger commented on FELIX-5446:
--
I have looked again, and it looks like the Http Service Web Console plugin
indeed *lists* the listener for the servlet context "'org.osgi.service.http"
where the HttpService registered services are listed. But the listener is not
called.
> Http Service ignores Whiteboard Servlet API Listeners
> -
>
> Key: FELIX-5446
> URL: https://issues.apache.org/jira/browse/FELIX-5446
> Project: Felix
> Issue Type: Bug
> Components: HTTP Service
>Affects Versions: http.base-3.0.16, http.jetty-3.4.0
>Reporter: Felix Meschberger
>Assignee: Carsten Ziegeler
> Fix For: http.base-3.0.18, http.jetty-3.4.2
>
>
> Situation:
> # A ServletRequestListener registered with the Http Whiteboard Service
> (standard OSGi Http Whiteboard) with property
> {{osgi.http.whiteboard.listener==true}}.
> # A Servlet registered with the traditional OSGi HttpService
> Problem: The ServletRequestListener is not called for requests for requests
> to said servlet.
> Investigation: It looks like the ServletRequestListenerManager used to handle
> ServletRequestListener services for traditionally registered Servlets
> explicitly ignores listeners registered with the
> {{osgi.http.whiteboard.listener}} property set. See this code in
> [ServletRequestListenerManager|https://github.com/apache/felix/blob/trunk/http/base/src/main/java/org/apache/felix/http/base/internal/service/listener/ServletRequestListenerManager.java#L45].
> For one thing, the listener should at best ignore services registered with
> the property set to true. If the property is set to anything else, it will
> explicitly be ignored by the OSGi Whiteboard Http Service and thus should
> probably be accepted by the legacy Felix Http Service implementation.
> On the other hand: Why ignore at all ? Originally the legacy Felix Http
> Service accepted all Servlet API listeners regardless of such property set.
> So if there is a listener used and the Jetty bundle is updated and the
> service updated to make sure it is called for new OSGi Whiteboard services it
> will not be called any more for the legacy registered services
> I think the legacy Felix Http Service should just accept all listeners like
> it always did.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (FELIX-5446) Http Service ignores Whiteboard Servlet API Listeners
Felix Meschberger created FELIX-5446:
Summary: Http Service ignores Whiteboard Servlet API Listeners
Key: FELIX-5446
URL: https://issues.apache.org/jira/browse/FELIX-5446
Project: Felix
Issue Type: Bug
Components: HTTP Service
Affects Versions: http.jetty-3.4.0
Reporter: Felix Meschberger
Situation:
# A ServletRequestListener registered with the Http Whiteboard Service
(standard OSGi Http Whiteboard) with property
{{osgi.http.whiteboard.listener==true}}.
# A Servlet registered with the traditional OSGi HttpService
Problem: The ServletRequestListener is not called for requests for requests to
said servlet.
Investigation: It looks like the ServletRequestListenerManager used to handle
ServletRequestListener services for traditionally registered Servlets
explicitly ignores listeners registered with the
{{osgi.http.whiteboard.listener}} property set. See this code in
[ServletRequestListenerManager|https://github.com/apache/felix/blob/trunk/http/base/src/main/java/org/apache/felix/http/base/internal/service/listener/ServletRequestListenerManager.java#L45].
For one thing, the listener should at best ignore services registered with the
property set to true. If the property is set to anything else, it will
explicitly be ignored by the OSGi Whiteboard Http Service and thus should
probably be accepted by the legacy Felix Http Service implementation.
On the other hand: Why ignore at all ? Originally the legacy Felix Http Service
accepted all Servlet API listeners regardless of such property set. So if there
is a listener used and the Jetty bundle is updated and the service updated to
make sure it is called for new OSGi Whiteboard services it will not be called
any more for the legacy registered services
I think the legacy Felix Http Service should just accept all listeners like it
always did.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (FELIX-5443) Frequent Changes cause UpdateThread to ConcurrentModificationException
[
https://issues.apache.org/jira/browse/FELIX-5443?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15728607#comment-15728607
]
Felix Meschberger commented on FELIX-5443:
--
Good catch. Current uses do not seem to trigger this much concurrency in this
context ...
How about replacing the internal set with an immutable variant:
{code}
Index: Factory.java
===
--- Factory.java(Revision 1773058)
+++ Factory.java(Arbeitskopie)
@@ -20,6 +20,7 @@
import java.io.IOException;
+import java.util.Collections;
import java.util.Dictionary;
import java.util.HashSet;
import java.util.Hashtable;
@@ -41,7 +42,7 @@
public static final String FACTORY_PID_LIST = "factory.pidList";
// the set of configuration PIDs belonging to this factory
-private final Set pids = new HashSet();;
+private Set pids;
static boolean exists( PersistenceManager persistenceManager, String
factoryPid )
@@ -67,6 +68,7 @@
Factory( ConfigurationManager configurationManager, PersistenceManager
persistenceManager, String factoryPid )
{
super( configurationManager, persistenceManager, factoryPid );
+this.pids = Collections.unmodifiableSet( Collections.emptySet() );
}
@@ -77,6 +79,7 @@
// set pids
String[] pidList = ( String[] ) props.get( FACTORY_PID_LIST );
+HashSet pids = new HashSet();
if ( pidList != null )
{
for ( int i = 0; i < pidList.length; i++ )
@@ -84,6 +87,7 @@
pids.add( pidList[i] );
}
}
+this.pids = Collections.unmodifiableSet( pids );
}
@@ -101,19 +105,25 @@
Set getPIDs()
{
-return new HashSet( pids );
+return this.pids;
}
boolean addPID( String pid )
{
-return pids.add( pid );
+HashSet pids = new HashSet();
+boolean added = pids.add( pid );
+this.pids = Collections.unmodifiableSet( pids );
+return added;
}
boolean removePID( String pid )
{
-return pids.remove( pid );
+HashSet pids = new HashSet();
+boolean removed = pids.remove( pid );
+this.pids = Collections.unmodifiableSet( pids );
+return removed;
}
@@ -120,6 +130,7 @@
void store() throws IOException
{
Hashtable props = new Hashtable();
+Set pids = this.pids;
if ( !pids.isEmpty() )
{
{code}
This allows us to optimize the {{getPids()}} method which is presumably called
more often than {{addPid}} and {{removePid}} which become more expensive.
> Frequent Changes cause UpdateThread to ConcurrentModificationException
> --
>
> Key: FELIX-5443
> URL: https://issues.apache.org/jira/browse/FELIX-5443
> Project: Felix
> Issue Type: Bug
> Components: Configuration Admin
>Affects Versions: configadmin-1.8.8
>Reporter: Fabian Lange
>
> 2016-11-30T10:20:15.614+ | ERROR | 836-1bc8-4066-963b-9b9cbccbd9d0) |
> configadmin | org.apache.felix.configadmin - 1.8.8 | Unexpected problem
> executing task java.util.ConcurrentModificationException at
> java.util.HashMap$HashIterator.nextNode(HashMap.java:1437)[:1.8.0_101] at
> java.util.HashMap$KeyIterator.next(HashMap.java:1461)[:1.8.0_101] at
> java.util.AbstractCollection.toArray(AbstractCollection.java:196)[:1.8.0_101]
> at
> org.apache.felix.cm.impl.Factory.store(Factory.java:126)[4:org.apache.felix.configadmin:1.8.8]
> at
> org.apache.felix.cm.impl.ConfigurationManager$DeleteConfiguration.run(ConfigurationManager.java:1851)[4:org.apache.felix.configadmin:1.8.8]
> at
> org.apache.felix.cm.impl.UpdateThread.run0(UpdateThread.java:143)[4:org.apache.felix.configadmin:1.8.8]
> at
> org.apache.felix.cm.impl.UpdateThread.run(UpdateThread.java:110)[4:org.apache.felix.configadmin:1.8.8]
> at java.lang.Thread.run(Thread.java:745)[:1.8.0_101]
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (FELIX-5394) Memoryusage plugin creates a heap dump on every notification
[
https://issues.apache.org/jira/browse/FELIX-5394?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15650513#comment-15650513
]
Felix Meschberger commented on FELIX-5394:
--
On rethought and some discussions, it might probably be worth while extending
the memory plugin as follows:
* Allow to set thresholds for each of the events separately, where zero means
the plugin should *not* change any current threshold
* Allow to configure whether to dump heap on either or both of the events or to
not dump at all
Possible UI:
{code}
+---+---+---+
| Mem Threshold | | ☐ dump heap ? |
+---+---+---+
| Snapshot Th. | | ☐ dump heap ? |
+---+---+---+
{code}
In addition dumping heap should be limited more flexibly:
* dump only if last dump is more than some amount of time in the past (as today)
* dump if nth event within an amount of time (e.g. dump if 3rd event within an
hour)
> Memoryusage plugin creates a heap dump on every notification
>
>
> Key: FELIX-5394
> URL: https://issues.apache.org/jira/browse/FELIX-5394
> Project: Felix
> Issue Type: Bug
> Components: Web Console
>Affects Versions: webconsole-memoryusage-plugin-1.0.6
>Reporter: Alex Parvulescu
> Labels: patch-available
> Attachments: FELIX-5394-v0.patch
>
>
> As a part of OAK-4966 I'm trying to install a listener on available memory
> with a notification when a certain available memory threshold is met [0].
> This seems to clash a bit with the current {{memoryusage}} plugin, as both
> jmx listeners try to change the threshold for the notification, and
> subsequently both might receive the notification at a different value than
> expected. (for example I'm setting a notification at {{15%}} and even though
> the {{memoryusage}} plugin is not used and is currently set at {{0%}} it will
> still create a heap dump:
> {noformat}
> *WARN* [Service Thread] org.apache.felix.webconsole.plugins.memoryusage
> Received Memory Threshold Exceeded Notification, dumping Heap
> {noformat}
> I have 2 suggestions:
> * first is to _not_ change the threshold value if it's already set at a
> smaller value. this means the plugin will not break other listeners
> expectations of receiving an event
>
> * second is to verify the locally set threshold value against the values seen
> at notification time. this effectively means the plugin is free to ignore
> certain events, and not dump the heap to disk every time it gets a ping [1].
> I would like to provide a patch for this issue pretty soon as I really need
> to fix OAK-4966, unless someone is more eager to come up with a working
> solution.
> [0]
> https://issues.apache.org/jira/browse/OAK-4966?focusedCommentId=15629253&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15629253
> [1]
> https://github.com/apache/felix/blob/trunk/webconsole-plugins/memoryusage/src/main/java/org/apache/felix/webconsole/plugins/memoryusage/internal/MemoryUsageSupport.java#L553
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (FELIX-5394) Memoryusage plugin creates a heap dump on every notification
[
https://issues.apache.org/jira/browse/FELIX-5394?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15637414#comment-15637414
]
Felix Meschberger commented on FELIX-5394:
--
bq. could you just clarify who will be responsible for setting the threshold on
the memory pool? will the plugin not set it any more going forward?
If the threshold is configured to zero, yes, the idea is that the plugin will
not set it any longer. If the configured value is in the valid range, the
plugin will set it.
bq. also, might I add a small thing to your list: if the plugin is registered
for a specific threshold and it receives an event, it should check that the
memory delta is within that threshold before creating the dump
I am a bit at unease at doing that. My assumption is that someone enabled
dumping by threshold. Now someone else changed the threshold, but still the
dump might be desired
> Memoryusage plugin creates a heap dump on every notification
>
>
> Key: FELIX-5394
> URL: https://issues.apache.org/jira/browse/FELIX-5394
> Project: Felix
> Issue Type: Bug
> Components: Web Console
>Affects Versions: webconsole-memoryusage-plugin-1.0.6
>Reporter: Alex Parvulescu
> Labels: patch-available
> Attachments: FELIX-5394-v0.patch
>
>
> As a part of OAK-4966 I'm trying to install a listener on available memory
> with a notification when a certain available memory threshold is met [0].
> This seems to clash a bit with the current {{memoryusage}} plugin, as both
> jmx listeners try to change the threshold for the notification, and
> subsequently both might receive the notification at a different value than
> expected. (for example I'm setting a notification at {{15%}} and even though
> the {{memoryusage}} plugin is not used and is currently set at {{0%}} it will
> still create a heap dump:
> {noformat}
> *WARN* [Service Thread] org.apache.felix.webconsole.plugins.memoryusage
> Received Memory Threshold Exceeded Notification, dumping Heap
> {noformat}
> I have 2 suggestions:
> * first is to _not_ change the threshold value if it's already set at a
> smaller value. this means the plugin will not break other listeners
> expectations of receiving an event
>
> * second is to verify the locally set threshold value against the values seen
> at notification time. this effectively means the plugin is free to ignore
> certain events, and not dump the heap to disk every time it gets a ping [1].
> I would like to provide a patch for this issue pretty soon as I really need
> to fix OAK-4966, unless someone is more eager to come up with a working
> solution.
> [0]
> https://issues.apache.org/jira/browse/OAK-4966?focusedCommentId=15629253&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15629253
> [1]
> https://github.com/apache/felix/blob/trunk/webconsole-plugins/memoryusage/src/main/java/org/apache/felix/webconsole/plugins/memoryusage/internal/MemoryUsageSupport.java#L553
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (FELIX-5397) Memoryusage plugin default configuration incorrect
Felix Meschberger created FELIX-5397: Summary: Memoryusage plugin default configuration incorrect Key: FELIX-5397 URL: https://issues.apache.org/jira/browse/FELIX-5397 Project: Felix Issue Type: Bug Components: Web Console Affects Versions: webconsole-memoryusage-plugin-1.0.6 Reporter: Felix Meschberger Fix For: webconsole-memoryusage-plugin-1.0.8 When no Configuration Admin configuration exists for the Memoryusage plugin static default values are displayed. In addition the dump interval time is documented to be given seconds with a default value of 6h, while the displayed values would 6h in milliseconds (or 6000h in seconds). As the metatype is dynamically generated anyway, the default values should actually be derived from the currently configured values as provided by the either the static defaults or the configuration provided from the framework properties. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (FELIX-5394) Memoryusage plugin creates a heap dump on every notification
[
https://issues.apache.org/jira/browse/FELIX-5394?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15636472#comment-15636472
]
Felix Meschberger edited comment on FELIX-5394 at 11/4/16 2:17 PM:
---
Apart from that, there is indeed a proplem with the plugin: The documentation
of the _Dump Threshold_ property states _zero to disable automatic dump
creation_.
This is clearly not implemented like that. Rather the implementation does this
when the property is zero:
* Registers the notification listener (yes, this listener is always
registered !)
* Sets the threshold to zero on all memory pools allowing to set the
threshold. This causes these pools to not send events.
* Still set the threshold to zero on the settable pools (this may be
overwritten by other tooling but dumps by the plugin will not be created)
Now, should some other system tooling decide to set the threshold to some value
(of course this setting is sort of a race condition between this plugin and the
other tool), the plugin will receive events and in contrast to the stated
"disable automatic dump creation", dumps will be created.
We should fix this as follows:
* Register the listener only in case a non-zero threshold is configured
* Make sure the listener is not registered (or unregistered) if a zero
threshold is configured
[~alex.parvulescu] Does that work for you ?
was (Author: fmeschbe):
Apart from that, there is indeed a proplem with the plugin: The documentation
of the _Dump Threshold_ property states _zero to disable automatic dump
creation_.
This is clearly not implemented like that. Rather the implementation does this
when the property is zero:
* Registers the notification listener (yes, this listener is always
registered !)
* Sets the threshold to zero on all memory pools allowing to set the
threshold. This causes these pools to not send events.
Now, should some other system tooling decide to set the threshold to some value
(of course this setting is sort of a race condition between this plugin and the
other tool), the plugin will receive events and in contrast to the stated
"disable automatic dump creation", dumps will be created.
We should fix this as follows:
* Register the listener only in case a non-zero threshold is configured
* Make sure the listener is not registered (or unregistered) if a zero
threshold is configured
[~alex.parvulescu] Does that work for you ?
> Memoryusage plugin creates a heap dump on every notification
>
>
> Key: FELIX-5394
> URL: https://issues.apache.org/jira/browse/FELIX-5394
> Project: Felix
> Issue Type: Bug
> Components: Web Console
>Affects Versions: webconsole-memoryusage-plugin-1.0.6
>Reporter: Alex Parvulescu
> Labels: patch-available
> Attachments: FELIX-5394-v0.patch
>
>
> As a part of OAK-4966 I'm trying to install a listener on available memory
> with a notification when a certain available memory threshold is met [0].
> This seems to clash a bit with the current {{memoryusage}} plugin, as both
> jmx listeners try to change the threshold for the notification, and
> subsequently both might receive the notification at a different value than
> expected. (for example I'm setting a notification at {{15%}} and even though
> the {{memoryusage}} plugin is not used and is currently set at {{0%}} it will
> still create a heap dump:
> {noformat}
> *WARN* [Service Thread] org.apache.felix.webconsole.plugins.memoryusage
> Received Memory Threshold Exceeded Notification, dumping Heap
> {noformat}
> I have 2 suggestions:
> * first is to _not_ change the threshold value if it's already set at a
> smaller value. this means the plugin will not break other listeners
> expectations of receiving an event
>
> * second is to verify the locally set threshold value against the values seen
> at notification time. this effectively means the plugin is free to ignore
> certain events, and not dump the heap to disk every time it gets a ping [1].
> I would like to provide a patch for this issue pretty soon as I really need
> to fix OAK-4966, unless someone is more eager to come up with a working
> solution.
> [0]
> https://issues.apache.org/jira/browse/OAK-4966?focusedCommentId=15629253&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15629253
> [1]
> https://github.com/apache/felix/blob/trunk/webconsole-plugins/memoryusage/src/main/java/org/apache/felix/webconsole/plugins/memoryusage/internal/MemoryUsageSupport.java#L553
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (FELIX-5394) Memoryusage plugin creates a heap dump on every notification
[
https://issues.apache.org/jira/browse/FELIX-5394?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15636472#comment-15636472
]
Felix Meschberger commented on FELIX-5394:
--
Apart from that, there is indeed a proplem with the plugin: The documentation
of the _Dump Threshold_ property states _zero to disable automatic dump
creation_.
This is clearly not implemented like that. Rather the implementation does this
when the property is zero:
* Registers the notification listener (yes, this listener is always
registered !)
* Sets the threshold to zero on all memory pools allowing to set the
threshold. This causes these pools to not send events.
Now, should some other system tooling decide to set the threshold to some value
(of course this setting is sort of a race condition between this plugin and the
other tool), the plugin will receive events and in contrast to the stated
"disable automatic dump creation", dumps will be created.
We should fix this as follows:
* Register the listener only in case a non-zero threshold is configured
* Make sure the listener is not registered (or unregistered) if a zero
threshold is configured
[~alex.parvulescu] Does that work for you ?
> Memoryusage plugin creates a heap dump on every notification
>
>
> Key: FELIX-5394
> URL: https://issues.apache.org/jira/browse/FELIX-5394
> Project: Felix
> Issue Type: Bug
> Components: Web Console
>Affects Versions: webconsole-memoryusage-plugin-1.0.6
>Reporter: Alex Parvulescu
> Labels: patch-available
> Attachments: FELIX-5394-v0.patch
>
>
> As a part of OAK-4966 I'm trying to install a listener on available memory
> with a notification when a certain available memory threshold is met [0].
> This seems to clash a bit with the current {{memoryusage}} plugin, as both
> jmx listeners try to change the threshold for the notification, and
> subsequently both might receive the notification at a different value than
> expected. (for example I'm setting a notification at {{15%}} and even though
> the {{memoryusage}} plugin is not used and is currently set at {{0%}} it will
> still create a heap dump:
> {noformat}
> *WARN* [Service Thread] org.apache.felix.webconsole.plugins.memoryusage
> Received Memory Threshold Exceeded Notification, dumping Heap
> {noformat}
> I have 2 suggestions:
> * first is to _not_ change the threshold value if it's already set at a
> smaller value. this means the plugin will not break other listeners
> expectations of receiving an event
>
> * second is to verify the locally set threshold value against the values seen
> at notification time. this effectively means the plugin is free to ignore
> certain events, and not dump the heap to disk every time it gets a ping [1].
> I would like to provide a patch for this issue pretty soon as I really need
> to fix OAK-4966, unless someone is more eager to come up with a working
> solution.
> [0]
> https://issues.apache.org/jira/browse/OAK-4966?focusedCommentId=15629253&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15629253
> [1]
> https://github.com/apache/felix/blob/trunk/webconsole-plugins/memoryusage/src/main/java/org/apache/felix/webconsole/plugins/memoryusage/internal/MemoryUsageSupport.java#L553
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (FELIX-5394) Memoryusage plugin creates a heap dump on every notification
[
https://issues.apache.org/jira/browse/FELIX-5394?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15635568#comment-15635568
]
Felix Meschberger commented on FELIX-5394:
--
If I understand it correctly, Oak wants to be notified if there is a memory
shortage while they perform some housekeeping (tar online compaction). I
appreciate their use of this notification to try to make sure their heap
consumption while housekeeping does not "kill" the system.
But then, I think it cannot be Oak's task to change any of the thresholds. As
such I think we should not change this plugin and rather have Oak just register
for the notification and document that they expect deployments to have a
reasonable threshold configuration.
> Memoryusage plugin creates a heap dump on every notification
>
>
> Key: FELIX-5394
> URL: https://issues.apache.org/jira/browse/FELIX-5394
> Project: Felix
> Issue Type: Bug
> Components: Web Console
>Affects Versions: webconsole-memoryusage-plugin-1.0.6
>Reporter: Alex Parvulescu
> Labels: patch-available
> Attachments: FELIX-5394-v0.patch
>
>
> As a part of OAK-4966 I'm trying to install a listener on available memory
> with a notification when a certain available memory threshold is met [0].
> This seems to clash a bit with the current {{memoryusage}} plugin, as both
> jmx listeners try to change the threshold for the notification, and
> subsequently both might receive the notification at a different value than
> expected. (for example I'm setting a notification at {{15%}} and even though
> the {{memoryusage}} plugin is not used and is currently set at {{0%}} it will
> still create a heap dump:
> {noformat}
> *WARN* [Service Thread] org.apache.felix.webconsole.plugins.memoryusage
> Received Memory Threshold Exceeded Notification, dumping Heap
> {noformat}
> I have 2 suggestions:
> * first is to _not_ change the threshold value if it's already set at a
> smaller value. this means the plugin will not break other listeners
> expectations of receiving an event
>
> * second is to verify the locally set threshold value against the values seen
> at notification time. this effectively means the plugin is free to ignore
> certain events, and not dump the heap to disk every time it gets a ping [1].
> I would like to provide a patch for this issue pretty soon as I really need
> to fix OAK-4966, unless someone is more eager to come up with a working
> solution.
> [0]
> https://issues.apache.org/jira/browse/OAK-4966?focusedCommentId=15629253&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15629253
> [1]
> https://github.com/apache/felix/blob/trunk/webconsole-plugins/memoryusage/src/main/java/org/apache/felix/webconsole/plugins/memoryusage/internal/MemoryUsageSupport.java#L553
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (FELIX-5148) Framework Security unusable
[
https://issues.apache.org/jira/browse/FELIX-5148?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15105216#comment-15105216
]
Felix Meschberger commented on FELIX-5148:
--
I have to admit [~olli], that I don't know exactly what's going on here.
I once added a policy file to the configadmin bundle (FELIX-4039), but TBH I
don't exactly know that works, except that with this file in place the bundle
passes the OSGi CT tests even with SecurityManager enabled.
> Framework Security unusable
> ---
>
> Key: FELIX-5148
> URL: https://issues.apache.org/jira/browse/FELIX-5148
> Project: Felix
> Issue Type: Bug
> Components: Configuration Admin, Framework Security
>Affects Versions: framework.security-2.4.0, configadmin-1.8.0
>Reporter: Oliver Lietz
>
> While fixing an issue with Sling and RMI (SLING-5375) reported by an user I
> came across an issue (KARAF-3400) reported by [~achim_nierbeck] for Karaf
> related to framework security.
> There is also an issue with [Sling's own OSGi launcher
> Launchpad|https://svn.apache.org/viewvc/sling/trunk/launchpad/builder/] and
> framework security when using {{org.apache.felix.configadmin}} >= {{1.8.0}}.
> {{all.policy}}:
> {noformat}
> grant {
>permission java.security.AllPermission;
> };
> {noformat}
> Adding {{org.apache.felix/org.apache.felix.framework.security/2.4.0}} to
> {{boot.txt}} and starting with arguments described on [Framework Security's
> page|http://felix.apache.org/documentation/subprojects/apache-felix-framework-security.html]
> (which looks broken) and
> [{{-Djava.security.manager}}|http://docs.oracle.com/javase/8/docs/technotes/guides/security/spec/security-spec.doc6.html]
> ([Building Secure OSGi
> Applications|http://de.slideshare.net/marrs/building-secure-osgi-applications])
> throws a {{java.security.AccessControlException}}:
> {noformat}
> java -Djava.security.manager -Djava.security.policy="all.policy"
> -Dorg.osgi.framework.security="osgi" -jar
> org.apache.sling.launchpad-9-SNAPSHOT.jar
> {noformat}
> {noformat}
> [...]
> [...] *ERROR* [FelixStartLevel] ERROR: Error starting
> slinginstall:org.apache.felix.configadmin-1.8.0.jar
> (java.security.AccessControlException: access denied
> ("java.io.FilePermission" "/[...]/sling/config" "read"))
> java.security.AccessControlException: access denied ("java.io.FilePermission"
> "/[...]/sling/config" "read")
> at
> java.security.AccessControlContext.checkPermission(AccessControlContext.java:472)
> at
> java.security.AccessController.checkPermission(AccessController.java:884)
> at java.lang.SecurityManager.checkPermission(SecurityManager.java:549)
> at java.lang.SecurityManager.checkRead(SecurityManager.java:888)
> at java.io.File.isDirectory(File.java:844)
> at
> org.apache.felix.cm.file.FilePersistenceManager.(FilePersistenceManager.java:342)
> at
> org.apache.felix.cm.impl.ConfigurationManager.start(ConfigurationManager.java:244)
> at
> org.apache.felix.framework.util.SecureAction$Actions.run(SecureAction.java:1709)
> at java.security.AccessController.doPrivileged(Native Method)
> at
> org.apache.felix.framework.util.SecureAction.startActivator(SecureAction.java:688)
> at org.apache.felix.framework.Felix.activateBundle(Felix.java:2226)
> at org.apache.felix.framework.Felix.startBundle(Felix.java:2144)
> at org.apache.felix.framework.Felix.setActiveStartLevel(Felix.java:1371)
> at
> org.apache.felix.framework.FrameworkStartLevelImpl.run(FrameworkStartLevelImpl.java:308)
> at java.lang.Thread.run(Thread.java:745)
> [...]
> {noformat}
> I had to remove OSGi Subsystems support from {{boot.txt}} when using
> {{org.apache.felix.configadmin}} {{1.6}}:
> {noformat}
> org.apache.felix/org.apache.felix.coordinator/1.0.0
> org.eclipse.equinox/org.eclipse.equinox.region/1.2.101.v20150831-1342
> org.apache.aries.subsystem/org.apache.aries.subsystem.api/2.0.6
> org.apache.aries.subsystem/org.apache.aries.subsystem.core/2.0.6
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (FELIX-4890) Implement a MetaType service inventory printer
[ https://issues.apache.org/jira/browse/FELIX-4890?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger updated FELIX-4890: - Fix Version/s: webconsole-metatype-plugin-1.0.0 > Implement a MetaType service inventory printer > -- > > Key: FELIX-4890 > URL: https://issues.apache.org/jira/browse/FELIX-4890 > Project: Felix > Issue Type: Task > Components: Web Console >Reporter: Felix Meschberger >Assignee: Felix Meschberger > Fix For: webconsole-metatype-plugin-1.0.0 > > > For completeness of information of the status output of a framework > supporting inventory printing, it would be good to have an InventoryPrinter > for MetaType service information. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (FELIX-4890) Implement a MetaType service inventory printer
[ https://issues.apache.org/jira/browse/FELIX-4890?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14547767#comment-14547767 ] Felix Meschberger commented on FELIX-4890: -- Added first version in commit 1679974 to http://svn.apache.org/repos/asf/felix/trunk/webconsole-plugins/metatype > Implement a MetaType service inventory printer > -- > > Key: FELIX-4890 > URL: https://issues.apache.org/jira/browse/FELIX-4890 > Project: Felix > Issue Type: Task > Components: Web Console >Reporter: Felix Meschberger >Assignee: Felix Meschberger > > For completeness of information of the status output of a framework > supporting inventory printing, it would be good to have an InventoryPrinter > for MetaType service information. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (FELIX-4890) Implement a MetaType service inventory printer
Felix Meschberger created FELIX-4890: Summary: Implement a MetaType service inventory printer Key: FELIX-4890 URL: https://issues.apache.org/jira/browse/FELIX-4890 Project: Felix Issue Type: Task Components: Web Console Reporter: Felix Meschberger Assignee: Felix Meschberger For completeness of information of the status output of a framework supporting inventory printing, it would be good to have an InventoryPrinter for MetaType service information. -- 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-tabpanel&focusedCommentId=14317926#comment-14317926 ] Felix Meschberger commented on FELIX-4599: -- No they are really on called as I said :-) > 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-tabpanel&focusedCommentId=14317907#comment-14317907 ] Felix Meschberger commented on FELIX-4599: -- [~chetanm] The problem ConfigurationPlugin is that they only kick in when ConfigurationAdmin service is sending configuration ManagedService[Factory] services. They don't kick in when accessing configuration with getConfiguration and listConfigurations. As such they are not a complete solution. > 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] [Resolved] (FELIX-4792) [SCR] Handle Errors on component initialization
[ https://issues.apache.org/jira/browse/FELIX-4792?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger resolved FELIX-4792. -- Resolution: Fixed Implemented catching any Throwable during initial component initialization and logging it in Rev. 1658457. In addition the component is disabled to make sure any partical setup is rolled back. > [SCR] Handle Errors on component initialization > --- > > Key: FELIX-4792 > URL: https://issues.apache.org/jira/browse/FELIX-4792 > Project: Felix > Issue Type: Bug > Components: Declarative Services (SCR) >Affects Versions: scr-1.8.2 >Reporter: Felix Meschberger >Assignee: Felix Meschberger > Fix For: scr-2.0.0 > > > During component initialization the component implementation class is loaded. > If the class or one of its dependencies cannot be properly loaded a > ClassDefNotFound error can be thrown. > This error bubbles up from BundleComponentActivator.initialEnable to the > AbstractExtender.createExtension method, where it is logged. The problem with > this is, that the BundleComponentActivator has registered all the components > of the bundle with the ComponentRegistry but when the error is thrown, the > BundleComponentActivator is not registered in Activator's m_componentBundles > map. > So, when the bundle is stopped, the components registered with the > ComponentRegistry stay registered and will never be cleaned away. > The simple fix is to catch Throwable in the > BundleComponentActivator.initialEnable method and log it. The single > component failing to load will stay inactive but the rest of the component > registration will continue unaffected. > Background: We have a situation where a bundle is compiled against an API > bundle whose exported API is not properly versioned. So the OSGi framework > happily wires the bundle to the older API bundle version but one of the > components fails to load due to missing API. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (FELIX-4792) [SCR] Handle Errors on component initialization
Felix Meschberger created FELIX-4792: Summary: [SCR] Handle Errors on component initialization Key: FELIX-4792 URL: https://issues.apache.org/jira/browse/FELIX-4792 Project: Felix Issue Type: Bug Components: Declarative Services (SCR) Affects Versions: scr-1.8.2 Reporter: Felix Meschberger Assignee: Felix Meschberger Fix For: scr-2.0.0 During component initialization the component implementation class is loaded. If the class or one of its dependencies cannot be properly loaded a ClassDefNotFound error can be thrown. This error bubbles up from BundleComponentActivator.initialEnable to the AbstractExtender.createExtension method, where it is logged. The problem with this is, that the BundleComponentActivator has registered all the components of the bundle with the ComponentRegistry but when the error is thrown, the BundleComponentActivator is not registered in Activator's m_componentBundles map. So, when the bundle is stopped, the components registered with the ComponentRegistry stay registered and will never be cleaned away. The simple fix is to catch Throwable in the BundleComponentActivator.initialEnable method and log it. The single component failing to load will stay inactive but the rest of the component registration will continue unaffected. Background: We have a situation where a bundle is compiled against an API bundle whose exported API is not properly versioned. So the OSGi framework happily wires the bundle to the older API bundle version but one of the components fails to load due to missing API. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (FELIX-4787) DS implementation should be based on R6
[ https://issues.apache.org/jira/browse/FELIX-4787?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14308846#comment-14308846 ] Felix Meschberger commented on FELIX-4787: -- In light of FELIX-4785 where we discuss keeping the old service API I think we should not jump the band wagon and just blindly require framework R6. Just as we have consumers of the old service API we might have implementations of the old Framework API which cannot easily migrate to a new framework version (in fact migrating the framework is probably harder than migrating just about some bundle). So I suggest we should actually keep compatibility with old framework versions. This probably means: * not support new functionality if the framework does not support it. For ServiceObjects this means that components making use of this functionality fail to "resolve" due to a missing dependency. * embed parts of the API which we cannot expect on older frameworks -- or not expose that functionality at all. For DTO this means either embedding the DTO API and exporting/importing it like we do with the Promise API or it means not exposing the DTOs if the basic DTO API is not available -- similar to how we support Configuration Admin and Metatype depending on whether these APIs and services are available. > DS implementation should be based on R6 > --- > > Key: FELIX-4787 > URL: https://issues.apache.org/jira/browse/FELIX-4787 > Project: Felix > Issue Type: Task > Components: Declarative Services (SCR) >Reporter: Carsten Ziegeler >Assignee: Carsten Ziegeler > Fix For: scr-2.0.0 > > > Right now the new DS implementation stills tries to run on older frameworks, > the bnd.bnd file claims it works with version 1.4 of the framework api. > However, the new DS spec includes support for ServiceObjects and DTOs which > are part of core R6 (package version 1.8). There is some effort in the code > to still run on an older framework if these features are not used, but I'm > wondering if this is a good idea and how we ensure that everything is working. > Now, that we have an official Apache Felix releases that is R6 compliant, I > would rather require this as the minimal version. > [~djencks] WDYT? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (FELIX-4692) Improve Service access time
[ https://issues.apache.org/jira/browse/FELIX-4692?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger resolved FELIX-4692. -- Resolution: Fixed Thanks for the feedback. I have applied the second patch in Rev. 1649858 (and I hope I got the formatting right this time :-) ) > Improve Service access time > --- > > Key: FELIX-4692 > URL: https://issues.apache.org/jira/browse/FELIX-4692 > Project: Felix > Issue Type: Improvement > Components: Framework >Affects Versions: framework-4.4.1 >Reporter: Felix Meschberger >Assignee: Felix Meschberger > Fix For: framework-4.6.0 > > Attachments: FELIX-4692-2.patch, FELIX-4692.diff > > > Currently the ServiceRegistry takes roughly 1ms to access a single service. > In a reasonably large system, this may over time consume considerable time. > For example in our inhouse system sporting roughly 5000 services with 15'000 > service accesses during startup, these accesses acount for almost 15 seconds > or roughly 25-30% of the total startup time. > Internally all accesses to services are handled with a Filter even if the > service is simply retrieved with the service name without a filter. This > causes a considerable overhead. > A simple improvement is to keep services not only in a global Capabitliy Set > accessible through generic filters but also keep such a set for each > registered service name. > The measured improvement of this change is substantial: accessing these > 15'000 services now only takes roughly 3 seconds or 0.2 ms per service or 5 > times faster. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (FELIX-4692) Improve Service access time
[
https://issues.apache.org/jira/browse/FELIX-4692?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14265944#comment-14265944
]
Felix Meschberger commented on FELIX-4692:
--
For illustration purposes some measurments of the
{{ServiceRegistry.getServiceReferences(String className, SimpleFilter filter)}}
method.
|| Period || #1 || #2|| #3 || #4|| #5||
#6 || ||
| Startup | 8720 | 8720 | 8720 | 8720 | 8722 | 8720 | calls
to getServiceReferences method |
| | 4074 | 3983 | 3740 | 1397 | 1086 | 1017 |
Total ms spent in method |
| Startup + Shutdown | 15093 | 15105 | 15075 | 15091 | 15199 | 15197 | calls to
getServiceReferences method |
| | 12951 | 13039 | 12012 | 4336 | 3144 | 3101
| Total ms spent in method |
# Unmodified framework at Rev. 1649764
# Guard {{matches.retainAll(caps)}} call only -- not that much of an influence,
interestingly; probably not doing much work most of the time due to small set
of entries in the matches set.
# Guard {{matches.retainAll(caps)}} call and not wrapping set in ArrayList --
some more improvement, nothing drammatic yet
# Guard {{matches.retainAll(caps)}} call, not wrapping set in ArrayList,
special case code (not in the patch) to specially handle
{{SimpleFilter.PRESENT}} filters - starts to go into the right direction
# [^FELIX-4692-2.patch] applied -- since the presence check derives from access
to services with a {{null}} service interface, changing the filter to
{{MATCH_ALL}} instead looks even better and makes for simpler code in the
{{CapabilitySet}} not requiring special handling of the presence check.
# [^FELIX-4692.diff] applied -- best numbers but most complex and thus not used.
All tests are run on an mid-2013 MacBook Air 13 with 1.7 GHz Intel Core i7, 8GB
RAM, and SSD. The absolute values vary but relative values across the options
are interesting.
> Improve Service access time
> ---
>
> Key: FELIX-4692
> URL: https://issues.apache.org/jira/browse/FELIX-4692
> Project: Felix
> Issue Type: Improvement
> Components: Framework
>Affects Versions: framework-4.4.1
>Reporter: Felix Meschberger
>Assignee: Felix Meschberger
> Fix For: framework-4.6.0
>
> Attachments: FELIX-4692-2.patch, FELIX-4692.diff
>
>
> Currently the ServiceRegistry takes roughly 1ms to access a single service.
> In a reasonably large system, this may over time consume considerable time.
> For example in our inhouse system sporting roughly 5000 services with 15'000
> service accesses during startup, these accesses acount for almost 15 seconds
> or roughly 25-30% of the total startup time.
> Internally all accesses to services are handled with a Filter even if the
> service is simply retrieved with the service name without a filter. This
> causes a considerable overhead.
> A simple improvement is to keep services not only in a global Capabitliy Set
> accessible through generic filters but also keep such a set for each
> registered service name.
> The measured improvement of this change is substantial: accessing these
> 15'000 services now only takes roughly 3 seconds or 0.2 ms per service or 5
> times faster.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (FELIX-4692) Improve Service access time
[ https://issues.apache.org/jira/browse/FELIX-4692?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger updated FELIX-4692: - Attachment: FELIX-4692-2.patch Simpler patch with three changes as described in previous comment. > Improve Service access time > --- > > Key: FELIX-4692 > URL: https://issues.apache.org/jira/browse/FELIX-4692 > Project: Felix > Issue Type: Improvement > Components: Framework >Affects Versions: framework-4.4.1 >Reporter: Felix Meschberger >Assignee: Felix Meschberger > Fix For: framework-4.6.0 > > Attachments: FELIX-4692-2.patch, FELIX-4692.diff > > > Currently the ServiceRegistry takes roughly 1ms to access a single service. > In a reasonably large system, this may over time consume considerable time. > For example in our inhouse system sporting roughly 5000 services with 15'000 > service accesses during startup, these accesses acount for almost 15 seconds > or roughly 25-30% of the total startup time. > Internally all accesses to services are handled with a Filter even if the > service is simply retrieved with the service name without a filter. This > causes a considerable overhead. > A simple improvement is to keep services not only in a global Capabitliy Set > accessible through generic filters but also keep such a set for each > registered service name. > The measured improvement of this change is substantial: accessing these > 15'000 services now only takes roughly 3 seconds or 0.2 ms per service or 5 > times faster. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (FELIX-4692) Improve Service access time
[
https://issues.apache.org/jira/browse/FELIX-4692?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14265906#comment-14265906
]
Felix Meschberger commented on FELIX-4692:
--
Digging a bit deeper, I found the following opportunities for improvements:
# In the {{CapabilitySet.match(Set<> caps, SimpleFilter sf)}} method on line
239 the {{matches.retainAll(caps)}} call is guarded by an {{if (caps !=
m_capSet)}}
# The {{ServiceRegistry.getServiceReferences(String className, SimpleFilter
filter)}} method returns the set from the {{CapabilitySet.match(SimplerFilter,
boolean)}} method directly without copying that into an ArrayList. This
requires a slight adaption in the {{Felix.getServiceReferences(BundleImpl,
String, String, boolean)}} method.
# Using a {{SimpleFilter.MATCH_ALL}} filter instead of a filter which checks
for the objectclass property presence.
This last change has a drammatic impact in our use case, because the presence
checks caused lots of "useless" property access because the objectclasses
property is always present for services and hence just simply matching all
services is correct. The reason for this impact is that we leverage the Aries
JMX bundles which do repeated {{BundleContext.getAllServiceReferences(null,
null)}} calls (maybe worth investigating on another route).
With these three changes I come close to the improvements compared to attached
patch [^FELIX-4692.diff] but they have a much lower impact. So I will create a
new patch with these changes.
> Improve Service access time
> ---
>
> Key: FELIX-4692
> URL: https://issues.apache.org/jira/browse/FELIX-4692
> Project: Felix
> Issue Type: Improvement
> Components: Framework
>Affects Versions: framework-4.4.1
>Reporter: Felix Meschberger
>Assignee: Felix Meschberger
> Fix For: framework-4.6.0
>
> Attachments: FELIX-4692.diff
>
>
> Currently the ServiceRegistry takes roughly 1ms to access a single service.
> In a reasonably large system, this may over time consume considerable time.
> For example in our inhouse system sporting roughly 5000 services with 15'000
> service accesses during startup, these accesses acount for almost 15 seconds
> or roughly 25-30% of the total startup time.
> Internally all accesses to services are handled with a Filter even if the
> service is simply retrieved with the service name without a filter. This
> causes a considerable overhead.
> A simple improvement is to keep services not only in a global Capabitliy Set
> accessible through generic filters but also keep such a set for each
> registered service name.
> The measured improvement of this change is substantial: accessing these
> 15'000 services now only takes roughly 3 seconds or 0.2 ms per service or 5
> times faster.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (FELIX-4704) Show ranking in web console services plugin
[
https://issues.apache.org/jira/browse/FELIX-4704?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14264411#comment-14264411
]
Felix Meschberger commented on FELIX-4704:
--
bq. while often important
It is actually not very important that often ... But it really depends on your
concrete use case and so YMMV (and, yes if you need it, you need it badly, also
applies :-) )
> Show ranking in web console services plugin
> ---
>
> Key: FELIX-4704
> URL: https://issues.apache.org/jira/browse/FELIX-4704
> Project: Felix
> Issue Type: Improvement
> Components: Web Console
>Reporter: Alexander Klimetschek
>Assignee: Carsten Ziegeler
>Priority: Minor
> Fix For: webconsole-4.2.6
>
> Attachments: FELIX-4704.patch, screenshot.png
>
>
> The service ranking is an important property of services and one often needs
> to look for all implementations of a given service and sort them by their
> ranking - to list them in the order they are used by some other component.
> Thus adding a new column to the services table that can be sorted like the
> other ones would be really helpful. Filtering down to one service interface
> is already possible since FELIX-4202 (e.g. {{(objectclass=*.MyService}}).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (FELIX-4704) Show ranking in web console services plugin
[
https://issues.apache.org/jira/browse/FELIX-4704?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14264409#comment-14264409
]
Felix Meschberger commented on FELIX-4704:
--
Ok
> Show ranking in web console services plugin
> ---
>
> Key: FELIX-4704
> URL: https://issues.apache.org/jira/browse/FELIX-4704
> Project: Felix
> Issue Type: Improvement
> Components: Web Console
>Reporter: Alexander Klimetschek
>Assignee: Carsten Ziegeler
>Priority: Minor
> Fix For: webconsole-4.2.6
>
> Attachments: FELIX-4704.patch, screenshot.png
>
>
> The service ranking is an important property of services and one often needs
> to look for all implementations of a given service and sort them by their
> ranking - to list them in the order they are used by some other component.
> Thus adding a new column to the services table that can be sorted like the
> other ones would be really helpful. Filtering down to one service interface
> is already possible since FELIX-4202 (e.g. {{(objectclass=*.MyService}}).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (FELIX-3773) WebConsole uses library with ASL-incompatible licence
[ https://issues.apache.org/jira/browse/FELIX-3773?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14264405#comment-14264405 ] Felix Meschberger commented on FELIX-3773: -- I like this very much. We should get started with some concepts of how to build the next generation Web Console and its API. We can still see how we can support old Web Console 3/4 plugins with some kind of a compat/bridge bundle. As for JSON, I am really fine. As for RPC, I am more weary -- I prefer proper REST style. :-) As for plugin.*: Sounds like a good approach. Since we would have .html, .css, and .js in most cases, we might want to define a plugin service registration property setting the base name where the property defaults to "plugin" if missing. The reason fo adding another service property is to allow for multiple plugins with different helper files to be embedded in a single bundle (e.g. the Web Console Core bundle itself). > WebConsole uses library with ASL-incompatible licence > - > > Key: FELIX-3773 > URL: https://issues.apache.org/jira/browse/FELIX-3773 > Project: Felix > Issue Type: Bug > Components: Web Console >Affects Versions: webconsole-4.0.0 >Reporter: Neil Bartlett >Priority: Critical > > WebConsole uses the JSON library from json.org that contains the following > term in its licence (http://www.json.org/license.html): > "The Software shall be used for Good, not Evil." > I believe that this restriction is incompatible with the ASL. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (FELIX-4692) Improve Service access time
[
https://issues.apache.org/jira/browse/FELIX-4692?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14264296#comment-14264296
]
Felix Meschberger commented on FELIX-4692:
--
bq. Looking at the code of CapabilitySet.match(Set<> caps, SimpleFilter sf) on
line 239 we do "matches.retainAll(caps)" which in your case caps would be your
10k services, so I expect that this is where you see the slowdown.
Interestingly I just found a draft message in my inbox which comes to the exact
same conclusion. I like your proposal of only retaining all if {{(caps !=
m_capSet)}}.
> Improve Service access time
> ---
>
> Key: FELIX-4692
> URL: https://issues.apache.org/jira/browse/FELIX-4692
> Project: Felix
> Issue Type: Improvement
> Components: Framework
>Affects Versions: framework-4.4.1
>Reporter: Felix Meschberger
>Assignee: Felix Meschberger
> Fix For: framework-4.6.0
>
> Attachments: FELIX-4692.diff
>
>
> Currently the ServiceRegistry takes roughly 1ms to access a single service.
> In a reasonably large system, this may over time consume considerable time.
> For example in our inhouse system sporting roughly 5000 services with 15'000
> service accesses during startup, these accesses acount for almost 15 seconds
> or roughly 25-30% of the total startup time.
> Internally all accesses to services are handled with a Filter even if the
> service is simply retrieved with the service name without a filter. This
> causes a considerable overhead.
> A simple improvement is to keep services not only in a global Capabitliy Set
> accessible through generic filters but also keep such a set for each
> registered service name.
> The measured improvement of this change is substantial: accessing these
> 15'000 services now only takes roughly 3 seconds or 0.2 ms per service or 5
> times faster.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (FELIX-4704) Show ranking in web console services plugin
[
https://issues.apache.org/jira/browse/FELIX-4704?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14264260#comment-14264260
]
Felix Meschberger edited comment on FELIX-4704 at 1/5/15 7:13 AM:
--
While I appreciate this patch and the importance of the service.ranking
property, I really think the service.ranking property is not important on a
general level. But maybe it makes sense to expose it explicitly in the list.
Regardless, I still have some issues with the simplistic approach here: First I
don't think we should show the service.ranking in the second column even before
the service types. Maybe the last column is more appropriate.
Second, and more subtle, though, is that the service.ranking property is not
generally used on a global level across all services but amongst services of a
specific type. So I doubt the general usefulness of sorting the global service
table by the service.ranking property.
Finally, whether a certain service is actually used by a particular consumer
depends on more than the service.ranking itself. For example the whether a
filter has been used to select the service. Or how the Declarative Services
@Reference is setup (static vs. dynamic policy, target filter).
was (Author: fmeschbe):
While I appreciate this patch and the importance of the service.ranking
property, I really think the service.ranking property is not important on a
general level. But maybe it makes sense to expose it explicitly in the list.
Regardless, I still have some issues with the simplistic approach here: First I
don't think we should show the service.ranking in the second column even before
the service types. Maybe the last column is more appropriate.
Second, and more subtle, though, is that the service.ranking property is not
generally used on a global level across all services but amongst services of a
specific type. So I doubt the general usefulness of sorting the global service
table by the service.ranking property.
> Show ranking in web console services plugin
> ---
>
> Key: FELIX-4704
> URL: https://issues.apache.org/jira/browse/FELIX-4704
> Project: Felix
> Issue Type: Improvement
> Components: Web Console
>Reporter: Alexander Klimetschek
>Assignee: Carsten Ziegeler
>Priority: Minor
> Fix For: webconsole-4.2.6
>
> Attachments: FELIX-4704.patch, screenshot.png
>
>
> The service ranking is an important property of services and one often needs
> to look for all implementations of a given service and sort them by their
> ranking - to list them in the order they are used by some other component.
> Thus adding a new column to the services table that can be sorted like the
> other ones would be really helpful. Filtering down to one service interface
> is already possible since FELIX-4202 (e.g. {{(objectclass=*.MyService}}).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (FELIX-4704) Show ranking in web console services plugin
[
https://issues.apache.org/jira/browse/FELIX-4704?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14264260#comment-14264260
]
Felix Meschberger commented on FELIX-4704:
--
While I appreciate this patch and the importance of the service.ranking
property, I really think the service.ranking property is not important on a
general level. But maybe it makes sense to expose it explicitly in the list.
Regardless, I still have some issues with the simplistic approach here: First I
don't think we should show the service.ranking in the second column even before
the service types. Maybe the last column is more appropriate.
Second, and more subtle, though, is that the service.ranking property is not
generally used on a global level across all services but amongst services of a
specific type. So I doubt the general usefulness of sorting the global service
table by the service.ranking property.
> Show ranking in web console services plugin
> ---
>
> Key: FELIX-4704
> URL: https://issues.apache.org/jira/browse/FELIX-4704
> Project: Felix
> Issue Type: Improvement
> Components: Web Console
>Reporter: Alexander Klimetschek
>Assignee: Carsten Ziegeler
>Priority: Minor
> Fix For: webconsole-4.2.6
>
> Attachments: FELIX-4704.patch, screenshot.png
>
>
> The service ranking is an important property of services and one often needs
> to look for all implementations of a given service and sort them by their
> ranking - to list them in the order they are used by some other component.
> Thus adding a new column to the services table that can be sorted like the
> other ones would be really helpful. Filtering down to one service interface
> is already possible since FELIX-4202 (e.g. {{(objectclass=*.MyService}}).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (FELIX-4734) Web Console RESTful API should wait for asynchonous operations until they complete
[
https://issues.apache.org/jira/browse/FELIX-4734?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14253595#comment-14253595
]
Felix Meschberger commented on FELIX-4734:
--
Please make sure to not cause deadlocks ! We had situations in the past where
the web console bundle itself was involved in the update and refreshPackage
operations and when not properly handling this, this may cause a deadlock !
> Web Console RESTful API should wait for asynchonous operations until they
> complete
> ---
>
> Key: FELIX-4734
> URL: https://issues.apache.org/jira/browse/FELIX-4734
> Project: Felix
> Issue Type: Bug
> Components: Web Console
>Affects Versions: webconsole-4.2.4
>Reporter: Konrad Windszus
> Attachments: FELIX-4734.patch
>
>
> Currently the RESTful API
> (http://felix.apache.org/documentation/subprojects/apache-felix-web-console/web-console-restful-api.html)
> adds a delay of 800ms to the response to give the asynchronous operations
> enough time to complete successfully
> (https://github.com/apache/felix/blob/trunk/webconsole/src/main/java/org/apache/felix/webconsole/internal/core/BundlesServlet.java#L412).
> Instead the according listeners should be used which are notified upon
> completion of an asynchronous task.
> For {{refresh}} {{FrameworkWiring.refreshBundles}} can be used
> (http://www.osgi.org/javadoc/r4v43/core/org/osgi/framework/wiring/FrameworkWiring.html#refreshBundles%28java.util.Collection,%20org.osgi.framework.FrameworkListener...%29).
> A similar approach should be used for the other actions like uninstall,
> install, update, start, stop, ...
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (FELIX-4692) Improve Service access time
[ https://issues.apache.org/jira/browse/FELIX-4692?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14253374#comment-14253374 ] Felix Meschberger commented on FELIX-4692: -- [~cziegeler] For the reasons stated by [~rickhall] I would not apply the patch yet. Looking at the code, it really *is* strange that this patch exhibits such a dramatic improvement. I wanted to find out, what actually is going on in the indexed capability set which really should have a quick (or almost as quick) exit as my patch. > Improve Service access time > --- > > Key: FELIX-4692 > URL: https://issues.apache.org/jira/browse/FELIX-4692 > Project: Felix > Issue Type: Improvement > Components: Framework >Affects Versions: framework-4.4.1 >Reporter: Felix Meschberger >Assignee: Felix Meschberger > Fix For: framework-4.6.0 > > Attachments: FELIX-4692.diff > > > Currently the ServiceRegistry takes roughly 1ms to access a single service. > In a reasonably large system, this may over time consume considerable time. > For example in our inhouse system sporting roughly 5000 services with 15'000 > service accesses during startup, these accesses acount for almost 15 seconds > or roughly 25-30% of the total startup time. > Internally all accesses to services are handled with a Filter even if the > service is simply retrieved with the service name without a filter. This > causes a considerable overhead. > A simple improvement is to keep services not only in a global Capabitliy Set > accessible through generic filters but also keep such a set for each > registered service name. > The measured improvement of this change is substantial: accessing these > 15'000 services now only takes roughly 3 seconds or 0.2 ms per service or 5 > times faster. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (FELIX-4730) RequestDispatcher's servletPath is wrong for the root servlet
[ https://issues.apache.org/jira/browse/FELIX-4730?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger resolved FELIX-4730. -- Resolution: Fixed Fix Version/s: http-2.4.0 Fixed in Rev. 1644885 by applying using the empty string as the servlet path if the alias denotes the root servlet -- this is the same logic as in ServletHandlerRequest.getServletPath > RequestDispatcher's servletPath is wrong for the root servlet > - > > Key: FELIX-4730 > URL: https://issues.apache.org/jira/browse/FELIX-4730 > Project: Felix > Issue Type: Bug > Components: HTTP Service >Affects Versions: http-2.3.2 >Reporter: Felix Meschberger >Assignee: Felix Meschberger > Fix For: http-2.4.0 > > > ServletHandler.RequestDispatcherImpl uses the servlet alias unmodified as the > servlet path for forwarded requests. In case of the root servlet resgistered > with "/", this should actually be converted to the empty string according to > the specification of ServletRequest.getServletPath(). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (FELIX-4730) RequestDispatcher's servletPath is wrong for the root servlet
Felix Meschberger created FELIX-4730: Summary: RequestDispatcher's servletPath is wrong for the root servlet Key: FELIX-4730 URL: https://issues.apache.org/jira/browse/FELIX-4730 Project: Felix Issue Type: Bug Components: HTTP Service Affects Versions: http-2.3.2 Reporter: Felix Meschberger Assignee: Felix Meschberger ServletHandler.RequestDispatcherImpl uses the servlet alias unmodified as the servlet path for forwarded requests. In case of the root servlet resgistered with "/", this should actually be converted to the empty string according to the specification of ServletRequest.getServletPath(). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (FELIX-4720) Web Console and Gogo rely on Log history buffer in the Log Service
[ https://issues.apache.org/jira/browse/FELIX-4720?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14240770#comment-14240770 ] Felix Meschberger commented on FELIX-4720: -- Somehow I have the impression, that yes, the Web Console (or Gogo for that matter) should not do what [~pkriens] proposes because its none its/their business. On the other hand, from a practical and problem solving point of view, I agree with Peter that these tools should go to some length to help solving problems. I think the Web Console and Gogo stand special in the landscape of OSGi bundles in that they are tools for application administrators. As such they should do the best they can to support those (sometimes) poor guys. So, yes, lets build a simple circular buffer of log messages in the Web Console and Gogo: * Create a new administrative log support bundle * Inherit the LogServlet from Web Console core * Inherit logging support commands from Gogo Command (Basic class) * Dynamic package imports to Web Console and Gogo API (as needed) * Can be deployed very early independently of Web Console proper and Gogo to start collecting logs * Maintains its own log entries which have weak references to the Throwables * Gathers the entries in a circular buffer of configurable size WDYT ? > Web Console and Gogo rely on Log history buffer in the Log Service > -- > > Key: FELIX-4720 > URL: https://issues.apache.org/jira/browse/FELIX-4720 > Project: Felix > Issue Type: Bug > Components: Gogo Command, Web Console >Reporter: Peter Kriens > > The OSGi Log Reader Service has a command to get the history of the log. > However, the specification states that this history can be empty. The Equinox > framework is nowadays registering a Log Reader Service that has such an empty > history to prevent pinning objects in memory. > Using the history this way was always at odds with the specification since > the history was only intended to hold the start up events. The primary model > of the Log Service is a dispatcher. > I suggest that the Gogo log command and the Web Console maintain their own > history buffer to become independent on this fragile history buffer in the > Log Reader service. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (FELIX-4696) Improve native OS version sanitation
[ https://issues.apache.org/jira/browse/FELIX-4696?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger updated FELIX-4696: - Attachment: FELIX-4696.patch Proposed patch taking code from the DefaultMaven2OsgiConverter class of the Bundle Maven Plugin. > Improve native OS version sanitation > > > Key: FELIX-4696 > URL: https://issues.apache.org/jira/browse/FELIX-4696 > Project: Felix > Issue Type: Improvement > Components: Framework >Affects Versions: framework-4.4.1 >Reporter: Felix Meschberger >Assignee: Felix Meschberger > Fix For: framework-4.6.0 > > Attachments: FELIX-4696.patch > > > The Native OS version sanitation currently simply tries to parse the native > OS version and if failing falls back to 0.0.0. > I think it would be better to actually properly sanitize the version similar > to what the DefaultMaven2OsgiConverter class of the Bundle Maven Plugin does. > So for example, a FC9 version of "3.14.22-100.fc19.i686.PAE" would then be > converted to "3.14.22.100_fc19_i686_PAE" which is much more suited to real > world use. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (FELIX-4696) Improve native OS version sanitation
Felix Meschberger created FELIX-4696: Summary: Improve native OS version sanitation Key: FELIX-4696 URL: https://issues.apache.org/jira/browse/FELIX-4696 Project: Felix Issue Type: Improvement Components: Framework Affects Versions: framework-4.4.1 Reporter: Felix Meschberger Assignee: Felix Meschberger Fix For: framework-4.6.0 The Native OS version sanitation currently simply tries to parse the native OS version and if failing falls back to 0.0.0. I think it would be better to actually properly sanitize the version similar to what the DefaultMaven2OsgiConverter class of the Bundle Maven Plugin does. So for example, a FC9 version of "3.14.22-100.fc19.i686.PAE" would then be converted to "3.14.22.100_fc19_i686_PAE" which is much more suited to real world use. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (FELIX-4695) Normalize os.version system property in framework properties
[ https://issues.apache.org/jira/browse/FELIX-4695?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger updated FELIX-4695: - Attachment: FELIX-4695-Felix.patch FELIX-4695-ExtensionManager.patch Two mutually "exclusive" patches: One against the Felix class causing the org.osgi.framework.os.version property to be a valid Version value string. This would be in line of my reading section 4.2.2, Launching Propertes, of OSGi Core R6: bq. The version of the operating system as used in the native code clause. If not set, then the framework must provide a default value. If the operating system reported version does not fit the standard version syntax (e.g. 2.4.32-kwt), then the launcher should define this launching property with a valid version value. The other patch is against the ExtensionManager building the native capabilities. This would ensure the native capability property is a valid version. Looking at cited section 4.2.2, I would probably prefer the patch against the Felix class to ensure the framework properties contain a valid OSGi Version string. WDYT ? > Normalize os.version system property in framework properties > > > Key: FELIX-4695 > URL: https://issues.apache.org/jira/browse/FELIX-4695 > Project: Felix > Issue Type: Bug > Components: Framework >Affects Versions: framework-4.4.1 >Reporter: Felix Meschberger >Assignee: Felix Meschberger > Fix For: framework-4.6.0 > > Attachments: FELIX-4695-ExtensionManager.patch, FELIX-4695-Felix.patch > > > The Felix class currently normalizes the processor name and os name system > property before putting it into the framework properties. > Likewise the os version system property should be normalized as well. > Symptom of not normalizing the os version is the > ExtensionManager.buildNativeCapabilites method failing to create the os > version. > Alternatively, the ExtensionManager.buildNativeCapabilites method could > itself normalize the os.version framework property. This would prevent the > method from failing and would still allow the R4LibraryClause to match an os > version capability (R4LlibraryClause does normalize the os version in the > clause of the bundle before matching). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (FELIX-4695) Normalize os.version system property in framework properties
Felix Meschberger created FELIX-4695: Summary: Normalize os.version system property in framework properties Key: FELIX-4695 URL: https://issues.apache.org/jira/browse/FELIX-4695 Project: Felix Issue Type: Bug Components: Framework Affects Versions: framework-4.4.1 Reporter: Felix Meschberger Assignee: Felix Meschberger Fix For: framework-4.6.0 The Felix class currently normalizes the processor name and os name system property before putting it into the framework properties. Likewise the os version system property should be normalized as well. Symptom of not normalizing the os version is the ExtensionManager.buildNativeCapabilites method failing to create the os version. Alternatively, the ExtensionManager.buildNativeCapabilites method could itself normalize the os.version framework property. This would prevent the method from failing and would still allow the R4LibraryClause to match an os version capability (R4LlibraryClause does normalize the os version in the clause of the bundle before matching). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (FELIX-4692) Improve Service access time
[ https://issues.apache.org/jira/browse/FELIX-4692?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger updated FELIX-4692: - Attachment: FELIX-4692.diff Patch with the proposed change. > Improve Service access time > --- > > Key: FELIX-4692 > URL: https://issues.apache.org/jira/browse/FELIX-4692 > Project: Felix > Issue Type: Improvement > Components: Framework >Affects Versions: framework-4.4.1 >Reporter: Felix Meschberger >Assignee: Felix Meschberger > Fix For: framework-4.6.0 > > Attachments: FELIX-4692.diff > > > Currently the ServiceRegistry takes roughly 1ms to access a single service. > In a reasonably large system, this may over time consume considerable time. > For example in our inhouse system sporting roughly 5000 services with 15'000 > service accesses during startup, these accesses acount for almost 15 seconds > or roughly 25-30% of the total startup time. > Internally all accesses to services are handled with a Filter even if the > service is simply retrieved with the service name without a filter. This > causes a considerable overhead. > A simple improvement is to keep services not only in a global Capabitliy Set > accessible through generic filters but also keep such a set for each > registered service name. > The measured improvement of this change is substantial: accessing these > 15'000 services now only takes roughly 3 seconds or 0.2 ms per service or 5 > times faster. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (FELIX-4692) Improve Service access time
Felix Meschberger created FELIX-4692: Summary: Improve Service access time Key: FELIX-4692 URL: https://issues.apache.org/jira/browse/FELIX-4692 Project: Felix Issue Type: Improvement Components: Framework Affects Versions: framework-4.4.1 Reporter: Felix Meschberger Assignee: Felix Meschberger Fix For: framework-4.6.0 Currently the ServiceRegistry takes roughly 1ms to access a single service. In a reasonably large system, this may over time consume considerable time. For example in our inhouse system sporting roughly 5000 services with 15'000 service accesses during startup, these accesses acount for almost 15 seconds or roughly 25-30% of the total startup time. Internally all accesses to services are handled with a Filter even if the service is simply retrieved with the service name without a filter. This causes a considerable overhead. A simple improvement is to keep services not only in a global Capabitliy Set accessible through generic filters but also keep such a set for each registered service name. The measured improvement of this change is substantial: accessing these 15'000 services now only takes roughly 3 seconds or 0.2 ms per service or 5 times faster. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (FELIX-4674) Allow inclusion/exclusion of protocols in SSL connector
[ https://issues.apache.org/jira/browse/FELIX-4674?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger resolved FELIX-4674. -- Resolution: Fixed Fix Version/s: http-2.3.2 Thanks for providing the patch. I have applied it somewhat extended in Rev. 1633120 The extension is to additionally support the included protocols for whitelisting and to add some more explanations to the property descriptions. > Allow inclusion/exclusion of protocols in SSL connector > --- > > Key: FELIX-4674 > URL: https://issues.apache.org/jira/browse/FELIX-4674 > Project: Felix > Issue Type: Improvement > Components: HTTP Service >Affects Versions: http-2.3.0 >Reporter: Dominique Pfister >Assignee: Felix Meschberger > Fix For: http-2.3.2 > > Attachments: patch.txt > > > With the recent security attack discovered called "POODLE" [1], it would be > great to make the set of SSL protocols Jetty accepts configurable through > OSGI. I suggest to introduce a string array property containing the list of > protocols to disable, e.g. [ "SSLv3" ]. > [1] https://zmap.io/sslv3/ -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (FELIX-4674) Allow inclusion/exclusion of protocols in SSL connector
[ https://issues.apache.org/jira/browse/FELIX-4674?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger reassigned FELIX-4674: Assignee: Felix Meschberger > Allow inclusion/exclusion of protocols in SSL connector > --- > > Key: FELIX-4674 > URL: https://issues.apache.org/jira/browse/FELIX-4674 > Project: Felix > Issue Type: Improvement > Components: HTTP Service >Affects Versions: http-2.3.0 >Reporter: Dominique Pfister >Assignee: Felix Meschberger > Attachments: patch.txt > > > With the recent security attack discovered called "POODLE" [1], it would be > great to make the set of SSL protocols Jetty accepts configurable through > OSGI. I suggest to introduce a string array property containing the list of > protocols to disable, e.g. [ "SSLv3" ]. > [1] https://zmap.io/sslv3/ -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (FELIX-4664) [SSLFilter] Support for pre-3.0 Servlet API
[ https://issues.apache.org/jira/browse/FELIX-4664?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger resolved FELIX-4664. -- Resolution: Fixed Fix Version/s: http-sslfilter-0.2.0 http-2.3.2 Assignee: Felix Meschberger Applied the patch in Rev. 1629609 > [SSLFilter] Support for pre-3.0 Servlet API > --- > > Key: FELIX-4664 > URL: https://issues.apache.org/jira/browse/FELIX-4664 > Project: Felix > Issue Type: Bug > Components: HTTP Service >Affects Versions: http-2.3.0, http-sslfilter-0.1.0 >Reporter: Felix Meschberger >Assignee: Felix Meschberger > Fix For: http-2.3.2, http-sslfilter-0.2.0 > > Attachments: FELIX-4664.patch > > > The SSL Filter bundle currently inherits the Servlet API dependency from the > parent project which sets it to Servlet API 3.0. > Actually, the filter itself does not depend at all on Servlet API 3.0 and the > dependency should probably be fixed to a reduced version number -- maybe even > the lowest version still compiling... > There is one caveat: unit tests currently use HttpServletResponse.getHeader > method which has been introduced with Servlet API 3.0. So the tests need to > be tweaked. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (FELIX-4664) [SSLFilter] Support for pre-3.0 Servlet API
[ https://issues.apache.org/jira/browse/FELIX-4664?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger updated FELIX-4664: - Attachment: FELIX-4664.patch Proposed patch. > [SSLFilter] Support for pre-3.0 Servlet API > --- > > Key: FELIX-4664 > URL: https://issues.apache.org/jira/browse/FELIX-4664 > Project: Felix > Issue Type: Bug > Components: HTTP Service >Affects Versions: http-2.3.0, http-sslfilter-0.1.0 >Reporter: Felix Meschberger > Attachments: FELIX-4664.patch > > > The SSL Filter bundle currently inherits the Servlet API dependency from the > parent project which sets it to Servlet API 3.0. > Actually, the filter itself does not depend at all on Servlet API 3.0 and the > dependency should probably be fixed to a reduced version number -- maybe even > the lowest version still compiling... > There is one caveat: unit tests currently use HttpServletResponse.getHeader > method which has been introduced with Servlet API 3.0. So the tests need to > be tweaked. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (FELIX-4664) [SSLFilter] Support for pre-3.0 Servlet API
Felix Meschberger created FELIX-4664: Summary: [SSLFilter] Support for pre-3.0 Servlet API Key: FELIX-4664 URL: https://issues.apache.org/jira/browse/FELIX-4664 Project: Felix Issue Type: Bug Components: HTTP Service Affects Versions: http-sslfilter-0.1.0, http-2.3.0 Reporter: Felix Meschberger The SSL Filter bundle currently inherits the Servlet API dependency from the parent project which sets it to Servlet API 3.0. Actually, the filter itself does not depend at all on Servlet API 3.0 and the dependency should probably be fixed to a reduced version number -- maybe even the lowest version still compiling... There is one caveat: unit tests currently use HttpServletResponse.getHeader method which has been introduced with Servlet API 3.0. So the tests need to be tweaked. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (FELIX-4530) [SCR Plugin] Revisit setting the default output to target/classes
[
https://issues.apache.org/jira/browse/FELIX-4530?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14032215#comment-14032215
]
Felix Meschberger commented on FELIX-4530:
--
[~cziegeler] It's about a default behaviour of the bundle plugin and how the
SCR plugin interferes.
I am absolutely in favor of the SCR plugin adding the generated descriptors to
the project resources. But this is just the manifests not the complete folder
where they reside in.
If the only way to add the desciptors is to add the complete descriptor target
folder, then using target/classes is not a good idea because then you loose all
the fine tuning that the bundle plugin and bnd offer.
And maybe, it is the Sling tooling which should be more intelligent ?
> [SCR Plugin] Revisit setting the default output to target/classes
> -
>
> Key: FELIX-4530
> URL: https://issues.apache.org/jira/browse/FELIX-4530
> Project: Felix
> Issue Type: Bug
> Components: SCR Tooling
>Affects Versions: maven-scr-plugin 1.17.0
>Reporter: Felix Meschberger
>Priority: Critical
> Fix For: maven-scr-plugin 1.17.2
>
>
> With FELIX-4241 the default value for the descriptor output files has been
> set to {{target/classes}}. Unfortunately this causes {{target/classes}} to be
> added to the Maven Input Resources resulting in all contents of
> {{target/classes}} to be included in the final bundle regardless of whether
> this is actually desired or not.
> Regardless of tooling integration noted in FELIX-4241, it is against the
> spirit of the bundle plugin to blindly include everything in
> {{target/classes}} in the bundle. So the resolution for FELIX-4241 must be
> revisited.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (FELIX-4530) [SCR Plugin] Revisit setting the default output to target/classes
[
https://issues.apache.org/jira/browse/FELIX-4530?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Felix Meschberger updated FELIX-4530:
-
Fix Version/s: maven-scr-plugin 1.17.2
> [SCR Plugin] Revisit setting the default output to target/classes
> -
>
> Key: FELIX-4530
> URL: https://issues.apache.org/jira/browse/FELIX-4530
> Project: Felix
> Issue Type: Bug
> Components: SCR Tooling
>Affects Versions: maven-scr-plugin 1.17.0
>Reporter: Felix Meschberger
>Priority: Critical
> Fix For: maven-scr-plugin 1.17.2
>
>
> With FELIX-4241 the default value for the descriptor output files has been
> set to {{target/classes}}. Unfortunately this causes {{target/classes}} to be
> added to the Maven Input Resources resulting in all contents of
> {{target/classes}} to be included in the final bundle regardless of whether
> this is actually desired or not.
> Regardless of tooling integration noted in FELIX-4241, it is against the
> spirit of the bundle plugin to blindly include everything in
> {{target/classes}} in the bundle. So the resolution for FELIX-4241 must be
> revisited.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Created] (FELIX-4530) [SCR Plugin] Revisit setting the default output to target/classes
Felix Meschberger created FELIX-4530:
Summary: [SCR Plugin] Revisit setting the default output to
target/classes
Key: FELIX-4530
URL: https://issues.apache.org/jira/browse/FELIX-4530
Project: Felix
Issue Type: Bug
Components: SCR Tooling
Affects Versions: maven-scr-plugin 1.17.0
Reporter: Felix Meschberger
Priority: Critical
With FELIX-4241 the default value for the descriptor output files has been set
to {{target/classes}}. Unfortunately this causes {{target/classes}} to be added
to the Maven Input Resources resulting in all contents of {{target/classes}} to
be included in the final bundle regardless of whether this is actually desired
or not.
Regardless of tooling integration noted in FELIX-4241, it is against the spirit
of the bundle plugin to blindly include everything in {{target/classes}} in the
bundle. So the resolution for FELIX-4241 must be revisited.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (FELIX-4420) [HTTP SSLFilter] Implement sendRedirect
[ https://issues.apache.org/jira/browse/FELIX-4420?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14007629#comment-14007629 ] Felix Meschberger commented on FELIX-4420: -- [~jajans] +1 Except that I would make "Constants" a final class and rename it to SSLFilterConstants (there are so many Constants classes and interfaces flying around that it is hard to disambiguate them). Thanks. > [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-2.3.0, http-sslfilter-1.0.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-4330) [HTTP SSL Filter] Make SSL header(s) configurable
[ https://issues.apache.org/jira/browse/FELIX-4330?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger updated FELIX-4330: - Attachment: FELIX-4330-fme2.patch Updated patch supporting all four listed headers. > [HTTP SSL Filter] Make SSL header(s) configurable > - > > Key: FELIX-4330 > URL: https://issues.apache.org/jira/browse/FELIX-4330 > Project: Felix > Issue Type: Bug > Components: HTTP Service >Affects Versions: http-2.2.1 >Reporter: Felix Meschberger >Assignee: Felix Meschberger > Attachments: FELIX-4330-fme.patch, FELIX-4330-fme2.patch, > FELIX-4330.patch > > > The request header indicating a proxy terminating an HTTPS connection is > currently hard coded to be "X-Forwarded-SSL" with the only value supported to > be "on" -- based on the assumption of this being the most commonly used > header value. > It looks that Amazon's Elastice Load Balancer uses a different header and > value: X-Forwarded-Proto whose value is the actual protocol by which the > client talks to the load balancer. The filter should kick in if the protocol > is https (or maybe if it is just not the same as the one which the servlet > container reports). > [1] > http://docs.aws.amazon.com/ElasticLoadBalancing/latest/DeveloperGuide/TerminologyandKeyConcepts.html#x-forwarded-proto -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (FELIX-4330) [HTTP SSL Filter] Make SSL header(s) configurable
[
https://issues.apache.org/jira/browse/FELIX-4330?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13988796#comment-13988796
]
Felix Meschberger commented on FELIX-4330:
--
This really *is* a mess: I found mentions of four headers:
* {{X-Forwarded-SSL: on}} – the currently hard coded default value
* {{X-Forwarded-Proto: https}} – [Amazon ELBs hard coded
header|http://docs.aws.amazon.com/ElasticLoadBalancing/latest/DeveloperGuide/TerminologyandKeyConcepts.html#x-forwarded-proto]
and in an Nginx Wiki page on
[SSL-Offload|http://wiki.nginx.org/SSL-Offloader]. Also listed on Wikipedia's
[List of HTTP header
fields|http://en.wikipedia.org/wiki/List_of_HTTP_header_fields] as a quasi
standard.
* {{X-Forwarded-Protocol: https}} – Alternative to X-Forwarded-Proto
* {{Front-End-Https: on}} – Microsoft header, see [Helping to Secure
Communication: Client to Front-End
Server|http://technet.microsoft.com/en-us/library/aa997519%28v=exchg.65%29.aspx].
Also listed on Wikipedia's [List of HTTP header
fields|http://en.wikipedia.org/wiki/List_of_HTTP_header_fields]
I fear we have to provide support for all.
> [HTTP SSL Filter] Make SSL header(s) configurable
> -
>
> Key: FELIX-4330
> URL: https://issues.apache.org/jira/browse/FELIX-4330
> Project: Felix
> Issue Type: Bug
> Components: HTTP Service
>Affects Versions: http-2.2.1
>Reporter: Felix Meschberger
>Assignee: Felix Meschberger
> Attachments: FELIX-4330-fme.patch, FELIX-4330.patch
>
>
> The request header indicating a proxy terminating an HTTPS connection is
> currently hard coded to be "X-Forwarded-SSL" with the only value supported to
> be "on" -- based on the assumption of this being the most commonly used
> header value.
> It looks that Amazon's Elastice Load Balancer uses a different header and
> value: X-Forwarded-Proto whose value is the actual protocol by which the
> client talks to the load balancer. The filter should kick in if the protocol
> is https (or maybe if it is just not the same as the one which the servlet
> container reports).
> [1]
> http://docs.aws.amazon.com/ElasticLoadBalancing/latest/DeveloperGuide/TerminologyandKeyConcepts.html#x-forwarded-proto
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (FELIX-4330) [HTTP SSL Filter] Make SSL header(s) configurable
[ https://issues.apache.org/jira/browse/FELIX-4330?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger updated FELIX-4330: - Attachment: FELIX-4330-fme.patch Proposing a slightly more complicated version which allows configuration of the header value and property. WDYT ? > [HTTP SSL Filter] Make SSL header(s) configurable > - > > Key: FELIX-4330 > URL: https://issues.apache.org/jira/browse/FELIX-4330 > Project: Felix > Issue Type: Bug > Components: HTTP Service >Affects Versions: http-2.2.1 >Reporter: Felix Meschberger >Assignee: Felix Meschberger > Attachments: FELIX-4330-fme.patch, FELIX-4330.patch > > > The request header indicating a proxy terminating an HTTPS connection is > currently hard coded to be "X-Forwarded-SSL" with the only value supported to > be "on" -- based on the assumption of this being the most commonly used > header value. > It looks that Amazon's Elastice Load Balancer uses a different header and > value: X-Forwarded-Proto whose value is the actual protocol by which the > client talks to the load balancer. The filter should kick in if the protocol > is https (or maybe if it is just not the same as the one which the servlet > container reports). > [1] > http://docs.aws.amazon.com/ElasticLoadBalancing/latest/DeveloperGuide/TerminologyandKeyConcepts.html#x-forwarded-proto -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (FELIX-4489) [Jetty] Ignore empty (string) entries in configuration arrays
Felix Meschberger created FELIX-4489: Summary: [Jetty] Ignore empty (string) entries in configuration arrays Key: FELIX-4489 URL: https://issues.apache.org/jira/browse/FELIX-4489 Project: Felix Issue Type: Bug Components: HTTP Service Affects Versions: http-2.2.2 Reporter: Felix Meschberger Assignee: Felix Meschberger When configuring the Jetty Service through the Web Console, the enabled and disabled cipher suites properties might become single-entry lists of empty strings. For cipher suite enablement this essentially means that no suites are actually enabled at all. When configuring the cipher suites such empty entries should in fact be removed from the list and if the list becomes empty, no explicit configuration should be used. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (FELIX-4473) [Jetty] Add support for Jetty Connector injection
[
https://issues.apache.org/jira/browse/FELIX-4473?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13955717#comment-13955717
]
Felix Meschberger commented on FELIX-4473:
--
bq. there's an unused variable ({{connectors}})
That is a transient variable which turns out to not be needed. Would remove
before committing. Thanks for spotting.
bq. the default HTTP and/or HTTPS connectors are installed by default
Actually plain HTTP is enabled by default while HTTPS is disabled by default.
Even if you configure HTTPS it is only enabled if the
{{org.apache.felix.https.enable}} is set to true (or yes) and the HTTPS port is
defined (which it is by default).
So I think we are probably fine since, also if you configure the embedded HTTPS
connector you still have to explicitly disable the plain HTTP connector if you
don't want it.
One additional thing, though: Currently the Jetty server is stopped (aka not
started) if neither HTTP nor HTTPS connector are (or can be) started. With the
{{ConnectorFactory}} we should keep the Jetty server running since a
{{ConnectorFactory}} service can come at any time. Alternatively starting the
Jetty server could be delayed until a {{ConnectorFactory}} service becomes
available (or default HTTP or HTTPS are configured).
> [Jetty] Add support for Jetty Connector injection
> -
>
> Key: FELIX-4473
> URL: https://issues.apache.org/jira/browse/FELIX-4473
> Project: Felix
> Issue Type: Task
> Components: HTTP Service
>Affects Versions: http-2.2.2
>Reporter: Felix Meschberger
> Attachments: FELIX-4473.patch
>
>
> As discussed on the list [1] a ConnectorFactory service is to be defined
> which allows the injection of Jetty Connector objects into the running Jetty
> server.
> package org.apache.felix.http.jetty;
> public interface ConnectorFactory {
> Connector createConnector();
> }
> * createConnector creates a new configured (but not started) Connector
> instance on each call
> * The Jetty bundle calls createConnector for each Jetty server started (for
> now this is a single one).
> * The Connector is added to the Jetty server and started
> * When the Jetty server stops, the connector is stopped and discarded along
> with the Jetty server
> * When the ConnectorFactory is stopped, the Connector has to be stopped and
> removed from the Jetty server
> [1] http://felix.markmail.org/thread/wvnani5362kq5ynr
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (FELIX-4473) [Jetty] Add support for Jetty Connector injection
[
https://issues.apache.org/jira/browse/FELIX-4473?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Felix Meschberger updated FELIX-4473:
-
Attachment: FELIX-4473.patch
Proposed patch with the new ConnectorFactory service API
> [Jetty] Add support for Jetty Connector injection
> -
>
> Key: FELIX-4473
> URL: https://issues.apache.org/jira/browse/FELIX-4473
> Project: Felix
> Issue Type: Task
> Components: HTTP Service
>Affects Versions: http-2.2.2
>Reporter: Felix Meschberger
> Attachments: FELIX-4473.patch
>
>
> As discussed on the list [1] a ConnectorFactory service is to be defined
> which allows the injection of Jetty Connector objects into the running Jetty
> server.
> package org.apache.felix.http.jetty;
> public interface ConnectorFactory {
> Connector createConnector();
> }
> * createConnector creates a new configured (but not started) Connector
> instance on each call
> * The Jetty bundle calls createConnector for each Jetty server started (for
> now this is a single one).
> * The Connector is added to the Jetty server and started
> * When the Jetty server stops, the connector is stopped and discarded along
> with the Jetty server
> * When the ConnectorFactory is stopped, the Connector has to be stopped and
> removed from the Jetty server
> [1] http://felix.markmail.org/thread/wvnani5362kq5ynr
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Created] (FELIX-4473) [Jetty] Add support for Jetty Connector injection
Felix Meschberger created FELIX-4473:
Summary: [Jetty] Add support for Jetty Connector injection
Key: FELIX-4473
URL: https://issues.apache.org/jira/browse/FELIX-4473
Project: Felix
Issue Type: Task
Components: HTTP Service
Affects Versions: http-2.2.2
Reporter: Felix Meschberger
As discussed on the list [1] a ConnectorFactory service is to be defined which
allows the injection of Jetty Connector objects into the running Jetty server.
package org.apache.felix.http.jetty;
public interface ConnectorFactory {
Connector createConnector();
}
* createConnector creates a new configured (but not started) Connector
instance on each call
* The Jetty bundle calls createConnector for each Jetty server started (for now
this is a single one).
* The Connector is added to the Jetty server and started
* When the Jetty server stops, the connector is stopped and discarded along
with the Jetty server
* When the ConnectorFactory is stopped, the Connector has to be stopped and
removed from the Jetty server
[1] http://felix.markmail.org/thread/wvnani5362kq5ynr
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Comment Edited] (FELIX-4460) Bad HTTPS settings render Jetty inaccessible
[ https://issues.apache.org/jira/browse/FELIX-4460?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13942271#comment-13942271 ] Felix Meschberger edited comment on FELIX-4460 at 3/20/14 9:05 PM: --- Fixed in Rev. 1579733 & 1579739: * Start connectors individually after the server start * Stop the server if no connector can be started was (Author: fmeschbe): Fixed in Rev. 1579733: * Start connectors individually after the server start * Stop the server if no connector can be started > Bad HTTPS settings render Jetty inaccessible > > > Key: FELIX-4460 > URL: https://issues.apache.org/jira/browse/FELIX-4460 > Project: Felix > Issue Type: Bug > Components: HTTP Service >Affects Versions: http-2.2.2 >Reporter: Dominique Pfister >Assignee: Felix Meschberger > Fix For: http-2.3.0 > > Attachments: patch.txt > > > Entering some bad values for the HTTPS configuration prevents the complete > Jetty server startup. This looks like a regression of upgrading Jetty to > version 7. > The current implementation initializes all enabled connectors, adds them to > the server and then starts the server which in turn starts all connectors. If > one of them fails to start, the complete server startup fails and the Jetty > Bridge is no longer accessible via HTTP. > I suggest to initialize an additional HTTPS connector only after having > started the server, so at least HTTP stays available if enabled. > -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (FELIX-4460) Bad HTTPS settings render Jetty inaccessible
[ https://issues.apache.org/jira/browse/FELIX-4460?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger resolved FELIX-4460. -- Resolution: Fixed Fix Version/s: http-2.3.0 Fixed in Rev. 1579733: * Start connectors individually after the server start * Stop the server if no connector can be started > Bad HTTPS settings render Jetty inaccessible > > > Key: FELIX-4460 > URL: https://issues.apache.org/jira/browse/FELIX-4460 > Project: Felix > Issue Type: Bug > Components: HTTP Service >Affects Versions: http-2.2.2 >Reporter: Dominique Pfister >Assignee: Felix Meschberger > Fix For: http-2.3.0 > > Attachments: patch.txt > > > Entering some bad values for the HTTPS configuration prevents the complete > Jetty server startup. This looks like a regression of upgrading Jetty to > version 7. > The current implementation initializes all enabled connectors, adds them to > the server and then starts the server which in turn starts all connectors. If > one of them fails to start, the complete server startup fails and the Jetty > Bridge is no longer accessible via HTTP. > I suggest to initialize an additional HTTPS connector only after having > started the server, so at least HTTP stays available if enabled. > -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (FELIX-4460) Bad HTTPS settings render Jetty inaccessible
[ https://issues.apache.org/jira/browse/FELIX-4460?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13942243#comment-13942243 ] Felix Meschberger commented on FELIX-4460: -- Thanks for providing the patch. I actually took a different route: The server will be started at first and then the connectors will be started one after the other. Any connector not being able to start will prevent the other connector from starting. If neither connector can be started, the Jetty server itself is stopped again. > Bad HTTPS settings render Jetty inaccessible > > > Key: FELIX-4460 > URL: https://issues.apache.org/jira/browse/FELIX-4460 > Project: Felix > Issue Type: Bug > Components: HTTP Service >Affects Versions: http-2.2.2 >Reporter: Dominique Pfister >Assignee: Felix Meschberger > Attachments: patch.txt > > > Entering some bad values for the HTTPS configuration prevents the complete > Jetty server startup. This looks like a regression of upgrading Jetty to > version 7. > The current implementation initializes all enabled connectors, adds them to > the server and then starts the server which in turn starts all connectors. If > one of them fails to start, the complete server startup fails and the Jetty > Bridge is no longer accessible via HTTP. > I suggest to initialize an additional HTTPS connector only after having > started the server, so at least HTTP stays available if enabled. > -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Assigned] (FELIX-4460) Bad HTTPS settings render Jetty inaccessible
[ https://issues.apache.org/jira/browse/FELIX-4460?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger reassigned FELIX-4460: Assignee: Felix Meschberger > Bad HTTPS settings render Jetty inaccessible > > > Key: FELIX-4460 > URL: https://issues.apache.org/jira/browse/FELIX-4460 > Project: Felix > Issue Type: Bug > Components: HTTP Service >Affects Versions: http-2.2.2 >Reporter: Dominique Pfister >Assignee: Felix Meschberger > Attachments: patch.txt > > > Entering some bad values for the HTTPS configuration prevents the complete > Jetty server startup. This looks like a regression of upgrading Jetty to > version 7. > The current implementation initializes all enabled connectors, adds them to > the server and then starts the server which in turn starts all connectors. If > one of them fails to start, the complete server startup fails and the Jetty > Bridge is no longer accessible via HTTP. > I suggest to initialize an additional HTTPS connector only after having > started the server, so at least HTTP stays available if enabled. > -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (FELIX-4446) Optionally enhance event admin to add a timestamp and the authenticated subject before dispatching events
[ https://issues.apache.org/jira/browse/FELIX-4446?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13922555#comment-13922555 ] Felix Meschberger commented on FELIX-4446: -- [~gnt] A right. Thanks. My typing was faster than my waiting, or so ... I am still reluctant, though, but then it does not hurt, either. > Optionally enhance event admin to add a timestamp and the authenticated > subject before dispatching events > - > > Key: FELIX-4446 > URL: https://issues.apache.org/jira/browse/FELIX-4446 > Project: Felix > Issue Type: New Feature > Components: Event Admin >Reporter: Guillaume Nodet >Assignee: Guillaume Nodet > > EventAdmin is great because various bundles do send events, so it's really > nice for an audit trail of what happened. > However, in order for the audit trail to be useful, it's missing a few > properties such as the timestamp and the user performing the action. > It would be nice if event admin add those automatically to avoid modifying > various projects to add those properties. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (FELIX-4446) Optionally enhance event admin to add a timestamp and the authenticated subject before dispatching events
[ https://issues.apache.org/jira/browse/FELIX-4446?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13922539#comment-13922539 ] Felix Meschberger commented on FELIX-4446: -- Upfront, this sounds interesting, but then: You would probably have to create a variant of the EventProperties class which sets the TIMESTAMP and source properties in the constructor unless the TIMESTAMP and source properties are not set yet. Also: what is the "user performing the action" ? So, I am a bit reluctant to such an extension to the spec behaviour. > Optionally enhance event admin to add a timestamp and the authenticated > subject before dispatching events > - > > Key: FELIX-4446 > URL: https://issues.apache.org/jira/browse/FELIX-4446 > Project: Felix > Issue Type: New Feature > Components: Event Admin >Reporter: Guillaume Nodet >Assignee: Guillaume Nodet > > EventAdmin is great because various bundles do send events, so it's really > nice for an audit trail of what happened. > However, in order for the audit trail to be useful, it's missing a few > properties such as the timestamp and the user performing the action. > It would be nice if event admin add those automatically to avoid modifying > various projects to add those properties. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (FELIX-4439) ConfigurationAdmin should send events through the EventAdmin
[ https://issues.apache.org/jira/browse/FELIX-4439?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13914412#comment-13914412 ] Felix Meschberger commented on FELIX-4439: -- Are you aware of the Event Admin bridge for Configuration Admin at https://svn.apache.org/repos/asf/felix/trunk/eventadmin/bridge.configuration ? I think having the bridge is more elegant. Apart from the patch probably breaking Configuration Admin if the Event Admin API is not present; i.e. cannot be wired. > ConfigurationAdmin should send events through the EventAdmin > > > Key: FELIX-4439 > URL: https://issues.apache.org/jira/browse/FELIX-4439 > Project: Felix > Issue Type: New Feature > Components: Configuration Admin >Affects Versions: configadmin-1.6.0, configadmin-1.8.0 >Reporter: Marc de Jonge > Labels: feature > Attachments: FELIX-4439.patch > > Original Estimate: 96h > Remaining Estimate: 96h > > According to the OSGi compendium specifications 4.3.0, section 104.8.1 (page > 88), the ConfigurationAdmin should send events through the EventAdmin when it > is available. > Copy of the text: > Configuration events must be delivered asynchronously by the Configuration > Admin implementation, if present. The topic of a configuration event must be: > org/osgi/service/cm/ConfigurationEvent/ > The can be any of the following: > - CM_DELETED > - CM_UPDATED > - CM_LOCATION_CHANGED > The properties of a configuration event are: > • cm.factoryPid – (String) The factory PID of the associated Configuration > object, if the target is a > Managed Service Factory. Otherwise not set. > • cm.pid – (String) The PID of the associated Configuration object. > • service – (ServiceReference) The Service Reference of the Configuration > Admin service. > • service.id – (Long) The Configuration Admin service's ID. > • service.objectClass – (String[]) The Configuration Admin service's object > class (which must > include org.osgi.service.cm.ConfigurationAdmin) > • service.pid – (String) The Configuration Admin service's persistent > identity, if set. > I'd like to use the EventAdmin for this information, because it is guaranteed > to have no side effects and to be informative only. > Now of course I could use the ConfigurationListener for this, but it seems > that this has some unwanted side effects. Unbounded configurations now seem > to bind to my listenening bundle, while I only want to present some > configuration status on a Web UI. There is another bundle to which the > configuration should bind, but I use DS to do so. Maybe this is another > issue... -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Resolved] (FELIX-4438) [Jetty] Jetty server reports itself as being version 8.y.z-SNAPSHOT
[ https://issues.apache.org/jira/browse/FELIX-4438?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger resolved FELIX-4438. -- Resolution: Fixed Fixed in Rev. 1572163 > [Jetty] Jetty server reports itself as being version 8.y.z-SNAPSHOT > --- > > Key: FELIX-4438 > URL: https://issues.apache.org/jira/browse/FELIX-4438 > Project: Felix > Issue Type: Bug > Components: HTTP Service >Affects Versions: http-2.2.1 >Reporter: Felix Meschberger >Assignee: Felix Meschberger > Fix For: http-2.2.2 > > > The Jetty server currently announces itself as version "8.y.z-SNAPSHOT" in > the ServletContext.getServerInfo() and the Server header. > The fault seems to be that Jetty's Server class inspects the package > implementation name and version and does not find it. It then falls back to > the jetty.version system property which is not set. Finally it falls back to > said version "8.y.z-SNAPSHOT". > The fix is to set the jetty.version system property in the > JettyService.getJettyVersion method. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Created] (FELIX-4438) [Jetty] Jetty server reports itself as being version 8.y.z-SNAPSHOT
Felix Meschberger created FELIX-4438: Summary: [Jetty] Jetty server reports itself as being version 8.y.z-SNAPSHOT Key: FELIX-4438 URL: https://issues.apache.org/jira/browse/FELIX-4438 Project: Felix Issue Type: Bug Components: HTTP Service Affects Versions: http-2.2.1 Reporter: Felix Meschberger Assignee: Felix Meschberger Fix For: http-2.2.2 The Jetty server currently announces itself as version "8.y.z-SNAPSHOT" in the ServletContext.getServerInfo() and the Server header. The fault seems to be that Jetty's Server class inspects the package implementation name and version and does not find it. It then falls back to the jetty.version system property which is not set. Finally it falls back to said version "8.y.z-SNAPSHOT". The fix is to set the jetty.version system property in the JettyService.getJettyVersion method. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Resolved] (FELIX-4437) [Inventory] Zip Writer does not pass the correct isZip status to the InventoryPrinterHandler
[ https://issues.apache.org/jira/browse/FELIX-4437?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger resolved FELIX-4437. -- Resolution: Fixed Fixed in Rev. 1572113 > [Inventory] Zip Writer does not pass the correct isZip status to the > InventoryPrinterHandler > > > Key: FELIX-4437 > URL: https://issues.apache.org/jira/browse/FELIX-4437 > Project: Felix > Issue Type: Bug > Components: Inventory >Affects Versions: inventory-1.0.2 >Reporter: Felix Meschberger >Assignee: Felix Meschberger > Fix For: inventory-1.0.4 > > > The ZipConfigurationWriter calls the InventoryPrinterHandler for the TEXT > format (if TEXT is supported) but does not forward that the output goes into > the ZIP file. > This may cause InventoryPrinterHandler to not generate the appropriate > output. For example the WebConsole's Thread Dumper will omit the stack traces > if the thread dumps do not go to the ZIP file. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Created] (FELIX-4437) [Inventory] Zip Writer does not pass the correct isZip status to the InventoryPrinterHandler
Felix Meschberger created FELIX-4437: Summary: [Inventory] Zip Writer does not pass the correct isZip status to the InventoryPrinterHandler Key: FELIX-4437 URL: https://issues.apache.org/jira/browse/FELIX-4437 Project: Felix Issue Type: Bug Components: Inventory Affects Versions: inventory-1.0.2 Reporter: Felix Meschberger Assignee: Felix Meschberger Fix For: inventory-1.0.4 The ZipConfigurationWriter calls the InventoryPrinterHandler for the TEXT format (if TEXT is supported) but does not forward that the output goes into the ZIP file. This may cause InventoryPrinterHandler to not generate the appropriate output. For example the WebConsole's Thread Dumper will omit the stack traces if the thread dumps do not go to the ZIP file. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (FELIX-4430) [PackageAdmin Web Console Plugin] Provide using bundles with versions
[ https://issues.apache.org/jira/browse/FELIX-4430?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger updated FELIX-4430: - Component/s: Web Console Affects Version/s: webconsole-packageadmin-plugin 1.0.0 > [PackageAdmin Web Console Plugin] Provide using bundles with versions > - > > Key: FELIX-4430 > URL: https://issues.apache.org/jira/browse/FELIX-4430 > Project: Felix > Issue Type: Improvement > Components: Web Console >Affects Versions: webconsole-packageadmin-plugin 1.0.0 >Reporter: Felix Meschberger >Assignee: Felix Meschberger > Fix For: webconsole-packageadmin-plugin 1.0.2 > > > The PackageAdmin web console plugin allows for searching of package exporting > bundles as well as finding duplicate exports. > The package search does not expose the using bundles. Sometimes it is > interesting to see, which bundle is actually importing an exported package > and at what version this package is imported. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Resolved] (FELIX-4430) [PackageAdmin Web Console Plugin] Provide using bundles with versions
[ https://issues.apache.org/jira/browse/FELIX-4430?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger resolved FELIX-4430. -- Resolution: Fixed Fix Version/s: webconsole-packageadmin-plugin 1.0.2 Assignee: Felix Meschberger Implemented this feauture in Rev. 1570134: In addition to the exporting bundle and its maven coordinates, the list of importing bundles along with the versions at which the package is imported is printed. > [PackageAdmin Web Console Plugin] Provide using bundles with versions > - > > Key: FELIX-4430 > URL: https://issues.apache.org/jira/browse/FELIX-4430 > Project: Felix > Issue Type: Improvement > Components: Web Console >Affects Versions: webconsole-packageadmin-plugin 1.0.0 >Reporter: Felix Meschberger >Assignee: Felix Meschberger > Fix For: webconsole-packageadmin-plugin 1.0.2 > > > The PackageAdmin web console plugin allows for searching of package exporting > bundles as well as finding duplicate exports. > The package search does not expose the using bundles. Sometimes it is > interesting to see, which bundle is actually importing an exported package > and at what version this package is imported. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Created] (FELIX-4430) [PackageAdmin Web Console Plugin] Provide using bundles with versions
Felix Meschberger created FELIX-4430: Summary: [PackageAdmin Web Console Plugin] Provide using bundles with versions Key: FELIX-4430 URL: https://issues.apache.org/jira/browse/FELIX-4430 Project: Felix Issue Type: Improvement Reporter: Felix Meschberger The PackageAdmin web console plugin allows for searching of package exporting bundles as well as finding duplicate exports. The package search does not expose the using bundles. Sometimes it is interesting to see, which bundle is actually importing an exported package and at what version this package is imported. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (FELIX-4427) Create separate API bundle
[ https://issues.apache.org/jira/browse/FELIX-4427?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13904103#comment-13904103 ] Felix Meschberger commented on FELIX-4427: -- Found out how to actually use the bundle plugin to generate the bundle instead of my jar file with static manifest hack: The exported packages have to be fully listed and then the bundle plugin is actually able to export the same packages twice with different versions. Fixed in Rev. 1569365 > Create separate API bundle > -- > > Key: FELIX-4427 > URL: https://issues.apache.org/jira/browse/FELIX-4427 > Project: Felix > Issue Type: Bug > Components: HTTP Service >Affects Versions: http-2.2.1 >Reporter: Felix Meschberger >Assignee: Felix Meschberger > > Currently the Servlet API is exported from the Http Service Bundle bundle and > the Jetty bundle. > In a typical web application a large number of bundles will typically wire to > the Servlet API and to the Http Service API. To detach the application from > the Http Service implementation, if would be usefull to have the APIs fully > detached from the implementations. > As such, I suggest we do not export the Servlet API from the Jetty bundle but > expect the Servlet API to be exported from somewhere else. > As the Http Service Bundle bundle is a convenience all-in-one bundle, it does > not hurt for this bundle to export the API. > To help solve the versioning problem, I actually think we should create our > own Servlet API bundle. The versioning problem is that the Servlet API 3.0 > spec is actually backwards compatible with Servlet 2.5 but chose to upgrade > the specification major version. Unfortunately that does not play well with > semantic versioning when applying the specification version to the API > exports (as is customarily but wrongly done). > So, our bundle should: > - be based on the Tomcat Servlet API library (since this is ASL2 licensed and > can easily be included) > - export Servlet API at version 2.6 (which is a custom compromise) as well as > version 3.0 > - also Provide-Capability for the Servlet API capability -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (FELIX-4427) Create separate API bundle
[ https://issues.apache.org/jira/browse/FELIX-4427?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13903980#comment-13903980 ] Felix Meschberger commented on FELIX-4427: -- [~jajans] Yes, I could not get the bundle plugin to export the same package twice with different versions. If you know how to do it ... Also have to also import the OSGi Http Service API in the API bundle to make it more lenient to 3rd party providers of the OSGi service API (as is the case in the integration tests which happen to install the compendium bundle). Fix in Rev. 1569288. > Create separate API bundle > -- > > Key: FELIX-4427 > URL: https://issues.apache.org/jira/browse/FELIX-4427 > Project: Felix > Issue Type: Bug > Components: HTTP Service >Affects Versions: http-2.2.1 >Reporter: Felix Meschberger >Assignee: Felix Meschberger > > Currently the Servlet API is exported from the Http Service Bundle bundle and > the Jetty bundle. > In a typical web application a large number of bundles will typically wire to > the Servlet API and to the Http Service API. To detach the application from > the Http Service implementation, if would be usefull to have the APIs fully > detached from the implementations. > As such, I suggest we do not export the Servlet API from the Jetty bundle but > expect the Servlet API to be exported from somewhere else. > As the Http Service Bundle bundle is a convenience all-in-one bundle, it does > not hurt for this bundle to export the API. > To help solve the versioning problem, I actually think we should create our > own Servlet API bundle. The versioning problem is that the Servlet API 3.0 > spec is actually backwards compatible with Servlet 2.5 but chose to upgrade > the specification major version. Unfortunately that does not play well with > semantic versioning when applying the specification version to the API > exports (as is customarily but wrongly done). > So, our bundle should: > - be based on the Tomcat Servlet API library (since this is ASL2 licensed and > can easily be included) > - export Servlet API at version 2.6 (which is a custom compromise) as well as > version 3.0 > - also Provide-Capability for the Servlet API capability -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (FELIX-4427) Create separate API bundle
[ https://issues.apache.org/jira/browse/FELIX-4427?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13903974#comment-13903974 ] Felix Meschberger commented on FELIX-4427: -- Fix Servlet API export bundle in Rev. 1569272 (bundle version was corrupt and local strings were missing) and added the API bundles in the integration tests in Rev. 1569274. > Create separate API bundle > -- > > Key: FELIX-4427 > URL: https://issues.apache.org/jira/browse/FELIX-4427 > Project: Felix > Issue Type: Bug > Components: HTTP Service >Affects Versions: http-2.2.1 >Reporter: Felix Meschberger >Assignee: Felix Meschberger > > Currently the Servlet API is exported from the Http Service Bundle bundle and > the Jetty bundle. > In a typical web application a large number of bundles will typically wire to > the Servlet API and to the Http Service API. To detach the application from > the Http Service implementation, if would be usefull to have the APIs fully > detached from the implementations. > As such, I suggest we do not export the Servlet API from the Jetty bundle but > expect the Servlet API to be exported from somewhere else. > As the Http Service Bundle bundle is a convenience all-in-one bundle, it does > not hurt for this bundle to export the API. > To help solve the versioning problem, I actually think we should create our > own Servlet API bundle. The versioning problem is that the Servlet API 3.0 > spec is actually backwards compatible with Servlet 2.5 but chose to upgrade > the specification major version. Unfortunately that does not play well with > semantic versioning when applying the specification version to the API > exports (as is customarily but wrongly done). > So, our bundle should: > - be based on the Tomcat Servlet API library (since this is ASL2 licensed and > can easily be included) > - export Servlet API at version 2.6 (which is a custom compromise) as well as > version 3.0 > - also Provide-Capability for the Servlet API capability -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (FELIX-4427) Create separate API bundle
[ https://issues.apache.org/jira/browse/FELIX-4427?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13903945#comment-13903945 ] Felix Meschberger commented on FELIX-4427: -- Fixed the exports in Rev. 1569268: * Removed Http Service, ext Http Service and Servlet API exports from Jetty bundle * Added OSGi Http Service export to API bundle * API bundle depends on Servlet API 2.3 which was the first to provide Filter and imports servlet API at [2.3,4) to support all servlet API which we currently assume compatible. > Create separate API bundle > -- > > Key: FELIX-4427 > URL: https://issues.apache.org/jira/browse/FELIX-4427 > Project: Felix > Issue Type: Bug > Components: HTTP Service >Affects Versions: http-2.2.1 >Reporter: Felix Meschberger >Assignee: Felix Meschberger > > Currently the Servlet API is exported from the Http Service Bundle bundle and > the Jetty bundle. > In a typical web application a large number of bundles will typically wire to > the Servlet API and to the Http Service API. To detach the application from > the Http Service implementation, if would be usefull to have the APIs fully > detached from the implementations. > As such, I suggest we do not export the Servlet API from the Jetty bundle but > expect the Servlet API to be exported from somewhere else. > As the Http Service Bundle bundle is a convenience all-in-one bundle, it does > not hurt for this bundle to export the API. > To help solve the versioning problem, I actually think we should create our > own Servlet API bundle. The versioning problem is that the Servlet API 3.0 > spec is actually backwards compatible with Servlet 2.5 but chose to upgrade > the specification major version. Unfortunately that does not play well with > semantic versioning when applying the specification version to the API > exports (as is customarily but wrongly done). > So, our bundle should: > - be based on the Tomcat Servlet API library (since this is ASL2 licensed and > can easily be included) > - export Servlet API at version 2.6 (which is a custom compromise) as well as > version 3.0 > - also Provide-Capability for the Servlet API capability -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (FELIX-4427) Create separate API bundle
[ https://issues.apache.org/jira/browse/FELIX-4427?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13903942#comment-13903942 ] Felix Meschberger commented on FELIX-4427: -- Created a first version based on the Tomcat Servlet API 7.0.8 (tomcat 8 is already Servlet API 3.1) in Rev. 1569258 Next steps: * Remove API exports from the Jetty bundle * Add HTTP Service API export to the Api bundle > Create separate API bundle > -- > > Key: FELIX-4427 > URL: https://issues.apache.org/jira/browse/FELIX-4427 > Project: Felix > Issue Type: Bug > Components: HTTP Service >Affects Versions: http-2.2.1 >Reporter: Felix Meschberger >Assignee: Felix Meschberger > > Currently the Servlet API is exported from the Http Service Bundle bundle and > the Jetty bundle. > In a typical web application a large number of bundles will typically wire to > the Servlet API and to the Http Service API. To detach the application from > the Http Service implementation, if would be usefull to have the APIs fully > detached from the implementations. > As such, I suggest we do not export the Servlet API from the Jetty bundle but > expect the Servlet API to be exported from somewhere else. > As the Http Service Bundle bundle is a convenience all-in-one bundle, it does > not hurt for this bundle to export the API. > To help solve the versioning problem, I actually think we should create our > own Servlet API bundle. The versioning problem is that the Servlet API 3.0 > spec is actually backwards compatible with Servlet 2.5 but chose to upgrade > the specification major version. Unfortunately that does not play well with > semantic versioning when applying the specification version to the API > exports (as is customarily but wrongly done). > So, our bundle should: > - be based on the Tomcat Servlet API library (since this is ASL2 licensed and > can easily be included) > - export Servlet API at version 2.6 (which is a custom compromise) as well as > version 3.0 > - also Provide-Capability for the Servlet API capability -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Assigned] (FELIX-4427) Create separate API bundle
[ https://issues.apache.org/jira/browse/FELIX-4427?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger reassigned FELIX-4427: Assignee: Felix Meschberger > Create separate API bundle > -- > > Key: FELIX-4427 > URL: https://issues.apache.org/jira/browse/FELIX-4427 > Project: Felix > Issue Type: Bug > Components: HTTP Service >Affects Versions: http-2.2.1 >Reporter: Felix Meschberger >Assignee: Felix Meschberger > > Currently the Servlet API is exported from the Http Service Bundle bundle and > the Jetty bundle. > In a typical web application a large number of bundles will typically wire to > the Servlet API and to the Http Service API. To detach the application from > the Http Service implementation, if would be usefull to have the APIs fully > detached from the implementations. > As such, I suggest we do not export the Servlet API from the Jetty bundle but > expect the Servlet API to be exported from somewhere else. > As the Http Service Bundle bundle is a convenience all-in-one bundle, it does > not hurt for this bundle to export the API. > To help solve the versioning problem, I actually think we should create our > own Servlet API bundle. The versioning problem is that the Servlet API 3.0 > spec is actually backwards compatible with Servlet 2.5 but chose to upgrade > the specification major version. Unfortunately that does not play well with > semantic versioning when applying the specification version to the API > exports (as is customarily but wrongly done). > So, our bundle should: > - be based on the Tomcat Servlet API library (since this is ASL2 licensed and > can easily be included) > - export Servlet API at version 2.6 (which is a custom compromise) as well as > version 3.0 > - also Provide-Capability for the Servlet API capability -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (FELIX-4427) Create separate API bundle
[ https://issues.apache.org/jira/browse/FELIX-4427?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger updated FELIX-4427: - Description: Currently the Servlet API is exported from the Http Service Bundle bundle and the Jetty bundle. In a typical web application a large number of bundles will typically wire to the Servlet API and to the Http Service API. To detach the application from the Http Service implementation, if would be usefull to have the APIs fully detached from the implementations. As such, I suggest we do not export the Servlet API from the Jetty bundle but expect the Servlet API to be exported from somewhere else. As the Http Service Bundle bundle is a convenience all-in-one bundle, it does not hurt for this bundle to export the API. To help solve the versioning problem, I actually think we should create our own Servlet API bundle. The versioning problem is that the Servlet API 3.0 spec is actually backwards compatible with Servlet 2.5 but chose to upgrade the specification major version. Unfortunately that does not play well with semantic versioning when applying the specification version to the API exports (as is customarily but wrongly done). So, our bundle should: - be based on the Tomcat Servlet API library (since this is ASL2 licensed and can easily be included) - export Servlet API at version 2.6 (which is a custom compromise) as well as version 3.0 - also Provide-Capability for the Servlet API capability was: Currently the Servlet API is exported from the Http Service Bundle bundle and the Jetty bundle. In a typical web application a large number of bundles will typically wire to the Servlet API and to the Http Service API. To detach the application from the Http Service implementation, if would be usefull to have the APIs fully detached from the implementations. As such, I suggest we do not export the Servlet API from the Jetty bundle but expect the Servlet API to be exported from somewhere else. As the Http Service Bundle bundle is a convenience all-in-one bundle, it does not hurt for this bundle to export the API. > Create separate API bundle > -- > > Key: FELIX-4427 > URL: https://issues.apache.org/jira/browse/FELIX-4427 > Project: Felix > Issue Type: Bug > Components: HTTP Service >Affects Versions: http-2.2.1 >Reporter: Felix Meschberger > > Currently the Servlet API is exported from the Http Service Bundle bundle and > the Jetty bundle. > In a typical web application a large number of bundles will typically wire to > the Servlet API and to the Http Service API. To detach the application from > the Http Service implementation, if would be usefull to have the APIs fully > detached from the implementations. > As such, I suggest we do not export the Servlet API from the Jetty bundle but > expect the Servlet API to be exported from somewhere else. > As the Http Service Bundle bundle is a convenience all-in-one bundle, it does > not hurt for this bundle to export the API. > To help solve the versioning problem, I actually think we should create our > own Servlet API bundle. The versioning problem is that the Servlet API 3.0 > spec is actually backwards compatible with Servlet 2.5 but chose to upgrade > the specification major version. Unfortunately that does not play well with > semantic versioning when applying the specification version to the API > exports (as is customarily but wrongly done). > So, our bundle should: > - be based on the Tomcat Servlet API library (since this is ASL2 licensed and > can easily be included) > - export Servlet API at version 2.6 (which is a custom compromise) as well as > version 3.0 > - also Provide-Capability for the Servlet API capability -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Created] (FELIX-4427) Create separate API bundle
Felix Meschberger created FELIX-4427: Summary: Create separate API bundle Key: FELIX-4427 URL: https://issues.apache.org/jira/browse/FELIX-4427 Project: Felix Issue Type: Bug Components: HTTP Service Affects Versions: http-2.2.1 Reporter: Felix Meschberger Currently the Servlet API is exported from the Http Service Bundle bundle and the Jetty bundle. In a typical web application a large number of bundles will typically wire to the Servlet API and to the Http Service API. To detach the application from the Http Service implementation, if would be usefull to have the APIs fully detached from the implementations. As such, I suggest we do not export the Servlet API from the Jetty bundle but expect the Servlet API to be exported from somewhere else. As the Http Service Bundle bundle is a convenience all-in-one bundle, it does not hurt for this bundle to export the API. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (FELIX-3988) FilterHandler does not handle return of context.handleSecurity() correctly
[
https://issues.apache.org/jira/browse/FELIX-3988?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13900203#comment-13900203
]
Felix Meschberger commented on FELIX-3988:
--
Oh, you are right ! each filter is registered with an HttpContext and the
handleSecurity of each of these context's is called.
I have the impression, this is not how it should be. In fact, this raises a
very interesting question: Should only filters be called for a servlet where
all HttpContexts are the same ? Not going into this one here.
So, ok, lets keep it as you proposed and reconsider later if needed.
Thanks.
> FilterHandler does not handle return of context.handleSecurity() correctly
> --
>
> Key: FELIX-3988
> URL: https://issues.apache.org/jira/browse/FELIX-3988
> Project: Felix
> Issue Type: Bug
> Components: HTTP Service
>Affects Versions: http-2.2.0
>Reporter: Kaspar von Gunten
>Assignee: J.W. Janssen
> Attachments: FilterHandler.patch
>
>
> This is somewhat similar to FELIX-2768, but not resolved.
> The JavaDoc for HttpContext.handleSecurity states:
> * When this method returns false, the Http Service will send the response
> back to the client, thereby
> * completing the request. When this method returns true, the Http Service
> will proceed with servicing the
> * request.
> The current FilterHandler impl is as follows:
> if (!getContext().handleSecurity(req, res)) {
> res.sendError(HttpServletResponse.SC_FORBIDDEN);
> } else {
> this.filter.doFilter(req, res, chain);
> }
> 1) This does not comply to the above doc, because the context might have set
> a status/error code and prepared everything correctly to be returned. Sending
> an error will overwrite the prepared headers and status.
> 2) Some context implementations are a bit eager and already send the response
> back before they return "false" from the above method. The current
> implementation will then lead to an IllegalStateException, because the
> response has already been committed. In order to be more robust, there should
> be a if(!res.isCommitted())-block around the handling of the "false" return
> value.
> I attached a patch for the second aspect of the issue, but couldn't resolve
> the first part, because - as it is at the moment - there seems to be no way
> to check if there is already a status set on the resource (no getStatus() or
> isStatusSet() method).
> Ideally the fix should be something like:
> if (!res.isCommitted() && !res.isStatusSet()) {
> res.sendError(SC_FORBIDDEN);
> }
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Commented] (FELIX-3988) FilterHandler does not handle return of context.handleSecurity() correctly
[
https://issues.apache.org/jira/browse/FELIX-3988?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13900155#comment-13900155
]
Felix Meschberger commented on FELIX-3988:
--
Will the filters be called during handleSecurity at all ? I thought requests
are processed like this:
1. handleSecurity
2. REQUEST scoped filters
3. Servlet
4. more filters and servlet as per RequestDispatcher
> FilterHandler does not handle return of context.handleSecurity() correctly
> --
>
> Key: FELIX-3988
> URL: https://issues.apache.org/jira/browse/FELIX-3988
> Project: Felix
> Issue Type: Bug
> Components: HTTP Service
>Affects Versions: http-2.2.0
>Reporter: Kaspar von Gunten
>Assignee: J.W. Janssen
> Attachments: FilterHandler.patch
>
>
> This is somewhat similar to FELIX-2768, but not resolved.
> The JavaDoc for HttpContext.handleSecurity states:
> * When this method returns false, the Http Service will send the response
> back to the client, thereby
> * completing the request. When this method returns true, the Http Service
> will proceed with servicing the
> * request.
> The current FilterHandler impl is as follows:
> if (!getContext().handleSecurity(req, res)) {
> res.sendError(HttpServletResponse.SC_FORBIDDEN);
> } else {
> this.filter.doFilter(req, res, chain);
> }
> 1) This does not comply to the above doc, because the context might have set
> a status/error code and prepared everything correctly to be returned. Sending
> an error will overwrite the prepared headers and status.
> 2) Some context implementations are a bit eager and already send the response
> back before they return "false" from the above method. The current
> implementation will then lead to an IllegalStateException, because the
> response has already been committed. In order to be more robust, there should
> be a if(!res.isCommitted())-block around the handling of the "false" return
> value.
> I attached a patch for the second aspect of the issue, but couldn't resolve
> the first part, because - as it is at the moment - there seems to be no way
> to check if there is already a status set on the resource (no getStatus() or
> isStatusSet() method).
> Ideally the fix should be something like:
> if (!res.isCommitted() && !res.isStatusSet()) {
> res.sendError(SC_FORBIDDEN);
> }
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Commented] (FELIX-3988) FilterHandler does not handle return of context.handleSecurity() correctly
[
https://issues.apache.org/jira/browse/FELIX-3988?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13900134#comment-13900134
]
Felix Meschberger commented on FELIX-3988:
--
I am not really sure, that proposed fix is a good one, since the handleSecurity
could expressely set SC_OK for any one reason (e.g. sending an HTML form to
enter credentials) but not commit the response. In this case sending back
FORBIDDEN is wrong.
Maybe we could setStatus(SC_FORBIDDEN) before calling handleSecurity and if
that returns false the response is just terminated (committed if needed).
Otherwise (handleSecurity returns true) setStatus(SC_OK) is called and the
request continues.
WDYT ?
> FilterHandler does not handle return of context.handleSecurity() correctly
> --
>
> Key: FELIX-3988
> URL: https://issues.apache.org/jira/browse/FELIX-3988
> Project: Felix
> Issue Type: Bug
> Components: HTTP Service
>Affects Versions: http-2.2.0
>Reporter: Kaspar von Gunten
>Assignee: J.W. Janssen
> Attachments: FilterHandler.patch
>
>
> This is somewhat similar to FELIX-2768, but not resolved.
> The JavaDoc for HttpContext.handleSecurity states:
> * When this method returns false, the Http Service will send the response
> back to the client, thereby
> * completing the request. When this method returns true, the Http Service
> will proceed with servicing the
> * request.
> The current FilterHandler impl is as follows:
> if (!getContext().handleSecurity(req, res)) {
> res.sendError(HttpServletResponse.SC_FORBIDDEN);
> } else {
> this.filter.doFilter(req, res, chain);
> }
> 1) This does not comply to the above doc, because the context might have set
> a status/error code and prepared everything correctly to be returned. Sending
> an error will overwrite the prepared headers and status.
> 2) Some context implementations are a bit eager and already send the response
> back before they return "false" from the above method. The current
> implementation will then lead to an IllegalStateException, because the
> response has already been committed. In order to be more robust, there should
> be a if(!res.isCommitted())-block around the handling of the "false" return
> value.
> I attached a patch for the second aspect of the issue, but couldn't resolve
> the first part, because - as it is at the moment - there seems to be no way
> to check if there is already a status set on the resource (no getStatus() or
> isStatusSet() method).
> Ideally the fix should be something like:
> if (!res.isCommitted() && !res.isStatusSet()) {
> res.sendError(SC_FORBIDDEN);
> }
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Resolved] (FELIX-2871) Transistive Dependencies
[ https://issues.apache.org/jira/browse/FELIX-2871?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger resolved FELIX-2871. -- Resolution: Fixed Fix Version/s: http-2.2.1 Assignee: Felix Meschberger You are right, this seems to have been fixed in the last release already. > Transistive Dependencies > > > Key: FELIX-2871 > URL: https://issues.apache.org/jira/browse/FELIX-2871 > Project: Felix > Issue Type: Improvement > Components: HTTP Service >Affects Versions: http-2.2.0 > Environment: Win XP >Reporter: Andrew Holland >Assignee: Felix Meschberger >Priority: Minor > Fix For: http-2.2.1 > > > i use both felix org.apache.felix.http.jetty & > org.apache.felix.http.whiteboard bundles with my project, it seems that both > these bundles export the same packages. > is it possible that transitive dependencies could be excluded from the built > bundles and Import-Package should be used to find required packages. (the > base and api bundles) > As it stands org.apache.felix.http.jetty includes the following embedded > dependencies > javax.servlet > org.apache.felix.http.api > org.apache.felix.http.base > org.mortbay > org.osgi.service.http > org.apache.felix.http.whiteboard bundles includes > org.apache.felix.http.api > org.apache.felix.http.base > is it not possible to just use Import-Package and not use the embedded > dependencies -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (FELIX-4423) ClassNotFoundException when stopping Jetty bundle
[
https://issues.apache.org/jira/browse/FELIX-4423?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13899065#comment-13899065
]
Felix Meschberger commented on FELIX-4423:
--
Hmm this might be caused by the JettyService.stop() method scheduling the
server shutdown but not waiting until the Executor service has actually
executed all scheduled tasks.
Maybe the stop() method should call the awaitTermination() method after
shutting down the executor to make sure the server has been stopped.
> ClassNotFoundException when stopping Jetty bundle
> -
>
> Key: FELIX-4423
> URL: https://issues.apache.org/jira/browse/FELIX-4423
> Project: Felix
> Issue Type: Bug
> Components: HTTP Service
>Affects Versions: http-2.2.2
>Reporter: J.W. Janssen
>Assignee: J.W. Janssen
> Fix For: http-2.3.0
>
>
> I sometimes see a class-not-found exception when stopping the OSGi framework
> with a running Jetty bundle. It seems that due to the asynchronous nature of
> this bundle, subtle timing issues can occur during shutdown:
> {code}
> 2014-02-07 17:21:23.312:WARN:oejuc.AbstractLifeCycle:FAILED
> qtp1827750836{8<=8<=8/254,0}: java.lang.NoClassDefFoundError:
> org/eclipse/jetty/util/thread/QueuedThreadPool$1
> java.lang.NoClassDefFoundError:
> org/eclipse/jetty/util/thread/QueuedThreadPool$1
> at
> org.eclipse.jetty.util.thread.QueuedThreadPool.doStop(QueuedThreadPool.java:126)
> at
> org.eclipse.jetty.util.component.AbstractLifeCycle.stop(AbstractLifeCycle.java:89)
> at
> org.eclipse.jetty.util.component.AggregateLifeCycle.doStop(AggregateLifeCycle.java:107)
> at
> org.eclipse.jetty.server.handler.AbstractHandler.doStop(AbstractHandler.java:69)
> at
> org.eclipse.jetty.server.handler.HandlerWrapper.doStop(HandlerWrapper.java:108)
> at org.eclipse.jetty.server.Server.doStop(Server.java:342)
> at
> org.eclipse.jetty.util.component.AbstractLifeCycle.stop(AbstractLifeCycle.java:89)
> at
> org.apache.felix.http.jetty.internal.JettyService.stopJetty(JettyService.java:228)
> at
> org.apache.felix.http.jetty.internal.JettyService.access$100(JettyService.java:72)
> at
> org.apache.felix.http.jetty.internal.JettyService$3.doExecute(JettyService.java:169)
> at
> org.apache.felix.http.jetty.internal.JettyService$JettyOperation.call(JettyService.java:792)
> at
> org.apache.felix.http.jetty.internal.JettyService$JettyOperation.call(JettyService.java:783)
> at java.util.concurrent.FutureTask.run(FutureTask.java:262)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:744)
> Caused by:
> java.lang.ClassNotFoundException: Unable to load class
> 'org.eclipse.jetty.util.thread.QueuedThreadPool$1' because the bundle wiring
> for org.apache.felix.http.jetty is no longer valid.
> at
> org.apache.felix.framework.BundleWiringImpl.findClassOrResourceByDelegation(BundleWiringImpl.java:1494)
> at
> org.apache.felix.framework.BundleWiringImpl.access$400(BundleWiringImpl.java:75)
> at
> org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.loadClass(BundleWiringImpl.java:1955)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:358)
> at
> org.eclipse.jetty.util.thread.QueuedThreadPool.doStop(QueuedThreadPool.java:126)
> at
> org.eclipse.jetty.util.component.AbstractLifeCycle.stop(AbstractLifeCycle.java:89)
> at
> org.eclipse.jetty.util.component.AggregateLifeCycle.doStop(AggregateLifeCycle.java:107)
> at
> org.eclipse.jetty.server.handler.AbstractHandler.doStop(AbstractHandler.java:69)
> at
> org.eclipse.jetty.server.handler.HandlerWrapper.doStop(HandlerWrapper.java:108)
> at org.eclipse.jetty.server.Server.doStop(Server.java:342)
> at
> org.eclipse.jetty.util.component.AbstractLifeCycle.stop(AbstractLifeCycle.java:89)
> at
> org.apache.felix.http.jetty.internal.JettyService.stopJetty(JettyService.java:228)
> at
> org.apache.felix.http.jetty.internal.JettyService.access$100(JettyService.java:72)
> at
> org.apache.felix.http.jetty.internal.JettyService$3.doExecute(JettyService.java:169)
> at
> org.apache.felix.http.jetty.internal.JettyService$JettyOperation.call(JettyService.java:792)
> at
> org.apache.felix.http.jetty.internal.JettyService$JettyOperation.call(JettyService.java:783)
> at java.util.concurrent.FutureTask.run(FutureTask.java:262)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
>
[jira] [Commented] (FELIX-4422) Remove asynchronous starting of Jetty service
[
https://issues.apache.org/jira/browse/FELIX-4422?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13899064#comment-13899064
]
Felix Meschberger commented on FELIX-4422:
--
[~jajans] Looks like this asynchronous start up behaviour was introduced with
the patch for FELIX-4137 to implement web app bundle support.
[~dpfister] Do you remember why you introduced this for web app support ?
> Remove asynchronous starting of Jetty service
> -
>
> Key: FELIX-4422
> URL: https://issues.apache.org/jira/browse/FELIX-4422
> Project: Felix
> Issue Type: Bug
> Components: HTTP Service
>Affects Versions: http-2.2.2
>Reporter: J.W. Janssen
> Fix For: http-2.3.0
>
>
> The Jetty bundle currently uses an {{ExecutorService}} to start Jetty in the
> background. I'm not sure this is actually needed with the recent versions of
> Jetty. I've did a quick test to start Jetty synchronously in the bundle
> activator, but could not measure any significant timing differences in
> startup times.
> A reason to change this is that it makes the start/stop behaviour bundle more
> deterministic when using it in integration tests.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Commented] (FELIX-4424) ClassLoader leak in Http Service ServletContextManager
[
https://issues.apache.org/jira/browse/FELIX-4424?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13898929#comment-13898929
]
Felix Meschberger commented on FELIX-4424:
--
Thanks.
Yes, I agree with the full fix. I would think that we need to track consumers
of the ServletContexts:
* In the Whiteboard case we can remove the ServletContext once the HttpContext
service is unregistered
* In the traditional registration case we can probably remove the entry when
the last Servlet (and Filter in our case) referring to the same HttpContext is
unregistered from the HttpService.
> ClassLoader leak in Http Service ServletContextManager
> --
>
> Key: FELIX-4424
> URL: https://issues.apache.org/jira/browse/FELIX-4424
> Project: Felix
> Issue Type: Bug
> Components: HTTP Service
>Reporter: Chetan Mehrotra
>Assignee: J.W. Janssen
>
> While analyzing heap dump for classloader leaks using script [1] following
> possible leak was reported
> {noformat}
> com.day.crx.packmgr.impl.AuthHttpContext@0x124214d18
>Following are few of the live paths found
>Live path
> com.day.crx.packmgr.impl.AuthHttpContext@0x124214d18
> java.util.HashMap$Entry@0x12429db50
> [Ljava.util.HashMap$Entry;@0x1238f47b0
> java.util.HashMap@0x1238f4780
>
> org.apache.felix.http.base.internal.context.ServletContextManager@0x1238f4760
> [*]
>
> org.apache.felix.http.base.internal.service.HttpServiceImpl@0x1238f45c0 [*]
>
> org.apache.felix.framework.ServiceRegistry$UsageCount@0x1238f45a8
>
> [Lorg.apache.felix.framework.ServiceRegistry$UsageCount;@0x129efb430
> java.util.HashMap$Entry@0x1235ee950
> [Ljava.util.HashMap$Entry;@0x1249e2b78
> java.util.HashMap@0x123484668
> org.apache.felix.framework.ServiceRegistry@0x12339c108
> org.apache.felix.framework.ServiceRegistrationImpl@0x126a7a3c8
> java.util.concurrent.atomic.AtomicReference@0x126a7a3b8
>
> org.apache.felix.scr.impl.manager.DelayedComponentManager@0x126a79ab8 [*]
> java.util.HashMap$Entry@0x126a9c3f0
> java.util.HashMap$Entry@0x1286ce7a0
> [Ljava.util.HashMap$Entry;@0x124884030
> java.util.HashMap@0x1238f1ce0
> org.apache.felix.scr.impl.ComponentRegistry@0x1236757f0 [*]
> org.apache.felix.scr.impl.BundleComponentActivator@0x127152bd0
> [*]
>
> org.apache.felix.scr.impl.config.ImmediateComponentHolder@0x127153a08 [*]
>
> org.apache.felix.scr.impl.manager.DelayedComponentManager@0x127154398 [*]
> org.apache.felix.scr.impl.manager.DependencyManager@0x127154720
> [*]
> {noformat}
> In our case the AuthHttpContext was being registered via the Whiteboard
> pattern. The dump shows that ServletContextManager [2] uses the HttpContext
> as key for the map however it is never removed. If our bundle would had used
> HttpService directly then internal map would have been GC upon bundle
> deactivation.
> In Felix HttpService is registered as a ServiceFactory however as all
> interactions with HttpService is done via Whiteboard bundle the HttpService
> is bound to Whiteboard bundle. So such HttpContext might remain for the
> lifetime of whiteboard bundle and hence cause classloader leak.
> [1] https://gist.github.com/chetanmeh/8860776
> [2]
> https://github.com/apache/felix/blob/trunk/http/base/src/main/java/org/apache/felix/http/base/internal/context/ServletContextManager.java
> PS: The lines marked with [*] are objects which are from valid bundle and are
> maintaining hard reference to the objects from classloader which should have
> been GC
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Commented] (FELIX-4424) ClassLoader leak in Http Service ServletContextManager
[
https://issues.apache.org/jira/browse/FELIX-4424?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13897830#comment-13897830
]
Felix Meschberger commented on FELIX-4424:
--
[~jajans] Thanks alot. This is just a quick shot approach which I did not
actually thoroughly test, though :-)
> ClassLoader leak in Http Service ServletContextManager
> --
>
> Key: FELIX-4424
> URL: https://issues.apache.org/jira/browse/FELIX-4424
> Project: Felix
> Issue Type: Bug
> Components: HTTP Service
>Reporter: Chetan Mehrotra
>Assignee: J.W. Janssen
>
> While analyzing heap dump for classloader leaks using script [1] following
> possible leak was reported
> {noformat}
> com.day.crx.packmgr.impl.AuthHttpContext@0x124214d18
>Following are few of the live paths found
>Live path
> com.day.crx.packmgr.impl.AuthHttpContext@0x124214d18
> java.util.HashMap$Entry@0x12429db50
> [Ljava.util.HashMap$Entry;@0x1238f47b0
> java.util.HashMap@0x1238f4780
>
> org.apache.felix.http.base.internal.context.ServletContextManager@0x1238f4760
> [*]
>
> org.apache.felix.http.base.internal.service.HttpServiceImpl@0x1238f45c0 [*]
>
> org.apache.felix.framework.ServiceRegistry$UsageCount@0x1238f45a8
>
> [Lorg.apache.felix.framework.ServiceRegistry$UsageCount;@0x129efb430
> java.util.HashMap$Entry@0x1235ee950
> [Ljava.util.HashMap$Entry;@0x1249e2b78
> java.util.HashMap@0x123484668
> org.apache.felix.framework.ServiceRegistry@0x12339c108
> org.apache.felix.framework.ServiceRegistrationImpl@0x126a7a3c8
> java.util.concurrent.atomic.AtomicReference@0x126a7a3b8
>
> org.apache.felix.scr.impl.manager.DelayedComponentManager@0x126a79ab8 [*]
> java.util.HashMap$Entry@0x126a9c3f0
> java.util.HashMap$Entry@0x1286ce7a0
> [Ljava.util.HashMap$Entry;@0x124884030
> java.util.HashMap@0x1238f1ce0
> org.apache.felix.scr.impl.ComponentRegistry@0x1236757f0 [*]
> org.apache.felix.scr.impl.BundleComponentActivator@0x127152bd0
> [*]
>
> org.apache.felix.scr.impl.config.ImmediateComponentHolder@0x127153a08 [*]
>
> org.apache.felix.scr.impl.manager.DelayedComponentManager@0x127154398 [*]
> org.apache.felix.scr.impl.manager.DependencyManager@0x127154720
> [*]
> {noformat}
> In our case the AuthHttpContext was being registered via the Whiteboard
> pattern. The dump shows that ServletContextManager [2] uses the HttpContext
> as key for the map however it is never removed. If our bundle would had used
> HttpService directly then internal map would have been GC upon bundle
> deactivation.
> In Felix HttpService is registered as a ServiceFactory however as all
> interactions with HttpService is done via Whiteboard bundle the HttpService
> is bound to Whiteboard bundle. So such HttpContext might remain for the
> lifetime of whiteboard bundle and hence cause classloader leak.
> [1] https://gist.github.com/chetanmeh/8860776
> [2]
> https://github.com/apache/felix/blob/trunk/http/base/src/main/java/org/apache/felix/http/base/internal/context/ServletContextManager.java
> PS: The lines marked with [*] are objects which are from valid bundle and are
> maintaining hard reference to the objects from classloader which should have
> been GC
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Commented] (FELIX-4424) ClassLoader leak in Http Service ServletContextManager
[
https://issues.apache.org/jira/browse/FELIX-4424?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13896573#comment-13896573
]
Felix Meschberger commented on FELIX-4424:
--
Wow ! Excellent catch, indeed !
We could use a WeakHashMap, though, instead of a regular HashMap. This way, we
can cope for this.
{noformat}
Index: ServletContextManager.java
===
--- ServletContextManager.java (Revision 1566626)
+++ ServletContextManager.java (Arbeitskopie)
@@ -16,8 +16,8 @@
*/
package org.apache.felix.http.base.internal.context;
-import java.util.HashMap;
import java.util.Map;
+import java.util.WeakHashMap;
import javax.servlet.ServletContext;
import javax.servlet.ServletContextAttributeListener;
@@ -39,7 +39,7 @@
this.bundle = bundle;
this.context = context;
this.attributeListener = attributeListener;
-this.contextMap = new HashMap();
+this.contextMap = new WeakHashMap();
this.sharedAttributes = sharedAttributes;
}
{noformat}
> ClassLoader leak in Http Service ServletContextManager
> --
>
> Key: FELIX-4424
> URL: https://issues.apache.org/jira/browse/FELIX-4424
> Project: Felix
> Issue Type: Bug
> Components: HTTP Service
>Reporter: Chetan Mehrotra
>
> While analyzing heap dump for classloader leaks using script [1] following
> possible leak was reported
> {noformat}
> com.day.crx.packmgr.impl.AuthHttpContext@0x124214d18
>Following are few of the live paths found
>Live path
> com.day.crx.packmgr.impl.AuthHttpContext@0x124214d18
> java.util.HashMap$Entry@0x12429db50
> [Ljava.util.HashMap$Entry;@0x1238f47b0
> java.util.HashMap@0x1238f4780
>
> org.apache.felix.http.base.internal.context.ServletContextManager@0x1238f4760
> [*]
>
> org.apache.felix.http.base.internal.service.HttpServiceImpl@0x1238f45c0 [*]
>
> org.apache.felix.framework.ServiceRegistry$UsageCount@0x1238f45a8
>
> [Lorg.apache.felix.framework.ServiceRegistry$UsageCount;@0x129efb430
> java.util.HashMap$Entry@0x1235ee950
> [Ljava.util.HashMap$Entry;@0x1249e2b78
> java.util.HashMap@0x123484668
> org.apache.felix.framework.ServiceRegistry@0x12339c108
> org.apache.felix.framework.ServiceRegistrationImpl@0x126a7a3c8
> java.util.concurrent.atomic.AtomicReference@0x126a7a3b8
>
> org.apache.felix.scr.impl.manager.DelayedComponentManager@0x126a79ab8 [*]
> java.util.HashMap$Entry@0x126a9c3f0
> java.util.HashMap$Entry@0x1286ce7a0
> [Ljava.util.HashMap$Entry;@0x124884030
> java.util.HashMap@0x1238f1ce0
> org.apache.felix.scr.impl.ComponentRegistry@0x1236757f0 [*]
> org.apache.felix.scr.impl.BundleComponentActivator@0x127152bd0
> [*]
>
> org.apache.felix.scr.impl.config.ImmediateComponentHolder@0x127153a08 [*]
>
> org.apache.felix.scr.impl.manager.DelayedComponentManager@0x127154398 [*]
> org.apache.felix.scr.impl.manager.DependencyManager@0x127154720
> [*]
> {noformat}
> In our case the AuthHttpContext was being registered via the Whiteboard
> pattern. The dump shows that ServletContextManager [2] uses the HttpContext
> as key for the map however it is never removed. If our bundle would had used
> HttpService directly then internal map would have been GC upon bundle
> deactivation.
> In Felix HttpService is registered as a ServiceFactory however as all
> interactions with HttpService is done via Whiteboard bundle the HttpService
> is bound to Whiteboard bundle. So such HttpContext might remain for the
> lifetime of whiteboard bundle and hence cause classloader leak.
> [1] https://gist.github.com/chetanmeh/8860776
> [2]
> https://github.com/apache/felix/blob/trunk/http/base/src/main/java/org/apache/felix/http/base/internal/context/ServletContextManager.java
> PS: The lines marked with [*] are objects which are from valid bundle and are
> maintaining hard reference to the objects from classloader which should have
> been GC
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Comment Edited] (FELIX-4421) Embed Jetty 8 in Felix Http Jetty
[ https://issues.apache.org/jira/browse/FELIX-4421?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13893411#comment-13893411 ] Felix Meschberger edited comment on FELIX-4421 at 2/6/14 2:56 PM: -- [~jajans] I thought this would come up :-) According to [~dpfister] the changes from Jetty 7 to Jetty 8 are not that dramatic and require little changes to the bridge. The changes to Jetty 9 seem to be rather substantial apart from Jetty 9 requiring Java 7 (there is still a large install base on Java 6, unfortunately). So in the interest of having Servlet API 3 soonish, I suggest to first go for Jetty 8 (and have a release of that) and do the Jetty 9 switch later. An option would also be to have two bridges: one for Jetty 8 (requiring Java 6) and one for Jetty 9 (requiring Java 7). Not sure, whether that is a good idea, though, maintenance-wise. WDYT ? was (Author: fmeschbe): [~jajans] I thought this would come up :-) According to [~dpfister] the changes from Jetty 7 to Jetty 8 are not that dramatic and require little changes to the bridge. The changes to Jetty 9 seem to be rather substantial apart from Jetty 9 requiring Java 7 (there is still a large install base on Java 6, unfortunately). So in the interest of having Servlet API 3 soonish, I suggest to first go for Jetty 8 (and have a release of that) and do the Jetty 9 switch later. WDYT ? > Embed Jetty 8 in Felix Http Jetty > - > > Key: FELIX-4421 > URL: https://issues.apache.org/jira/browse/FELIX-4421 > Project: Felix > Issue Type: New Feature > Components: HTTP Service >Affects Versions: http-2.2.1 >Reporter: Dominique Pfister > Attachments: patch.txt > > > Currently, the Jetty version embedded in Felix Http Jetty is version > 7.6.13.v20130916. In order to leverage features available in Servlet API 3.0 > only, I'd like to change the embedded version to 8.1.14.v20131031. > A quick test shows that increasing this version number in parent/pom.xml > alone requires some small changes to JettyService, deployment of a fresh > build of Http Jetty into an OSGI container succeeds, but no request can be > handled, because Jetty internally calls methods on interfaces and classes > that were only introduced in Servlet API 3.0. > This implies that the servlet version supported should be upped to 3.0 as > well. In order to be backward compatible with bundles expecting a 2.x > version, one could also export a virtual version (e.g. 2.6) to satisfy those. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (FELIX-4421) Embed Jetty 8 in Felix Http Jetty
[ https://issues.apache.org/jira/browse/FELIX-4421?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13893411#comment-13893411 ] Felix Meschberger commented on FELIX-4421: -- [~jajans] I thought this would come up :-) According to [~dpfister] the changes from Jetty 7 to Jetty 8 are not that dramatic and require little changes to the bridge. The changes to Jetty 9 seem to be rather substantial apart from Jetty 9 requiring Java 7 (there is still a large install base on Java 6, unfortunately). So in the interest of having Servlet API 3 soonish, I suggest to first go for Jetty 8 (and have a release of that) and do the Jetty 9 switch later. WDYT ? > Embed Jetty 8 in Felix Http Jetty > - > > Key: FELIX-4421 > URL: https://issues.apache.org/jira/browse/FELIX-4421 > Project: Felix > Issue Type: New Feature > Components: HTTP Service >Affects Versions: http-2.2.1 >Reporter: Dominique Pfister > Attachments: patch.txt > > > Currently, the Jetty version embedded in Felix Http Jetty is version > 7.6.13.v20130916. In order to leverage features available in Servlet API 3.0 > only, I'd like to change the embedded version to 8.1.14.v20131031. > A quick test shows that increasing this version number in parent/pom.xml > alone requires some small changes to JettyService, deployment of a fresh > build of Http Jetty into an OSGI container succeeds, but no request can be > handled, because Jetty internally calls methods on interfaces and classes > that were only introduced in Servlet API 3.0. > This implies that the servlet version supported should be upped to 3.0 as > well. In order to be backward compatible with bundles expecting a 2.x > version, one could also export a virtual version (e.g. 2.6) to satisfy those. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Created] (FELIX-4420) [HTTP SSLFilter] Implement sendRedirect
Felix Meschberger created FELIX-4420: Summary: [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 Reporter: Felix Meschberger Assignee: Felix Meschberger Fix For: http-2.2.2, http-sslfilter-1.0.0 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.1.5#6160)
[jira] [Commented] (FELIX-4415) Cannot associate HttpService instance with ServletContext
[
https://issues.apache.org/jira/browse/FELIX-4415?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13891979#comment-13891979
]
Felix Meschberger commented on FELIX-4415:
--
[RFC-1089|https://github.com/osgi/design/blob/master/rfcs/rfc0189/rfc-0189-Http_Service_Updates.pdf]
for the upcoming Http Service update currently defines the
{{osgi.http.endpoint}} service property to list the endpoint URLs (scheme,
authority, context path) served by the Http Service instance. But this property
is defined to be optional.
I asked the experts whether we can change this property to be mandatory and
actually be a relative URL: if the scheme and authority is know it is included,
otherwise it is just the servlet context path served.
> Cannot associate HttpService instance with ServletContext
> -
>
> Key: FELIX-4415
> URL: https://issues.apache.org/jira/browse/FELIX-4415
> Project: Felix
> Issue Type: Bug
> Components: HTTP Service
>Affects Versions: http-2.2.1
>Reporter: Thomas Diesler
>
> A tracker like this
> {code}
> tracker = new ServiceTracker(context,
> HttpService.class, null) {
> @Override
> public HttpService addingService(ServiceReference
> sref) {
> httpService = super.addingService(sref);
> registerHttpServiceServlet();
> return httpService;
> }
> };
> tracker.open();
> {code}
> cannot associate an HttpService instance with the servlet context that
> registered it. Adding the contextPath as service property would be a possible
> solution.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Commented] (FELIX-4412) Add Provide-Capability for declarative services bundle
[ https://issues.apache.org/jira/browse/FELIX-4412?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13889293#comment-13889293 ] Felix Meschberger commented on FELIX-4412: -- As BJ Hargrave wrote in the Eclipse bug, the extender will be defined as part of the DS update. See https://github.com/osgi/design/blob/master/rfcs/rfc0190/rfc-0190-Declarative_Services_Enhancements.pdf for the current state, particularly section 5.5. I would suggest to wait with implementing this Capability until the RFC is finalized. > Add Provide-Capability for declarative services bundle > -- > > Key: FELIX-4412 > URL: https://issues.apache.org/jira/browse/FELIX-4412 > Project: Felix > Issue Type: Bug > Components: Declarative Services (SCR), Specification compliance >Affects Versions: scr-1.8.0 >Reporter: Alex Blewitt >Priority: Minor > > To allow bundles to declare that they need declarative services, a > Provide-Capability should be defined on the DS bundle such that clients can > depend on it, for example: > Provide-Capability: > osgi.extender;osgi.extender="osgi.service.component";version:=1.1.0 > This would allow clients to require that there be a Declarative Services > bundle without actually declaring a package dependency: > Require-Capability: > osgi.extender;filter:="(&(osgi.extender=osgi.service.component")(version>1.0.0))" > The name of the declarative services component isn't well defined but > osgi.service.component or osgi.declarative.services might be used. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (FELIX-4412) Add Provide-Capability for declarative services bundle
[ https://issues.apache.org/jira/browse/FELIX-4412?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger updated FELIX-4412: - Affects Version/s: scr-1.8.0 > Add Provide-Capability for declarative services bundle > -- > > Key: FELIX-4412 > URL: https://issues.apache.org/jira/browse/FELIX-4412 > Project: Felix > Issue Type: Bug > Components: Declarative Services (SCR), Specification compliance >Affects Versions: scr-1.8.0 >Reporter: Alex Blewitt >Priority: Minor > > To allow bundles to declare that they need declarative services, a > Provide-Capability should be defined on the DS bundle such that clients can > depend on it, for example: > Provide-Capability: > osgi.extender;osgi.extender="osgi.service.component";version:=1.1.0 > This would allow clients to require that there be a Declarative Services > bundle without actually declaring a package dependency: > Require-Capability: > osgi.extender;filter:="(&(osgi.extender=osgi.service.component")(version>1.0.0))" > The name of the declarative services component isn't well defined but > osgi.service.component or osgi.declarative.services might be used. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (FELIX-4412) Add Provide-Capability for declarative services bundle
[ https://issues.apache.org/jira/browse/FELIX-4412?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger updated FELIX-4412: - Component/s: Specification compliance > Add Provide-Capability for declarative services bundle > -- > > Key: FELIX-4412 > URL: https://issues.apache.org/jira/browse/FELIX-4412 > Project: Felix > Issue Type: Bug > Components: Declarative Services (SCR), Specification compliance >Affects Versions: scr-1.8.0 >Reporter: Alex Blewitt >Priority: Minor > > To allow bundles to declare that they need declarative services, a > Provide-Capability should be defined on the DS bundle such that clients can > depend on it, for example: > Provide-Capability: > osgi.extender;osgi.extender="osgi.service.component";version:=1.1.0 > This would allow clients to require that there be a Declarative Services > bundle without actually declaring a package dependency: > Require-Capability: > osgi.extender;filter:="(&(osgi.extender=osgi.service.component")(version>1.0.0))" > The name of the declarative services component isn't well defined but > osgi.service.component or osgi.declarative.services might be used. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Resolved] (FELIX-4408) CaseInsensitiveDictionary is platform/locale dependant
[ https://issues.apache.org/jira/browse/FELIX-4408?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger resolved FELIX-4408. -- Resolution: Fixed Fix Version/s: configadmin-1.8.2 Assignee: Felix Meschberger Thanks for providing the patch. I have applied it slightly modified in Rev. 1561599: Instead of calling the String.toLowerCase(Locale) method in each place, I created a new helper method. > CaseInsensitiveDictionary is platform/locale dependant > -- > > Key: FELIX-4408 > URL: https://issues.apache.org/jira/browse/FELIX-4408 > Project: Felix > Issue Type: Bug > Components: Configuration Admin >Affects Versions: configadmin-1.8.0 >Reporter: Tobias Bocanegra >Assignee: Felix Meschberger > Fix For: configadmin-1.8.2 > > Attachments: FELIX-4408-r1558196.patch, FELIX-4408-test-r1558196.patch > > > The CaseInsensitiveDictionary [0] can behave wrongly for non english locales. > see reasoning in COLLECTIONS-294 and [1]. > [0] > https://svn.apache.org/repos/asf/felix/trunk/configadmin/src/main/java/org/apache/felix/cm/impl/CaseInsensitiveDictionary.java > [1] http://mattryall.net/blog/2009/02/the-infamous-turkish-locale-bug > A fix similar to the 2nd patch in COLLECTIONS-294 probably solves the problem. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (FELIX-4389) Configuration ranking for LMF services should also use "jaas.ranking" property
[ https://issues.apache.org/jira/browse/FELIX-4389?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13878357#comment-13878357 ] Felix Meschberger commented on FELIX-4389: -- Sorry for the dealy and thanks for the patch. I have applied it in Rev. 1560267. > Configuration ranking for LMF services should also use "jaas.ranking" property > -- > > Key: FELIX-4389 > URL: https://issues.apache.org/jira/browse/FELIX-4389 > Project: Felix > Issue Type: Improvement > Components: JAAS >Affects Versions: jaas-0.0.2 >Reporter: Tobias Bocanegra >Assignee: Felix Meschberger > Fix For: jaas-0.0.2 > > Attachments: felix-4389-r1558508.patch, felix-4389-r1558868.patch > > > The JAAS configuration entries that are managed by configuration are sorted > using the "jaas.ranking" property, but the entries that are managed via a > LoginModuleFactory service are ranked using the "service.ranking" property. > this might be a problem if an implementing class also implements another > service that is ranked by the "service.ranking" property (e.g. the > AuthenticationHandlers in Sling). > Suggest to use the "jaas.ranking" also for LMF service based entries. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Resolved] (FELIX-4389) Configuration ranking for LMF services should also use "jaas.ranking" property
[ https://issues.apache.org/jira/browse/FELIX-4389?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger resolved FELIX-4389. -- Resolution: Fixed Fix Version/s: jaas-0.0.2 Thanks for providing the patch. I have applied it with a small extension in Rev. 1558854: - For backwards compatibility support for service.ranking is retained if the jaas.ranking property is missing - Also consolidated the service property and configuration constants > Configuration ranking for LMF services should also use "jaas.ranking" property > -- > > Key: FELIX-4389 > URL: https://issues.apache.org/jira/browse/FELIX-4389 > Project: Felix > Issue Type: Improvement > Components: JAAS >Affects Versions: jaas-0.0.2 >Reporter: Tobias Bocanegra >Assignee: Felix Meschberger > Fix For: jaas-0.0.2 > > Attachments: felix-4389-r1558508.patch > > > The JAAS configuration entries that are managed by configuration are sorted > using the "jaas.ranking" property, but the entries that are managed via a > LoginModuleFactory service are ranked using the "service.ranking" property. > this might be a problem if an implementing class also implements another > service that is ranked by the "service.ranking" property (e.g. the > AuthenticationHandlers in Sling). > Suggest to use the "jaas.ranking" also for LMF service based entries. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Resolved] (FELIX-4390) Login modules registered via LMF not updated if LMF service config changes
[ https://issues.apache.org/jira/browse/FELIX-4390?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger resolved FELIX-4390. -- Resolution: Fixed Fix Version/s: jaas-0.0.2 Thanks for providing the patch. I have applied it in Rev. 1558624 > Login modules registered via LMF not updated if LMF service config changes > -- > > Key: FELIX-4390 > URL: https://issues.apache.org/jira/browse/FELIX-4390 > Project: Felix > Issue Type: Bug > Components: JAAS >Affects Versions: jaas-0.0.2 >Reporter: Tobias Bocanegra >Assignee: Felix Meschberger > Fix For: jaas-0.0.2 > > Attachments: felix-4390-r1558508.patch > > > The configuration entries of LoginModules registered via a LoginModuleFactory > service are not updated, if the LMF service changes its configuration. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Resolved] (FELIX-4387) JAAS config fields are initialized too late in the ConfigSpiOsgi constructor
[
https://issues.apache.org/jira/browse/FELIX-4387?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Felix Meschberger resolved FELIX-4387.
--
Resolution: Fixed
Fix Version/s: jaas-0.0.2
Thanks for providing the patch. I have applied in in Rev. 1558623
> JAAS config fields are initialized too late in the ConfigSpiOsgi constructor
>
>
> Key: FELIX-4387
> URL: https://issues.apache.org/jira/browse/FELIX-4387
> Project: Felix
> Issue Type: Bug
> Components: JAAS
>Affects Versions: jaas-0.0.2
>Reporter: Tobias Bocanegra
>Assignee: Felix Meschberger
> Fix For: jaas-0.0.2
>
> Attachments: felix-4387-r1558508.patch
>
>
> The {{originalConfig}} and {{proxyConfig}} fields are initialized after the
> service registration, which is a problem in the {{update()}} call triggered
> by the config admin.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
