[jira] [Commented] (FELIX-2980) org.apache.felix:maven-scr-plugin:1.7.1-SNAPSHOT:scr failed. NullPointerException
[
https://issues.apache.org/jira/browse/FELIX-2980?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13048279#comment-13048279
]
Carsten Ziegeler commented on FELIX-2980:
-
I've now pulished the latest snapshots
> org.apache.felix:maven-scr-plugin:1.7.1-SNAPSHOT:scr failed.
> NullPointerException
> -
>
> Key: FELIX-2980
> URL: https://issues.apache.org/jira/browse/FELIX-2980
> Project: Felix
> Issue Type: Bug
> Components: Maven SCR Plugin
>Reporter: Andrei Pozolotin
>Assignee: Carsten Ziegeler
> Fix For: maven-scr-plugin-1.7.2, scr generator 1.1.2
>
>
> public Class[] value() {
> return Util.getClassArrayValue(annotation, "value",
> Service.class, desc.getClassLoader()); // line #80
> }
> [ERROR] Failed to execute goal
> org.apache.felix:maven-scr-plugin:1.7.1-SNAPSHOT:scr (scr) on project
> barchart-plugin-core: Execution scr of goal
> org.apache.felix:maven-scr-plugin:1.7.1-SNAPSHOT:scr failed.
> NullPointerException -> [Help 1]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
> goal org.apache.felix:maven-scr-plugin:1.7.1-SNAPSHOT:scr (scr) on project
> barchart-plugin-core: Execution scr of goal
> org.apache.felix:maven-scr-plugin:1.7.1-SNAPSHOT:scr failed.
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:225)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59)
> at
> org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183)
> at
> org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:319)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156)
> at org.apache.maven.cli.MavenCli.execute(MavenCli.java:534)
> at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:141)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352)
> Caused by: org.apache.maven.plugin.PluginExecutionException: Execution scr of
> goal org.apache.felix:maven-scr-plugin:1.7.1-SNAPSHOT:scr failed.
> at
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:116)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209)
> ... 19 more
> Caused by: java.lang.NullPointerException
> at
> org.apache.felix.scrplugin.tags.annotation.defaulttag.ServiceTag$1.value(ServiceTag.java:80)
> at
> org.apache.felix.scrplugin.tags.annotation.defaulttag.ServiceTag.createServiceTags(ServiceTag.java:87)
> at
> org.apache.felix.scrplugin.tags.annotation.defaulttag.DefaultAnnotationTagProvider.getTags(DefaultAnnotationTagProvider.java:50)
> at
> org.apache.felix.scrplugin.tags.annotation.AnnotationTagProviderManager.getTags(AnnotationTagProviderManager.java:159)
> at
> org.apache.felix.scrplugin.tags.annotation.AnnotationTagProviderManager.getTags(AnnotationTagProviderManager.java:141)
> at
> org.apache.felix.scrplugin.tags.annotation.AnnotationTagProviderManager.hasScrPluginAnnotation(AnnotationTagProviderManager.java:176)
> at
> org.apache.felix.scrplugin.JavaClassDescriptorManager.getJavaClassDescription(JavaClassDescriptorManager.java:396)
> at
> org.apache.felix.scrplugin.JavaClassDescriptorManager.getSourceDescriptions(JavaClassDescriptorManager.java:365)
> at
> org.apache.felix.scrplugin.SCRDescriptorGenerator.execute(SCRDescriptorGenerator.java:234)
> at
> org.apache.felix.scrplugin.mojo.SCRDescriptorMojo.execute(SCRDescriptorMojo.java:184)
> at
> org.apache.maven.plugi
[jira] [Resolved] (FELIX-2894) Gogo does not handles options but not parameters
[
https://issues.apache.org/jira/browse/FELIX-2894?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Derek Baum resolved FELIX-2894.
---
Resolution: Fixed
Fix Version/s: gogo.runtime-0.10.0
added new testcases for argument coercion, including Parameters.
Refactored Reflective.java to simplify code.
> Gogo does not handles options but not parameters
>
>
> Key: FELIX-2894
> URL: https://issues.apache.org/jira/browse/FELIX-2894
> Project: Felix
> Issue Type: Bug
> Components: Gogo Runtime
>Reporter: Peter Kriens
>Assignee: Derek Baum
> Fix For: gogo.runtime-0.10.0
>
>
> If you create a function with a parameter then the correct method cannot be
> found:
> public void xyz( @Parameter( names="-v", absentValue="absent") String string
> ) { return string; }
> This method is not found for xyz -v abc
> There were two bugs in the code:
> - annotation values can never be null but null was checked for the
> presentValue to see if it was not there.
> - After handling the parameters the new length of the command line was
> checked against the xargs. However, this still contained the parameter name +
> value. So the size was too high to match.
> I've added a check for the Parameter.UNSPECIFIED when checking the status of
> presentValue and I removed the check for the length of xargs, only types is
> relevant I think. However, might need some other pair of eyes
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (FELIX-2927) [gogo] coercion mechanism invokes foo(String) instead of foo(int) - even with explicit int argument
[ https://issues.apache.org/jira/browse/FELIX-2927?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Derek Baum resolved FELIX-2927. --- Resolution: Fixed Fix Version/s: gogo.runtime-0.10.0 fixed by refactoring Reflective.java to give conversion cost for coercion. > [gogo] coercion mechanism invokes foo(String) instead of foo(int) - even with > explicit int argument > --- > > Key: FELIX-2927 > URL: https://issues.apache.org/jira/browse/FELIX-2927 > Project: Felix > Issue Type: Bug > Components: Gogo Runtime >Affects Versions: gogo.runtime-0.8.0 >Reporter: Derek Baum >Assignee: Derek Baum > Fix For: gogo.runtime-0.10.0 > > > Equinox 3.7.M6 supports OSGi R4.3 which adds the overloaded method > BundleContext.getBundle(String). > This causes gogo startup to fail, as it expects to invoke getBundle(int) but > actually invokes getBundle(String). > Prior to R4.3, the gogo command: bundle 1 > resulted in the String "1" being coerced into a long, so that getBundle(long) > could be invoked. > Now that getBundle(String) exists, the result depends on the order that > methods are returned from Class.getMethods(), which varies between platforms: > On Mac java version "1.6.0_24": > g! type bundle > bundle is Bundle context:bundle(long) > bundle is Bundle context:bundle() > bundle is Bundle context:bundle(String) > On Windows 2003 server, java version "1.6.0_24": > g! type bundle > bundle is Bundle context:bundle() > bundle is Bundle context:bundle(String) > bundle is Bundle context:bundle(long) > The first "exact" match wins, where "exact" just means that all supplied > arguments are used. > On the Mac, getBundle(long) still wins, but on Windows getBundle(String) wins > and the gogo startup scripts fails. > What's worse, is that even when you realise what is happening, it is still > not possible to invoke getBundle(long): > g! 1L = new Long 1 > g! bundle $1L > because in this case the long is coerced to a String to invoke get > Bundle(String) and the getBundle(long) method is ignored. > There are at least two problems here: > 1. the gogo coercion mechanism simply invokes the first method it can, > regardless of whether any arguments needed to be converted. > It should instead try to score each method, perhaps adding to the score each > time an argument needs to be converted, > then it could invoke the method with the lowest score. > However, there may still be occasions when two methods have the same score > and gogo needs to behave deterministically > and allow either method to be invoked by supplying less ambiguous arguments. > 2. all arguments in gogo start out as Strings, which make it awkward to > prefer a method that takes an integer: > for example: g! bundle (new Long 1) > getBundle(long) is the most likely target method, but gogo does not any > syntax to indicate that arguments should be treated as numbers rather than > Strings. One possibility would be to recognize numbers in gogo's Tokenizer > similar to the way that true/false are handled: > g! t = true > true > g! tt = 'true' > true > g! set t > Boolean t true > String tt true > The above shows that the bare word: true is tokenized as a Boolean, where as > the quoted word 'true' is tokenized as a String. > So bare numbers could be tokenized as Numbers, and the existing coercion > mechanism would convert them back to Strings as needed; > alternative by quoting something that looks like a number, you force it to be > tokenized as a String. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (FELIX-2993) jnlp & felix.security
jnlp & felix.security - Key: FELIX-2993 URL: https://issues.apache.org/jira/browse/FELIX-2993 Project: Felix Issue Type: Bug Components: Framework Security Reporter: Andrei Pozolotin original thread: http://www.mail-archive.com/users@felix.apache.org/msg10424.html -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (FELIX-2993) jnlp & felix.security
[
https://issues.apache.org/jira/browse/FELIX-2993?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13048371#comment-13048371
]
Andrei Pozolotin commented on FELIX-2993:
-
per jdk jnlp source:
https://github.com/carrot-garden/carrot-jnlper/tree/master/carrot-jdk6-jnlp-unix
this place produces the "security concern":
https://github.com/carrot-garden/carrot-jnlper/blob/master/carrot-jdk6-jnlp-unix/src/common/share/classes/com/sun/deploy/security/CPCallbackHandler.java
public class CPCallbackHandler {
private synchronized void check(URL url, boolean trusted, boolean
authenticated) {
if (maybeTrustedChild && maybeUntrustedChild) {
String msg = checkAllowed(url, maybeTrustedChild &&
trustedChild);
if (msg != null) {
throw new SecurityException(msg);
}
}
private String checkAllowed(URL url, boolean wasTrusted) {
if (checkMixedTrust) {
int result = showMixedTrustDialog();
if (result == UIFactory.CANCEL) {
allowMixedTrust = true;
}
checkMixedTrust = false;
}
> jnlp & felix.security
> -
>
> Key: FELIX-2993
> URL: https://issues.apache.org/jira/browse/FELIX-2993
> Project: Felix
> Issue Type: Bug
> Components: Framework Security
>Reporter: Andrei Pozolotin
>
> original thread:
> http://www.mail-archive.com/users@felix.apache.org/msg10424.html
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (FELIX-2993) jnlp & felix.security
[ https://issues.apache.org/jira/browse/FELIX-2993?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13048373#comment-13048373 ] Andrei Pozolotin commented on FELIX-2993: - explanation of the original intent & how it was supposed to work : the "secruity concern" http://download.oracle.com/javase/6/docs/technotes/guides/jweb/mixed_code.html > jnlp & felix.security > - > > Key: FELIX-2993 > URL: https://issues.apache.org/jira/browse/FELIX-2993 > Project: Felix > Issue Type: Bug > Components: Framework Security >Reporter: Andrei Pozolotin > > original thread: > http://www.mail-archive.com/users@felix.apache.org/msg10424.html -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (FELIX-2994) Delayed Components in Dependency Manager
Delayed Components in Dependency Manager Key: FELIX-2994 URL: https://issues.apache.org/jira/browse/FELIX-2994 Project: Felix Issue Type: Improvement Components: Dependency Manager Reporter: Pierre De Rop Priority: Minor This issue proposes a lightweight implementation for the support of "delayed components" in Dependency Manager. (see patch attached to this issue). It allows components to delay their possibly expensive activation until they are really used, and allows Dependency Manager to instantiate/initialize components only as needed. For system where many services are installed, and where not every services are actually used, then this feature can significantly speed up startup time, especially when some unused components require an expensive processing from their "init" / "start" methods. A new "setDelayed(boolean)" method has been added in the Component interface, and also a new "delayed" state has been added in the ComponentDeclaration, allowing to browse delayed components from the DM shell. Here is a code example which defines a delayed component: dm.add(createComponent() .setImplementation(DelayedServiceImpl.class) .setInterface(DelayedService.class.getName, null) .setDelayed(true)); Implementation notes -- - By default, components are not delayed (as before). - A new DelayedComponentTest has been added in the test sub-project - This implementation is simple and is not intrusive: DM core classes *have not* been modified (excepts a micro-modif in ComponentImpl.java, and in ComponentDeclaration.java). Basically, we track every service listeners, and when a listener is matching a delayed component, then the component is started. Else, the component is not started, hence avoiding the useless component instantiation/initialization. - A new state has been added in the ComponentDeclaration class (STATE_DELAYED), allowing to track delayed components from the Dependency Manager shell. - The new filter index recently introduced in DM has not yet been used, but it might be useful to integrate it in the delayed component manager, since the DM indexer greatly speeds up service listeners lookup, especially when using many (thousands) of services. But this enhancement could be done in a next step. - The ListenerHook (from ServiceHook specification) is used for the implementation: this allows to trigger the activation of DM delayed components not only using DependencyManager dependencies, but also using other libraries, like Declarative Service, iPOJO, blueprint, or even ServiceTracker. This is important because in our environment, we are using both dependency manager and Declarative Service, and we need to be able to activate a delayed DM component from a Declarative Service "Reference" dependency. ListenerHook allows to do this because using ListenerHook, we are able to track every service listeners registered in the framework. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (FELIX-2994) Delayed Components in Dependency Manager
[ https://issues.apache.org/jira/browse/FELIX-2994?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pierre De Rop updated FELIX-2994: - Attachment: FELIX-2994.tgz attached the proposed implementation for delayed components. > Delayed Components in Dependency Manager > > > Key: FELIX-2994 > URL: https://issues.apache.org/jira/browse/FELIX-2994 > Project: Felix > Issue Type: Improvement > Components: Dependency Manager >Reporter: Pierre De Rop >Priority: Minor > Attachments: FELIX-2994.tgz > > > This issue proposes a lightweight implementation for the support of "delayed > components" in Dependency Manager. > (see patch attached to this issue). > It allows components to delay their possibly expensive activation until they > are really used, and allows > Dependency Manager to instantiate/initialize components only as needed. > For system where many services are installed, and where not every services > are actually used, then this feature > can significantly speed up startup time, especially when some unused > components require an expensive > processing from their "init" / "start" methods. > A new "setDelayed(boolean)" method has been added in the Component interface, > and also a new "delayed" state > has been added in the ComponentDeclaration, allowing to browse delayed > components from the DM shell. > Here is a code example which defines a delayed component: > dm.add(createComponent() >.setImplementation(DelayedServiceImpl.class) >.setInterface(DelayedService.class.getName, null) >.setDelayed(true)); > Implementation notes > -- >- By default, components are not delayed (as before). >- A new DelayedComponentTest has been added in the test sub-project > >- This implementation is simple and is not intrusive: DM core classes > *have not* been modified > (excepts a micro-modif in ComponentImpl.java, and in > ComponentDeclaration.java). Basically, > we track every service listeners, and when a listener is matching a > delayed component, then > the component is started. Else, the component is not started, hence > avoiding the useless component > instantiation/initialization. >- A new state has been added in the ComponentDeclaration class > (STATE_DELAYED), allowing to track > delayed components from the Dependency Manager shell. >- The new filter index recently introduced in DM has not yet been used, > but it might be useful to > integrate it in the delayed component manager, since the DM indexer > greatly speeds up service listeners lookup, > especially when using many (thousands) of services. But this enhancement > could be done in a next step. >- The ListenerHook (from ServiceHook specification) is used for the > implementation: this allows to trigger the > activation of DM delayed components not only using DependencyManager > dependencies, but also using other libraries, > like Declarative Service, iPOJO, blueprint, or even ServiceTracker. > This is important because > in our environment, we are using both dependency manager and Declarative > Service, and we need to be able to > activate a delayed DM component from a Declarative Service "Reference" > dependency. ListenerHook > allows to do this because using ListenerHook, we are able to track every > service listeners registered in the framework. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[REPORT] Apache Felix
Community * Normal mailing list and bug reporting activity. Software * Recent subproject releases: o AutoConf Resource Processor (0.1.0) o Dependency Manager (3.0.0) o Deployment Admin (0.9.0) o EventAdmin (1.2.12) o Framework and Main launcher (3.2.0, 3.2.1, 3.2.2) o Framework Security Provider (1.4.2) o iPOJO Event Admin Handler (1.8.0) o Log Service (1.0.1) o Maven SCR Plugin (1.7.0) o SCR Generator (1.1.0) o SCR Annotations (1.5.0) o SCR Ant Task (1.1.0) Project Branding * Project Website Basics: done * Website Navigation Links: done * Trademark Attributions: done * Logos and Graphics: open o TM missing from all Logos * Project Metadata: done Licensing and other issues * None.
