[jira] [Commented] (FELIX-3219) BundleInputStream class complexity
[ https://issues.apache.org/jira/browse/FELIX-3219?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13149484#comment-13149484 ] Karl Pauls commented on FELIX-3219: --- Well, the problem is that we can't assume that the jar file of the bundle is on disc (or at least, not as simple as that) -- hence, we use this wrapper to be able to work with any kind of content. I guess, one could be smart and switch on the content (i.e., if it is pointing to a jar on disc), just make it be a fileinputstream, otherwise (i.e., if it is a reference: to a dir) use the bundeinputstream. What is the issue you having on your vm (and what vm is it :-)? BundleInputStream class complexity -- Key: FELIX-3219 URL: https://issues.apache.org/jira/browse/FELIX-3219 Project: Felix Issue Type: Improvement Components: Framework Security Affects Versions: framework.security-1.4.1 Reporter: Andie Similon Priority: Minor What exactly is the purpose of the BundleInputStream class in the framework security package. Is there any reason why this was introduced? We are having issues with this class with our VM, when we replace it by a simple FileInputStream it seems to work fine. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (FELIX-3220) Multiple ClassCastException(s) when invoking OSGi Service-Hooks (EventHook, FindHook)
Multiple ClassCastException(s) when invoking OSGi Service-Hooks (EventHook,
FindHook)
-
Key: FELIX-3220
URL: https://issues.apache.org/jira/browse/FELIX-3220
Project: Felix
Issue Type: Bug
Components: Framework
Affects Versions: framework-4.0.1
Environment: Enable OSGi Security, using Felix security bundle version
2.0.0
Reporter: Michael Hirsch
Priority: Critical
Fix For: framework-4.2.0
*Scenario:*
- Register a EventHook in the OSGi service registry as described in the OSGi
core specification 4.2.
- Run felix with a SecurityManager
- The framework is not calling the EventHook during framework service
(register, modify, and unregister service) operations.
*Expected Behavior*
- The framework code calls the EventHook during framework service (register,
modify, and unregister service) operations.
*Current Behavior:*
- A ClassCastException occurs in the framework code
org.apache.felix.framework.util.SecureAction:1628
- Logged on WARNING Level
*Probably Caused By:*
The ClassCastException is caused by calling the wrong setter-method within the
org.apache.felix.framework.util.SecureAction:1135 class.
The ServiceEvent will never be set which causes that in line 1628 when invoking
the EventHook the ServiceEvent argument is missing and parameters for the
EventHook will be casted wrong.
Method: org.apache.felix.framework.util.SecureAction # invokeServiceEventHook
{code}
public void invokeServiceEventHook(
org.osgi.framework.hooks.service.EventHook eh,
ServiceEvent event, CollectionBundleContext contexts)
throws Exception
{
actions.set(Actions.INVOKE_SERVICE_EVENT_HOOK, eh, contexts);
}
{code}
Method: org.apache.felix.framework.util.SecureAction.Actions # run
has wrong arguments:
arg1 = EventHook
arg2 = CollectionBundleContext
arg3 = null
{code}
case INVOKE_SERVICE_EVENT_HOOK:
((org.osgi.framework.hooks.service.EventHook) arg1).event(
(ServiceEvent) arg2, (CollectionBundleContext) arg3);
return null;
{code}
*Solution:*
Changing the method of setting the arguments for the Action class. Set also the
ServiceEvent!
{code}
public void invokeServiceEventHook(
org.osgi.framework.hooks.service.EventHook eh,
ServiceEvent event, CollectionBundleContext contexts)
throws Exception
{
actions.set(Actions.INVOKE_SERVICE_EVENT_HOOK, eh, event, contexts);
}
{code}
*Additional:*
# Meanwhile investigating code I found that also invoking the
ServiceEventListenerHook has probably the same behavior! When calling the
setter-method for setting the arguments for the Action class there is missing
the ServiceEvent.
# Invoking FindHook using wrong action constant which causes a
ClassCastException!
Actions.INVOKE_SERVICE_EVENT_HOOK need to be changed to
Actions.INVOKE_SERVICE_FIND_HOOK
{code}
public void invokeServiceFindHook(
org.osgi.framework.hooks.service.FindHook fh,
BundleContext context, String name, String filter,
boolean allServices, CollectionServiceReference? references)
throws Exception
{
actions.set(
Actions.INVOKE_SERVICE_EVENT_HOOK, fh, context, name, filter,
(allServices) ? Boolean.TRUE : Boolean.FALSE, references);
}
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (FELIX-3221) NPE when uninstall a bundle on enabled OSGi security
NPE when uninstall a bundle on enabled OSGi security
Key: FELIX-3221
URL: https://issues.apache.org/jira/browse/FELIX-3221
Project: Felix
Issue Type: Bug
Components: Framework Security
Affects Versions: framework.security-2.0.0
Reporter: Michael Hirsch
org.apache.felix.framework.BundleImpl#adapt returns null:
{code}
public synchronized A A adapt(ClassA type)
{
else if (type == BundleRevision.class)
{
if (m_state == Bundle.UNINSTALLED)
{
return null;
}
.
{code}
This causes a NPE:
StackTrace:
java.lang.NullPointerException
at
org.apache.felix.framework.SecurityProviderImpl.getSignerMatcher(SecurityProviderImpl.java:73)
at org.apache.felix.framework.Felix.getSignerMatcher(Felix.java:4130)
at
org.apache.felix.framework.BundleImpl.getSignerCertificates(BundleImpl.java:901)
at
org.osgi.framework.SignerProperty.isBundleSigned(SignerProperty.java:110)
at org.osgi.framework.AdminPermission$1.run(AdminPermission.java:884)
at java.security.AccessController.doPrivileged(Native Method)
at
org.osgi.framework.AdminPermission.getProperties(AdminPermission.java:875)
at org.osgi.framework.AdminPermission.implies0(AdminPermission.java:671)
at
org.osgi.framework.AdminPermissionCollection.implies(AdminPermission.java:1014)
at
org.apache.felix.framework.security.util.Permissions.implies(Permissions.java:469)
at
org.apache.felix.framework.security.condpermadmin.ConditionalPermissionAdminImpl.eval(ConditionalPermissionAdminImpl.java:949)
at
org.apache.felix.framework.security.condpermadmin.ConditionalPermissionAdminImpl.hasPermission(ConditionalPermissionAdminImpl.java:882)
at
org.apache.felix.framework.SecurityProviderImpl.hasBundlePermission(SecurityProviderImpl.java:122)
at
org.apache.felix.framework.Felix.impliesBundlePermission(Felix.java:4139)
at
org.apache.felix.framework.BundleProtectionDomain.implies(BundleProtectionDomain.java:66)
at java.security.AccessControlContext.checkPermission(Unknown Source)
at java.security.AccessController.checkPermission(Unknown Source)
at java.lang.SecurityManager.checkPermission(Unknown Source)
at
org.apache.felix.framework.BundleImpl.getLocation(BundleImpl.java:583)
at
org.apache.felix.cm.impl.ConfigurationManager.bundleChanged(ConfigurationManager.java:607)
at
org.apache.felix.framework.util.EventDispatcher$3.run(EventDispatcher.java:861)
at java.security.AccessController.doPrivileged(Native Method)
at
org.apache.felix.framework.util.EventDispatcher.invokeBundleListenerCallback(EventDispatcher.java:858)
at
org.apache.felix.framework.util.EventDispatcher.fireEventImmediately(EventDispatcher.java:789)
at
org.apache.felix.framework.util.EventDispatcher.run(EventDispatcher.java:1088)
at
org.apache.felix.framework.util.EventDispatcher.access$000(EventDispatcher.java:54)
at
org.apache.felix.framework.util.EventDispatcher$1.run(EventDispatcher.java:101)
at java.lang.Thread.run(Unknown Source)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (FELIX-3145) VerifyError on Java 7
[ https://issues.apache.org/jira/browse/FELIX-3145?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13149521#comment-13149521 ] Clement Escoffier commented on FELIX-3145: -- There is two issues: * ASM must be updated * the manipulator must compute the frames VerifyError on Java 7 - Key: FELIX-3145 URL: https://issues.apache.org/jira/browse/FELIX-3145 Project: Felix Issue Type: Bug Components: iPOJO Environment: java 1.7.0 ant 1.8.2 felix 3.2.2 ipojo 1.6.0 1.6.2 1.8.0 bnd-task : bnd-0.0.401.jar Ubuntu Linux Reporter: Clement Escoffier Assignee: Clement Escoffier Fix For: ipojo-manipulator-1.8.2 The manipulator must use a more recent version of ASM to avoid the following issue: java.lang.VerifyError: Expecting a stackmap frame at branch target 5 in method acme.world.EmptyHelloNonImmediate._setInstanceManager(Lorg/apache/felix/ipojo/InstanceManager;)V at offset 1 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Issue Comment Edited] (FELIX-3145) VerifyError on Java 7
[ https://issues.apache.org/jira/browse/FELIX-3145?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13149521#comment-13149521 ] Clement Escoffier edited comment on FELIX-3145 at 11/14/11 9:55 AM: There is two issues: * ASM must be updated * the manipulator must compute the frames Running with -XX:-UseSplitVerifier makes it works. was (Author: clement.escoffier): There is two issues: * ASM must be updated * the manipulator must compute the frames VerifyError on Java 7 - Key: FELIX-3145 URL: https://issues.apache.org/jira/browse/FELIX-3145 Project: Felix Issue Type: Bug Components: iPOJO Environment: java 1.7.0 ant 1.8.2 felix 3.2.2 ipojo 1.6.0 1.6.2 1.8.0 bnd-task : bnd-0.0.401.jar Ubuntu Linux Reporter: Clement Escoffier Assignee: Clement Escoffier Fix For: ipojo-manipulator-1.8.2 The manipulator must use a more recent version of ASM to avoid the following issue: java.lang.VerifyError: Expecting a stackmap frame at branch target 5 in method acme.world.EmptyHelloNonImmediate._setInstanceManager(Lorg/apache/felix/ipojo/InstanceManager;)V at offset 1 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [VOTE] Drop support for javadoc annotations in SCR Tooling for future versions
+1 Regards Felix Am 12.11.2011 um 02:38 schrieb Carsten Ziegeler: Hi, as we have recently discussed the future of the scr tooling, it became obvious in that thread that we should drop the error prone approach of javadoc tags from scr tooling. In future versions we will support our own annotations, the annotation provider support we have right now, and the new annotations from the upcoming spec. But all of them are real Java annotations. With this change we will bump the version of the plugin to 2.0 - of course we will continue to support the 1.x line (if required) So please cast your votes. Thanks Carsten -- Carsten Ziegeler cziege...@apache.org
[jira] [Resolved] (FELIX-3145) VerifyError on Java 7
[ https://issues.apache.org/jira/browse/FELIX-3145?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Clement Escoffier resolved FELIX-3145. -- Resolution: Fixed Fixed in trunk. The new manipulator and the ant tasks are also deployed to the Maven apache.snapshots repository (https://repository.apache.org/content/repositories/snapshots/org/apache/felix/) VerifyError on Java 7 - Key: FELIX-3145 URL: https://issues.apache.org/jira/browse/FELIX-3145 Project: Felix Issue Type: Bug Components: iPOJO Environment: java 1.7.0 ant 1.8.2 felix 3.2.2 ipojo 1.6.0 1.6.2 1.8.0 bnd-task : bnd-0.0.401.jar Ubuntu Linux Reporter: Clement Escoffier Assignee: Clement Escoffier Fix For: ipojo-manipulator-1.8.2 The manipulator must use a more recent version of ASM to avoid the following issue: java.lang.VerifyError: Expecting a stackmap frame at branch target 5 in method acme.world.EmptyHelloNonImmediate._setInstanceManager(Lorg/apache/felix/ipojo/InstanceManager;)V at offset 1 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (FELIX-3222) [PATCH] build fails with unreported exception
[PATCH] build fails with unreported exception --- Key: FELIX-3222 URL: https://issues.apache.org/jira/browse/FELIX-3222 Project: Felix Issue Type: Bug Components: Maven Bundle Plugin Affects Versions: maven-bundle-plugin-2.3.5 Environment: fedora-rawhide-x86_64 Reporter: Jaromír Cápík The following error appears when building in the latest fedora-rawhide environment: [ERROR] /projects/maven-plugin-bundle/maven-bundle-plugin-2.3.5/src/main/java/org/apache/felix/obrplugin/RemoteFileManager.java:[118,45] unreported exception org.apache.maven.repository.legacy.WagonConfigurationException; must be caught or declared to be thrown The following patch solved the build issue (i know, that exception catchall is not the best solution): http://jcapik.fedorapeople.org/files/maven-bundle-plugin/maven-bundle-plugin-unreported-exception.patch -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (FELIX-3223) SCR Plugin requires installed .jar files for metadata extraction
SCR Plugin requires installed .jar files for metadata extraction
Key: FELIX-3223
URL: https://issues.apache.org/jira/browse/FELIX-3223
Project: Felix
Issue Type: Bug
Components: Maven SCR Plugin
Affects Versions: maven-scr-plugin-1.7.2
Reporter: Mark Derricutt
Priority: Minor
I was just diagnosing a strange build problem for a coworker and traced it down
to a combination of us doing a release yesterday, and the developer in question
running mvn clean test rather than clean install which the rest of us do.
It looks like the plugin attempts to resolve and open an installed JAR file for
dependencies, rather than - in the case of a reactor build that this was, read
from the target/classes directory of the artifact.
I don't know if Maven provides support for automating this at all, but the
failure could be a bit more graceful, and inform the user that they need to
install dependent artifacts.
{code}
[ERROR] Failed to execute goal org.apache.felix:maven-scr-plugin:1.0.8:scr
(generate-scr-scrdescriptor) on project smx3.schema.provider: Unable to get
manifest from artifact smx3:smx3.api:jar:4.1.35-SNAPSHOT:compile: error in
opening zip file - [Help 1]
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal
org.apache.felix:maven-scr-plugin:1.0.8:scr (generate-scr-scrdescriptor) on
project smx3.schema.provider: Unable to get manifest from artifact
smx3:smx3.api:jar:4.1.35-SNAPSHOT:compile
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:217)
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:537)
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.MojoExecutionException: Unable to get
manifest from artifact smx3:smx3.api:jar:4.1.35-SNAPSHOT:compile
at
org.apache.felix.scrplugin.tags.JavaClassDescriptorManager.init(JavaClassDescriptorManager.java:171)
at
org.apache.felix.scrplugin.SCRDescriptorMojo.execute(SCRDescriptorMojo.java:106)
at
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209)
... 19 more
Caused by: java.util.zip.ZipException: error in opening zip file
at java.util.zip.ZipFile.open(Native Method)
at java.util.zip.ZipFile.init(ZipFile.java:127)
at java.util.jar.JarFile.init(JarFile.java:135)
at java.util.jar.JarFile.init(JarFile.java:99)
at
org.apache.felix.scrplugin.tags.JavaClassDescriptorManager.getManifest(JavaClassDescriptorManager.java:287)
at
org.apache.felix.scrplugin.tags.JavaClassDescriptorManager.init(JavaClassDescriptorManager.java:151)
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [VOTE] Release new SCR Tools
Anyone? We're missing two more votes... Thanks Carsten 2011/11/11 Carsten Ziegeler cziege...@apache.org: +1 Carsten 2011/11/10 Stefan Seifert sseif...@pro-vision.de: +1 (non-binding) i tested it with our projects and found no problems -Original Message- From: Carsten Ziegeler [mailto:cziege...@apache.org] Sent: Thursday, November 10, 2011 6:21 PM To: dev@felix.apache.org Subject: [VOTE] Release new SCR Tools Hi, this vote is about our SCR Tools - Apache Felix SCR Maven Plugin 1.7.4 - Apache Felix SCR Ant Task 1.1.4 - Apache Felix SCR Generator 1.1.4 This release is intended to be the last release before the discussed restructing of the plugin (if we have to fix serious things, we'll of course cut new releases) We solved several important issues in this release: https://issues.apache.org/jira/browse/FELIX/fixforversion/12317147 https://issues.apache.org/jira/browse/FELIX/fixforversion/12317148 https://issues.apache.org/jira/browse/FELIX/fixforversion/12317149 Staging repository: https://repository.apache.org/content/repositories/orgapachefelix-170/ You can use this UNIX script to download the release and verify the signatures: http://svn.apache.org/repos/asf/felix/trunk/check_staged_release.sh Usage: sh check_staged_release.sh 170 /tmp/felix-staging Please vote to approve this release: [ ] +1 Approve the release [ ] -1 Veto the release (please provide specific comments) This vote will be open for 72 hours. Regards -- Carsten Ziegeler cziege...@apache.org -- Carsten Ziegeler cziege...@apache.org -- Carsten Ziegeler cziege...@apache.org
[jira] [Assigned] (FELIX-3223) SCR Plugin requires installed .jar files for metadata extraction
[
https://issues.apache.org/jira/browse/FELIX-3223?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Carsten Ziegeler reassigned FELIX-3223:
---
Assignee: Carsten Ziegeler
SCR Plugin requires installed .jar files for metadata extraction
Key: FELIX-3223
URL: https://issues.apache.org/jira/browse/FELIX-3223
Project: Felix
Issue Type: Bug
Components: Maven SCR Plugin
Affects Versions: maven-scr-plugin-1.7.2
Reporter: Mark Derricutt
Assignee: Carsten Ziegeler
Priority: Minor
I was just diagnosing a strange build problem for a coworker and traced it
down to a combination of us doing a release yesterday, and the developer in
question running mvn clean test rather than clean install which the rest
of us do.
It looks like the plugin attempts to resolve and open an installed JAR file
for dependencies, rather than - in the case of a reactor build that this was,
read from the target/classes directory of the artifact.
I don't know if Maven provides support for automating this at all, but the
failure could be a bit more graceful, and inform the user that they need to
install dependent artifacts.
{code}
[ERROR] Failed to execute goal org.apache.felix:maven-scr-plugin:1.0.8:scr
(generate-scr-scrdescriptor) on project smx3.schema.provider: Unable to get
manifest from artifact smx3:smx3.api:jar:4.1.35-SNAPSHOT:compile: error in
opening zip file - [Help 1]
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
goal org.apache.felix:maven-scr-plugin:1.0.8:scr (generate-scr-scrdescriptor)
on project smx3.schema.provider: Unable to get manifest from artifact
smx3:smx3.api:jar:4.1.35-SNAPSHOT:compile
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:217)
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:537)
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.MojoExecutionException: Unable to get
manifest from artifact smx3:smx3.api:jar:4.1.35-SNAPSHOT:compile
at
org.apache.felix.scrplugin.tags.JavaClassDescriptorManager.init(JavaClassDescriptorManager.java:171)
at
org.apache.felix.scrplugin.SCRDescriptorMojo.execute(SCRDescriptorMojo.java:106)
at
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209)
... 19 more
Caused by: java.util.zip.ZipException: error in opening zip file
at java.util.zip.ZipFile.open(Native Method)
at java.util.zip.ZipFile.init(ZipFile.java:127)
at java.util.jar.JarFile.init(JarFile.java:135)
at java.util.jar.JarFile.init(JarFile.java:99)
at
org.apache.felix.scrplugin.tags.JavaClassDescriptorManager.getManifest(JavaClassDescriptorManager.java:287)
at
org.apache.felix.scrplugin.tags.JavaClassDescriptorManager.init(JavaClassDescriptorManager.java:151)
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (FELIX-3223) SCR Plugin requires installed .jar files for metadata extraction
[
https://issues.apache.org/jira/browse/FELIX-3223?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13150278#comment-13150278
]
Carsten Ziegeler commented on FELIX-3223:
-
This looks like FELIX-2878 though that should be fixed in 1.7.2 of the plugin;
we fixed another multi module problem FELIX-3113, so could you please try
latest from trunk to see if your problem is already fixed?
SCR Plugin requires installed .jar files for metadata extraction
Key: FELIX-3223
URL: https://issues.apache.org/jira/browse/FELIX-3223
Project: Felix
Issue Type: Bug
Components: Maven SCR Plugin
Affects Versions: maven-scr-plugin-1.7.2
Reporter: Mark Derricutt
Priority: Minor
I was just diagnosing a strange build problem for a coworker and traced it
down to a combination of us doing a release yesterday, and the developer in
question running mvn clean test rather than clean install which the rest
of us do.
It looks like the plugin attempts to resolve and open an installed JAR file
for dependencies, rather than - in the case of a reactor build that this was,
read from the target/classes directory of the artifact.
I don't know if Maven provides support for automating this at all, but the
failure could be a bit more graceful, and inform the user that they need to
install dependent artifacts.
{code}
[ERROR] Failed to execute goal org.apache.felix:maven-scr-plugin:1.0.8:scr
(generate-scr-scrdescriptor) on project smx3.schema.provider: Unable to get
manifest from artifact smx3:smx3.api:jar:4.1.35-SNAPSHOT:compile: error in
opening zip file - [Help 1]
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
goal org.apache.felix:maven-scr-plugin:1.0.8:scr (generate-scr-scrdescriptor)
on project smx3.schema.provider: Unable to get manifest from artifact
smx3:smx3.api:jar:4.1.35-SNAPSHOT:compile
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:217)
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:537)
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.MojoExecutionException: Unable to get
manifest from artifact smx3:smx3.api:jar:4.1.35-SNAPSHOT:compile
at
org.apache.felix.scrplugin.tags.JavaClassDescriptorManager.init(JavaClassDescriptorManager.java:171)
at
org.apache.felix.scrplugin.SCRDescriptorMojo.execute(SCRDescriptorMojo.java:106)
at
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209)
... 19 more
Caused by: java.util.zip.ZipException: error in opening zip file
at java.util.zip.ZipFile.open(Native Method)
at java.util.zip.ZipFile.init(ZipFile.java:127)
at java.util.jar.JarFile.init(JarFile.java:135)
at java.util.jar.JarFile.init(JarFile.java:99)
at
org.apache.felix.scrplugin.tags.JavaClassDescriptorManager.getManifest(JavaClassDescriptorManager.java:287)
at
org.apache.felix.scrplugin.tags.JavaClassDescriptorManager.init(JavaClassDescriptorManager.java:151)
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your
Re: [VOTE] Drop support for javadoc annotations in SCR Tooling for future versions
Thanks everyone for voting - so we have at least 5 +1 votes, three of them binding. I'll go ahead and create appropriate issues etc. Regards Carsten 2011/11/14 Felix Meschberger fmesc...@adobe.com: +1 Regards Felix Am 12.11.2011 um 02:38 schrieb Carsten Ziegeler: Hi, as we have recently discussed the future of the scr tooling, it became obvious in that thread that we should drop the error prone approach of javadoc tags from scr tooling. In future versions we will support our own annotations, the annotation provider support we have right now, and the new annotations from the upcoming spec. But all of them are real Java annotations. With this change we will bump the version of the plugin to 2.0 - of course we will continue to support the 1.x line (if required) So please cast your votes. Thanks Carsten -- Carsten Ziegeler cziege...@apache.org -- Carsten Ziegeler cziege...@apache.org
[jira] [Created] (FELIX-3224) Drop javadoc annotation support
Drop javadoc annotation support --- Key: FELIX-3224 URL: https://issues.apache.org/jira/browse/FELIX-3224 Project: Felix Issue Type: Task Components: Maven SCR Plugin Affects Versions: maven-scr-plugin-1.7.4, scr ant task 1.1.4, scr generator 1.1.4 Reporter: Carsten Ziegeler Assignee: Carsten Ziegeler Fix For: maven-scr-plugin-1.7.6, scr ant task 1.1.6, scr generator 1.1.6 As recently discussed and voted in the dev mailing list, we will drop the javadoc annotation support to streamline the functionality, make the implementation easier and support new features -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [VOTE] Release new SCR Tools
+1 Sorry for the delay Regards Felix Am 10.11.2011 um 18:20 schrieb Carsten Ziegeler: Hi, this vote is about our SCR Tools - Apache Felix SCR Maven Plugin 1.7.4 - Apache Felix SCR Ant Task 1.1.4 - Apache Felix SCR Generator 1.1.4 This release is intended to be the last release before the discussed restructing of the plugin (if we have to fix serious things, we'll of course cut new releases) We solved several important issues in this release: https://issues.apache.org/jira/browse/FELIX/fixforversion/12317147 https://issues.apache.org/jira/browse/FELIX/fixforversion/12317148 https://issues.apache.org/jira/browse/FELIX/fixforversion/12317149 Staging repository: https://repository.apache.org/content/repositories/orgapachefelix-170/ You can use this UNIX script to download the release and verify the signatures: http://svn.apache.org/repos/asf/felix/trunk/check_staged_release.sh Usage: sh check_staged_release.sh 170 /tmp/felix-staging Please vote to approve this release: [ ] +1 Approve the release [ ] -1 Veto the release (please provide specific comments) This vote will be open for 72 hours. Regards -- Carsten Ziegeler cziege...@apache.org
[VOTE RESULT] Drop support for javadoc annotations in SCR Tooling for future versions
This time with changed subject -- Forwarded message -- From: Carsten Ziegeler cziege...@apache.org Date: 2011/11/15 Subject: Re: [VOTE] Drop support for javadoc annotations in SCR Tooling for future versions To: dev@felix.apache.org Thanks everyone for voting - so we have at least 5 +1 votes, three of them binding. I'll go ahead and create appropriate issues etc. Regards Carsten 2011/11/14 Felix Meschberger fmesc...@adobe.com: +1 Regards Felix Am 12.11.2011 um 02:38 schrieb Carsten Ziegeler: Hi, as we have recently discussed the future of the scr tooling, it became obvious in that thread that we should drop the error prone approach of javadoc tags from scr tooling. In future versions we will support our own annotations, the annotation provider support we have right now, and the new annotations from the upcoming spec. But all of them are real Java annotations. With this change we will bump the version of the plugin to 2.0 - of course we will continue to support the 1.x line (if required) So please cast your votes. Thanks Carsten -- Carsten Ziegeler cziege...@apache.org -- Carsten Ziegeler cziege...@apache.org -- Carsten Ziegeler cziege...@apache.org
[jira] [Created] (FELIX-3225) Support flexible use of HttpContext implementations for Servlet whiteboard pattern
Support flexible use of HttpContext implementations for Servlet whiteboard pattern -- Key: FELIX-3225 URL: https://issues.apache.org/jira/browse/FELIX-3225 Project: Felix Issue Type: New Feature Components: HTTP Service Affects Versions: http-2.2.0 Reporter: Felix Meschberger The servlet registration whiteboard pattern is great. But it lacks functionality to use a custom HttpContext implementation. This is particularly annoying in situations where a custom implementation is required e.g. for authentication purposes. The idea is: * HttpContext services are registered with an identification property, e.g. felix.context.id * Servlet services are registered with the same identification property, where the whiteboard support will merge the two * If a Servlet service is registered for which not HttpContext is available, the servlet is not registered with the HttpService (yet). * When an HttpContext is registered any registered servlet services are checked for whether they refer to the newly registered HttpContext * Likewise on HttpContext unregistration, related services must be unregistered from the HttpContext again -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (FELIX-1963) Add possibility to share ServletContext between bundles
[ https://issues.apache.org/jira/browse/FELIX-1963?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13150292#comment-13150292 ] Felix Meschberger commented on FELIX-1963: -- I think for HttpContext equality the Object identity is good enough (and probably even correct). Add possibility to share ServletContext between bundles --- Key: FELIX-1963 URL: https://issues.apache.org/jira/browse/FELIX-1963 Project: Felix Issue Type: New Feature Components: HTTP Service Affects Versions: http-2.0.4 Reporter: Sten Roger Sandvik Assignee: Sten Roger Sandvik Check out the possibility to share ServletContext between bundles. If ServletContextManager is global instead of local to each bundle then it chould be done. If you want to share ServletContext each HttpContext must implement equals method that ensures equality. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
