[jira] Updated: (FELIX-1863) getServletPath() should return "" when alias is /
[ https://issues.apache.org/jira/browse/FELIX-1863?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Edelson updated FELIX-1863: -- Attachment: FELIX-1863.patch here's a patch > getServletPath() should return "" when alias is / > - > > Key: FELIX-1863 > URL: https://issues.apache.org/jira/browse/FELIX-1863 > Project: Felix > Issue Type: Bug > Components: HTTP Service >Affects Versions: http-2.0.2 >Reporter: Justin Edelson > Attachments: FELIX-1863.patch > > > When a servlet is registered with HttpService with an alias of "/", > getServletPath() should return "". Currently it returns "/". -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (FELIX-1863) getServletPath() should return "" when alias is /
getServletPath() should return "" when alias is / - Key: FELIX-1863 URL: https://issues.apache.org/jira/browse/FELIX-1863 Project: Felix Issue Type: Bug Components: HTTP Service Affects Versions: http-2.0.2 Reporter: Justin Edelson Attachments: FELIX-1863.patch When a servlet is registered with HttpService with an alias of "/", getServletPath() should return "". Currently it returns "/". -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
why SCR restarts components when service pid is modified ?
Hello everyone,
I'm playing with the latest SCR from the trunk (and with felix 2.0.2).
More specifically, I am testing the new DS 1.1 "modified" attribute,
which allows to invoke a callback when the service component
configuration is updated (using config admin).
it works fine, but once my component is invoked it it's "modified"
callback, the component is then deactivated and reactivated, and I am
wondering why ?
Here is my SCR xml descriptors:
http://www.osgi.org/xmlns/scr/v1.1.0";>
class="com.alcatel_lucent.dictionary.english.EnglishDictionary" />
and here is my component ->
public class EnglishDictionary implements DictionaryService {
private final static Logger _logger =
Logger.getLogger(EnglishDictionary.class);
protected void activate(Map conf) {
_logger.warn("Activate: config:" + conf);
}
protected void deactivate() {
_logger.warn("Deactivate");
}
public void updated(Map conf) {
_logger.warn("updated: " + conf);
}
// ...
}
So, when I update my configuration using the pid "englishdico", I see
that my "updated" method is nicely invoked ... but the component is then
deactivated/reactivated ?
Is it a normal behaviour ?
thanks;
/pierre
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
Re: Errors on the Apache Felix download page
Hi, You should use http://felix.apache.org/site/downloads.cgi (cgi not html) which replaces the placeholder by a 'correct' value. From where did you get the link to the .html file ? Regards, Clement On 11.11.2009, at 11:27, Kristian Waagan wrote: Hello, I tried downloading Felix today, but that didn't work as it was supposed to. At http://felix.apache.org/site/downloads.html , at least most of the links have some tokens/placeholders in them. For instance: http://felix.apache.org/site/%5Bpreferred%5D/felix/felix-framework-2.0.1.tar.gz http://felix.apache.org/site/%5Blocation%5D?Preferred=[ftp] Trying the last link results in: "Not Found The requested URL /site/[location] was not found on this server. Apache/2.2.12 (Unix) mod_fcgid/2.3.2-dev Server at felix.apache.org Port 80" Just wanted to let you know. I was able to get what I needed from the archives :) Regards, -- Kristian BTW: I'm not subscribing to this list.
[jira] Closed: (FELIX-1573) Occasional NPE in URLHandlersBundleStreamHandler
[ https://issues.apache.org/jira/browse/FELIX-1573?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Richard S. Hall closed FELIX-1573. -- Resolution: Fixed Closing this issue since there was a commit against 2.0.1 for this issue, so there is no reason to move this issue to 2.0.2 because it didn't fully resolve the bug. We have FELIX-1834 for the complete fix in 2.0.2. > Occasional NPE in URLHandlersBundleStreamHandler > > > Key: FELIX-1573 > URL: https://issues.apache.org/jira/browse/FELIX-1573 > Project: Felix > Issue Type: Bug > Components: Framework >Affects Versions: felix-1.8.1, felix-2.0.0 >Reporter: Don Brown >Assignee: Karl Pauls > Fix For: felix-2.0.1 > > > I'm occasionally seeing startup failures in my integration tests due to an > NPE in URLHandlersBundleStreamHandler that looks like some sort of race > condition: > - Started bundle org.springframework (5) > 08-Sep-2009 02:54:37 - Loading XML bean definitions from OSGi > resource[bundle://6.0:0/META-INF/spring/extender/spring-event-bridge.xml|bnd.id=6|bnd.sym=org.springframework.osgi.extender] > 08-Sep-2009 02:54:37 - Unable to process extender configuration > 08-Sep-2009 02:54:37 > org.springframework.beans.factory.BeanDefinitionStoreException: IOException > parsing XML document from OSGi > resource[bundle://6.0:0/META-INF/spring/extender/spring-event-bridge.xml|bnd.id=6|bnd.sym=org.springframework.osgi.extender]; > nested exception is java.io.IOException: No framework context found > 08-Sep-2009 02:54:37 at > org.springframework.beans.factory.xml.XmlBeanDefinitionReader.loadBeanDefinitions(XmlBeanDefinitionReader.java:349) > 08-Sep-2009 02:54:37 at > org.springframework.beans.factory.xml.XmlBeanDefinitionReader.loadBeanDefinitions(XmlBeanDefinitionReader.java:310) > 08-Sep-2009 02:54:37 at > org.springframework.beans.factory.support.AbstractBeanDefinitionReader.loadBeanDefinitions(AbstractBeanDefinitionReader.java:143) > 08-Sep-2009 02:54:37 at > org.springframework.beans.factory.support.AbstractBeanDefinitionReader.loadBeanDefinitions(AbstractBeanDefinitionReader.java:178) > 08-Sep-2009 02:54:37 at > org.springframework.beans.factory.support.AbstractBeanDefinitionReader.loadBeanDefinitions(AbstractBeanDefinitionReader.java:149) > 08-Sep-2009 02:54:37 at > org.springframework.osgi.context.support.OsgiBundleXmlApplicationContext.loadBeanDefinitions(OsgiBundleXmlApplicationContext.java:176) > 08-Sep-2009 02:54:37 at > org.springframework.osgi.context.support.OsgiBundleXmlApplicationContext.loadBeanDefinitions(OsgiBundleXmlApplicationContext.java:142) > 08-Sep-2009 02:54:37 at > org.springframework.context.support.AbstractRefreshableApplicationContext.refreshBeanFactory(AbstractRefreshableApplicationContext.java:123) > 08-Sep-2009 02:54:37 at > org.springframework.context.support.AbstractApplicationContext.obtainFreshBeanFactory(AbstractApplicationContext.java:422) > 08-Sep-2009 02:54:37 at > org.springframework.context.support.AbstractApplicationContext.refresh(AbstractApplicationContext.java:352) > 08-Sep-2009 02:54:37 at > org.springframework.osgi.context.support.AbstractDelegatedExecutionApplicationContext.access$301(AbstractDelegatedExecutionApplicationContext.java:69) > 08-Sep-2009 02:54:37 at > org.springframework.osgi.context.support.AbstractDelegatedExecutionApplicationContext$1.run(AbstractDelegatedExecutionApplicationContext.java:186) > 08-Sep-2009 02:54:37 at > org.springframework.osgi.util.internal.PrivilegedUtils.executeWithCustomTCCL(PrivilegedUtils.java:85) > 08-Sep-2009 02:54:37 at > org.springframework.osgi.context.support.AbstractDelegatedExecutionApplicationContext.normalRefresh(AbstractDelegatedExecutionApplicationContext.java:182) > 08-Sep-2009 02:54:37 at > org.springframework.osgi.context.support.AbstractDelegatedExecutionApplicationContext$NoDependenciesWaitRefreshExecutor.refresh(AbstractDelegatedExecutionApplicationContext.java:89) > 08-Sep-2009 02:54:37 at > org.springframework.osgi.context.support.AbstractDelegatedExecutionApplicationContext.refresh(AbstractDelegatedExecutionApplicationContext.java:175) > 08-Sep-2009 02:54:37 at > org.springframework.osgi.extender.internal.support.ExtenderConfiguration.(ExtenderConfiguration.java:169) > 08-Sep-2009 02:54:37 at > org.springframework.osgi.extender.internal.activator.ContextLoaderListener.start(ContextLoaderListener.java:380) > 08-Sep-2009 02:54:37 at > org.apache.felix.framework.util.SecureAction.startActivator(SecureAction.java:589) > 08-Sep-2009 02:54:37 at > org.apache.felix.framework.Felix.startBundle(Felix.java:1461) > 08-Sep-2009 02:54:37
Errors on the Apache Felix download page
Hello, I tried downloading Felix today, but that didn't work as it was supposed to. At http://felix.apache.org/site/downloads.html , at least most of the links have some tokens/placeholders in them. For instance: http://felix.apache.org/site/%5Bpreferred%5D/felix/felix-framework-2.0.1.tar.gz http://felix.apache.org/site/%5Blocation%5D?Preferred=[ftp] Trying the last link results in: "Not Found The requested URL /site/[location] was not found on this server. Apache/2.2.12 (Unix) mod_fcgid/2.3.2-dev Server at felix.apache.org Port 80" Just wanted to let you know. I was able to get what I needed from the archives :) Regards, -- Kristian BTW: I'm not subscribing to this list.
[jira] Commented: (FELIX-1789) FileInstall is too verbose
[
https://issues.apache.org/jira/browse/FELIX-1789?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12776528#action_12776528
]
Richard S. Hall commented on FELIX-1789:
It looks like File Install uses the Log Service if its present, but if not then
it always logs to stdout. So, if there is a log service then the output can be
controlled, but if there is not then there is no control over what is logged to
stdout. It seems like this could be solved by adding a configuration property
to indicate which level of messages should be logged. This would control what
was logged regardless of whether it was using the log service or stdout.
> FileInstall is too verbose
> --
>
> Key: FELIX-1789
> URL: https://issues.apache.org/jira/browse/FELIX-1789
> Project: Felix
> Issue Type: Bug
> Components: File Install
>Affects Versions: fileinstall-2.0.0
> Environment: generic
>Reporter: Sahoo
> Fix For: fileinstall-2.0.6
>
>
> GlassFish users have commented that FileInstall is too verbose. They suggest
> the initial configuration related messages to be moved to debug level.
> e.g.,
> INFO: {felix.fileinstall.poll (ms) = 5000, felix.fileinstall.dir =
> /space/ss141213/WS/gf/v3/publish/glassfishv3/glassfish/domains/domain1/autodeploy/bundles,
> felix.fileinstall.debug = 1, felix.fileinstall.bundles.new.start = true,
> felix.fileinstall.tmpdir = /tmp/fileinstall, felix.fileinstall.filter = null}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
FileInstall updating a bundle instead of installing
I am observing that if I add a file with different name in the watched directory with a bundle-symbolicname and version that's already used by an existing bundle, fileinstall 2.0.4 updates the existing bundle. Is it not true this behavior is different from versions < 2.0 ? Should it not fail to install the new bundle? Thanks, Sahoo
[jira] Created: (FELIX-1862) fileinstall thread name as printed in log messages need to be less verbose
fileinstall thread name as printed in log messages need to be less verbose
--
Key: FELIX-1862
URL: https://issues.apache.org/jira/browse/FELIX-1862
Project: Felix
Issue Type: Bug
Components: File Install
Affects Versions: fileinstall-2.0.4
Environment: generic
Reporter: Sahoo
Look at the following message. The thread created by fileinstall has a name
that includes everything that's used to configure fileinstall:
[#|2009-11-11T19:06:28.958+0530|INFO|glassfishv3.0|null|_ThreadID=23;_ThreadName={felix.fileinstall.poll=5000,
felix.fileinstall.bundles.new.start=true,
felix.fileinstall.dir=/space/ss141213/WS/gf/v3/publish/glassfishv3/glassfish/modules/autostart/,
felix.fileinstall.debug=1};|Installed
/space/ss141213/WS/gf/v3/publish/glassfishv3/glassfish/modules/autostart/org.apache.felix.fileinstall-autodeploy-bundles.cfg|#]
It would have been sufficient to only include the watched directory name in the
thread name as there is always one thread per watched directory.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (FELIX-1861) FileInstall created temp directories are never deleted
FileInstall created temp directories are never deleted
--
Key: FELIX-1861
URL: https://issues.apache.org/jira/browse/FELIX-1861
Project: Felix
Issue Type: Bug
Components: File Install
Affects Versions: fileinstall-2.0.4
Environment: Linux/SunJDK6
Reporter: Sahoo
In GlassFish, I don't configure any specific temp folder for file install, so
it creates some temp folders in ${java.io.tmpdir}, but I never see them getting
deleted. e.g., from fileinstall logs, I see the following:
[#|2009-11-11T19:06:23.633+0530|INFO|glassfishv3.0|null|_ThreadID=22;_ThreadName={felix.fileinstall.poll=5000,
service.pid=org.apache.felix.fileinstall.5ed48f74-77d9-4b78-9972-9e235f76ba8c,
felix.fileinstall.bundles.new.start=true,
felix.fileinstall.dir=/space/ss141213/WS/gf/v3/publish/glassfishv3/glassfish/domains/domain1/autodeploy/bundles/,
service.factorypid=org.apache.felix.fileinstall,
felix.fileinstall.filename=org.apache.felix.fileinstall-autodeploy-bundles.cfg,
felix.fileinstall.debug=1};|{felix.fileinstall.poll (ms) = 5000,
felix.fileinstall.dir =
/space/ss141213/WS/gf/v3/publish/glassfishv3/glassfish/domains/domain1/autodeploy/bundles,
felix.fileinstall.debug = 1, felix.fileinstall.bundles.new.start = true,
felix.fileinstall.tmpdir = /tmp/fileinstall-867036041551774039,
felix.fileinstall.filter = null}|#]
[#|2009-11-11T19:06:23.637+0530|INFO|glassfishv3.0|null|_ThreadID=23;_ThreadName={felix.fileinstall.poll=5000,
felix.fileinstall.bundles.new.start=true,
felix.fileinstall.dir=/space/ss141213/WS/gf/v3/publish/glassfishv3/glassfish/modules/autostart/,
felix.fileinstall.debug=1};|{felix.fileinstall.poll (ms) = 5000,
felix.fileinstall.dir =
/space/ss141213/WS/gf/v3/publish/glassfishv3/glassfish/modules/autostart,
felix.fileinstall.debug = 1, felix.fileinstall.bundles.new.start = true,
felix.fileinstall.tmpdir = /tmp/fileinstall-2323635376943197261,
felix.fileinstall.filter = null}|#]
and after the program is stopped, I still see those tmp folders. In fact, they
just keep getting created and it's a nightmare.
ls /tmp/fileinstall-* | wc
41 21 827
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
