[jira] [Resolved] (FELIX-2917) Constructor of SecurityExceptino() which is incompatible to 1.4 is used
[
https://issues.apache.org/jira/browse/FELIX-2917?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Richard S. Hall resolved FELIX-2917.
Resolution: Fixed
Assignee: Richard S. Hall
I have committed a patch to resolve this issue. I fixed the issue you pointed
out, plus a couple more. Please close this issue if you are satisfied. Thanks.
> Constructor of SecurityExceptino() which is incompatible to 1.4 is used
> -
>
> Key: FELIX-2917
> URL: https://issues.apache.org/jira/browse/FELIX-2917
> Project: Felix
> Issue Type: Bug
> Components: Framework
>Affects Versions: framework-3.2.0
> Environment: J2SE-1.4
>Reporter: Ikuo YAMASAKI
>Assignee: Richard S. Hall
> Fix For: framework-4.0.0
>
>
> The constructor of SecurityException with Throwable must not be used.
> For example, Felix.java has
>
> throw new SecurityException(ex);
> throw new SecurityException("Unable to install custom SecurityManager: " +
> security, t);
>
> Other classes might use those constructors.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (FELIX-2918) Missing package in Import-Package causes NoClassDefFoundError at runtime
Missing package in Import-Package causes NoClassDefFoundError at runtime
Key: FELIX-2918
URL: https://issues.apache.org/jira/browse/FELIX-2918
Project: Felix
Issue Type: Bug
Components: Maven Bundle Plugin
Affects Versions: maven-bundle-plugin-2.3.4
Environment: OSX Snow Leopard, Maven3, Java6, Guice/Peaberry
Reporter: Yuri
Priority: Minor
I have an issue where I get a NoClassDefFoundError while starting my
multi-project bundles. This exception is thrown while Peaberry is creating an
proxy for a multiple() import. Aside from the Peaberry specifics, the
multiple() import is loading the service interface, it's implementation and
dependencies until it hits this error. After taking a closer look and comparing
the bundle giving me grief to another similar (wrt dependencies) one that was
working fine, I noticed two differences in the Manifest: a missing package in
the Import-Package and the same package missing from the uses directive in the
Export-Package. Basically, maven-bundle-plugin was not "seeing" the missing
package when auto generating the manifest.
The scenario, in more detail, is as follows.
Bundle A (the one with the missing package in the manifest) imports packages
from bundle E:
BUNDLE A (package a):
interface a.AS extends e.ES{}
interface a.AW extends e.EW{}
BUNDLE E (packages e and b):
interface e.EW, W extends e.EW> extends b.AD, b.AH{}
interface b.AD{} // THIS IS THE NoClassDefFoundError CLASS
interface b.AH{}
I then ran my mvn3 build with maven-bundle-plugin v2.3.4 and attached a
debugger to it. I then stopped in the aQute.lib.osgi.Analyzer line
1684 (t.addAll(clazz.getReferred());) for class a.AS. I was expecting
to see packages a (for a.AS and the two generic parameters a.AS and
a.AW, which happens to be in the same package), e (for e.ES interface,
and the two generic parameters a.ES and e.EW, which happens to be in
the same package) and b (b.AD and b.AH). However, I didn't see the
package b there.
So it seems that BND is not analyzing dependencies of dependencies and the
reason my other module worked was because there was an unrelated, direct
dependency to package b somewhere else, forcing the package to be added to the
Manifest.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (FELIX-2899) [GSoc 2011]Bndtools based OSGi bundles maker project
[ https://issues.apache.org/jira/browse/FELIX-2899?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13020319#comment-13020319 ] Přemek Brada commented on FELIX-2899: - I find the proposal certainly a much needed and useful thing. We are just in the middle of manually decomposing a small-ish monolithic app into a bundelized one, so I would be much interested in comparing the results with possible outcome of this project. That said, creating a truly generic (not just strongly connected components but also patterns in code, hidden dependencies e.g. via resources cutting through many layers, etc.) and scalable (from a dozen to hundreds-thousands of potential bundles) solution is a great challenge. In fact, I was thinking proposing this as a research topic for 1-2 phd students :-) So, fingers crossed Tiger. > [GSoc 2011]Bndtools based OSGi bundles maker project > > > Key: FELIX-2899 > URL: https://issues.apache.org/jira/browse/FELIX-2899 > Project: Felix > Issue Type: Task > Environment: Eclipse platform, this project add a new tool for Felix > users to improve OSGi bundles development process in Eclipse environment >Reporter: Tiger Gui >Assignee: Peter Kriens > Labels: gsoc, gsoc2011, mentor, mentoring > Original Estimate: 1680h > Remaining Estimate: 1680h > > OSGi(Open Service Gateway Initiative) is a worldwide consortium of technology > innovators that advances a proven and > mature process to create open specifications that enable the modular assembly > of software built with Java technology. > It is becoming more and more popular in Java Desktop or Web application > developmenent especially when we are working on > some huge project, as it is growing more and more complex, OSGi can help > us.Developing with OSGi technology means > developing bundles: the OSGi components. Bundles are modules. > OSGi is a good thing, but coin has two sides. Usually the development process > with OSGi will be more troublesome. Suppose > that we are in this scenario. We use a interface Greeting to say hello to our > customers , but we should say different words to different kind of customers > , so we have two implemention class for Greeting interface, we > name them BasicGreeting and GreatGreeting. > If we develop this application in a traditional OSGi way, we should create at > lease 3 projects (or bundles) in our IDE (Eclipse for example). > one service define bundle, two service supply bundles, it's a long list in > our workspace.Isn't it troublesome? If we just > write these codes in a Jave project and some tool can help us to split this > project in OSGi way and export 3 jar files, isn't it cool? > So i want to build OSGi split tool for Java project, it can also be used to > split and refactor our exist huge project in OSGi way. This > is very important. In some huge application, how to manage components in a > convinent way is an art, so far, OSGi is the best solution > that we can find. But the refactor and split for exist huge project is > complex and painful. This tool will help us to do this job. > We want to build a bnd(tools) based OSGi bunlles maker project, it will help > us analyse java application and split the whole project into several OSGi > bundles. > Suppose that we write code in good style, define service in interface, > implement the service by the implemention class of the interface > and put similar service in a package. This tool can analyse source code, > supply vari-size grained split and refactor suggestions, show > the analyse result in a GUI view and we can change split solution manually, > then it will split the project into several projects. > Function lists: > 1. configuration > Define default split/refactor solution for this tool. For example,assign > default interface split particle or package split partical. Or may be > we can just split the project by function module define, similar with > M(Module)-V(View)-C(control) develop pattern. Or in some other ways. > 2. analyse module > It can analyse project source code, make clear of class dependency > relationship and give us a graphical view analyse result, this is default > split solution, and we can change it as we like. > The trick is to find strongly coupled packages. These are packages that are > in a cycle. A -> B -> C -> A. Normally I find that these packages should be > in the same bundle. In bnd (the current next branch) I already can calculate > those strongly connected packages. In general, I find that many, especially > larger, bundles consist of a number of subsystems. > These subsystems have dependencies on each other, however, by definition > there is no cycle between these subsystem dependencies (otherwise they would > be strongly connected an
[jira] [Updated] (FELIX-2917) Constructor of SecurityExceptino() which is incompatible to 1.4 is used
[
https://issues.apache.org/jira/browse/FELIX-2917?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Richard S. Hall updated FELIX-2917:
---
Fix Version/s: framework-4.0.0
> Constructor of SecurityExceptino() which is incompatible to 1.4 is used
> -
>
> Key: FELIX-2917
> URL: https://issues.apache.org/jira/browse/FELIX-2917
> Project: Felix
> Issue Type: Bug
> Components: Framework
>Affects Versions: framework-3.2.0
> Environment: J2SE-1.4
>Reporter: Ikuo YAMASAKI
> Fix For: framework-4.0.0
>
>
> The constructor of SecurityException with Throwable must not be used.
> For example, Felix.java has
>
> throw new SecurityException(ex);
> throw new SecurityException("Unable to install custom SecurityManager: " +
> security, t);
>
> Other classes might use those constructors.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Bndtools based OSGi bundles maker project need feedback
Hi Tiger, On Fri, Apr 15, 2011 at 4:21 AM, Tiger Gui wrote: > Hi Bert, > > Thank you for your remind, in fact, i am really interested in OSGi > technology and just want to do *some thing* for this community, may be > it is not really a good idea to ask you guys register as mentor to > support our project... Don't get me wrong - your project certainly deserves the support that this community is willing to express. My point was that people signing up as GSoC mentors just to support it, with no intention of actually mentoring, is not the right thing to do. Supporting comments in FELIX-2899 or on blogs, twitter etc. can certainly be relayed by the actual mentors to the GSoC team to show community support. -Bertrand > > 2011/4/15 Bertrand Delacretaz : >> On Thu, Apr 14, 2011 at 4:31 PM, David Bosschaert >> wrote: >>> Sure, but I guess there are other responsibilities attached to being a >>> mentor, than just leaving a supportive comment. >> >> Yes - I'm not a GSoC admin this year but I was in the past, and AFAIK >> signing up as a mentor indeed means you're intending to mentor a >> project. Signing up just to support a project is pushing it a bit, >> IMO. >> >> -Bertrand
[jira] [Created] (FELIX-2917) Constructor of SecurityExceptino() which is incompatible to 1.4 is used
Constructor of SecurityExceptino() which is incompatible to 1.4 is used
-
Key: FELIX-2917
URL: https://issues.apache.org/jira/browse/FELIX-2917
Project: Felix
Issue Type: Bug
Components: Framework
Affects Versions: framework-3.2.0
Environment: J2SE-1.4
Reporter: Ikuo YAMASAKI
The constructor of SecurityException with Throwable must not be used.
For example, Felix.java has
throw new SecurityException(ex);
throw new SecurityException("Unable to install custom SecurityManager: " +
security, t);
Other classes might use those constructors.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (FELIX-2916) Don't include Embed-Dependency in manifest
Don't include Embed-Dependency in manifest -- Key: FELIX-2916 URL: https://issues.apache.org/jira/browse/FELIX-2916 Project: Felix Issue Type: Improvement Components: Maven Bundle Plugin Affects Versions: maven-bundle-plugin-2.3.4 Reporter: Carsten Ziegeler Priority: Minor The Embed-Dependency directive is an instruction for the plugin (bnd) - it should not be included in the final manifest -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
