[jira] [Updated] (FELIX-3973) Exclusion from {local-packages} doesn't work anymore
[
https://issues.apache.org/jira/browse/FELIX-3973?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tuomas Kiviaho updated FELIX-3973:
--
Attachment: FELIX-3973.diff
Reattaching once more. I reverted unnecessary modifications from the code while
fixing one bug that I accidentally introduced. Sorry about the inconvenient GIT
diff format.
Key of this patch is to retrieve properties without waking up BND macros at
this point.
I also use BNDs PackageRef instead of direct string manipulation to ensure that
delimiter is compatible with BND macros and list notation (, instead of ;).
I'll repatch the FELIX-3381 also so that macros can be allied to sources and
resources
PS. I don't recollect reading a documentation about automatic split package
which I think is great considering that plugin takes care of classpath already.
For some reason it was only applied to the last package which I don't believe
being intentional.
> Exclusion from {local-packages} doesn't work anymore
>
>
> Key: FELIX-3973
> URL: https://issues.apache.org/jira/browse/FELIX-3973
> Project: Felix
> Issue Type: Bug
> Components: Maven Bundle Plugin
> Environment: bnd 2.0.0.x
>Reporter: Tuomas Kiviaho
> Attachments: FELIX-3973.diff
>
>
> I've been using Export-Package: !org.apache.jsp.*, {local-packages} to
> exclude jspc compilers output, but with BND 2.0.0 this stopped working
> completely (although until now I was getting a bunch of warnings).
> BND currently gives a second chance to non matching packages. This feature
> will rended !org.apache.jsp.* useless since {local-packages} is expanded to
> clause that contains org.apache.jsp prefixed packages.
> A fix would be to pre-filter the {local-packages} against
> Export/Private-Package clauses
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (FELIX-3973) Exclusion from {local-packages} doesn't work anymore
[
https://issues.apache.org/jira/browse/FELIX-3973?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tuomas Kiviaho updated FELIX-3973:
--
Attachment: (was: FELIX-3973.diff)
> Exclusion from {local-packages} doesn't work anymore
>
>
> Key: FELIX-3973
> URL: https://issues.apache.org/jira/browse/FELIX-3973
> Project: Felix
> Issue Type: Bug
> Components: Maven Bundle Plugin
> Environment: bnd 2.0.0.x
>Reporter: Tuomas Kiviaho
>
> I've been using Export-Package: !org.apache.jsp.*, {local-packages} to
> exclude jspc compilers output, but with BND 2.0.0 this stopped working
> completely (although until now I was getting a bunch of warnings).
> BND currently gives a second chance to non matching packages. This feature
> will rended !org.apache.jsp.* useless since {local-packages} is expanded to
> clause that contains org.apache.jsp prefixed packages.
> A fix would be to pre-filter the {local-packages} against
> Export/Private-Package clauses
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (FELIX-3996) Upgrade to latest bnd version
[ https://issues.apache.org/jira/browse/FELIX-3996?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13613079#comment-13613079 ] Marcel Offermans commented on FELIX-3996: - Pierre, could you take a look. I think it makes sense to upgrade our code to support the latest bnd version. > Upgrade to latest bnd version > - > > Key: FELIX-3996 > URL: https://issues.apache.org/jira/browse/FELIX-3996 > Project: Felix > Issue Type: Improvement > Components: Dependency Manager >Reporter: Paul Bakker > > In the Dependency Mannager Annotations plugin for bnd a old version is used. > This is a problem for usage in for example BndTools, where the latest bnd > version is used. > The most important change is that aQute.lib.osgi is renamed to > aQute.bnd.service. Unfortunately there are also some real API changes. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (FELIX-3996) Upgrade to latest bnd version
Paul Bakker created FELIX-3996: -- Summary: Upgrade to latest bnd version Key: FELIX-3996 URL: https://issues.apache.org/jira/browse/FELIX-3996 Project: Felix Issue Type: Improvement Components: Dependency Manager Reporter: Paul Bakker In the Dependency Mannager Annotations plugin for bnd a old version is used. This is a problem for usage in for example BndTools, where the latest bnd version is used. The most important change is that aQute.lib.osgi is renamed to aQute.bnd.service. Unfortunately there are also some real API changes. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (FELIX-2733) The maven-ipojo-plugin should support JAR and WAR as packaging type
[ https://issues.apache.org/jira/browse/FELIX-2733?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13612676#comment-13612676 ] Guillaume Sauthier commented on FELIX-2733: --- Sure, please open a new issue Please also provides your full stack trace > The maven-ipojo-plugin should support JAR and WAR as packaging type > --- > > Key: FELIX-2733 > URL: https://issues.apache.org/jira/browse/FELIX-2733 > Project: Felix > Issue Type: New Feature > Components: iPOJO >Reporter: Clement Escoffier >Assignee: Clement Escoffier > Fix For: iPOJO-1.8.0 > > > The maven-ipojo-plugin does not yet support project using JAR and WAR as > packaging (only BUNDLE) is supported. Those types should be supported. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (FELIX-2733) The maven-ipojo-plugin should support JAR and WAR as packaging type
[ https://issues.apache.org/jira/browse/FELIX-2733?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13612625#comment-13612625 ] Giulio Ruggeri commented on FELIX-2733: --- In versions next to 1.8.0 the build fails with: Path 'META-INF/MANIFEST.MF' do not start with 'WEB-INF/classes/' Should an issue be created? > The maven-ipojo-plugin should support JAR and WAR as packaging type > --- > > Key: FELIX-2733 > URL: https://issues.apache.org/jira/browse/FELIX-2733 > Project: Felix > Issue Type: New Feature > Components: iPOJO >Reporter: Clement Escoffier >Assignee: Clement Escoffier > Fix For: iPOJO-1.8.0 > > > The maven-ipojo-plugin does not yet support project using JAR and WAR as > packaging (only BUNDLE) is supported. Those types should be supported. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (FELIX-3995) Missing options in Bind annotation
German Vega created FELIX-3995: -- Summary: Missing options in Bind annotation Key: FELIX-3995 URL: https://issues.apache.org/jira/browse/FELIX-3995 Project: Felix Issue Type: Bug Components: iPOJO Affects Versions: ipojo-annotations-1.8.4, iPOJO-1.8.0 Reporter: German Vega Priority: Minor The Bind annotation doesn't accept all the options available in the Require annotation. In particular, it is not possible to specify @Bind(proxy=false) to request that service object be injected directly. Workaround: define a dummy field, and use a @Require with the same Id as the @Bind to set the missing options. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (FELIX-3973) Exclusion from {local-packages} doesn't work anymore
[
https://issues.apache.org/jira/browse/FELIX-3973?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13612589#comment-13612589
]
Stuart McCulloch commented on FELIX-3973:
-
Thanks for the updated patch, I'll try to get round to applying it over the
Easter break.
> Exclusion from {local-packages} doesn't work anymore
>
>
> Key: FELIX-3973
> URL: https://issues.apache.org/jira/browse/FELIX-3973
> Project: Felix
> Issue Type: Bug
> Components: Maven Bundle Plugin
> Environment: bnd 2.0.0.x
>Reporter: Tuomas Kiviaho
> Attachments: FELIX-3973.diff
>
>
> I've been using Export-Package: !org.apache.jsp.*, {local-packages} to
> exclude jspc compilers output, but with BND 2.0.0 this stopped working
> completely (although until now I was getting a bunch of warnings).
> BND currently gives a second chance to non matching packages. This feature
> will rended !org.apache.jsp.* useless since {local-packages} is expanded to
> clause that contains org.apache.jsp prefixed packages.
> A fix would be to pre-filter the {local-packages} against
> Export/Private-Package clauses
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [jira] [Created] (FELIX-3990) iPOJO 1.8.6 manipulator removes custom annotations
Hi,
In iPOJO 1.8.6, we are injecting proxy by default. You can disable the
proxy-fixation by setting the ipojo.proxy system property to 'disabled'
(http://felix.apache.org/site/service-requirement-handler.html#ServiceRequirementHandler-Proxies).
Regards,
Clement
On 23 mars 2013, at 15:35, "YANG, BongYeol (JIRA)" wrote:
> YANG, BongYeol created FELIX-3990:
> -
>
> Summary: iPOJO 1.8.6 manipulator removes custom annotations
> Key: FELIX-3990
> URL: https://issues.apache.org/jira/browse/FELIX-3990
> Project: Felix
> Issue Type: Bug
> Components: iPOJO
>Affects Versions: ipojo-runtime-1.8.6, ipojo-manipulator-1.8.6
> Environment: JDK 1.7.0_17, felix framework 4.2.0
>Reporter: YANG, BongYeol
>
>
> I want to migrate from iPOJO 1.4.0 to 1.8.6 and tested my bundles.
>
> In ipojo 1.4.0, custom (user-defined) runtime annotations are moved to ipojo
> generated proxy class, but ipojo 1.8.6 does not care about it.
>
> For example:
>
> # TestMethod.java
> package org.araqne.test;
>
> import java.lang.annotation.ElementType;
> import java.lang.annotation.Retention;
> import java.lang.annotation.RetentionPolicy;
> import java.lang.annotation.Target;
>
> @Retention(RetentionPolicy.RUNTIME)
> @Target(ElementType.METHOD)
> public @interface TestMethod {
> String name();
> }
>
> # TestService.java
>
> package org.araqne.test;
>
> public interface TestService {
>
> void stop();
> void start();
>
> }
>
> # TestServiceImpl.java
>
> package org.araqne.test.impl;
>
> import org.apache.felix.ipojo.annotations.Component;
> import org.apache.felix.ipojo.annotations.Provides;
> import org.araqne.test.TestMethod;
> import org.araqne.test.TestService;
>
> @Component(name = "test-service")
> @Provides
> public class TestServiceImpl implements TestService {
>
> public TestServiceImpl(String guid) {
> }
>
> @Override
> @TestMethod(name = "start")
> public void start() {
>
> }
>
> @Override
> @TestMethod(name = "stop")
> public void stop() {
> }
>
> }
>
> # OtherServiceImpl.java
>
> package org.araqne.test.impl;
>
> import java.lang.reflect.Method;
>
> import org.apache.felix.ipojo.annotations.Component;
> import org.apache.felix.ipojo.annotations.Requires;
> import org.apache.felix.ipojo.annotations.Validate;
> import org.araqne.test.TestMethod;
> import org.araqne.test.TestService;
>
> @Component(name = "test-base-service")
> public class OtherServiceImpl {
>
> @Requires
> private TestService testService;
>
> public OtherServiceImpl(String guid) {
> }
>
> @Validate
> public void s() {
> Method[] methods = testService.getClass().getDeclaredMethods();
> for (Method m : methods) {
> TestMethod rpcMethod =
> m.getAnnotation(TestMethod.class);
> if (rpcMethod == null) {
> System.out.println(String.format("annotation
> not found: method [%s], class=[%s]", m.getName(),
> testService.getClass().getName()));
> } else {
> System.out.println(String.format("annotation
> found: method [%s], class=[%s]", m.getName(),
> testService.getClass().getName()));
> }
> }
> }
> }
>
>
> In iPOJO 1.4.0, bundle print out like this:
>
> annotation found: method [start], class=[org.araqne.test.impl.TestServiceImpl]
> annotation found: method [stop], class=[org.araqne.test.impl.TestServiceImpl]
> annotation not found: method [__start],
> class=[org.araqne.test.impl.TestServiceImpl]
> annotation not found: method [__stop],
> class=[org.araqne.test.impl.TestServiceImpl]
> annotation not found: method [_setInstanceManager],
> class=[org.araqne.test.impl.TestServiceImpl]
> annotation not found: method [getComponentInstance],
> class=[org.araqne.test.impl.TestServiceImpl]
>
> In iPOJO 1.8.6, bundle print out like this:
>
> annotation not found: method [start],
> class=[org.araqne.test.TestService$$Proxy]
> annotation not found: method [stop],
> class=[org.araqne.test.TestService$$Proxy]
>
> Are there any other workaround for this? or just bug?
>
>
> --
> This message is automatically generated by JIRA.
> If you think it was sent incorrectly, please contact your JIRA administrators
> For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (FELIX-3992) Classloader access outside of a privileged block
[
https://issues.apache.org/jira/browse/FELIX-3992?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karl Pauls updated FELIX-3992:
--
Fix Version/s: framework-4.4.0
> Classloader access outside of a privileged block
>
>
> Key: FELIX-3992
> URL: https://issues.apache.org/jira/browse/FELIX-3992
> Project: Felix
> Issue Type: Bug
> Components: Framework
>Affects Versions: framework-4.2.0
>Reporter: Romain Dubois
>Assignee: Karl Pauls
>Priority: Minor
> Labels: security
> Fix For: framework-4.4.0
>
>
> In method
> org.apache.felix.framework.ServiceRegistrationImpl.isClassAccessible(Class),
> there is an access to the registered ServiceFactory classloader (lines
> 163:169 in v4.2.1):
> if ((m_factory != null)
> && (m_factory.getClass().getClassLoader() instanceof
> BundleReference)
> && !((BundleReference) m_factory.getClass()
> .getClassLoader()).getBundle().equals(m_bundle))
> {
> return true;
> }
> If a bundle registers a service through a ServiceFactory and if there is an
> active ServiceListener matching this service, those lines are executed inside
> the registering bundle's protection domain.
> If this bundle does not have the (java.util.RuntimePermission
> 'getClassloader') privilege, the getClassLoader invocation throws a
> SecurityException and the listener is always called because the exception is
> catched at line 526 (isAssignableTo) of the same class.
> The comment inside the catch block does not seem to justify this case.
> I think a simple privileged block around the bundle comparison is harmless
> and should fix this. It could be something like :
> if (m_factory != null)
> {
> Bundle bundle = null;
> if (System.getSecurityManager() == null)
> {
> if ((m_factory.getClass().getClassLoader() instanceof
> BundleReference) {
> bundle = ((BundleReference)
> m_factory.getClass().getClassLoader()).getBundle();
> }
> }
> else
> {
> bundle = AccessController.doPrivileged(new
> PrivilegedAction() {
> public Bundle run() {
> if ((m_factory.getClass().getClassLoader() instanceof
> BundleReference) {
> return ((BundleReference)
> m_factory.getClass().getClassLoader()).getBundle();
> }
> return null;
> }
> });
> }
>
> if (bundle != null && bundle.equals(m_bundle)) {
> return true;
> }
> }
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (FELIX-3992) Classloader access outside of a privileged block
[
https://issues.apache.org/jira/browse/FELIX-3992?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karl Pauls reassigned FELIX-3992:
-
Assignee: Karl Pauls
Looks like something like your patch would make sense. Thanks, I'll try to get
to it soon...
> Classloader access outside of a privileged block
>
>
> Key: FELIX-3992
> URL: https://issues.apache.org/jira/browse/FELIX-3992
> Project: Felix
> Issue Type: Bug
> Components: Framework
>Affects Versions: framework-4.2.0
>Reporter: Romain Dubois
>Assignee: Karl Pauls
>Priority: Minor
> Labels: security
>
> In method
> org.apache.felix.framework.ServiceRegistrationImpl.isClassAccessible(Class),
> there is an access to the registered ServiceFactory classloader (lines
> 163:169 in v4.2.1):
> if ((m_factory != null)
> && (m_factory.getClass().getClassLoader() instanceof
> BundleReference)
> && !((BundleReference) m_factory.getClass()
> .getClassLoader()).getBundle().equals(m_bundle))
> {
> return true;
> }
> If a bundle registers a service through a ServiceFactory and if there is an
> active ServiceListener matching this service, those lines are executed inside
> the registering bundle's protection domain.
> If this bundle does not have the (java.util.RuntimePermission
> 'getClassloader') privilege, the getClassLoader invocation throws a
> SecurityException and the listener is always called because the exception is
> catched at line 526 (isAssignableTo) of the same class.
> The comment inside the catch block does not seem to justify this case.
> I think a simple privileged block around the bundle comparison is harmless
> and should fix this. It could be something like :
> if (m_factory != null)
> {
> Bundle bundle = null;
> if (System.getSecurityManager() == null)
> {
> if ((m_factory.getClass().getClassLoader() instanceof
> BundleReference) {
> bundle = ((BundleReference)
> m_factory.getClass().getClassLoader()).getBundle();
> }
> }
> else
> {
> bundle = AccessController.doPrivileged(new
> PrivilegedAction() {
> public Bundle run() {
> if ((m_factory.getClass().getClassLoader() instanceof
> BundleReference) {
> return ((BundleReference)
> m_factory.getClass().getClassLoader()).getBundle();
> }
> return null;
> }
> });
> }
>
> if (bundle != null && bundle.equals(m_bundle)) {
> return true;
> }
> }
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (FELIX-3994) Optional merging of duplicate manifest headers
Tuomas Kiviaho created FELIX-3994:
-
Summary: Optional merging of duplicate manifest headers
Key: FELIX-3994
URL: https://issues.apache.org/jira/browse/FELIX-3994
Project: Felix
Issue Type: Improvement
Components: Maven Bundle Plugin
Reporter: Tuomas Kiviaho
Priority: Minor
Bundle plugin seems to always overwrite exported manifest. There are currently
several other ways of merging manifest headers together but none of them can
merge duplicated headers back to one or omit unwanted/uninteresting headers
altogether.
[Archiver|http://maven.apache.org/shared/maven-archiver/examples/manifestFile.html]
can already be used pass headers to BND process but what I'm after is to only
have an impact what is written out to the manifest location at the end and not
tamper with the produced artifact itself.
The idea is to be able to print out project artifact's manifest for Eclipse PDE
and later on selectively overlay it with test artifact's manifest so that PDE
sees simultaneously information from both artifacts excluding test-only headers
such as {{Fragment-Host}} and those starting with {{Bundle-}}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (FELIX-3973) Exclusion from {local-packages} doesn't work anymore
[
https://issues.apache.org/jira/browse/FELIX-3973?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tuomas Kiviaho updated FELIX-3973:
--
Attachment: FELIX-3973.diff
Here's the patch again in such form that doesn't use BND internals via
reflection but instead BND postpones macro evaluation after {local-packages}
has been replaced. Now I can use
${filterout;{local-packages};org\\.apache\\.jsp.*} macro to solve my problem
> Exclusion from {local-packages} doesn't work anymore
>
>
> Key: FELIX-3973
> URL: https://issues.apache.org/jira/browse/FELIX-3973
> Project: Felix
> Issue Type: Bug
> Components: Maven Bundle Plugin
> Environment: bnd 2.0.0.x
>Reporter: Tuomas Kiviaho
> Attachments: FELIX-3973.diff
>
>
> I've been using Export-Package: !org.apache.jsp.*, {local-packages} to
> exclude jspc compilers output, but with BND 2.0.0 this stopped working
> completely (although until now I was getting a bunch of warnings).
> BND currently gives a second chance to non matching packages. This feature
> will rended !org.apache.jsp.* useless since {local-packages} is expanded to
> clause that contains org.apache.jsp prefixed packages.
> A fix would be to pre-filter the {local-packages} against
> Export/Private-Package clauses
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
