[equinox-dev] What to do with 3.3.1 candidate bugs and milestones
Each major release the same thing happens. We start fixing bugs in HEAD for the next major release but find a few fixes that we would like to also release into a maintenance release. Then we have to decide what to do with the status of the original bug report which was used to release the fix into HEAD. I have seen this handled in two ways. 1) Leave the bug open and mark the milestone to the next maintenance release milestone (e.g. 3.3.1) and make a comment in the bug report stating the fix was released to HEAD. If/When the fix gets approved and released for the maintenance release then the bug is marked as fixed; otherwise we make a note that the fix is not going to be included in the maintenance release and the milestone is updated to major milestone the fix was included and marked as fixed. 2) Resolve the bug report and mark the milestone appropriate for the next major release (e.g. 3.4 M1) and open a separate bug with a proper milestone for the maintenance release (e.g. 3.3.1). For the past couple of releases the Equinox team has used option #1 but this has a few drawbacks. First of all, it gives inaccurate search results when querying bugzilla for the list of bug fixes for the next release milestone because code was released into the milestone but the bug is left open and marked for a maintenance stream. Also I find it generally confusing that the bug status does not reflect the fixed state of the bug until we can get approval and actually release the bug into the maintenance stream. The second approach has its advantages because it accurately reflects the state of the bug for a particular stream and makes for more accurate search results for fixed bugs and milestones. But there is a risk that the open bug against the maintenance stream will not get approved for release and then we would have to resolve the bug as wontfix (or something). I'm not sure that is really a problem because at least the reason why the fix is not in the maintenance stream is recorded. Another disadvantage is that the bugs will look like duplicates which could cause confusion. What are other committers preferences? How is this handled on other teams? Is there a standard Eclipse way to handle this? Tom ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
Re: [equinox-dev] What to do with 3.3.1 candidate bugs and milestones
We will bring this topic up for discussion at next week's architecture call. Personally I want to use option #2 but if we are the only team doing this then it will look pretty inconsistent with the rest of the eclipse teams. Tom BJ Hargrave/Austin/[EMAIL PROTECTED] Sent by: [EMAIL PROTECTED] 07/13/2007 10:49 AM Please respond to Equinox development mailing list equinox-dev@eclipse.org To Equinox development mailing list equinox-dev@eclipse.org cc Subject Re: [equinox-dev] What to do with 3.3.1 candidate bugs and milestones So far, the respondents want #2. Tom was just observing that #1 has been the case in the past. Given that (a) bugzilla does not support multiple releases within a single bug (see CMVC tracks) and (b) bugzilla does have a quick and easy Clone This Bug link, #2 is the most practical and obvious choice. -- BJ Hargrave Senior Technical Staff Member, IBM OSGi Fellow and CTO of the OSGi Alliance [EMAIL PROTECTED] office: +1 386 848 1781 mobile: +1 386 848 3788 Jeff McAffer [EMAIL PROTECTED] Sent by: [EMAIL PROTECTED] 2007-07-13 11:18 Please respond to Equinox development mailing list equinox-dev@eclipse.org To Equinox development mailing list equinox-dev@eclipse.org cc Subject Re: [equinox-dev] What to do with 3.3.1 candidate bugs and milestones ok. in theory I support #2 but if everyone else is doing #1 then there may be more merit in consistency. there is some logic that says things released in 3.n.x will alos be in 3.n+1.x but that is not always true. The issue may come down to overhead in managing the bugs/process. Jeff Thomas Watson [EMAIL PROTECTED] Sent by: [EMAIL PROTECTED] 07/13/2007 08:59 AM Please respond to Equinox development mailing list equinox-dev@eclipse.org To Equinox development mailing list equinox-dev@eclipse.org cc Subject Re: [equinox-dev] What to do with 3.3.1 candidate bugs and milestones No we have not done #2 in the past releases. Searching through 3.2.x bugs for Platform and Equinox you will notice that most (all?) teams seem to have done #1 for the 3.2.x releases. https://bugs.eclipse.org/bugs/buglist.cgi?query_format=advancedshort_desc_type=allwordssubstrshort_desc=classification=Eclipseproduct=Equinoxproduct=Platformtarget_milestone=3.2.1target_milestone=3.2.2long_desc_type=allwordssubstrlong_desc=bug_file_loc_type=allwordssubstrbug_file_loc=status_whiteboard_type=allwordssubstrstatus_whiteboard=keywords_type=allwordskeywords=emailtype1=substringemail1=emailtype2=substringemail2=bugidtype=includebug_id=votes=chfieldfrom=chfieldto=Nowchfieldvalue=cmdtype=doitorder=Reuse+same+sort+as+last+timefield0-0-0=nooptype0-0-0=noopvalue0-0-0= Tom Jeff McAffer [EMAIL PROTECTED] Sent by: [EMAIL PROTECTED] 07/12/2007 09:19 PM Please respond to Equinox development mailing list equinox-dev@eclipse.org To Equinox development mailing list equinox-dev@eclipse.org cc Subject Re: [equinox-dev] What to do with 3.3.1 candidate bugs and milestones i thought we were all already doing #2... Jeff Thomas Watson [EMAIL PROTECTED] Sent by: [EMAIL PROTECTED] 07/11/2007 01:42 PM Please respond to Equinox development mailing list equinox-dev@eclipse.org To equinox-dev@eclipse.org cc Subject [equinox-dev] What to do with 3.3.1 candidate bugs and milestones Each major release the same thing happens. We start fixing bugs in HEAD for the next major release but find a few fixes that we would like to also release into a maintenance release. Then we have to decide what to do with the status of the original bug report which was used to release the fix into HEAD. I have seen this handled in two ways. 1) Leave the bug open and mark the milestone to the next maintenance release milestone (e.g. 3.3.1) and make a comment in the bug report stating the fix was released to HEAD. If/When the fix gets approved and released for the maintenance release then the bug is marked as fixed; otherwise we make a note that the fix is not going to be included in the maintenance release and the milestone is updated to major milestone the fix was included and marked as fixed. 2) Resolve the bug report and mark the milestone appropriate for the next major release (e.g. 3.4 M1) and open a separate bug with a proper milestone for the maintenance release (e.g. 3.3.1). For the past couple of releases the Equinox team has used option #1 but this has a few drawbacks. First of all, it gives inaccurate search results when querying bugzilla for the list of bug fixes for the next release milestone because code was released into the milestone but the bug is left open and marked for a maintenance stream. Also I find it generally confusing that the bug status does not reflect the fixed state of the bug until we can get approval and actually release the bug into the maintenance stream. The second approach has its advantages because it accurately reflects the state of the bug
Re: [equinox-dev] No available bundle exports package 'javax.swing.event'
Where do you see the error? In the java code file where you import the javax.swing.event package or in your bundle MANIFEST.MF file where you use Import-Package: javax.swing.event? This package should be exported by the system bundle (org.eclipse.osgi in equinox) when running on a J2SE-1.2 or higher VM. Tom David Leangen [EMAIL PROTECTED] Sent by: [EMAIL PROTECTED] 07/24/2007 04:36 AM Please respond to [EMAIL PROTECTED]; Please respond to Equinox development mailing list equinox-dev@eclipse.org To Equinox development mailing list equinox-dev@eclipse.org cc Subject [equinox-dev] No available bundle exports package 'javax.swing.event' Hello! I am getting a bunch of errors in Eclipse like the one above. I thought that javax packages were supposed to be automatically imported by the framework... Is there some setting I need to set in Eclipse? Thanks! David ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
[equinox-dev] Equinox projects tagged for 3.4 M1 build
The map file has been updated for the following Bug changes: + Bug 181881. Unfortunate Console CommandProvider Help Formatting (FIXED) + Bug 189794. sytem bundle fragments cannot supply manifest localization (FIXED) + Bug 193802. BaseStorage adds invalid URL to a URLClassLoader (FIXED) + Bug 198405. NPE if EventManager is created with null thread name (FIXED) + Bug 198459. [Registry] Enhancement request to make hasContributor() API (FIXED) + Bug 198535. HostSpecification#getHosts() returns null (FIXED) The following projects have changed: org.eclipse.equinox.launcher.motif.hpux.PA_RISC org.eclipse.equinox.launcher org.eclipse.equinox.registry org.eclipse.equinox.supplement org.eclipse.osgi.tests org.eclipse.osgi Tom ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
[equinox-dev] Equinox projects tagged for 3.4 I-build
The map file has been updated for the following Bug changes: + Bug 184283. Remove ServiceFactory code for StartLevel implementation (FIXED) + Bug 185952. EnviromentInfo defaults ws to motif on solaris and linux (FIXED) + Bug 187203. Define value for osgi.os for Symbian OS (Epoc32) (FIXED) + Bug 187237. Request for defining value for osgi.ws property for Symbian S60 platform + Bug 188089. [osgi] can't launch an osgi bundle if the path of its plugin project contains the caracter @ (ASSIGNED) + Bug 195073. [Preferences] Some preferences are not crash safe (FIXED) + Bug 199606. getprop console command does not sort output (FIXED) + Bug 199634. IndexOutOfBoundsException during bundle resolution (ASSIGNED) + Bug 200202. Malformed javadoc tags (FIXED) + Bug 200211. Malformed javadoc tags (FIXED) + Bug 200296. [NLS] NLS.bind crashed with NegativeArraySizeException when given empty format string and short parameter (FIXED) The following projects have changed: org.eclipse.equinox.launcher org.eclipse.equinox.registry org.eclipse.equinox.preferences org.eclipse.equinox.supplement org.eclipse.equinox.common org.eclipse.equinox.app org.eclipse.osgi.tests org.eclipse.osgi Tom ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
Re: [equinox-dev] Equinox coding conventions
I updated the following equinox projects to have the latest Equinox code convention settings. I also updated each project to format java files when saving. You may notice additional changes when saving java files and creating patches. In this case the code was probably not correctly formatted. org.eclipse.equinox.app org.eclipse.equinox.common org.eclipse.equinox.device org.eclipse.equinox.event org.eclipse.equinox.http org.eclipse.equinox.http.jetty org.eclipse.equinox.http.registry org.eclipse.equinox.http.servlet org.eclipse.equinox.http.servletbridge org.eclipse.equinox.jsp.jasper org.eclipse.equinox.jsp.jasper.registry org.eclipse.equinox.launcher org.eclipse.equinox.log org.eclipse.equinox.metatype org.eclipse.equinox.preferences org.eclipse.equinox.registry org.eclipse.equinox.servletbridge org.eclipse.equinox.supplement org.eclipse.equinox.useradmin org.eclipse.osgi Because of bug https://bugs.eclipse.org/bugs/show_bug.cgi?id=200207 the org.eclipse.osgi project cannot set the Malformed Javadoc compiler settings to Error. All other projects do have this set to Error. Tom John Arthorne [EMAIL PROTECTED] Sent by: [EMAIL PROTECTED] 08/20/2007 04:35 PM Please respond to Equinox development mailing list equinox-dev@eclipse.org To equinox-dev@eclipse.org cc Subject [equinox-dev] Equinox coding conventions As more and more people are contributing to Equinox (Thanks!) we thought it would make sense to point out the Equinox coding conventions: http://www.eclipse.org/equinox/documents/coding.php In some ways these sort of guidelines can show up as restricting one's freedom of artistic code formatting or variable naming expression. In practice however, having a common set of coding practices is one of the ingredients of our success. We have a large and growing body of committers in Equinox, and a much larger community looking in and trying to understand what we write. Having common and consistent conventions makes our code easier to read and work with for everyone. In particular, check out the section around formatter and compiler settings. These we should setup in each project so that everyone is seeing the same errors and formatting the same way. We're also going to experiment with enabling automatic formatting and code cleanup on save, so we can just forget about these issues and let the tools do the work. ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
Re: [equinox-dev] getResources : bundleresource
I'm a bit confused by the usecase. Are these real bundles or just inner jars which you use as inner libraries? If they are real bundles then why don't you install them as real bundles instead? The bundleresource protocol uses the port as an index into the list of resources of a given name (e.g plugin.xml). In your case it sounds like you have more resources named META-INF/MANIFEST.MF in your bundle than you do plugin.xml so the two lists and indexes do not match up. For example, imagine you have a bundle which has jars A, B, C, D which all have META-INF/MANIFEST.MF resources but only C and D have plugin.xml. A call to classloader.getResources(plugin.xml) gives you something like this: bundleresource://26:0/plugin.xml (C) bundleresource://26:1/plugin.xml (D) A call to classloader.getResources(META-INF/MANIFEST.MF) gives you something like this: bundleresource://26:0/META-INF/MANIFEST.MF (base bundle) bundleresource://26:1/META-INF/MANIFEST.MF (A) bundleresource://26:2/META-INF/MANIFEST.MF (B) bundleresource://26:3/META-INF/MANIFEST.MF (C) bundleresource://26:4/META-INF/MANIFEST.MF (D) As you can see the resource indexes will not match for the two different resources (plugin.xml and METE-INF/MANIFEST.MF) from C and D. Tom Erik Bengtson [EMAIL PROTECTED] Sent by: [EMAIL PROTECTED] 08/27/2007 01:58 PM Please respond to Equinox development mailing list equinox-dev@eclipse.org To Equinox development mailing list equinox-dev@eclipse.org cc Subject [equinox-dev] getResources : bundleresource Hi, I have some bundles (B,C,D) that are not deployed as osgi bundles, but as libraries within a bundle (A). In bundle A, I have a custom internal registry of the plugin.xml from files (B,C,D). 1) find and load all plugin.xml files using classloader.getResources() I get an enumeration of: bundleresource://26:3/plugin.xml (D) bundleresource://26:2/plugin.xml (C) bundleresource://26:1/plugin.xml (B) So far so good, but now I have to load the corresponding /META-INF/MANIFEST.MF files from each bundle (B,C,D). 2) do: -- new URL(bundleresource://26:3/META-INF/MANIFEST.MF); My problem is that it returns the MANIFEST.MF from bundle (C), instead of bundle (D). What am I doing wrong? Background: My project JPOX, a JDO/JPA implementation, is OSGi compatible and uses Eclipse Extension/Extension Points for declarative services. I have an internal registry of bundles/extension/extension points when running outside an osgi container. Regards, Erik Bengtson http://jpox.org ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
[equinox-dev] Equinox projects tagged for 3.4 I-build
Along with the following bug fixes I updated every equinox project in the SDK with the new code formatter settings for Equinox. That is why so many projects have changed this build. The map file has been updated for the following Bug changes: + Bug 127963. ContextFinder caches classes from Class#forName (FIXED) + Bug 177007. Classes in boot classloader are not properly loaded for some Eclipse plugins (FIXED) + Bug 198423. [launcher] failed to load x86_64 library on win32.x86 when self-hosting (FIXED) + Bug 198447. FileLocator needs a helper method to get the location of a bundle (FIXED) + Bug 198525. HashCode problem in org.eclipse.osgi.framework.internal.core.BundleResourceHandler (FIXED) + Bug 198823. [launcher] eclipse.ini is not portable (NEW) + Bug 200231. [app] Support creating app container without app launcher (ASSIGNED) + Bug 200296. [NLS] NLS.bind crashed with NegativeArraySizeException when given empty format string and short parameter (FIXED) + Bug 200582. [Launcher] Shared Memory Leak (FIXED) + Bug 200596. Eclipse launcher (erroneously) fails to find its companion shared library when using relative directory with a forward slash and launch directory is in your PATH (on Windows) (NEW) + Bug 200604. [Launcher] Allow relative path for --launcher.library (FIXED) + Bug 200950. [launcher] Bad memory reference after failed shared memory (FIXED) + Bug 201255. NullPointerException occurs if a fragment attaches to an uninstalled bundle (FIXED) The following projects have changed: org.eclipse.equinox.launcher.carbon.macosx org.eclipse.equinox.app org.eclipse.equinox.http.jetty org.eclipse.osgi.tests org.eclipse.equinox.http org.eclipse.osgi org.eclipse.equinox.metatype org.eclipse.equinox.launcher org.eclipse.equinox.log org.eclipse.equinox.launcher.gtk.solaris.sparc org.eclipse.equinox.jsp.jasper.registry org.eclipse.equinox.registry org.eclipse.equinox.servletbridge org.eclipse.equinox.launcher.motif.aix.ppc org.eclipse.equinox.device org.eclipse.equinox.launcher.win32.win32.x86_64 org.eclipse.equinox.http.servletbridge org.eclipse.equinox.launcher.gtk.linux.ppc org.eclipse.equinox.http.registry org.eclipse.equinox.launcher.motif.linux.x86 org.eclipse.equinox.launcher.gtk.linux.x86_64 org.eclipse.equinox.http.servlet org.eclipse.equinox.launcher.wpf.win32.x86 org.eclipse.equinox.executable org.eclipse.equinox.launcher.win32.win32.x86 org.eclipse.equinox.preferences org.eclipse.equinox.useradmin org.eclipse.equinox.supplement org.eclipse.equinox.common org.eclipse.equinox.launcher.gtk.linux.x86 org.eclipse.equinox.event org.eclipse.equinox.jsp.jasper Tom ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
Re: [equinox-dev] restricted access setttings
I misread Jeff's earlier post. The template is fine. I agree with Jeff, forbidden access should always be an error, it will never work at runtime. Thanks for the tip on deprecated methods John. This means we have to javadoc to internal classes to add the @deprecated tag? Not really a big deal I guess. Tom Jeff McAffer [EMAIL PROTECTED] ibm.com To Sent by: Equinox development mailing list equinox-dev-bounc equinox-dev@eclipse.org [EMAIL PROTECTED] cc Subject 08/30/2007 06:56 Re: [equinox-dev] restricted access AMsetttings Please respond to Equinox development mailing list [EMAIL PROTECTED] pse.org yes, the test project did not have the pref set to error. Note however setting this particular one to warning is goofy since the resultant code does not have a hope of running. it really is an error. We are talking about Forbidden access not Discouraged. Jeff John Arthorne/Ottawa/[EMAIL PROTECTED] Sent by: [EMAIL PROTECTED]To Equinox development mailing list equinox-dev@eclipse.org 08/29/2007 06:33 PMcc Subject Please respond to Re: [equinox-dev] restricted Equinox development mailing list access setttings equinox-dev@eclipse.org I think Jeff was saying that the template has that preference set to error, not that the template has an error. This deviation from the template for the test project was intentional though, since tests sometimes need to access internals. The tests also intentionally deviate from the conventions for the unexternalized strings setting (ignore instead of warning). Perhaps we need a different convention for tests/tools that aren't part of shipping code. Tom, for the deprecation warning, you can avoid that by marking the implementation method as deprecated as well (a deprecated method that implements a deprecated interface method is not flagged as a warning). Thomas Watson [EMAIL PROTECTED] Sent by: [EMAIL PROTECTED]To Equinox development mailing list equinox-dev@eclipse.org 08/29/2007 09:30 AMcc Subject Please respond to Re: [equinox-dev] restricted Equinox development mailing list access setttings equinox-dev@eclipse.org
Re: [equinox-dev] Simple SWT App launched with OSGi Launcher hangs on Mac OS X
-XstartOnFirstThread -Dorg.eclipse.swt.internal.carbon.smallFonts Am I missing a command line option to make this work? Or is there something special I need to do in the SWT code to make this work? I also tried the RCP example that is packaged with Eclipse to see if all SWT applications have this problem but that ran just fine, and the UI did not hang. I checked bugzilla and found launcher bugs dealing with swing, swt, launcher interactions but none with just the launcher and SWT. Attached is com.eclipse.swt.sample.src.zip which contains the project com.eclipse.swt.sample and the binary bundle com.eclipse.swt.sample_1.0.0.jar[attachment org.eclipse.swt.sample.src.zip deleted by Thomas Watson/Austin/IBM] Thanks, Patrick ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev inline: graycol.gifinline: pic27008.gifinline: ecblank.gif___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
Re: [equinox-dev] [vote] graduating the new jar processor bundle
+1 There is currently provisional API in the org.eclipse.osgi which is currently used by update to check the certificate trust and to verify the content of signed bundles. I assume the jar processor API can use an IProcessStep to which uses the API from the framework to perform this type of check? Or would verifying the signed content continue to be a separate step as it is today in update? Tom Andrew Niefer [EMAIL PROTECTED] omTo Sent by: Equinox development mailing list equinox-dev-bounc equinox-dev@eclipse.org [EMAIL PROTECTED] cc Subject 09/10/2007 10:29 Re: [equinox-dev] [vote] graduating AMthe new jar processor bundle Please respond to Equinox development mailing list [EMAIL PROTECTED] pse.org +1 As for doing it now, is there any benefit to waiting? There is some amount of work that will depend on this change. Both update.core and pde.build will need to be updated after this change. As well, the p2.jarprocessor is considered HEAD for bug fixes (there is at least https://bugs.eclipse.org/bugs/show_bug.cgi?id=190064 that should be fixed). and clients would not get these fixes until it is promoted. While there is no particular rush on these changes, it is good to get anything that might block them out of the way. -Andrew Pascal Rapicault/Ottawa/[EMAIL PROTECTED] Sent by: To [EMAIL PROTECTED] Equinox development mailing list equinox-dev@eclipse.org cc 09/10/2007 09:54 AM Subject Re: [equinox-dev] [vote] Please respond to graduating the new jar Equinox development mailing list processor bundle equinox-dev@eclipse.org In the long, there is no discussion about doing this change. However the benefits of doing it right away are not clear to me. +0 PaScaL From: Jeff McAffer/Ottawa/[EMAIL PROTECTED] To: equinox-dev@eclipse.org Date: 09/09/2007 11:07 PM Subject:[equinox-dev] [vote] graduating the new jar processor bundle As you may know, we used to have the JARProcessor embedded in the bowels of Update manager. Turns out that there are several uses for the processor (pack200 support, signing, verifying, ...) and having this function as a stand-alone bundle would be a good thing(tm). So in the p2 work we did just that and created org.eclipse.equinox.p2.jarprocessor. Bug https://bugs.eclipse.org/bugs/show_bug.cgi?id=198564 talks about updating update to use the new processor. Of course, the current JarProcessor bundle is in the Equinox Incubator. To date I think we have avoided cases where we build the mainstream SDK based on content from an incubator. We have two choices, we can wait to move Update over or we can graduate the current JARProcessor bundle. Here I popose the latter since the
[equinox-dev] Equinox projects tagged for 3.4 I-build
The map file has been updated for the following Bug changes: + Bug 165964. Process Bundle-NativeCode at resolve time (FIXED) + Bug 200068. AdapterManager fails to find correct IAdapterFactory if the IAdapterFactory implementation class loader cannot load the class returned by the getAdapterList() method (FIXED) + Bug 201489. [osgi R5] multiple versions of a fragment should not attach to the same host (FIXED) The following projects have changed: org.eclipse.osgi.tests org.eclipse.osgi org.eclipse.equinox.common org.eclipse.equinox.supplement Tom ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
Re: [equinox-dev] Compilation warnings in latest nightly build
Thanks for the info and the lead-in Olivier. As you may have noticed the new bundles contributed by Prosyst have been added to the equinox incubator build and can now be downloaded from the equinox download page. I updated the projects with the following: - added .qualifier to the Bundle-Version - added appropriate Bundle-RequiredExecutionEnvironment headers and updated compiler settings to use the proper execution environment JRE to build. - updated the settings the equinox code formatter and to format and organize imports on Java file saves - formatted and organized imports of all the code according to the new settings - fixed the compiler warnings from the build Over the next few milestones we will be reviewing the code and getting it into shape for graduation out of the incubator. Any help from the community in testing and reviewing the code is appreciated. Please use the bundles from the equinox download page and open any bugs for issues you may find. Thanks. Tom Olivier Thomann Olivier_Thomann@ ca.ibm.comTo Sent by: equinox-dev@eclipse.org equinox-dev-bounc cc [EMAIL PROTECTED] Subject [equinox-dev] Compilation warnings 09/11/2007 09:16 in latest nightly build AM Please respond to Equinox development mailing list [EMAIL PROTECTED] pse.org Hi, Several warnings were found in last nightly build. Here is a list of concerned bundles: - org.eclipse.equinox.ds - org.eclipse.equinox.io - org.eclipse.equinox.ip - org.eclipse.equinox.util - org.eclipse.equinox.wireadmin Please review the warnings from the nightly build results. These warnings are trivial to address. If you wonder why it is useful to provide a serialVersionUID field, I would suggest the reading of the tutorial about serialization. The projects' settings can also be modified to prevent this kind of warnings in future builds. If you don't know how to do that, let me know. Olivier ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev inline: graycol.gifinline: pic19172.gifinline: ecblank.gif___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
[equinox-dev] Equinox-Bundles component is getting crowded
The Equinox project continues to grow with new components and new contributes being added. Thanks everyone!! As new contributions are graduated into Equinox proper we need to place them under one of the existing components. Currently we have the Framework and Bundles components for Equinox proper in bugzilla/cvs. A large majority of the new contributions will fall into the Bundles component. For example, we have a few work areas in the equinox incubator which are very active (e.g. p2, security etc). Once this work graduates it will likely to be placed into the generic Bundles component. This will make an already crowded component even more crowded. Should we consider creating a more diverse set of components for the work which is graduated into Equinox? I think the p2 and security work will deserve their own component when they graduate. Thoughts? Tom ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
Re: [equinox-dev] Equinox-Bundles component is getting crowded
For the security stuff I was referring to the security-specific bundles like login (JAAS integration etc.) You are right there is a lot of cross-cutting concerns with the other security related work that will not really fit into any one component. Tom John Arthorne [EMAIL PROTECTED] .ibm.com To Sent by: Equinox development mailing list equinox-dev-bounc equinox-dev@eclipse.org [EMAIL PROTECTED] cc Subject 09/12/2007 11:21 Re: [equinox-dev] Equinox-Bundles AMcomponent is getting crowded Please respond to Equinox development mailing list [EMAIL PROTECTED] pse.org Creating a new component for p2 definitely makes sense to me. I don't know much about the security work, but that may be difficult to partition into its own component because it's an inherently cross-cutting concern. If there end up being a number of security-specific bundles, it may make sense. Generally speaking, I think more components is a good thing. It's a great way to bring in new committers who may not be able to make the large commitment needed to contribute across a large part of Equinox. John Thomas Watson [EMAIL PROTECTED] Sent by: To [EMAIL PROTECTED] equinox-dev@eclipse.org cc 09/12/2007 11:42 AM Subject [equinox-dev] Equinox-Bundles component is getting crowded Please respond to Equinox development mailing list equinox-dev@eclipse.org The Equinox project continues to grow with new components and new contributes being added. Thanks everyone!! As new contributions are graduated into Equinox proper we need to place them under one of the existing components. Currently we have the Framework and Bundles components for Equinox proper in bugzilla/cvs. A large majority of the new contributions will fall into the Bundles component. For example, we have a few work areas in the equinox incubator which are very active (e.g. p2, security etc). Once this work graduates it will likely to be placed into the generic Bundles component. This will make an already crowded component even more crowded. Should we consider creating a more diverse set of components for the work which is graduated into Equinox? I think the p2 and security work will deserve their own component when they graduate. Thoughts? Tom ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev inline: graycol.gifinline: pic01850.gifinline: ecblank.gif___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
Re: [equinox-dev] Equinox-Bundles component is getting crowded
There are two extreme positions to take. Lump a large number of loosely related deliverables under one component or create a separate component for each and every deliverable. I'm not sure I favor the latter extreme. Currently the Equinox download page allows you to download each bundle individually so each bundle is a separate downloadable item. Creating a separate component for each and every bundle in Equinox may prove to be too much overhead. It is my understanding that in Eclipse typically every bugzilla component has its own set of commit rights in CVS. If we have a very high number of components then we will be holding a very large number of committer elections to get all the committers the access they need :-) I think we a balance and create components as we see fit to split up the different work areas in Equinox instead of creating a component for every bundle. Tom BJ Hargrave/Austin/I [EMAIL PROTECTED] To Sent by: Equinox development mailing list equinox-dev-bounc equinox-dev@eclipse.org [EMAIL PROTECTED] cc Subject 09/12/2007 12:30 Re: [equinox-dev] Equinox-Bundles PMcomponent is getting crowded Please respond to Equinox development mailing list [EMAIL PROTECTED] pse.org It would probably be best if each separately downloadable item had its own component against which people could file bugs. -- BJ Hargrave Senior Technical Staff Member, IBM OSGi Fellow and CTO of the OSGi Alliance [EMAIL PROTECTED] office: +1 386 848 1781 mobile: +1 386 848 3788 From: Thomas Watson/Austin/[EMAIL PROTECTED] To: Equinox development mailing list equinox-dev@eclipse.org Date: 2007-09-12 12:34 Subject: Re: [equinox-dev] Equinox-Bundles component is getting crowded For the security stuff I was referring to the security-specific bundles like login (JAAS integration etc.) You are right there is a lot of cross-cutting concerns with the other security related work that will not really fit into any one component. Tom John Arthorne ---09/12/2007 11:25:42 AM---Creating a new component for p2 definitely makes sense to me. I don't know much about the security work, but that may be diffi John Arthorne [EMAIL PROTECTED] Sent by: [EMAIL PROTECTED] 09/12/2007 11:21 AM Please respond to Equinox development mailing list equinox-dev@eclipse.org To Equinox development mailing list equinox-dev@eclipse.org cc Subject Re: [equinox-dev] Equinox-Bundles component is getting crowded Creating a new component for p2 definitely makes sense to me. I don't know much about the security work, but that may be difficult to partition into its own component because it's an inherently cross-cutting concern. If there end up being a number of security-specific bundles, it may make sense. Generally speaking, I think more components is a good thing. It's a great way to bring in new committers who may not be able to make the large commitment needed to contribute across a large part of Equinox. John Thomas Watson [EMAIL PROTECTED] Sent by: [EMAIL PROTECTED] 09/12/2007 11:42 AM Please respond to Equinox development mailing list equinox-dev@eclipse.org To equinox-dev@eclipse.org cc Subject [equinox-dev] Equinox-Bundles component is getting crowded The Equinox project continues to grow with new components and new contributes being added. Thanks everyone!! As new contributions are graduated into Equinox proper we need to place them under one of the existing components. Currently we have the Framework and Bundles components for Equinox proper in bugzilla/cvs. A large majority of the new contributions will fall into the Bundles component. For example, we have a few work areas in the equinox incubator which are very active (e.g. p2, security etc). Once this work graduates it will likely to be placed
[equinox-dev] Equinox projects tagged for 3.4 I-build
In preparation for M2 build on Monday I have tagged the equinox projects early. If additional fixes are releases please make sure they are tagged appropriately for the M2 warm-up build. The map file has been updated for the following Bug changes: + Bug 96034. Need an API to determine if another location is locked (FIXED) + Bug 188089. [osgi] can't launch an osgi bundle if the path of its plugin project contains the caracter @ (FIXED) + Bug 201425. [osgi R4.1] Fragments should be able to export duplicate packages (FIXED) + Bug 202282. Support a proposed extension:=ext (FIXED) + Bug 203135. buddy classloading fails if the boot classpath contains the same class as a buddy (FIXED) The following projects have changed: org.eclipse.osgi.tests org.eclipse.osgi org.eclipse.equinox.supplement Tom ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
[equinox-dev] [security] Merged org.eclipse.osgi v20070914 tag from HEAD into security incubator
I merged the org.eclipse.osgi v20070914 tag from the Equinox 3.4 (HEAD) stream into the security incubator. There were some fixes from the HEAD stream which are important to the security work. In particular https://bugs.eclipse.org/bugs/show_bug.cgi?id=202282 is needed to be able to provide JCA security provider implementations contributed from bundles. Matt, Eric and others on the security incubator team, please let me know if you find any issues with the merge. I created the following tags and branches in the security incubator equinox-proper-dev branch - intended to contain the unmodified code from equinox proper stream (3.4 HEAD) v20070914 - tag on the equinox-proper-dev branch used after initial check of the v20070914 code v20070914-premerge - tag used before merging in the changes from the equinox-proper-dev branch to the security HEAD stream v20070914-postmerge - tag used after merging in the changes from the equinox-proper-dev branch to the security HEAD stream Tom ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
[equinox-dev] Equinox Summit: Talks and topics
Equinox Summit 2007 attendees, The summit date is fast approaching, and it's time to firm up the agenda. The substance of the summit will be shaped by all attendees, so your help is needed in setting the agenda. To this end, can *all* attendees please add a quick summary of your areas of interest to the summit wiki. It can be just a few words, but if you don't let others know what you're here for, you probably won't get much out of the short time we have available. http://wiki.eclipse.org/Equinox_Summit_2007_topics#Areas_of_Interest Also, the summit will start off with some short talks on major work areas in and around Equinox over the coming year. Please consider adding a talk proposal here by Friday 9/18/2007: http://wiki.eclipse.org/Equinox_Summit_2007_topics#Lightning_Talks Tom ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
Re: [equinox-dev] Equinox Summit: Talks and topics
Sorry, I sent out the incorrect deadline date for short talk proposals. The correct deadline date is Friday 9/21/2007. Tom Thomas Watson/Austin/IBM @IBMUS To Sent by: equinox-dev@eclipse.org equinox-dev-bounc cc [EMAIL PROTECTED] Subject [equinox-dev] Equinox Summit: Talks 09/18/2007 04:20 and topics PM Please respond to Equinox development mailing list [EMAIL PROTECTED] pse.org Equinox Summit 2007 attendees, The summit date is fast approaching, and it's time to firm up the agenda. The substance of the summit will be shaped by all attendees, so your help is needed in setting the agenda. To this end, can *all* attendees please add a quick summary of your areas of interest to the summit wiki. It can be just a few words, but if you don't let others know what you're here for, you probably won't get much out of the short time we have available. http://wiki.eclipse.org/Equinox_Summit_2007_topics#Areas_of_Interest Also, the summit will start off with some short talks on major work areas in and around Equinox over the coming year. Please consider adding a talk proposal here by Friday 9/18/2007: http://wiki.eclipse.org/Equinox_Summit_2007_topics#Lightning_Talks Tom ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev inline: graycol.gifinline: pic22851.gifinline: ecblank.gif___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
[equinox-dev] Equinox projects tagged for 3.4 I-build
The map file has been updated for the following Bug changes: + Bug 203973. Bundles in cycles that should be resolved do not get resolved (ASSIGNED) + Bug 204007. [app] need automated tests for application admin (FIXED) + Bug 204027. [app] timing issues if app handle is destroyed before the application code is run (FIXED) + Bug 204381. [app] two application admin tests fail intermittently (FIXED) The following projects have changed: org.eclipse.equinox.app org.eclipse.osgi.tests org.eclipse.osgi Tom ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
Re: [equinox-dev] [p2] UI priorities for M3
There is a proposal for a new Bundle-License manifest header that will be considered for the next release of the OSGi specification. We will need to monitor this RFC #125 to ensure that it meets our needs for presentation of licenses in p2. This is not an immediate concern for p2 but we need to make sure the proposal is something we can use in the future. Tom From: Susan M Franklin/Beaverton/[EMAIL PROTECTED] To: equinox-dev@eclipse.org Date: 10/02/2007 01:57 PM Subject:[equinox-dev] [p2] UI priorities for M3 Hi, everyone. One of the goals for M3 is to try to define the conent/scope of our 3.4 deliverable. So I'm trying to balance our desire to resolve unknowns with getting current workflows more polished. I'm interested in the community's feedback on the current M3 UI plan, which currently includes - improving the install/uninstall/update workflow by providing more info (size, time, invalid states, etc.) - polling for software updates and notifying the user - improved support for browsing repos (IU categories and filtering) - more info in admin artifact repo views (You can see the expanded detail at http://wiki.eclipse.org/Equinox_p2_User_Interface#Milestone_plan). This is a rather aggressive plan but still does not address some other big UI items, most notably - UI for rollback - presentation of licenses So if you have opinions on the pressing issues and priorities in the UI, please let me know via this list, or annotating bugs you care about, etc thanks, susan___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev inline: graycol.gifinline: ecblank.gif___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
[equinox-dev] OSGi R4.2 Stream
The OSGi Alliance is busy working on the next release of the specification. The release of the next OSGi specification will be long after the Eclipse 3.4 (Ganymede) release. To achieve a stable Ganymede release we will not release new OSGi R4.2 API or implement new R4.2 functions in the Ganymede stream (HEAD). We need a place where we can continue to implement and prototype the next OSGi specification release as it is being developed. I see two options. 1) Create an area in the Equinox incubator to develop the OSGi R4.2 implementation 2) Create a branch off of the current Ganymede stream (HEAD) for OSGi R4.2 implementation I prefer using a branch instead of a separate repository project in the incubator because it will make life easier when developing streams in parallel, which we will likely need to do until the Ganymede release in June 2008. I plan to create a branch based of next weeks I-Build for the OSGi R4.2 work. Please let me know if you have any issues with this. Tom ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
Re: [equinox-dev] OSGi R4.2 Stream
At this point I do not think we intend on doing a major overhaul on the framework. I can only see us doing that if 1) it is evident that the current implementation is not fulfilling the Eclipse usecases which are important to the Eclipse community as a whole 2) The OSGi specification changes are so drastic that we need to restructure the code. In some cases the resolver may fall into category 1 but I would rather replace that with some existing technology instead of rewriting our own again (SAT solver, maybe look to the Felix resolver etc.). Tom From: Pascal Rapicault [EMAIL PROTECTED] To: Equinox development mailing list equinox-dev@eclipse.org Date: 10/12/2007 03:18 PM Subject:Re: [equinox-dev] OSGi R4.2 Stream There is no technical problems with building out of a branch or the incubator (except that we would have to run the build separately since there would be two bundles with the same BSN and therefore two map entries, etc.). In the end I was just curious about your intentions. Wrt to the actual location for the code, I think it depends on whether you want to limit your work to only spec work, or if you want to use this as a place to do bigger overhaul of the fwk. If you just want to do spec work, then a branch is fine, however for the other I would go for the incubator. Also the incubator has the nice attribute that it is easier to make people committer. PaScaL | | From: | | --| |Thomas Watson [EMAIL PROTECTED] | --| | | To:| | --| |Equinox development mailing list equinox-dev@eclipse.org | --| | | Date: | | --| |10/12/2007 04:05 PM | --| | | Subject: | | --| |Re: [equinox-dev] OSGi R4.2 Stream | --| I would like to publish a build of org.eclipse.osgi for OSGi R4.2. But that question is orthogonal to where the code lives. We can build out of the incubator or out of a branch, right? It is a good question though. I'm not sure where we would publish the build on the Equinox download site. In the end it is not critical to build it until the next release of OSGi is closer to being final. By that time hopefully we would have moved the code into the mainline stream and build it with the rest of the current release (post 3.4). Tom (Embedded image moved to file: pic18849.gif)Inactive hide details for Pascal Rapicault ---10/12/2007 02:26:20 PM---Do you have plan to publish builds of what will be develPascal Rapicault ---10/12/2007 02:26:20 PM---Do you have plan to publish builds of what will be developed? (Embedded image (Embedded image moved to file: pic21527.gif) moved to file: Pascal Rapicault [EMAIL PROTECTED] pic10871.gif) From: (Embedded image (Embedded image moved to file: pic18432.gif) moved to file: Equinox development mailing list pic17038.gif)equinox-dev@eclipse.org To: (Embedded image (Embedded image moved to file: pic31885.gif) moved to file: 10/12/2007 02:26 PM pic13205.gif) Date: (Embedded image (Embedded image moved to file: pic09675.gif) moved to file: Re: [equinox-dev] OSGi R4.2 Stream pic01580.gif) Subject: Do you have plan to publish builds of what will be developed? PaScaL | | From
[equinox-dev] Graduation of Prosyst contributed bundles
The bundles contributed by Prosyst have been in the incubator since July. The codebase Prosyst donated is already production quality and has been used in many products at Prosyst. A small number of issues have been reported against the bundles in the incubator. But these are to be expected and the committers from Prosyst have been responsive in addressing the issues. At this point I would like to ask Prosyst which of the incubator bundles would they like to graduate and support in the Equinox-Bundles component? We have the following bundles to consider: org.eclipse.equinox.util ( https://bugs.eclipse.org/bugs/show_bug.cgi?id=181731) org.eclipse.equinox.ds ( https://bugs.eclipse.org/bugs/show_bug.cgi?id=181733) org.eclipse.equinox.ip ( https://bugs.eclipse.org/bugs/show_bug.cgi?id=181734) org.eclipse.equinox.wireadmin ( https://bugs.eclipse.org/bugs/show_bug.cgi?id=181736) org.eclipse.equinox.io ( https://bugs.eclipse.org/bugs/show_bug.cgi?id=181737) The last four bundles (ds, ip, wireadmin, io) all provide implementations to OSGi specifications and do not provide public API. I am concerned about the amount of public API in the org.eclipse.equinox.util bundle (see https://bugs.eclipse.org/bugs/show_bug.cgi?id=206151). We should consider the following when making this decision: 1) Which bundles does the community need? We do not need to graduate all the bundles if we determine that the community is not interested in all of them. 2) Which bundles do we have sufficient resources to support at the graduated level. 3) How much API will be graduated. Graduated API has a long term commitment and requires a lot of review and must be positioned such that we do not break compatibility while evolving the API after graduation. Tom ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
Re: [equinox-dev] Proposal for an OSGi spec work area in the equinox incubator
The OSGi Next work area http://www.eclipse.org/equinox/incubator/osgi-next/ has been created. To begin the work on the Framework I have populated the current I-Build (v20071022) of org.eclipse.osgi into the osgi-next work area in CVS (equinox-incubator/osgi-next/org.eclipse.osgi) Tom From: Thomas Watson/Austin/[EMAIL PROTECTED] To: equinox-dev@eclipse.org Date: 10/16/2007 04:23 PM Subject:[equinox-dev] Proposal for an OSGi spec work area in the equinox incubator I would like to start a new work area in the Equinox incubator to support prototyping and investigating future OSGi specifications. The goal behind this work area is to develop an implementation of the specification as the specification is being developed. This work area will allow others to more easily join in on the investigations for future OSGi implementations. To begin with this work area would be used to implement the next release of the OSGi Framework, but other future OSGi specifications could also be contributed. This will also allow Equinox to provide reference implementations to OSGi without effecting the current Eclipse release. We would only graduate the code out of the incubator once the OSGi specification has gone public/final and we can align it with a major Eclipse release. I would like to take a vote to approve the OSGi spec work area in the equinox incubator. Tom - Forwarded by Thomas Watson/Austin/IBM on 10/16/2007 03:45 PM - From: Thomas Watson/Austin/IBM To: equinox-dev@eclipse.org Date: 10/12/2007 01:34 PM Subject:OSGi R4.2 Stream The OSGi Alliance is busy working on the next release of the specification. The release of the next OSGi specification will be long after the Eclipse 3.4 (Ganymede) release. To achieve a stable Ganymede release we will not release new OSGi R4.2 API or implement new R4.2 functions in the Ganymede stream (HEAD). We need a place where we can continue to implement and prototype the next OSGi specification release as it is being developed. I see two options. 1) Create an area in the Equinox incubator to develop the OSGi R4.2 implementation 2) Create a branch off of the current Ganymede stream (HEAD) for OSGi R4.2 implementation I prefer using a branch instead of a separate repository project in the incubator because it will make life easier when developing streams in parallel, which we will likely need to do until the Ganymede release in June 2008. I plan to create a branch based of next weeks I-Build for the OSGi R4.2 work. Please let me know if you have any issues with this. Tom ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev inline: graycol.gifinline: ecblank.gifinline: 08081209.gif___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
[equinox-dev] Equinox projects tagged for 3.4 I-build
The map file has been updated for the following Bug changes: + Bug 206649. Missing .qualifier for s390 launcher fragments (FIXED) + Bug 207087. [Launcher] Launcher needed for HP-UX IA64_32 (FIXED) + Bug 207215. Regression since 3.4M1 in performance test StatePerformanceTest#testResolution1000() (FIXED) + Bug 207360. [sec] graduate BundleDescription enable/disable concept (FIXED) + Bug 207515. AbstractBundle and BundleDescriptionImpl have incorrect getKeyHashCode impls (FIXED) The following projects have changed: org.eclipse.equinox.launcher org.eclipse.equinox.launcher.gtk.linux.s390x org.eclipse.equinox.executable org.eclipse.equinox.launcher.gtk.linux.s390 org.eclipse.equinox.supplement org.eclipse.equinox.event org.eclipse.osgi.tests org.eclipse.osgi Tom ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
[equinox-dev] Tagged org.eclipse.osgi for next 3.4 M3 build
The map file has been updated for the following Bug changes: + Bug 208313. Bundle-NativeCode header could cause ClassCastException in PDE-Build (FIXED) The following projects have changed: org.eclipse.osgi.tests org.eclipse.osgi Tom ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
Re: [equinox-dev] ConcurrentModificationException in DS implementation
Equinox has retired the old DS implementation in favor of the prosyst implementation. The old implementation never officially made it out of incubator status. Our plan is to graduate the DS implementation contributed by Prosyst in 3.4. To be clear, the new DS implementation contributed by Prosyst is now *the* Equinox DS implementation. Can someone from the Prosyst team go through the existing bug reports against the old DS implementation and confirm they cannot be reproduced on the new DS implementation. All of these bugs should be closed as worksforme if they are not reproduced on the new DS implementation. Tom From: Lukasz Bobowiec [EMAIL PROTECTED] To: equinox-dev@eclipse.org Date: 11/05/2007 04:15 AM Subject:[equinox-dev] ConcurrentModificationException in DS implementation Hello, I encountered an issue related to the lack of thread-safe in Declarative Service resolver. I found the similar bug 164574 https://bugs.eclipse.org/bugs/show_bug.cgi?id=164574 There is also a patch already provided by the bug's originator. My question is why this defect is still in NEW state and why this patch was not applied to DS implementation (I am talking about Equinox DS implementation not ProSyst). The last exposed on Equinox download site ds jar is: org.eclipse.equinox.ds_1.0.0.v20070226.jar but this patch was provided later? However it is not applied to any official Equinox version. The patch is available: https://bugs.eclipse.org/bugs/show_bug.cgi?id=181858 What is the Equinox's decision? --- Best regards, Lukasz Bobowiec Software Engineer, Common Agent Services [EMAIL PROTECTED] (+48 12) 628 9882 IBM SWG Lab, Cracow, Poland IBM Polska Sp. z o.o. oddział w Krakowie ul. Armii Krajowej 18 30 -150 Kraków NIP: 526-030-07-24 Sąd Rejonowy dla m.st. Warszawy, XIII Wydział Gospodarczy KRS KRS 012941, Kapitał zakładowy: 3.073.600 PLN ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev inline: graycol.gifinline: ecblank.gif___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
[equinox-dev] Equinox projects tagged for 3.4 I-build
The map file has been updated for the following Bug changes: + Bug 194943. Europa Crashes During Startup (ASSIGNED) + Bug 198598. multi-user installs not working in Redhat 4 (FIXED) + Bug 207599. java.io.IOException: Could not save file table (FIXED) + Bug 208202. NullPointerException in thread State Saver during shutdown of osgi (FIXED) The following projects have changed: org.eclipse.equinox.supplement org.eclipse.osgi Tom ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
Re: [equinox-dev] naming examples
I agree with John. Use org.eclipse.equinox.examples.* Tom From: John Arthorne [EMAIL PROTECTED] To: Equinox development mailing list equinox-dev@eclipse.org Date: 11/21/2007 07:51 AM Subject:Re: [equinox-dev] naming examples My vote would be for sticking with the Eclipse project naming conventions [1] and using org.eclipse.equinox.examples.*. This convention is consistently following in platform and JDT, and it would look odd if someone downloaded the examples from the welcome page and the Equinox examples didn't match. [1] - http://wiki.eclipse.org/Naming_Conventions Jeff McAffer/Ottawa/[EMAIL PROTECTED] Sent by: [EMAIL PROTECTED] To [EMAIL PROTECTED] 11/20/2007 09:26 PM se.org cc Please respond to Subject Equinox development mailing list [equinox-dev] equinox-dev@eclipse.org naming examples We have talked a few times about the need for a comprehensive set of examples in Equinox. We may be able to get some folks to work on this so it is interesting to look at the bundle/package namespace to use. The immediate choice that springs to mind is org.eclipse.equinox.examples.* This follows the precedence of org.eclipse.sdk.examples org.eclipse.jface.examples It has also been suggested that we use org.eclipse.equionox.eg.* to shorten things up. Let me know if you have other suggestions and I'll put together an email poll. Thanks Jeff___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev inline: graycol.gifinline: ecblank.gif___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
Re: [equinox-dev] Re: ContextFinder stops at first bundle class loader
I know about buddy class loading. But I want to avoid it. If the context finder would look further up the stack and not abort on the first bundle class loader it finds things would actually work without buddy class loading. I was just wondering if the context finder could be (or should not be) enhanced to support this. -Gunnar The design of ContextFinder is to be policy free. The policy comes from the OSGi delegation model + the Equinox buddy policy. We should avoid building such a policy into the ContextFinder. It is inevitable that there are scenarios where a built in policy would not work. The policy should be specified by the bundle (e.g. DynamicImport-Package, Eclipse-BuddyPolicy etc.) and not kept in a global ContextFinder TCCL. Tom.___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
Re: [equinox-dev] ContextFinder stops at first bundle class loader
[EMAIL PROTECTED] wrote on 11/26/2007 10:52:30 AM: How do buddy classloading and DynamicImport-Package compare with regards to performance ? I've had very bad experiences performance-wise with buddy classloading and a global policy... There is an existing bug about buddy classloading performance https://bugs.eclipse.org/bugs/show_bug.cgi?id=152006 This bug is about performance where there are a large number of bundles for the registered buddy policy. The global buddy policy can be expensive because we must search the global set of packages for the package where the requested class is from. We could optimize this to be faster but I really hope the global policy is rarely used. If you have a strong usecase for using the global policy and are seeing bad performance then please open a bug report so we can consider improving it. DynamicImport-Package does have a performance hit also, but it is only a one time hit when trying to establish a wire. Once the wire is established we no longer have to try and resolve the import on the next class request from the same package. This is one of the differences between dynamic import and buddy classloading. Dynamic imports are statically bound a package wire once they are established. In buddy loading a wire is not kept, the search for a buddy is done each class/resource load. Tom. ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
Re: [equinox-dev] Declarative Services with RCP Plug-in Extensions
[EMAIL PROTECTED] wrote on 11/27/2007 06:19:11 PM: Hello. I need some tips in narrowing down the cause of a problem We've been having in our RCP/OSGi application. Our project is using Declarative Services to manage several bundles of services, and Eclipse Plug-in Extensions for various RCP components. Everything seems to be running ok, but I'm having trouble with one thing: getting the OSGi framework and all of the bundles to shut down when the user closes the RCP Application window. First, a few questions: - I read articles like http://www.eclipsezone.com/articles/extensions- vs-services/ and start to worry if our use of both DS and RCP plug- ins is somehow fundamentally problematic. There is a lot of functional overlap, but do these two approaches ever conflict? Is there a standard way to get them to work together to close down when the application is done? Is it remotely possible that the org.eclipse.equinox.ds resolver's ConcurrentModificationException during the startup of an OSGi framework could have anything to do with preventing the entire OSGi framework from shutting down automatically after the RCP Applicationis closed? Which DS implementation are you using? The latest version of DS on the Equinox download page should fix the thread safety issues. The latest DS implementation is provided by Prosyst and has many improvements over our old Equinox implementation of DS. Eclipse automatically seems to understand that we want the framework to shut down when the application closes, but when we take our jars out into the real world, the framework doesn't stop. I suppose this is understandable, since we tell OSGi to start the applications and to start the bundles and services. How do we tell OSGi that they are linked, and must be shut down when the Application closes? By default the framework should be shutdown by EclipseStarter once your application has ended. This should cause all your bundles to be stopped automatically. I suspect you are having issues with non-daemon threads still being active. When shutting down we never call System.exit, we assume that all non-daemon threads will be stopped by the shutdown process. This is what Alex was describing in his response. If you use the launcher org.eclipse.equinox.launcher it does actually exit with System.exit as long as you don't use -noexit option. See the quick start guide for instructions on using the launcher. http://www.eclipse.org/equinox/documents/quickstart.php About our configuration: -- The framework is started up with the following command: java -cp . -jar org.eclipse.osgi_3.3.0.v20070530.jar -console config.ini is as follows -- eclipse.ignoreApp=false osgi.noShutdown=false osgi.bundles= \ [EMAIL PROTECTED]:start, \ [EMAIL PROTECTED], \ [EMAIL PROTECTED]:start, \ [EMAIL PROTECTED]:start, \ [EMAIL PROTECTED]:start, \ [EMAIL PROTECTED]:start, \ [EMAIL PROTECTED]:start, \ [EMAIL PROTECTED]:start, \ [EMAIL PROTECTED]:start, \ [EMAIL PROTECTED]:start, \ [EMAIL PROTECTED]:start, \ [EMAIL PROTECTED]:start, \ [EMAIL PROTECTED]:start, \ [EMAIL PROTECTED]:start, \ [EMAIL PROTECTED]:start, \ [EMAIL PROTECTED]:start, \ [EMAIL PROTECTED]:start, \ [EMAIL PROTECTED]:start, \ org.eclipse.swt.win32.win32.x86, \ [EMAIL PROTECTED]:start, \ [EMAIL PROTECTED]:start, \ [EMAIL PROTECTED]:start, \ [EMAIL PROTECTED]:start, \ [EMAIL PROTECTED]:start, \ [EMAIL PROTECTED]:start, \ [EMAIL PROTECTED]:start, \ [EMAIL PROTECTED]:start, \ [EMAIL PROTECTED]:start, \ [All of our bundles follow at run level 4] You should not have to start every bundle here. You should only have to start equinox.common, core.runtime and update.configurator and any bundles which need to be activated because they publish OSGi services (this includes DS, event, log etc.). Something like this should work: osgi.bundles= \ [EMAIL PROTECTED]:start, \ [EMAIL PROTECTED]:start, \ [EMAIL PROTECTED]:start, \ [EMAIL PROTECTED]:start, \ [EMAIL PROTECTED]:start, \ [EMAIL PROTECTED]:start, \ [All of your bundles that publish OSGi services] In this case update.configurator should ensure all your other bundles get installed before core.runtime is started. Tom ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
[equinox-dev] Equinox projects tagged for 3.4 I-Build
The map file has been updated for the following Bug changes: + Bug 44735. Unable to create platform lock file (ASSIGNED) + Bug 179619. Request for friendship: org.eclipse.core.filesystem (FIXED) + Bug 188304. Execution environment restricts access to org.w3c.dom sub packages (ASSIGNED) + Bug 207505. [registry] order in which registry events are sent vs. bundle dependencies (FIXED) + Bug 207847. Warnings in the log file when nl fragments for osgi bundles are present. (FIXED) + Bug 209344. [log] need an event adapter (FIXED) + Bug 209694. Equinox webstart launcher ignores interactive login splash handler (NEW) + Bug 210384. console is blocking in 3.3.1 (ASSIGNED) + Bug 210699. Moving AdapterFactory into the registry bundle (FIXED) + Bug 211289. osgi.services and osgi.util source bundles are broken (FIXED) + Bug 211295. equinox launcher source bundle is missing about.html (FIXED) + Bug 211823. HttpContextManager ArrayIndexOutOfBoundsException (ASSIGNED) The following projects have changed: org.eclipse.equinox.launcher.motif.hpux.ia64_32 org.eclipse.equinox.launcher org.eclipse.equinox.log org.eclipse.osgi.services org.eclipse.equinox.executable org.eclipse.osgi.util org.eclipse.equinox.registry org.eclipse.equinox.supplement org.eclipse.equinox.common org.eclipse.equinox.http.registry org.eclipse.osgi.tests org.eclipse.osgi Tom ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
Re: [equinox-dev] [prov] install / uninstall / update (was Configuration Admin bug)
[EMAIL PROTECTED] wrote on 12/07/2007 12:18:09 PM: The bundle.getLocation() does not matter, but since so many systems are used around that it is also problematic to not having meaningful. For clarification to the casual reader, simple configurator does not explicitly have two lists. The lists of things to install and to uninstall are actually derived by analysing what is in the system and what the system should look like. Now for the corner cases (in each case the bundles.txt described lists all the bundles): Example 1: In the system: Let's say that I have junit 3.8.1 and junit 4.1 installed (boths are singleton) case 1) In the bundles.txt: I have junit 5.0 - Do I update the two bundles ? Do I update the highest one or the lowest one, why? case 2) In the bundles.txt I have junit 3.8.2 - Is it an update or a donwgrade? case 3) In the bundles.txt I have junit 3.8.4 and junit 4.0 - Which one is really an update? Example 2: In the system: Let's say that I have foo 1.0.0 (it is singleton) case 1) In the bundles.txt I have foo 1.1 and foo 1.2 (these are no longer singleton) - Which bundle do I pick to be an update of the one present? Example 3: In the system: Let's say that I have bar 1.0.0 and bar 2.0.0 (both are non singleton) case 1) In the bundles.txt I have bar 1.5 (singleton). - Which one do you update? Why? We may be able to rationalize some policy for the above cases but since this is a simple configurator that is likely out of the question because it will get complicated fast ;-) So I punt on this and say if multiple versions of the same bundle are in the scenario then just do the uninstall(old) install(new) versions approach. In most cases where multiple versions are needed the bundle is not a singleton and is just a library. In this case it should not matter if you uninstall/install the bundle to be updated. In cases where the system should only have one version of the bundle installed it seems like you could use the update approach instead. The other problem with updates, is that given two systems starting from the same initial state, if they are submitted to different bundles.txt over time to finally get to the same one. Even though the resulting systems look the same it is not clear that they will actually behave the same depending on what the data file may contain. Another one in that space is, someone starting fresh and someone applying a bundles.txt over a system may not end up with the same runtime behavior (of course bundles should all be written properly, etc but you know the truth :-)) PaScaL Not sure what the answer is to this one. Bundles have bugs in them but should we throw away the update capability because some bundles cannot handle managing their persistent data correctly? I do not see how this is different from the other data bundles store in the configuration.area. Generally this type of data should be versioned so that when new versions are installed they can determine if they understand the data or not. This is also another option for the CM implementation. It could persist its data in the configuration.area. This area is not tied to the bundle ID or location. The drawback to this approach is that only one version of CM can manipulate this data. This is probably not an issue though since CM should probably be a singleton bundle anyway. This is essentially how the Eclipse preferences bundle persists its data. Tom ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
Re: [equinox-dev] classLoader.getResources(META-INF/.resource)
You also posted this on the osgi mailing list. I'm posting my answer here also for others ... but lets keep the general osgi questions on the osgi mailing list. With the current OSGi specification one way I can see doing this is to make all bundles supplying META-INF/.resources a fragment bundle of the main bundle using getResources(). This should make all resouces from the fragments available to the host as if they were part of the host. The problem with dynamic imports is you only get wired to a single exporter of the resource and you do not really have much of a choice on which one you get wired to. Although you could use some matching attributes to scope down the list of possible supplies, but this still does not help you get the resource from multiple suppliers. If you are using Equinox you could use the buddy classloading mechanism. Search Eclipse help for Eclipse-BuddyPolicy for more information. There is ongoing discussions within OSGi for how to solve these types of issues in a future version the specification, but that does not help you now :) Tom From: [EMAIL PROTECTED] To: equinox-dev@eclipse.org Date: 12/16/2007 05:42 AM Subject:[equinox-dev] classLoader.getResources(META-INF/.resource) Hi, I am little stuck with osgi while loading resources. My problem is to load all META-INF/.resource resources from all exporting bundles in osgi runtime. But classLoader.getResources(META-INF/.resource) returns empty enumeration. Bundle where this is done is a legacy library converted to Osgi plugin. Maximum I can do to legacy bundle is to change the manifest. It does many Class.forName(), So i have put dynamic import as * there that solves many class loading problem. All bundles that is having META-INF/.resource is exporting META-INF package. There is also a bundle that does not have .resource but exports META-INF for some other resource. Unfortunately my legacy bundle gets wired to this bundle when when getResources is done. Hence its returning empty enumeration. Had it been wired to one of the .resource containing bundle atleast enumeration would not been empty, though it would have returned only one. I am kinda stuck, please help me. -Rajesh ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev inline: graycol.gifinline: ecblank.gif___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
[equinox-dev] Equinox tagged for 3.4 I-Build
The map file has been updated for the following Bug changes: + Bug 211745. [sec] Graduate signedcontent API and related services (ASSIGNED) + Bug 211904. [launcher] Running from outside current directory causes contents of .ini file to be ignored (FIXED) The following projects have changed: org.eclipse.equinox.executable org.eclipse.osgi Tom ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
Re: [equinox-dev] Fw: [Bug 214801] [api tools] consider Export-Package as API
I agree that tooling is needed in order to make this somewhat feasable. On the OSGi mailing list there was a question posted about using EMF on another framework implementation. One of the issues was that EMF uses Require-Bundle on org.eclipse.core.runtime. This ends up pulling in lots of dependencies, one of which is org.eclipse.osgi. This makes it impossible to use EMF on another Framework impl. If EMF instead used Import-Package to get its packages then it is conceivable that EMF could have its dependancies resolved in another Framework impl. But using Import-Package for the eclipse packages without versions is dangerous because you do not know what you will get. Eclipse team rarely uses Import-Package, this maybe because it is a bit harder. But for now I would advise against it because it is dangerous without versions. Until versions are established EMF should *not* move to Import-Package IMO. Tom From: John Arthorne [EMAIL PROTECTED] To: Equinox development mailing list equinox-dev@eclipse.org Date: 01/11/2008 03:27 PM Subject:Re: [equinox-dev] Fw: [Bug 214801] [api tools] consider Export-Packageas API I don't think we can even contemplate this without full tooling automation. As Tom says, we struggle to keep our bundle version numbers correct as it is. We can maintain package versions manually up to a point, such as base framework packages and service packages, but any wider scope would become unmanageable. For most of the wider Eclipse team that rarely/never uses import package, there is no immediate need to version at the package level. Thomas Watson [EMAIL PROTECTED] Sent by: To [EMAIL PROTECTED]Equinox development mailing list rg equinox-dev@eclipse.org cc 01/11/2008 03:45 PM Subject Re: [equinox-dev] Fw: [Bug 214801] [api tools] consider Please respond to Export-Packageas API Equinox development mailing list equinox-dev@eclipse.org Without tooling this will be difficult. If we wanted to use the big hammer approach the we would have the API tooling (or plain old PDE) mark exports without versions as a warning/error by default or update each project settings in eclipse to make it an error. Now the question is what version would all the well established packages use? Most eclipse packages do not specify a version which means they have been using the default version of 0.0.0. If a package is being versioned for the first time what should its version be? - Start off using 1.0.0 - Use the Bundle-Version I favor using the Bundle-Version for well established packages because if we decide to add versions to the maintenance streams then we have room to downgrade the versions as appropriate. Completely new packages in a release should start off with version 1.0. I have been trying to version the exports of org.eclipse.osgi for the past few releases. It is hard to keep track of without tooling. Just look at how many times we forget to increment the bundle versions in Eclipse and that is just one version number per bundle to maintain. Now we will have to maintain each package version individually which is a much bigger task. Hopefully more advanced API tooling could detect that the API package has changed since last release and needs to be incremented. Does the new API tooling currently do something like this for Bundle-Version? Tom Inactive hide details for Jeff McAffer ---01/11/2008 02:17:11 PM---Tom raises a good point that we keep letting slide. Are we gJeff McAffer ---01 /11/2008 02:17
[equinox-dev] Equinox projects tagged for I-Build
The map file has been updated for the following Bug changes: + Bug 203999. NPE in WebStartMain.findBundle (FIXED) + Bug 209694. Equinox webstart launcher ignores interactive login splash handler (FIXED) + Bug 211904. [launcher] Running from outside current directory causes contents of .ini file to be ignored (FIXED) + Bug 212815. [launcher] resolve osgi.framework relative to osgi.install.area (FIXED) + Bug 214570. [JavaWebstart] NullpointerException at org.eclipse.equinox.launcher.Main.findMax(Main.java:871) (FIXED) + Bug 214760. Uninformative error message from AdapterFactoryProxy.loadFactory(..) (FIXED) + Bug 214929. org.eclipse.equinox.registry does not include schemas in source bundle (FIXED) The following projects have changed: org.eclipse.equinox.launcher.win32.win32.ia64 org.eclipse.equinox.launcher.wpf.win32.x86 org.eclipse.equinox.launcher org.eclipse.equinox.launcher.win32.win32.x86 org.eclipse.equinox.executable org.eclipse.equinox.launcher.win32.win32.x86_64 org.eclipse.equinox.registry Tom ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
[equinox-dev] equinox incubator projects tagged for the I-Build
The map file has been updated. The following projects have changed: org.eclipse.equinox.ds org.eclipse.equinox.util Tom ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
Re: [equinox-dev] OBR
Peter, who parses the filter? If OBR uses a different syntax from the Framework spec then the FrameworkUtil#createFilter or BundleContext#createFilter cannot be used. Who is throwing the syntax error in this case? The Equinox Framework implementation of the OBR implementation? Tom From: Peter Kriens [EMAIL PROTECTED] To: BJ Hargrave/Austin/[EMAIL PROTECTED] Cc: Equinox development mailing list equinox-dev@eclipse.org Date: 01/21/2008 02:27 AM Subject:Re: [equinox-dev] OBR This is not really true. The OSGi filter and the OBR filter are not required to be the same. RFC 112 specifically allows the and (as well as some other operators). Kind regards, Peter Kriens On 20 jan 2008, at 15:51, BJ Hargrave wrote: This may be a problem in the tool (from OSGi) which generates the xml. OSGi recently decide to add and to the set of filter operators. But this is not in the 4.1 spec. It will be in a future spec. So the tool which generates the xml should not use the new operators. BJ Hargrave Senior Technical Staff Member, IBM OSGi Fellow and CTO of the OSGi Alliance [EMAIL PROTECTED] Office: +1 386 848 1781 Mobile: +1 386 848 3788 - Original Message - From: ChangWoo Jung [EMAIL PROTECTED] Sent: 01/20/2008 07:43 AM To: Equinox development mailing list equinox-dev@eclipse.org Cc: Peter Kriens [EMAIL PROTECTED] Subject: Re: [equinox-dev] OBR I guess I found little bug in the generated OBR repo ( http://download.eclipse.org/releases/europa/repository.zip) The generated filter seems to be incorrect which throws exception in the runtime. For example, Jetty Http Service (org.eclipse.equinox.http.jetty), has dependency on javax.servlet which is shown as Import-Package: javax.servlet;version=[2.4.0,2.5.0) in the manifest. It turns out be generated like below, (which seems to be incorrect), so it throws InvalidSyntaxException when equinox tries to create the filter upon that. require extend='false' filter='(amp;(package=javax.servlet)(versiongt;=2.4.0)(versionlt;2.5.0))' multiple='false' name='package' optional='false' Import package javax.servlet ;version=2.4.0 /require I guess there is minor bug on creating filter and after applying my private fix it seems to be working. wrong: filter='(amp;(package=javax.servlet)(versiongt;=2.4.0)(versionlt;2.5.0))' correct: filter='(amp;(package=javax.servlet)(amp;(versiongt;=2.4.0)(amp;(version!=2.5.0)(versionlt;=2.5.0' Which component will be the right place to report a bug against that i can attach my fix there as well? Any pointers? Thanks. Sincerely, ChangWoo Jung From: Jeff McAffer [EMAIL PROTECTED] To: Equinox development mailing list equinox-dev@eclipse.org Date: 01/12/2008 12:43 AM Subject: Re: [equinox-dev] OBR We currently do host an OBR repo with the major releases. Don't remember the URL but the required repository.xml/zip file is there for Callisto and Europa. The OBR client code may be interesting but our strategic direction is p2. For the most part p2 has (or can be made to have) the same functionality as the OBR client but goes further towards solving the wider range of problems we see in the Eclipse provisioning space. I am all for supporting the use of OBR repositories in the sense that some people will make their function available that way. Given the p2 work however, it would be more interesting (to me at least) to write an OBR repository adaptor for p2 than to use the OBR api. Further, I hope that eclipse projects will feel comfortable making their content available as p2 repositories so that
[equinox-dev] Projects tagged for the I-Build
The map file has been updated for the following Bug changes: + Bug 212954. [AdapterManager] Uninstalling bundle declarating adpater factory removes all adapter factories for the adapter (FIXED) + Bug 215503. Allow KeyStoreTrustEngine to use another name (FIXED) + Bug 215648. [console] ensure console thread is a non-daemon thread (FIXED) + Bug 215901. Bundle-NativeCode resolution of org.osgi.framework.os.name and org.osgi.framework.processor is not case-insensitive (FIXED) The following projects have changed: org.eclipse.equinox.launcher.win32.win32.ia64 org.eclipse.equinox.launcher.carbon.macosx org.eclipse.equinox.launcher.win32.win32.x86_64 org.eclipse.equinox.launcher.gtk.linux.ppc org.eclipse.osgi.tests org.eclipse.equinox.launcher.motif.linux.x86 org.eclipse.osgi org.eclipse.equinox.launcher.gtk.linux.x86_64 org.eclipse.equinox.launcher.wpf.win32.x86 org.eclipse.equinox.launcher org.eclipse.equinox.launcher.win32.win32.x86 org.eclipse.equinox.launcher.gtk.solaris.sparc org.eclipse.equinox.registry org.eclipse.equinox.supplement org.eclipse.equinox.launcher.motif.aix.ppc org.eclipse.equinox.launcher.gtk.linux.x86 Tom ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
[equinox-dev] Incubator OSGi service implementations tagged for I-Build
The map file has been updated for the following Bug changes: + Bug 214124. [config] Need to use doPrivileged when accessing config store (FIXED) The following projects have changed: org.eclipse.equinox.ds org.eclipse.equinox.io org.eclipse.equinox.wireadmin org.eclipse.equinox.util org.eclipse.equinox.cm org.eclipse.equinox.ip A reminder to all equinox committers. Each bug you release to CVS must be released with a comment that includes the text bug bug number. For example, Simon used the comment Bug 214124. [config] Need to use doPrivileged when accessing config store when releasing the fix to org.eclipse.equinox.cm. This allows our release tools to generate a report with all the bugs which were fixed. Thanks. Tom ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
Re: [equinox-dev] OBR
ChangWoo, There currently is no implementation of OBR. If you look earlier in this thread you will see talk of investigating an OBR repository adaptor for p2. Thomas Hallgren showed interest in implementing such a repository adaptor. Thomas, do you have any interest in doing/contributing this work to Equinox? Perhaps start in the incubator? For your Filter issue. I would open a bug against the apache version of OBR. It should not be using the framework Filter implementation to construct Filter objects. Tom From: Peter Kriens [EMAIL PROTECTED] To: Equinox development mailing list equinox-dev@eclipse.org Date: 01/22/2008 02:09 AM Subject:Re: [equinox-dev] OBR RFC 112 is not a standard, but please note that and are specifically allowed. Rewriting bindex will not fix the problem if you want to interoperate, you have to use another filter impl to achieve that. Kind regards, Peter Kriens On 21 jan 2008, at 16:18, ChangWoo Jung wrote: I have been using OBR implementation from Apache Felix and it uses BundleContext#createFilter to create the filter which throws the exception in the equinox framework at the end. So if I don't modify the bindex not to generate the or operator, the repo xml can't be digested in the OBR bundle for bundle resolution in the framework. By the way, do we also have OBR implementation from equinox? Sincerely, ChangWoo Jung From: Thomas Watson [EMAIL PROTECTED] To: Equinox development mailing list equinox-dev@eclipse.org Date: 01/21/2008 11:44 PM Subject: Re: [equinox-dev] OBR Peter, who parses the filter? If OBR uses a different syntax from the Framework spec then the FrameworkUtil#createFilter or BundleContext#createFilter cannot be used. Who is throwing the syntax error in this case? The Equinox Framework implementation of the OBR implementation? Tom mime-attachment.gifPeter Kriens ---01/21/2008 02:27:18 AM---This is not really true. The OSGi filter and the OBR filter are not required to be the same. RFC 112 specifically allows the mime-attachment.gif mime-attachment.gif From: Peter Kriens [EMAIL PROTECTED] mime-attachment.gif mime-attachment.gif To: BJ Hargrave/Austin/[EMAIL PROTECTED] mime-attachment.gif mime-attachment.gif Cc: Equinox development mailing list equinox-dev@eclipse.org mime-attachment.gif mime-attachment.gif Date: 01/21/2008 02:27 AM mime-attachment.gif mime-attachment.gif Subject: Re: [equinox-dev] OBR This is not really true. The OSGi filter and the OBR filter are not required to be the same. RFC 112 specifically allows the and (as well as some other operators). Kind regards, Peter Kriens On 20 jan 2008, at 15:51, BJ Hargrave wrote: This may be a problem in the tool (from OSGi) which generates the xml. OSGi recently decide to add and to the set of filter operators. But this is not in the 4.1 spec. It will be in a future spec. So the tool which generates the xml should not use the new operators. BJ Hargrave Senior Technical Staff Member, IBM OSGi Fellow and CTO of the OSGi Alliance
Re: [equinox-dev] [prov] Download manager support for pack200
If the Pack200 class is loaded from the VM then it will fall under the boot class loader. There is no way we can throw that class loader away. Are you suggesting that we could somehow load this class from an isolated class loader that is not connected to the boot class loader? Tom From: Andrew Niefer [EMAIL PROTECTED] To: Equinox development mailing list equinox-dev@eclipse.org Date: 01/25/2008 09:57 AM Subject:Re: [equinox-dev] [prov] Download manager support for pack200 As Pascal mentioned, when we first started experimenting with Pack200 we had memory problems. It seemed that Pack200's internal data was static and not cleared between each jar that was packed. So once we had packed a reasonable number of jars we started running out of memory. It could be that we had been doing something wrong. It is also possible that we could work around this by playing with class loaders (under the assumption that if the classloader was garbage collected, all that static memory would go away). -Andrew Thomas Hallgren [EMAIL PROTECTED] Sent by: [EMAIL PROTECTED]To Equinox development mailing list equinox-dev@eclipse.org 01/25/2008 02:53 AMcc Subject Please respond toRe: [equinox-dev] [prov] Equinox development mailing listDownload manager support for equinox-dev@eclipse.orgpack200 Just out of curiosity, why do you use the external binary to do the pack/unpack and not the java.util.jar.Pack200 class? It seems to me that a fragment that is EE dependent (require Java 1.5 or higher) would be ideal here. Those who run lower then Java 5 simply would not have pack200 which is kind of natural isn't it? - thomas Jeff McAffer wrote: right but there is the practical detail that the exe you need comes with Java 5 or later and the licensing does not likely allow you to ship just the unpack200 exe. But that is a matter for someone's legal team. As John says, the unpack support simply cares whether or not the exe is there. What we really need is an open source implementation of unpack that runs on/with Foundation... Jeff John Arthorne wrote: Just to clarify, the JRE level doesn't matter here. Unpack is performed by a standalone unpack200 executable that doesn't require presence of a JVM. You can run with a Foundation class library, plus a standalone unpack200 executable from Java 5 or Java 6. *Jim Colson [EMAIL PROTECTED]* Sent by: [EMAIL PROTECTED] 01/24/2008 09:18 PM Please respond to Equinox development mailing list equinox-dev@eclipse.org To Equinox development mailing list equinox-dev@eclipse.org cc Equinox development mailing list equinox-dev@eclipse.org, [EMAIL PROTECTED] Subject Re: [equinox-dev] [prov] Download manager support for pack200 how would that work on J2ME (CDC/Foundatoin)? Jim Colson, Chief Architect - IBM Client Software Distinguished Engineer IBM Academy of Technology Board Member - IT Architect Certification 11501 Burnet Rd. Austin, TX 78758 Ph 512-823-7357, Fax 512-838-0962 email: [EMAIL PROTECTED] Admin: Sandra Wallis 512-838-3241 email: [EMAIL PROTECTED] From: Pascal Rapicault [EMAIL PROTECTED] To: Equinox development mailing list equinox-dev@eclipse.org Date: 01/24/2008 08:11 PM
Re: [equinox-dev] is this a service tracker bug?
Mark, I opened https://bugs.eclipse.org/bugs/show_bug.cgi?id=216648 for you. I tried to CC you to the bug but I noticed you did not seem to have a bugzilla e-mail, unless you use a different e-mail for bugzilla than the one you use to post to equinox-dev. Tom From: Mark [EMAIL PROTECTED] To: Equinox development mailing list equinox-dev@eclipse.org Date: 01/25/2008 02:43 PM Subject:Re: [equinox-dev] is this a service tracker bug? :( I'll file a report - one other solution pointed out was to seperate interface (api) from the impl and the client. So I guess I should create A, B, and C (A)pi, Impl-(B)undle, and (C)lient Regards osgi ss Framework is launched. idState Bundle 0ACTIVE org.eclipse.osgi_3.3.1.R33x_v20070828 1ACTIVE bundleA_1.0.0 2ACTIVE bundleB_1.0.0 osgi update 1 removedService osgi update 1 osgi ss Framework is launched. idState Bundle 0ACTIVE org.eclipse.osgi_3.3.1.R33x_v20070828 1INSTALLED bundleA_1.0.0 2ACTIVE bundleB_1.0.0 osgi start 1 org.osgi.framework.BundleException: Exception in bundlea.Activator.start() of bundle bundleA. at org.eclipse.osgi.framework.internal.core.BundleContextImpl.startActivator(BundleContextImpl.java:1018) at org.eclipse.osgi.framework.internal.core.BundleContextImpl.start(BundleContextImpl.java:974) at org.eclipse.osgi.framework.internal.core.BundleHost.startWorker(BundleHost.java:346) at org.eclipse.osgi.framework.internal.core.AbstractBundle.start(AbstractBundle.java:260) at org.eclipse.osgi.framework.internal.core.AbstractBundle.start(AbstractBundle.java:252) at org.eclipse.osgi.framework.internal.core.FrameworkCommandProvider._start(FrameworkCommandProvider.java:260) 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:585) at org.eclipse.osgi.framework.internal.core.FrameworkCommandInterpreter.execute(FrameworkCommandInterpreter.java:150) at org.eclipse.osgi.framework.internal.core.FrameworkConsole.docommand(FrameworkConsole.java:291) at org.eclipse.osgi.framework.internal.core.FrameworkConsole.console(FrameworkConsole.java:276) at org.eclipse.osgi.framework.internal.core.FrameworkConsole.run(FrameworkConsole.java:218) at java.lang.Thread.run(Thread.java:595) Caused by: java.lang.IllegalStateException: The state indicates the bundle is resolved at org.eclipse.osgi.framework.internal.core.AbstractBundle.getResolutionFailureMessage(AbstractBundle.java:1376) at org.eclipse.osgi.framework.internal.core.BundleHost.startWorker(BundleHost.java:305) at org.eclipse.osgi.framework.internal.core.AbstractBundle.start(AbstractBundle.java:260) at org.eclipse.osgi.framework.util.SecureAction.start(SecureAction.java:400) at org.eclipse.core.runtime.internal.adaptor.EclipseLazyStarter.postFindLocalClass(EclipseLazyStarter.java:111) at org.eclipse.osgi.baseadaptor.loader.ClasspathManager.findLocalClass(ClasspathManager.java:417) at org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader.findLocalClass(DefaultClassLoader.java:189) at org.eclipse.osgi.framework.internal.core.BundleLoader.findLocalClass(BundleLoader.java:340) at org.eclipse.osgi.framework.internal.core.SingleSourcePackage.loadClass(SingleSourcePackage.java:37) at org.eclipse.osgi.framework.internal.core.BundleLoader.findClassInternal(BundleLoader.java:396) at org.eclipse.osgi.framework.internal.core.BundleLoader.findClass(BundleLoader.java:369) at org.eclipse.osgi.framework.internal.core.BundleLoader.findClass(BundleLoader.java:357) at org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader.loadClass(DefaultClassLoader.java:83) at java.lang.ClassLoader.loadClass(ClassLoader.java:251) at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319) at bundlea.Activator.start(Activator.java:12) at org.eclipse.osgi.framework.internal.core.BundleContextImpl$2.run(BundleContextImpl.java:999) at java.security.AccessController.doPrivileged(Native Method) at org.eclipse.osgi.framework.internal.core.BundleContextImpl.startActivator(BundleContextImpl.java:993) ... 14 more Nested Exception: java.lang.IllegalStateException: The state indicates the bundle is resolved at
Re: [equinox-dev] is this a service tracker bug?
Mark, This is because of the pending removal of the old class loader from bundle A which bundle B is still wired to for package bundlea.service. You do not see the new service from bundle B because you would get a ClassCastException. The Framework filters out services that it knows you do not have the correct package wiring for. The new content for the service is loaded from the new class loader of Bundle A. But since Bundle B is still wired to the old content of Bundle A it will not see the service until it is refreshed. A refresh operation will rewire Bundle B so that it gets the new content from Bundle A and everybody will be happy. Tom [EMAIL PROTECTED] wrote on 01/25/2008 10:33:33 AM: This is driving me mad. I have two bundles A and B. B track the service offered by A. However if I call update on A then I get a remove Service notification but no add Service notification - that is until I issue a refresh command ? is this a bug? I have written the same simple code 10 time .. see the results. I have attached the two bundles and the two eclipse plugin projects (as one zip) - just in case a Eclipse/OSGi guru like yourself can figure it out? [image removed] [image removed] C:\egjava -jar equinox.osgi.jar -console osgi ss Framework is launched. id State Bundle 0 ACTIVE org.eclipse.osgi_3.4.0.v20071207 osgi install file:bundleA_1.0.0.jar Bundle id is 1 osgi install file:bundleB_1.0.0.jar Bundle id is 2 osgi ss Framework is launched. id State Bundle 0 ACTIVE org.eclipse.osgi_3.4.0.v20071207 1 INSTALLED bundleA_1.0.0 2 INSTALLED bundleB_1.0.0 osgi start 1 osgi start 2 addingService osgi stop 1 removedService osgi start 1 addingService osgi update 1 removedService - no add ! osgi stop 2 osgi start 2 osgi refresh - Only get add after refresh osgi addingService osgi On 25/01/2008, Neil Bartlett [EMAIL PROTECTED] wrote: Hi Mark, Many thanks for your kind words! Regarding the service tracker problem... that's not the behaviour I would expect to see, and I've just put together a small test case which prints a message in the addingService, removedService and modifiedService methods of the ServiceTracker. When I update the bundle that registered the service, I see the following: osgi update 5 Removed service Added service osgi Which seems to be the way it should work. I suggest posting a message to the equinox-dev mailing list ( https://dev.eclipse.org/ mailman/listinfo/equinox-dev) explaining the problem in detail and including a minimal code sample that reproduces the problem. Regards, Neil On 25 Jan 2008, at 13:42, Mark wrote: Neil, First off I have to thank you in a big way, because it was you articles that got me up and running on OSGI. I am also glad that you are putting together a book... because I was thinking about it myself...in practice or in action!, would you like some help? ..Anyway the reason for this mail... I was looking at the Listeners Considered Harmful: The Whiteboard Pattern white paper, and I put together a very simple two bundle example (on Equinox), Bundle A (offers a service) Bundle B (consumes service A, using a Service Tracker) So far so good, and not exactly rocket science. However this morning I discovered that if you update A - then you must refresh A in order for B to receive the added service event. This came as a surprise, go I Googled a while, and came up short. So I was wondering if you had some words of widom for me on this ? Kind Regards Mark [attachment bundleA_1.0.0.jar deleted by Thomas Watson/Austin/IBM] [attachment bundleB_1.0.0.jar deleted by Thomas Watson/Austin/IBM] [attachment eclipe-projects.zip deleted by Thomas Watson/Austin/IBM] ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
Re: [equinox-dev] is this a service tracker bug?
Matt, please open a bug against Equinox-Framework. I have reproduced, it appears to be related to lazy activation. If you remove the Eclipse-LazyStart header from Bundle A then it works. This is an interesting corner case we may need to get a clarification from OSGi on. I assume the old content of the bundle will not have access to a BundleContext. What does it mean to get wired to old pending removal content of a bundle that is lazy activated? The classes may be in an invalid state if they cannot have access to a BundleContext. Tom From: BJ Hargrave/Austin/[EMAIL PROTECTED] To: Equinox development mailing list equinox-dev@eclipse.org Date: 01/25/2008 12:10 PM Subject:Re: [equinox-dev] is this a service tracker bug? But you should not have to refresh. That is the whole point of importing the package which is exported. So that A' can import it from A which is where B imports it from. I think the IllegalStateException is is a bug in Equinox. -- BJ Hargrave Senior Technical Staff Member, IBM OSGi Fellow and CTO of the OSGi Alliance [EMAIL PROTECTED] office: +1 386 848 1781 mobile: +1 386 848 3788 From: Mark [EMAIL PROTECTED] To: Equinox development mailing list equinox-dev@eclipse.org Date: 2008-01-25 13:06 Subject: Re: [equinox-dev] is this a service tracker bug? I see - It's in an IllegalState until you refresh On 25/01/2008, Mark [EMAIL PROTECTED] wrote: Try adding: Import-Package: bundlea.service to the Bundle A manifest. = I just tried the suggestion above - but it blows up? Framework is launched. idState Bundle 0ACTIVE org.eclipse.osgi_3.3.1.R33x_v20070828 1ACTIVE bundleA_1.0.0 2ACTIVE bundleB_1.0.0 osgi stop 1 removedService osgi update 1 osgi ss Framework is launched. idState Bundle 0ACTIVE org.eclipse.osgi_3.3.1.R33x_v20070828 1INSTALLED bundleA_1.0.0 2ACTIVE bundleB_1.0.0 osgi start 1 org.osgi.framework.BundleException: Exception in bundlea.Activator.start() of bundle bundleA. at org.eclipse.osgi.framework.internal.core.BundleContextImpl.startActivator(BundleContextImpl.java:1018) at org.eclipse.osgi.framework.internal.core.BundleContextImpl.start(BundleContextImpl.java:974) at org.eclipse.osgi.framework.internal.core.BundleHost.startWorker(BundleHost.java:346) at org.eclipse.osgi.framework.internal.core.AbstractBundle.start(AbstractBundle.java:260) at org.eclipse.osgi.framework.internal.core.AbstractBundle.start(AbstractBundle.java:252) at org.eclipse.osgi.framework.internal.core.FrameworkCommandProvider._start(FrameworkCommandProvider.java:260) 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:585) at org.eclipse.osgi.framework.internal.core.FrameworkCommandInterpreter.execute(FrameworkCommandInterpreter.java:150) at org.eclipse.osgi.framework.internal.core.FrameworkConsole.docommand(FrameworkConsole.java:291) at org.eclipse.osgi.framework.internal.core.FrameworkConsole.console(FrameworkConsole.java:276) at org.eclipse.osgi.framework.internal.core.FrameworkConsole.run(FrameworkConsole.java:218) at java.lang.Thread.run(Thread.java:595) Caused by: java.lang.IllegalStateException: The state indicates the bundle is resolved at org.eclipse.osgi.framework.internal.core.AbstractBundle.getResolutionFailureMessage(AbstractBundle.java:1376) at org.eclipse.osgi.framework.internal.core.BundleHost.startWorker(BundleHost.java:305) at org.eclipse.osgi.framework.internal.core.AbstractBundle.start(AbstractBundle.java:260) at org.eclipse.osgi.framework.util.SecureAction.start(SecureAction.java:400) at org.eclipse.core.runtime.internal.adaptor.EclipseLazyStarter.postFindLocalClass(EclipseLazyStarter.java:111) at org.eclipse.osgi.baseadaptor.loader.ClasspathManager.findLocalClass(ClasspathManager.java:417) at org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader.findLocalClass(DefaultClassLoader.java:189) at org.eclipse.osgi.framework.internal.core.BundleLoader.findLocalClass(BundleLoader.java:340) at org.eclipse.osgi.framework.internal.core.SingleSourcePackage.loadClass(SingleSourcePackage.java:37) at
[equinox-dev] Equinox projects tagged for the I-Build
The map file has been updated for the following Bug changes: + Bug 181832. Console's diag command should try to display the ID of the Missing required bundle (FIXED) + Bug 201068. refreshPackages() incorrect behaviour (FIXED) + Bug 214635. [Launcher] maximum .ini/.ee line length of 1024 (FIXED) + Bug 215369. [launcher] Running with --launcher.suppressErrors hides all error messages (FIXED) + Bug 215730. VM must remain active until Framework is shutdown (FIXED) + Bug 215764. Service tracker is not closed in equinox.app's DefaultApplicationListener (FIXED) + Bug 216196. [sec] Add getStatus support to AuthorizationEngine (FIXED) + Bug 216286. Compiler warnings in N20080123-0010 in osgi tests (FIXED) + Bug 216648. Updating a bundle that exports/imports same package fails (FIXED) The following projects have changed: org.eclipse.equinox.executable org.eclipse.equinox.supplement org.eclipse.equinox.app org.eclipse.osgi.tests org.eclipse.osgi Tom ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
[equinox-dev] Equinox Incubator OSGi implementations tagged for I-Build
The map file has been updated for the following Bug changes: + Bug 216281. [ds] Compiler warnings in N20080123-0010 (FIXED) + Bug 216282. [ip] Compiler warnings in N20080123-0010 (FIXED) + Bug 216284. [util] Compiler warnings in N20080123-0010 (FIXED) + Bug 216285. [wireadmin] Compiler warnings in N20080123-0010 (FIXED) The following projects have changed: org.eclipse.equinox.ds org.eclipse.equinox.wireadmin org.eclipse.equinox.util org.eclipse.equinox.ip Tom ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
Re: FW: [equinox-dev] Declarative services bug?
I have not experienced this. From your description it does not sound like DS problem but rather a Framework issue. DS does not effect the class loading of an individual bundle. Could you open a bug and attach a test case? Tom From: Chris Hopkins [EMAIL PROTECTED] To: Equinox development mailing list equinox-dev@eclipse.org Date: 01/29/2008 05:06 AM Subject:FW: [equinox-dev] Declarative services bug? I may have missed a response to this. Has anyone else experienced it? Thanks, Chris THIS MESSAGE IS INTENDED FOR THE USE OF THE PERSON TO WHOM IT IS ADDRESSED. IT MAY CONTAIN INFORMATION THAT IS PRIVILEGED, CONFIDENTIAL AND EXEMPT FROM DISCLOSURE UNDER APPLICABLE LAW. If you are not the intended recipient, your use of this message for any purpose is strictly prohibited. If you have received this communication in error, please delete the message and notify the sender so that we may correct our records. From: [EMAIL PROTECTED] [ mailto:[EMAIL PROTECTED] On Behalf Of Chris Hopkins Sent: Friday, January 25, 2008 12:33 PM To: Equinox development mailing list Subject: [equinox-dev] Declarative services bug? Hi – I think I may have run into a bug with the declarative services implementation (we’re currently using org.eclipse.equinox.ds_0.1.0.v20071022.jar). If I have a .jar on the bundle classpath of my bundle and try to access the classes stored in that .jar while DS is creating my service declared in my XML file then I get a ClassNotFoundException. For our concrete example, I am trying to create a connection to Weblogic and have the weblogic jars on the classpath of my bundle. My DS XML specifies the class that creates the connection to Weblogic. When I start up my OSGi application, I get a class not found exception for weblogic/jndi/WLInitialContextFactory which is in the wlclient.jar that is on the bundle classpath. If I try to create that connection after the DS service has been created (e.g. in response to a button click) then the class is found just fine. Has anyone else experienced this? Thanks, Chris ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev inline: graycol.gifinline: ecblank.gif___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
[equinox-dev] Migrating Eclipse-LazyStart to Bundle-ActivationPolicy
There has been several discussions in various bug reports about migrating from the Eclipse-LazyStart header to the new Bundle-ActivationPolicy header specified in the OSGi R4.1 specification. With the latest I-Builds PDE is now flagging the old Eclipse-LazyStart header as deprecated and with this weeks I-Build PDE is offering two quickfix options to migrate to the Bundle-ActivationPolicy: 1) Convert the deprecated 'Eclipse-LazyStart' to 'Bundle-ActivationPolicy' 2) Add 'Bundle-ActivationPolicy' header The Equinox team is recommending that developers use option 2 when migrating to the new header. This will ensure that bundles will continue to work on older Eclipse platforms where the Bundle-ActivationPolicy header is not recognized. It will also allow the bundle to work on other OSGi R4 Framework implementations which probably do not recognize the Eclipse-LazyStart header. Tom ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
Re: [equinox-dev] triggering the storage adaptor questoin
Hi Martin, This is a tricky one. If a supplementer bundle is installed after a bundle it is supplementing then it will be too late for you to modify the bundle you are supplementing. This is because it has already been added to the state. Doing a Bundle.update() of the bundle you are supplementing may be required, but following it by a PackageAdmin.refreshPackages will likely cause quite a bit of flux if you are installing a bunch of supplementer bundles at one time. Each installation would trigger a refreshPackages operation (which BTW is an async operation). I would suggest not doing a PackageAdmin.refreshPackages and instead just doing the update() operation and then depending on the installer doing the refreshPackages for you. Currently update.configurator will call refreshPackages after it has uninstalled/installed a group of bundles. This should force the resolver to pick up the new supplemented data that you provided. If the bundle is installed by a reference URL then it should be as simple as calling Bundle.update() with no params. This should cause the storagehook for the supplemented bundle to be called and allow you to supplement it. Hope that makes sense. If not come to equinox-dev IRC and we can discuss next week. Tom From: Martin Lippert [EMAIL PROTECTED] To: Equinox Project equinox-dev@eclipse.org Date: 02/01/2008 04:22 PM Subject:[equinox-dev] triggering the storage adaptor questoin Hi! For equinox aspects we are using a storage adapter to modify the manifest of bundles with regards to the additionally defined manifest entries of aspect bundles. This happens in the initialize method of the storage adapter. My question now: Is it possible to trigger the call of this method for a specified bundle from within this method? Does a Bundle.update() do the trick, followed by a PackageAdmin.refresh()? I am asking because I don't know the order in which this method is called for different bundles. Therefore it might occur the situation in which I figure out that I need to supplement a bundle for which this method is already called. Any idea? Thanks!!! -Martin ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev inline: graycol.gifinline: ecblank.gif___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
[equinox-dev] Equinox projects tagged for next M5 build
The map file has been updated for the following Bug changes: + Bug 217317. Need an option to bypass uses constraint checks (FIXED) + Bug 217789. Compiler warnings in I20080204-1800 (FIXED) + Bug 217818. Setting up AdminPermission for signed bundles using PermissionAdmin causes ClassCastException (FIXED) The following projects have changed: org.eclipse.equinox.launcher.motif.hpux.ia64_32 org.eclipse.equinox.launcher org.eclipse.equinox.executable org.eclipse.osgi.tests org.eclipse.osgi Tom ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
Re: [equinox-dev] ECF consuming org.osgi.services.cm and org.osgi.service.metatype
We just had the graduation review for cm last week and are in the process of getting the code moved into the Equinox-Bundles project. A graduated cm bundle will be ready in M6. Tom From: Markus Alexander Kuppe [EMAIL PROTECTED] To: Equinox development mailing list equinox-dev@eclipse.org Date: 02/06/2008 07:00 AM Subject:[equinox-dev] ECF consuming org.osgi.services.cm and org.osgi.service.metatype Hi, the ECF team plans [1][2] to leverage org.osgi.services.cm and org.osgi.service.metatype with its discovery API and we're anxious to get comments from the Equinox team. Especially for #217981 which might be solved by combining efforts and on the issue of configuration admin still being in incubation/marked as red on the Equinox page. Do you plan on graduating cm with Ganymede? Cheers, Markus [1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=217981 [2] https://bugs.eclipse.org/bugs/show_bug.cgi?id=217978 ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev inline: graycol.gifinline: ecblank.gif___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
Re: [equinox-dev] Signed bundles
The option to enable signed bundles in 3.3 is osgi.support.signature.verify (notice support and signature are reversed). In 3.4 we are introducing a more general option called osgi.signedcontent.support which does not have simple true|false options, but we will continue to recognize the old 3.3. option. Matt is documenting the security options in https://bugs.eclipse.org/bugs/show_bug.cgi?id=217765 The internal security manager class is needed to fully support postponed conditions in ConditionalPermissionAdmin. If postponed conditions are not needed then simply enabling the security manager with -Djava.security.policy= will enable the built-in security manager which will satisfy most needs. There is an option called eclipse.security. This option is used by the launcher jar to setup a policy to grant the framework and the launcher AllPermissions and specify the security manager to use. Unfortunately this still requires a reference to an internal class if you want to load a security manager to support postponed conditions. I've opened a bug to investigate making this easier. Perhaps eclipse.security manager can have a value that indicates the framework should load its internal security manager. See https://bugs.eclipse.org/bugs/show_bug.cgi?id=218001. Tom From: Jeff McAffer [EMAIL PROTECTED] To: Equinox development mailing list equinox-dev@eclipse.org Date: 02/06/2008 07:47 AM Subject:Re: [equinox-dev] Signed bundles Marcel Offermans wrote: So, reiterating, if I want to run Equinox with OSGi security enabled and have it use my own keystore, I have to start it like this (formatted a bit for clarity, but typed as one big line): java -Djava.security.manager=org.eclipse.osgi.framework.internal.core.FrameworkSecurityManager -Djava.security.policy=policy -Dosgi.framework.keystore=keystore -Dosgi.signature.support.verify=true -jar org.eclipse.osgi_3.4.0.v20071207.jar -console -consoleLog Basically, I'm asking how Equinox is being run to be compliant with OSGi security. Is the above line accurate? Seems complicated and requires people to reference internal classes etc. Could be wrong but I remember it being simipler Jeff ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev inline: graycol.gifinline: ecblank.gif___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
Re: [equinox-dev] Signed bundles
Marcel, Seem that we keep giving you the wrong options!!! java -Djava.security.manager= -Djava.security.policy=policy -Dosgi.framework.keystore=file:keystore -Dosgi.signedcontent.support=true -jar org.eclipse.osgi_3.4.0.qualifier.jar -console -consoleLog Please try this on the latest I-Build of 3.4. The v20071207 version of org.eclipse.osgi was before we released some of the new signed bundle support. Tom From: Marcel Offermans [EMAIL PROTECTED] To: Equinox development mailing list equinox-dev@eclipse.org Date: 02/07/2008 07:05 AM Subject:Re: [equinox-dev] Signed bundles Hello Thomas, I'm trying your suggestions: java -Dosgi.signedcontent.support=true -Djava.security.policy= -jar org.eclipse.osgi_3.4.0.v20071207.jar -console From what I understand that should give me a framework with security and signed bundle support, but when I try that and type services from the equinox console, I don't get a (Conditional)PermissionAdmin service. Greetings, Marcel On Feb 6, 2008, at 15:43 , Thomas Watson wrote: The option to enable signed bundles in 3.3 is osgi.support.signature.verify (notice support and signature are reversed). In 3.4 we are introducing a more general option called osgi.signedcontent.support which does not have simple true|false options, but we will continue to recognize the old 3.3. option. Matt is documenting the security options in https://bugs.eclipse.org/bugs/show_bug.cgi?id=217765 The internal security manager class is needed to fully support postponed conditions in ConditionalPermissionAdmin. If postponed conditions are not needed then simply enabling the security manager with -Djava.security.policy= will enable the built-in security manager which will satisfy most needs. There is an option called eclipse.security. This option is used by the launcher jar to setup a policy to grant the framework and the launcher AllPermissions and specify the security manager to use. Unfortunately this still requires a reference to an internal class if you want to load a security manager to support postponed conditions. I've opened a bug to investigate making this easier. Perhaps eclipse.security manager can have a value that indicates the framework should load its internal security manager. See https://bugs.eclipse.org/bugs/show_bug.cgi?id=218001. Tom graycol.gifJeff McAffer ---02/06/2008 07:47:10 AM---Marcel Offermans wrote: ecblank.gif ecblank.gif From: Jeff McAffer [EMAIL PROTECTED] ecblank.gif ecblank.gif To:Equinox development mailing list equinox-dev@eclipse.org ecblank.gif ecblank.gif Date: 02/06/2008 07:47 AM ecblank.gif ecblank.gif Subject: Re: [equinox-dev] Signed bundles Marcel Offermans wrote: So, reiterating, if I want to run Equinox with OSGi security enabled and have it use my own keystore, I have to start it like this (formatted a bit for clarity, but typed as one big line): java -Djava.security.manager=org.eclipse.osgi.framework.internal.core.FrameworkSecurityManager -Djava.security.policy=policy -Dosgi.framework.keystore=keystore -Dosgi.signature.support.verify=true -jar org.eclipse.osgi_3.4.0.v20071207.jar -console -consoleLog Basically, I'm asking how Equinox is being run to be compliant with OSGi security. Is the above line accurate? Seems complicated and requires people to reference internal classes etc. Could be wrong but I remember it being simipler Jeff ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo
[equinox-dev] Equinox projects tagged for I-Build
The map file has been updated for the following Bug changes: + Bug 218516. [tests] timing issues with security tests. (FIXED) The following projects have changed: org.eclipse.osgi.tests Tom ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
Re: [equinox-dev] Re: startApp from osgi console
I think you may have run into bug https://bugs.eclipse.org/bugs/show_bug.cgi?id=198988 Tom From: 向雅 [EMAIL PROTECTED] To: Equinox development mailing list equinox-dev@eclipse.org Date: 02/13/2008 01:21 PM Subject:[equinox-dev] Re: startApp from osgi console Hi team, ha~It seems my homework not enough, why I just miss Alex Blewitt's article at http://www.eclipsezone.org/eclipse/forums/t99762.html. OK, the thread seems not a question. The true question is that, since the main thread mode IApplications cannot running, Why AppCommans not report a error or warning but a Lanuched ... message. From track, we can see that EclipseAppContainer or EclipseAppLauncher do not let the illegal/invalid application reached its IApplication.start() method. So in my view, it's better that let code give a report. If this can open a bug report? 在08-2-13，向雅 [EMAIL PROTECTED] 写道： Hi, I tried org.eclipse.equinox.examples.app.selector.application, with any and main thread mode, both visiable, all evironment is the newest 3.4M5 and cvs version plugins: And at selector I just add 3 lines printlog, no other changes. my running log as follows: ANY thread mode osgi !SESSION 2008-02-13 06:34:56.906 --- eclipse.buildId=unknown java.version=1.6.0_04 java.vendor=Sun Microsystems Inc. BootLoader constants: OS=win32, ARCH=x86, WS=win32, NL=zh_CN Framework arguments: -product org.eclipse.equinox.examples.app.selector.product Command-line arguments: -product org.eclipse.equinox.examples.app.selector.product -data F:\workspace\3.4/../runtime-AppSelector.product -dev file:F:/workspace/3.4/.metadata/.plugins/org.eclipse.pde.core/AppSelector.product/dev.properties -os win32 -ws win32 -arch x86 -console -consoleLog yes, I starting... [EMAIL PROTECTED] osgi osgi yes, I run returned. yes, I dispose... osgi startApp org.eclipse.equinox.examples.app.selector.application Launched application instance: org.eclipse.equinox.examples.app.selector.application.1 osgi class org.eclipse.equinox.internal.app.EclipseAppHandle yes, I starting... [EMAIL PROTECTED] yes, I run returned. yes, I dispose... In this mode, all seems ok, except must select stop action to close the application. if click windows close button, workbench Realm class would failed. MAIN_THEAD mode osgi !SESSION 2008-02-13 06:37:02.468 --- eclipse.buildId=unknown java.version=1.6.0_04 java.vendor=Sun Microsystems Inc. BootLoader constants: OS=win32, ARCH=x86, WS=win32, NL=zh_CN Framework arguments: -product org.eclipse.equinox.examples.app.selector.product Command-line arguments: -product org.eclipse.equinox.examples.app.selector.product -data F:\workspace\3.4/../runtime-AppSelector.product -dev file:F:/workspace/3.4/.metadata/.plugins/org.eclipse.pde.core/AppSelector.product/dev.properties -os win32 -ws win32 -arch x86 -console -consoleLog class org.eclipse.equinox.internal.app.EclipseAppHandle yes, I starting... [EMAIL PROTECTED] yes, I run returned. yes, I dispose... osgi osgi apps org.eclipse.equinox.app.error [not launchable] org.eclipse.swt.examples.addressbook.app [launchable] org.eclipse.equinox.examples.app.selector.application [launchable] osgi startApp org.eclipse.equinox.examples.app.selector.application Launched application instance: org.eclipse.equinox.examples.app.selector.application.1 osgi apps org.eclipse.equinox.app.error [not launchable] org.eclipse.swt.examples.addressbook.app [not launchable] org.eclipse.equinox.examples.app.selector.application [running] [not launchable] osgi stopApp org.eclipse.equinox.examples.app.selector.application Stopped application instance: org.eclipse.equinox.examples.app.selector.application.1 osgi startApp org.eclipse.swt.examples.addressbook.app Launched application instance: org.eclipse.swt.examples.addressbook.app.0
[equinox-dev] Equinox tagged for the I-Build
The map file has been updated for the following Bug changes: + Bug 215361. Support differing log levels (FIXED) + Bug 217724. Substitutable exports and require-bundle (FIXED) + Bug 218001. Using internal FrameworkSecurityManager should be easier (FIXED) + Bug 218625. [resolver] support for other system.bundle vendors (FIXED) + Bug 218861. Found 1 single quote in text handled by Java MessageFormat class (FIXED) + Bug 219094. [console] Use of FilteredOutputStream causes single byte writes to System.out (FIXED) + Bug 218710. [ds] [io] [ip] [wireadmin] [util] provision code to HEAD projects and build (FIXED) The following projects have changed: org.eclipse.equinox.launcher org.eclipse.equinox.app org.eclipse.equinox.event org.eclipse.equinox.ds org.eclipse.equinox.io org.eclipse.equinox.ip org.eclipse.equinox.util org.eclipse.equinox.wireadmin org.eclipse.osgi.tests org.eclipse.osgi Tom ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
Re: [equinox-dev] [prov] use of Foundation 1.1
The org.eclipse.equinox.registry also has J2SE 1.4 listed before Foundation 1.1. If I remember correctly, this is because we do not have a bundle at pde-build time that provides the XML api to bundles with BREE J2SE 1.4. I think if you simply reorder the BREEs we will get a build failure for bundles needing XML stuff to compile. We would need an XML bundle to be available at build time also. Tom From: Jeff McAffer [EMAIL PROTECTED] To: 'Equinox development mailing list' equinox-dev@eclipse.org Date: 02/19/2008 07:57 AM Subject:[equinox-dev] [prov] use of Foundation 1.1 There are several projects in p2 currently that list J2SE 1.4 and Foundation 1.1 in the BREE for the bundle. This is good but they list them in that order. The net result is that J2SE 1.4 is used to compile the code. What happens in some cases people don’t have 1.4 so PDE uses the next best thing which ends up being 1.5 or 1.6. In the end we get references to things we ought not. In particular, I just had a setup in which there were no XML api in my workspace or target yet everything was compiling ok. Took quite some time to figure out how this could be so. If everyone agrees, I will go through the projects and update them accordingly. Jeff___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev inline: graycol.gifinline: ecblank.gif___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
Re: [equinox-dev] DS invocation order of bind and activate (timing issue???)
The optional reference from A1 to B1 creates a cycle. The DS
implementation should be able to handle this since the reference is
optional it should be able to break the cycle and I assume provide a
consistent activation order of A1 and B1.
I recommend opening a bug against Equinox-Bundles to track the issue. It
would really help if you could provide a testcase to reproduce.
Tom
From: Foerster, Stefan [EMAIL PROTECTED]
To: equinox-dev@eclipse.org
Date: 02/22/2008 10:52 AM
Subject:[equinox-dev] DS invocation order of bind and activate (timing
issue???)
Hello,
I'm having three bundles providing three services using the declarative
service (version 1.0.0.v20080218):
bundle A:
component name=A1 immediate=true
implementation class=A1/
service
provide interface=IA/
/service
property name=service.pid value=A1/
property name=service.ranking value=1000/
reference name=b interface=IB bind=setB unbind=unsetB
cardinality=0..n policy=dynamic/
reference name=c interface=IC bind=setC unbind=unsetC
cardinality=0..1 policy=dynamic/
reference name=d interface=ID bind=setD unbind=unsetD
cardinality=1..1/
reference name=e interface=IE bind=setE unbind=unsetE
cardinality=0..n policy=dynamic/
/component
bundle B:
component name=B1
implementation class=B1/
service
provide interface=IB/
/service
property name=service.pid value=B1/
property name=service.ranking value=1000/
reference name=a interface=IA bind=setA unbind=unsetA
cardinality=1..1/
reference name=d interface=ID bind=setD unbind=unsetD
cardinality=1..1/
/component
bundle D:
component name=D1
implementation class=D1/
service
provide interface=ID/
/service
property name=service.pid value=D1/
property name=service.ranking value=1000/
reference name=logger interface=org.osgi.service.log.LogService
bind=setLog unbind=unsetLog cardinality=0..1 policy=dynamic/
/component
Reading the OSGi DS spec I assume the only valid method invocation order
(if the methods exists and are accessible) is:
1) D1.activate() - some instanceD
2) A1.setD(instanceD)
3) A1.activate() - some instanceA
4) B1.setA(instanceA) and B1.setD(instanceD) in any order
5) B1.activate() - some instanceB
6) A1.setB(instanceB)
Sometimes, it happens that B1 is activated before!!! A1. and I get the
following
order of calls from the OSGi log (calls to setD() are not logged!):
==
1: Debug [51] D1: activate() [EMAIL PROTECTED]:file:../../build/d1.jar/
2: Info [51] ServiceEvent REGISTERED {service.id=29}
3: Info [54] ServiceEvent REGISTERED {service.id=30}
4: Info [37] ServiceEvent REGISTERED {service.id=31}
5: Info [52] ServiceEvent REGISTERED {service.id=32}
6: Info [53] ServiceEvent REGISTERED {service.id=33}
7: Warn [4] ComponentReference.bind(): bind method setE is not accessible!
[EMAIL PROTECTED]:file:org.eclipse.equinox.ds_1.0.0.v20080218.jar/
8: Warn [4] ComponentReference.bind(): bind method setB is not accessible!
[EMAIL PROTECTED]:file:org.eclipse.equinox.ds_1.0.0.v20080218.jar/
9: Debug [51] B1: activate() [EMAIL PROTECTED]:file:../../build/d1.jar/
10:Debug [51] A1: setB() [EMAIL PROTECTED]:file:../../build/d1.jar/
11:Debug [51] A1: setB() A1 not yet activated!!! [EMAIL PROTECTED]:
file:../../build/d1.jar/
12:Debug [51] A1: activate() [EMAIL PROTECTED]:file:../../build/d1.jar/
13:Debug [51] E1: activate() [EMAIL PROTECTED]:file:../../build/d1.jar/
14:Debug [51] A1: setE() [EMAIL PROTECTED]:file:../../build/d1.jar/
15:Debug [51] B2: activate() [EMAIL PROTECTED]:file:../../build/d1.jar/
16:Debug [51] A1: setB() [EMAIL PROTECTED]:file:../../build/d1.jar/
17:Warn [4] ComponentReference.bind(): service reference already bound:
{IB}={service.ranking=1000, service.pid=B1, component.name=B1,
component.id=4, service.id=33} [EMAIL PROTECTED]:
[equinox-dev] Equinox-Framework tagged for next I-Build
I tagged Equinox-Framework for the next I-Build (today?). It will be good to get extra testing on bug 199103. The map file has been updated for the following Bug changes: + Bug 67220. Location.setUrl needs more error information (FIXED) + Bug 217503. DefaultAuthorizationEngine should allow policy to be set (FIXED) + Bug 218001. Using internal FrameworkSecurityManager should be easier (FIXED) + Bug 219512. CachedManifest should should cache Bundle-ManifestVersion and Bundle-ActivationPolicy (FIXED) + Bug 21. SignedContent missing a since tag (FIXED) + Bug 199103. ServiceRegistrationImpl has improper synchronization The following projects have changed: org.eclipse.osgi.tests org.eclipse.osgi Tom ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
RE: [equinox-dev] DS invocation order of bind and activate(timing issue???)
:
[EMAIL PROTECTED]; actionType 1
[EMAIL PROTECTED]:file:org.eclipse.equinox.ds_1.0.0.v20080218.jar/
Warn [5] [SCR - WorkThread] Timeout ocurred! Thread was blocked on
processing [QueuedJob] WorkPerformer:
[EMAIL PROTECTED]; actionType 1
[EMAIL PROTECTED]:file:org.eclipse.equinox.ds_1.0.0.v20080218.jar/
Info [12] BundleEvent STARTED
[EMAIL PROTECTED]:file:../../build/a1.jar/
Debug [5] bundleentry://14/OSGI-INF/Activator.xml [EMAIL PROTECTED]:
file:org.eclipse.equinox.ds_1.0.0.v20080218.jar/
Debug [5] [QueuedJob] WorkPerformer:
[EMAIL PROTECTED]; actionType 1
[EMAIL PROTECTED]:file:org.eclipse.equinox.ds_1.0.0.v20080218.jar/
Warn [5] [SCR - WorkThread] Timeout ocurred! Thread was blocked on
processing [QueuedJob] WorkPerformer:
[EMAIL PROTECTED]; actionType 1
[EMAIL PROTECTED]:file:org.eclipse.equinox.ds_1.0.0.v20080218.jar/
Info [14] BundleEvent STARTED
[EMAIL PROTECTED]:file:../../build/b2.jar/
Debug [5] bundleentry://15/OSGI-INF/Activator.xml [EMAIL PROTECTED]:
file:org.eclipse.equinox.ds_1.0.0.v20080218.jar/
Debug [5] [QueuedJob] WorkPerformer:
[EMAIL PROTECTED]; actionType 1
[EMAIL PROTECTED]:file:org.eclipse.equinox.ds_1.0.0.v20080218.jar/
Warn [5] [SCR - WorkThread] Timeout ocurred! Thread was blocked on
processing [QueuedJob] WorkPerformer:
[EMAIL PROTECTED]; actionType 1
[EMAIL PROTECTED]:file:org.eclipse.equinox.ds_1.0.0.v20080218.jar/
Info [15] BundleEvent STARTED
[EMAIL PROTECTED]:file:../../build/e1.jar/
Debug [5] bundleentry://16/OSGI-INF/Activator.xml [EMAIL PROTECTED]:
file:org.eclipse.equinox.ds_1.0.0.v20080218.jar/
Debug [5] bundleentry://16/OSGI-INF/Command.xml [EMAIL PROTECTED]:
file:org.eclipse.equinox.ds_1.0.0.v20080218.jar/
Debug [5] [QueuedJob] WorkPerformer:
[EMAIL PROTECTED]; actionType 1
[EMAIL PROTECTED]:file:org.eclipse.equinox.ds_1.0.0.v20080218.jar/
Warn [5] [SCR - WorkThread] Timeout ocurred! Thread was blocked on
processing [QueuedJob] WorkPerformer:
[EMAIL PROTECTED]; actionType 1
[EMAIL PROTECTED]:file:org.eclipse.equinox.ds_1.0.0.v20080218.jar/
Info [16] BundleEvent STARTED
[EMAIL PROTECTED]:file:../../build/d1.jar/
Debug [17] DEBUG 17 [0] 1 : [EMAIL PROTECTED]:
file:org.eclipse.equinox.util_1.0.0.v20080218.jar/
Debug [17] DEBUG 17 [0] 1001 : 0 [EMAIL PROTECTED]:
file:org.eclipse.equinox.util_1.0.0.v20080218.jar/
Debug [17] DEBUG 17 [0] 101 : 0 [EMAIL PROTECTED]:
file:org.eclipse.equinox.util_1.0.0.v20080218.jar/
Debug [17] DEBUG 17 [0] 102 : 0 [EMAIL PROTECTED]:
file:org.eclipse.equinox.util_1.0.0.v20080218.jar/
Debug [17] DEBUG 17 [0] 3001 : 0 [EMAIL PROTECTED]:
file:org.eclipse.equinox.util_1.0.0.v20080218.jar/
Debug [17] DEBUG 17 [0] 2001 : 0 [EMAIL PROTECTED]:
file:org.eclipse.equinox.util_1.0.0.v20080218.jar/
Debug [17] DEBUG 17 [0] 3 : 4 [EMAIL PROTECTED]:
file:org.eclipse.equinox.util_1.0.0.v20080218.jar/
Info [17] ServiceEvent REGISTERED {service.id=26}
Debug [17] DEBUG 17 [0] 4 : 1 [EMAIL PROTECTED]:
file:org.eclipse.equinox.util_1.0.0.v20080218.jar/
Debug [17] DEBUG 17 [0] 33 : 3 [EMAIL PROTECTED]:
file:org.eclipse.equinox.util_1.0.0.v20080218.jar/
Info [17] ServiceEvent REGISTERED {service.id=27}
Debug [17] DEBUG 17 [0] 5 : 0 [EMAIL PROTECTED]:
file:org.eclipse.equinox.util_1.0.0.v20080218.jar/
Debug [17] DEBUG 17 [0] 16 : 8 [EMAIL PROTECTED]:
file:org.eclipse.equinox.util_1.0.0.v20080218.jar/
Info [17] BundleEvent STARTED [EMAIL PROTECTED]:
file:org.eclipse.equinox.util_1.0.0.v20080218.jar/
Info [0] FrameworkEvent STARTLEVEL CHANGED System Bundle
==
Is there something wrong with my understanding of the DS or is there a
(timing related) issue
within the DS?
Yours sincerely
Stefan
___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev
___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev
___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev
[attachment atths1rz.dat deleted by Thomas Watson/Austin/IBM]
___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev
inline: graycol.gifinline: ecblank.gif___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev
Re: [equinox-dev] Adding 3rd party jar to Bundle.
A couple of things to check: 1) Does your bundle work when run from your workspace? 2) When you build the bundle can you confirm the lib/TestParser.jar is actually included in your bundle content? 3) Does your bundle manifest file end in an empty line after the Bundle-ClassPath header? If yes to the above questions then I recommend you create a testcase and open a bug for us to investigate. Thanks. Tom From: Srijith Kochunni [EMAIL PROTECTED] To: equinox-dev@eclipse.org Date: 02/25/2008 06:08 AM Subject:[equinox-dev] Adding 3rd party jar to Bundle. Hi All, I am trying to add a 3rd party jar to my bundle. I put it in a lib/ folder and update the manifest file and build properties file as follows. --- MANIFEST.MF Manifest-Version: 1.0 Bundle-ManifestVersion: 2 Bundle-Name: Xparse Plug-in Bundle-SymbolicName: xparse Bundle-Version: 1.0.0 Import-Package: org.osgi.framework;version=1.4.0, org.osgi.util.xml;version=1.0.0 Bundle-Activator: org.osgi.util.xml.XMLParserActivator Bundle-ClassPath: ., lib/TestParser.jar my build.properties file is as follows source.. = src/ output.. = bin/ bin.includes = META-INF/,\ .,\ lib/ When I start my bundle I keep getting a java.lang.ClassNotFoundException when I refer the class within the jar. However if I were to specify the absolute path of the jar file in Bundle-Classpath I get no error, and the bundle starts properly. I`ve searched for any articles regarding this. I found this bug https://bugs.eclipse.org/bugs/show_bug.cgi?id=108781 It contains example code and can`t spot any difference.. Is there something i am missing. ? Or has there been any change regarding this..? Any help would be greatly appreciated.? P.S: Please find attached the entire stack trace. Thanks, Srijith. (See attached file: StackTrace.txt) ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev inline: graycol.gifinline: ecblank.gif StackTrace.txt Description: Binary data ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
Re: [equinox-dev] Implementation for Foreign App Admin.?
The Equinox application container, which is implemented in the org.eclipse.equinox.app bundle, is a container for running Eclipse applications which are defined by the org.eclipse.core.runtime.applications extension point. This application container is not considered a Foreign application container because Eclipse applications are defined in real OSGi bundles and integrate fully into the OSGi environment (e.g. they can have a BundleActivator, export packages, use services etc.). Currently we do not have any examples of a Foreign application container in Equinox. Tom From: Srijith Kochunni [EMAIL PROTECTED] To: equinox-dev@eclipse.org Date: 03/03/2008 02:46 AM Subject:[equinox-dev] Implementation for Foreign App Admin.? Hi All, Is there an equinox implementation for Foreign Application Admin Service as defined in the OSGi specification. I went through the eclipse OSGi downloads section, but could not find anything related. Thanks, Srijith. ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev inline: graycol.gifinline: ecblank.gif___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
[equinox-dev] One more fix released for the I-Build
I released one more bug fix for the I-Build. I released the map just in time to make the I-Build. The map file has been updated for the following Bug changes: + Bug 221339. NPE in VersionConstraintImpl.getName() (FIXED) The following projects have changed: org.eclipse.osgi Tom ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
Re: [equinox-dev] equinox standalone problem
Hi Karl, You are running into bug https://bugs.eclipse.org/bugs/show_bug.cgi?id=215730 With 3.4 M5 you can set the configuration property osgi.framework.activeThreadType=normal to force a non-daemon thread be started so that the VM does not exit when the framework is running. The reason you see it stay up for 30 seconds is because there is a non-daemon thread spinning in the background waiting for a period of inactivity before persisting data. After it persists the data the thread exits and there is no other non-daemon thread alive to keep the VM running. HTH Tom From: Karl Pauls [EMAIL PROTECTED] To: equinox-dev@eclipse.org Date: 03/11/2008 04:04 PM Subject:[equinox-dev] equinox standalone problem Hi, I have a problem running equinox standalone. Basically, what I am trying to do is to run equinox without a console. The set-up is as follows: equinox/ configuration/ config.ini plugins/ equinox jars ../configuration/config.ini osgi.bundles=a set of bundles that use their own none daemon threads eclipse.ignoreApp=true osgi.noShutdown=true java -jar org.eclipse.equinox.launcher_1.0.100.v20080303.jar -noExit The above set-up does shutdown unexpectedly after a couple of seconds (~ 30) on the first startup and immediately on subsequent ones. I tried with all sorts of versions of equinox (including 3.3.2 3.4.M4 nightly, integration) and any combination of -Dosgi.noShutdown=true config.ini/osgi.noShutdown=true and -noExit but to no avail. If I use -console everything works fine. Help would be much appreciated. regards, Karl -- Karl Pauls [EMAIL PROTECTED] ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev inline: graycol.gifinline: ecblank.gif___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
Re: [equinox-dev] equinox standalone problem
Are you certain you are using the Thread.setDaemon(false) method? If you are not then the threads will inherit their daemon status from the invoking thread. If this happens to be one of the daemon framework threads then your bundle threads will be daemon also. One quick way to find out is to run with a console and run the threads command. It will tell you the daemon status of your bundle threads. Tom From: Karl Pauls [EMAIL PROTECTED] To: Equinox development mailing list equinox-dev@eclipse.org Date: 03/11/2008 05:14 PM Subject:Re: [equinox-dev] equinox standalone problem Hi Karl, You are running into bug https://bugs.eclipse.org/bugs/show_bug.cgi?id=215730 :-) With 3.4 M5 you can set the configuration property osgi.framework.activeThreadType=normal to force a non-daemon thread be started so that the VM does not exit when the framework is running. The reason you see it stay up for 30 seconds is because there is a non-daemon thread spinning in the background waiting for a period of inactivity before persisting data. After it persists the data the thread exits and there is no other non-daemon thread alive to keep the VM running. Well, that works but I don't really understand it. As I mentioned in my previous mail, I actually have bundles installed that are creating their own (non-daemon) threads so that should keep the jvm alive, no? Thanks a lot for this workaround! regards, Karl HTH Tom Karl Pauls ---03/11/2008 04:04:49 PM---Hi, From: Karl Pauls [EMAIL PROTECTED] To: equinox-dev@eclipse.org Date: 03/11/2008 04:04 PM Subject: [equinox-dev] equinox standalone problem Hi, I have a problem running equinox standalone. Basically, what I am trying to do is to run equinox without a console. The set-up is as follows: equinox/ configuration/ config.ini plugins/ equinox jars ../configuration/config.ini osgi.bundles=a set of bundles that use their own none daemon threads eclipse.ignoreApp=true osgi.noShutdown=true java -jar org.eclipse.equinox.launcher_1.0.100.v20080303.jar -noExit The above set-up does shutdown unexpectedly after a couple of seconds (~ 30) on the first startup and immediately on subsequent ones. I tried with all sorts of versions of equinox (including 3.3.2 3.4.M4 nightly, integration) and any combination of -Dosgi.noShutdown=true config.ini/osgi.noShutdown=true and -noExit but to no avail. If I use -console everything works fine. Help would be much appreciated. regards, Karl -- Karl Pauls [EMAIL PROTECTED] ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev -- Karl Pauls [EMAIL PROTECTED] ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev inline: graycol.gifinline: ecblank.gif___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
Re: [equinox-dev] Re: Missing doPriv when creating a new URL with a custom handler for internal protocols
Hi Karl, Can you open a bug report against Equinox-Framework about this. This sounds like a bug. Tom From: Karl Pauls [EMAIL PROTECTED] To: Equinox development mailing list equinox-dev@eclipse.org Date: 03/12/2008 06:26 AM Subject:[equinox-dev] Re: Missing doPriv when creating a new URL with a custom handler for internal protocols And another one this time regarding file permission: java.security.AccessControlException: access denied (java.io.FilePermission /Users/pauls/equinox/configuration/org.eclipse.osgi/bundles/1/1/bundlefile read) at java.security.AccessControlContext.checkPermission(AccessControlContext.java:264) at java.security.AccessController.checkPermission(AccessController.java:427) at java.lang.SecurityManager.checkPermission(SecurityManager.java:532) at java.lang.SecurityManager.checkRead(SecurityManager.java:871) at java.io.File.isFile(File.java:745) at org.eclipse.core.runtime.internal.adaptor.EclipseStorageHook.getGeneratedManifest(EclipseStorageHook.java:381) at org.eclipse.core.runtime.internal.adaptor.EclipseStorageHook.createCachedManifest(EclipseStorageHook.java:367) at org.eclipse.core.runtime.internal.adaptor.CachedManifest.getManifest(CachedManifest.java:38) at org.eclipse.core.runtime.internal.adaptor.CachedManifest.get(CachedManifest.java:133) at org.eclipse.osgi.framework.internal.core.ManifestLocalization.getResourceBundle(ManifestLocalization.java:99) at org.eclipse.osgi.framework.internal.core.ManifestLocalization.getHeaders(ManifestLocalization.java:53) at org.eclipse.osgi.framework.internal.core.AbstractBundle.getHeaders(AbstractBundle.java:1020) at org.eclipse.osgi.framework.internal.core.AbstractBundle.getHeaders(AbstractBundle.java:968) am I missing something (I use the PermissionAdmin to give permissions to my bundles and set the default permissions to null). This kind of internal access should be handled by the framework right? regards, Karl On Wed, Mar 12, 2008 at 11:36 AM, Karl Pauls [EMAIL PROTECTED] wrote: Hi, it looks to me like there is a missing doPriv around creating a new URL with a custom handler: java.security.AccessControlException: access denied (java.net.NetPermission specifyStreamHandler) at java.security.AccessControlContext.checkPermission(AccessControlContext.java:264) at java.security.AccessController.checkPermission(AccessController.java:427) at java.lang.SecurityManager.checkPermission(SecurityManager.java:532) at java.net.URL.checkSpecifyHandler(URL.java:629) at java.net.URL.init(URL.java:354) at org.eclipse.osgi.baseadaptor.BaseData.getEntry(BaseData.java:104) at org.eclipse.osgi.internal.baseadaptor.AdaptorUtil.loadManifestFrom(AdaptorUtil.java:192) at org.eclipse.core.runtime.internal.adaptor.EclipseStorageHook.getGeneratedManifest(EclipseStorageHook.java:371) at org.eclipse.core.runtime.internal.adaptor.EclipseStorageHook.createCachedManifest(EclipseStorageHook.java:367) at org.eclipse.core.runtime.internal.adaptor.CachedManifest.getManifest(CachedManifest.java:38) at org.eclipse.core.runtime.internal.adaptor.CachedManifest.get(CachedManifest.java:133) at org.eclipse.osgi.framework.internal.core.ManifestLocalization.getResourceBundle(ManifestLocalization.java:99) at org.eclipse.osgi.framework.internal.core.ManifestLocalization.getHeaders(ManifestLocalization.java:53) at org.eclipse.osgi.framework.internal.core.AbstractBundle.getHeaders(AbstractBundle.java:1020) at org.eclipse.osgi.framework.internal.core.AbstractBundle.getHeaders(AbstractBundle.java:968) the bundle in question has been installed using the config.ini osgi.bundles property hence, looks like: [EMAIL PROTECTED]:/Users/pauls/... Is this a known issue? For now I can work around it by giving my calling bundle the needed permission but I do think this is something the framework should do by creating the urls for its internal protocols in a doPriv, no? regards, Karl -- Karl Pauls [EMAIL PROTECTED] -- Karl Pauls [EMAIL PROTECTED] ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev inline: graycol.gifinline: ecblank.gif___ equinox-dev mailing list equinox-dev@eclipse.org
Re: [equinox-dev] Re: Does equinox support extension:=bootclasspath
The short answer is no and we have no plans to implement it in the current 3.4 release. But there is a bug open https://bugs.eclipse.org/bugs/show_bug.cgi?id=127724 We could consider implementing it in a future release. The struggle we have had with this feature in OSGi is to implement true boot classpath extensions we need to know about the extensions before the VM is even launched. This could be done by modifying the eclipse.ini but the problem with this is that eclipse.ini is not managed by the framework. In 3.4 p2 can now manage this file. One possibility would be to have p2 manage the eclipse.ini to add the proper boot classpath arguments with the bootclasspath extension content. I don't really like this solution either because it involves a dance between p2 and the framework in order to make bootclasspath fragments really work. In other words they will not work in a framework that does not have p2 managing it. Tom From: Alin Dreghiciu [EMAIL PROTECTED] To: equinox-dev@eclipse.org Date: 03/18/2008 08:10 AM Subject:[equinox-dev] Re: Does equinox support extension:=bootclasspath And related: If the answer is no, is there a plan to supported in the future? Thanx again, Alin On Tue, Mar 18, 2008 at 9:04 PM, Alin Dreghiciu [EMAIL PROTECTED] wrote: Hi guys, Does equinox support extension:=bootclasspath? I cannot find a clear reference about the subject, only some mail archive back from 2006. As I see the property org.osgi.supports.bootclasspath.extension is not set (in 3.3.1), so it defaults to false = it does not support. Thanx, Alin Dreghiciu ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev inline: graycol.gifinline: ecblank.gif___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
[equinox-dev] Equinox projects tagged for warm up build
The map file has been updated for the following Bug changes: + Bug 81640. [ErrorHandling] CoreException should provide an easy way to wrap itself (and other wrappers) recursively (FIXED) + Bug 199922. [sec] ILoginContext should simply be an extension of LoginContext (ASSIGNED) + Bug 215828. [sec] JAAS and server-side Eclipse (NEW) + Bug 221862. [sec] add password recovery option (FIXED) + Bug 222874. security bundle should not rely on Runtime (FIXED) + Bug 222891. [sec] Need to provide versions for all public API that is exported (FIXED) + Bug 222971. Restart fails after updating from I20080305-1100 (FIXED) + Bug 223171. Severity sometimes not logged by EclipseLog.writeEntry(int, FrameworkLogEntry) (FIXED) The following projects have changed: org.eclipse.equinox.security.ui org.eclipse.equinox.security org.eclipse.equinox.common org.eclipse.equinox.security.tests org.eclipse.osgi Tom ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
[equinox-dev] Some security classes are moving to internal.provisional packages for M6
We've decided to make a couple of our APIs for working with signed content internal.provisional. Specifically, AuthorizationEngine and related classes in org.eclipse.osgi as well as AuthorizationManager in org.eclipse.equinox.security.ui. The APIs for examining signed content will continue to be public - including SignedContent et al in org.eclipse.osgi, and the mechanism for establishing trust, TrustEngine in org.eclipse.osgi. We currently have no known clients of the API in the security.ui or of the AuthorizationEngine in org.eclipse.osgi. At this point we are not confident enough in the API to make the necessary API contracts required for future releases. Once we have a good prototype of a consumer of AuthorizationEngine/Manager, we will feel more comfortable with establishing a public API for this function. At this point, we don't yet have the confidence to cast the API in stone. For reference, the following classes are now internal.provisional: org.eclipse.osgi.internal.provisional.service.security AuthorizationEngine AuthorizationEvent AuthorizationListener AuthorizationStatus org.eclipse.equinox.internal.provisional.security.ui.actions SecurityContributionItemFactory org.eclipse.equinox.internal.provisional.security.ui.services AuthorizationManager We are not aware of any clients of this API and do not expect this will effect anyone on the Eclipse team. Please let us know if you have code which depends on these classes. Thanks. The Equinox team. ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
[equinox-dev] Equinox projects tagged for next M6 build.
The map file has been updated for the following Bug changes: + Bug 223380. [sec] Login event API needs change (ASSIGNED) + Bug 223945. [sec] Should AuthorizationEngine/AuthorizationManager be internal.provisional ? (FIXED) The following projects have changed: org.eclipse.equinox.security.ui org.eclipse.equinox.security org.eclipse.osgi.tests org.eclipse.osgi org.eclipse.platform.doc.isv Tom ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
[equinox-dev] Equinox projects tagged for the next M6 build
Javadoc only changes. The map file has been updated for the following Bug changes: + Bug 224287. Javadoc errors (FIXED) The following projects have changed: org.eclipse.equinox.security Tom ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
RE: [equinox-dev] Incubator request for Extensions/Services Integration work
+1 I think a component programming model incubator area is a great idea. Tom From: Jeff McAffer [EMAIL PROTECTED] To: 'Equinox development mailing list' equinox-dev@eclipse.org Date: 03/27/2008 12:06 PM Subject:RE: [equinox-dev] Incubator request for Extensions/Services Integration work +1 This fits well with investigations we need to do for e4 as well as the SAT work and some discussions with James Branigan from the Jazz team around stuff they have been doing. Need a pithy name for the workarea. “component programming model” (CPM) perhaps? As Oleg points out, it is really something that is broader than just services and extensions. Jeff From: [EMAIL PROTECTED] [ mailto:[EMAIL PROTECTED] On Behalf Of Chris Aniszczyk Sent: Thursday, March 27, 2008 11:31 AM To: Equinox development mailing list Subject: Re: [equinox-dev] Incubator request for Extensions/Services Integration work +1 also Cheers, --- Chris Aniszczyk | IBM Lotus | Eclipse Committer | http://mea-bloga.blogspot.com | +1.860.839.2465 Inactive hide details for Oleg Besedin ---03/27/2008 10:24:40 AM---+1 from me. If needed, I can help with IPZilla. The area proOleg Besedin ---03 /27/2008 10:24:40 AM---+1 from me. If needed, I can help with IPZilla. The area probably could be created with a more gener From: Oleg Besedin [EMAIL PROTECTED] To: Equinox development mailing list equinox-dev@eclipse.org Date: 03/27/2008 10:24 AM Subject: Re: [equinox-dev] Incubator request for Extensions/Services Integration work +1 from me. If needed, I can help with IPZilla. The area probably could be created with a more general purpose - something like component models investigation? equinox-incubator/component-model/service-injection Thanks, Oleg Neil Bartlett [EMAIL PROTECTED] Sent by: [EMAIL PROTECTED] To rg Equinox development mailing list equinox-dev@eclipse.org cc 03/27/2008 10:53 AM Subject [equinox-dev] Incubator request for Extensions/Services Integration work Please respond to Equinox development mailing list equinox-dev@eclipse.org
Re: [equinox-dev] my confusion for unregistering services in bundle.stop
It is more clear to clean up your service registrations and service listeners in your BundleActivator.stop method. In many cases you want to unregister your listeners and services before you do other clean-up that will invalidate the services/listeners and cause them to behave incorrectly. For example, closing a database connection that backs a service implementation. You should unregister the service before closing the database connection. The extra cleanup the Framework does is really a safeguard to prevent invalid services and listeners from collecting in the Framework. Tom From: Meng Xin Zhu [EMAIL PROTECTED] To: equinox-dev@eclipse.org Cc: Xiang Yu Hao [EMAIL PROTECTED] Date: 03/31/2008 05:17 AM Subject:[equinox-dev] my confusion for unregistering services in bundle.stop I find below description in the OSGi R4 specification section '4.3.6 Activation': stop(BundleContext) – This method must undo all the actions of the BundleActivator.start(BundleContext) method. However, it is unnecessary to unregister services or Framework listeners, because they must be cleaned up by the Framework anyway. Recently I read a post introducing development best practices(it's ibm internal site), it says: While the OSGi Framework will clean up services and service references, it is still good programming practice to clean up what you allocate. If you register services in the start() method, unregister the services in the stop() method. If you create (and open) a ServiceTracker in the start() method, close it in the stop() method. If you start threads or jobs in your start() method, make sure that the threads or jobs are terminated by your stop method. Which practice I would choice when programming OSGi service under Equinox? Thanks Best Regards Zhu Meng Xin IBM Workplace Client Technology Tel: 86-10-82452244-52342 Fax: 86-10-82452887 NOTES: Meng Xin Zhu/China/IBM E-mail: [EMAIL PROTECTED] ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev inline: graycol.gifinline: ecblank.gif___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
[equinox-dev] Equinox projects tagged for the next I-Build.
The map file has been updated for the following Bug changes: + Bug 224432. Memory Leak in install - start - stop - uninistall cycle (FIXED) + Bug 224905. [AAP001] The source issue (FIXED) + Bug 224990. org.eclipse.core.runtime.adaptor.run() covers up all exceptions (FIXED) The following projects have changed: org.eclipse.equinox.security org.eclipse.equinox.app org.eclipse.osgi Tom ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
Re: [equinox-dev] Caused by: org.osgi.framework.BundleException: State change in progress for bundle...by thread OSGi Console
Hi
Lukasz's solution assumes that the bundle you are installing will
eventually enter the RESOLVED state. This is not going to happen
automatically. You would have to run a PackageAdmin.resolveBundles to make
the bundle resolve. The actual exception seems to be occurring because the
second bundle you are installing and starting is trying to start the
original bundle again. Since this is all happening on the same thread the
Framework does not allow the second lifecycle operation proceed because the
thread is already in the process of starting the first bundle.
Tom
From: Lukasz Bobowiec [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Cc: equinox-dev@eclipse.org
Date: 04/04/2008 05:41 AM
Subject:Re: [equinox-dev] Caused by: org.osgi.framework.BundleException:
State change in progress for bundle...by thread
OSGi Console
Hi Jacek,
I think this is some threading issue. First of all remember that in the
start/stop methods of BundleActivator you shouldn't spawn a long running
task (just use a new Thread to do this). In the javadoc to
org.osgi.framework.BundleActivator#start() method is written:
Called when this bundle is started so the Framework can perform the
bundle-specific activities necessary to start this bundle. This method can
be used to register services or to allocate any resources that this bundle
needs.
This method must complete and return to its caller in a timely manner.
Otherwise you can block the OSGi console thread.
I suspect that installing and resolving the Spring bundle may consume some
amount of time and it should be in the start method. Moreover nesting a
start of another bundle in your bundle is not the best idea. I am wondering
if you are using OSGi console and you are able to install and start your
bundle why you don't install and start the spring bundle?
Anyway I think that BundleListener resolves your issue:
package pl.jaceklaskowski.osgi;
import java.util.logging.Level;
import java.util.logging.Logger;
import org.osgi.framework.Bundle;
import org.osgi.framework.BundleActivator;
import org.osgi.framework.BundleContext;
import org.osgi.framework.BundleEvent;
import org.osgi.framework.BundleException;
import org.osgi.framework.BundleListener;
public class AktywatorPakunku implements BundleActivator, BundleListener {
Logger log = Logger.getLogger(AktywatorPakunku.class.getName());
private Bundle bundle;
public void start(BundleContext bundleContext) throws Exception {
// add bundle listener
bundleContext.addBundleListener(this);
bundle = bundleContext.installBundle(
file:c:/projs/osgi/spring-osgi-activationpolicy/target/spring-osgi-activationpolicy-1.0.jar
);
long bundleId = bundle.getBundleId();
String bundleLocation = bundle.getLocation();
String bundleSymbolicName = bundle.getSymbolicName();
System.out.println();
System.out.println(Charakterystyka zainstalowanego pakunku:);
System.out.println( Identyfikator: + bundleId);
System.out.println( Identyfikator położenia: + bundleLocation);
System.out.println( Nazwa symboliczna: + bundleSymbolicName);
System.out.println();
}
public void stop(BundleContext bundleContext) throws Exception {
// remove bundle listener
bundleContext.removeBundleListener(this);
log.info(stop() wykonano - czyszczę po sobie);
}
public void bundleChanged(BundleEvent event) {
if (event.getType() == Bundle.RESOLVED event.getBundle()
== bundle) {
try {
Re: [equinox-dev] The RCP-delta feature
Hi Thomas, Are you wanting a feature to install the RCP-delta packs or a feature that contains only the launchers? The launchers for the various platforms are available from the equinox download page at http://download.eclipse.org/eclipse/equinox/drops/S-3.4 M6-200803301350/index.php But I think the launcher zips suffer from the same issues you have about the RCP-delta pack zip available on the Eclipse SDK download page. What is the recommended work flow in p2 to get the RCP-delta pack installed into your target? Seems like we would need an update site for the delta pack if we want a clean way to provision it with p2. Tom From: Thomas Hallgren [EMAIL PROTECTED] To: Equinox development mailing list equinox-dev@eclipse.org Date: 04/03/2008 04:48 AM Subject:[equinox-dev] The RCP-delta feature Hi, I was trying to find the org.eclipse.equinox.executable feature on an update site at Eclipse.org but failed. Do I miss something here or is the only way to install the RCP-delta feature to download the zip and unpack it on top of an existing platform? Using a Buckminster build it would be great if it could be treated just like any other installable feature. Regards, Thomas Hallgren ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev inline: graycol.gifinline: ecblank.gif___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
Re: [equinox-dev] [p2] plug-in versions
My 2 cents ... For Ganymede the plan is to have 1.0 p2 functionality. This should not imply that we will have p2 1.0 API. I imagine for the first release of p2 we are going to have lots of bundles start to use the internal.provisional APIs because there is no public API available and they will have to resort to using the internal.provisional APIs. I suggest we release with all p2 bundle versions as 1.0. When we graduate to real API for p2 then the bundles can be increased to 2.0. This way we can recommend a version range of [1.0, 2.0) for early adopters use internal.provisional API. In a future release when p2 does include real API then the early adopters will be able to clearly see which bundles graduated real API. I suppose the same can be done with 0.1.0 versions with a range of [0.1.0, 1.0) and [1.0, 2.0) after the real API is introduced. But a bundle version of 0.1.0 does not give the impression that p2 is releasing 1.0 functionality in Ganymede. Tom From: John Arthorne [EMAIL PROTECTED] To: Equinox development mailing list equinox-dev@eclipse.org Date: 04/14/2008 07:31 AM Subject:Re: [equinox-dev] [p2] plug-in versions I don't think we ever decided on this. The thinking was that since no API was being declared, we might leave the plug-ins with a number 1.0 and then move to 1.0 in the first release that contains real API (likely 3.5). Typically the initial API of a plug-in appears in version 1.0 of the plug-in. Chris Aniszczyk [EMAIL PROTECTED] Sent by: [EMAIL PROTECTED]To Equinox development mailing list equinox-dev@eclipse.org 04/10/2008 07:23 PMcc Subject Please respond to [equinox-dev] [p2] plug-in Equinox development mailing list versions equinox-dev@eclipse.org I noticed that all of p2 plug-ins are currently 0.10.qualifier... shouldn't this be 1.0.0.qualifier since these have been graduated and will be included in the SDK for 3.4? I ask this as I'm trying to straighten out some plug-in dependency ranges in PDE. Cheers, --- Chris Aniszczyk | IBM Lotus | Eclipse Committer | http://mea-bloga.blogspot.com | +1.860.839.2465 ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev inline: graycol.gifinline: ecblank.gif___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
[equinox-dev] Equinox projects tagged for the I-Build
The map file has been updated for the following Bug changes:
+ Bug 194943. Europa Crashes During Startup (FIXED)
+ Bug 217351. [prov] What is the install location in a p2 context
(ASSIGNED)
+ Bug 221581. Inconsistent handling of {ee.home} in EE files (FIXED)
+ Bug 223089. [sec] Do we need -password, -keyring (FIXED)
+ Bug 225090. Need cleanup of temporary files after browsing sites (FIXED)
+ Bug 225386. [sec] Javadoc gotchas (FIXED)
+ Bug 225891. Deadlock due to synchronization in the
org.eclipse.equinox.log bundle's Activator's stop(BundleContext) method
(FIXED)
+ Bug 225899. org.eclipse.equinox.log - JavaDoc errors (FIXED)
+ Bug 225907. [DS] Unexpected component deactivation-activation when
creating new Configuration (FIXED)
+ Bug 226048. [sec] Add progress monitor to long-runing secure storage
operations (FIXED)
+ Bug 226053. eclipse -console /dev/null prints infinite loop (FIXED)
+ Bug 226576. [sec] messages params are reversed for missing files in a
signed jar (FIXED)
+ Bug 226579. [sec] Array out of bounds in Base64 (FIXED)
+ Bug 226591. [sec] Change and recover password should be specific to a
password provider (FIXED)
+ Bug 226615. CCE in catch Throwable (FIXED)
+ Bug 226716. [sec] Allow user to disable password providers (FIXED)
+ Bug 226744. [sec] Polish password recovery dialog (FIXED)
+ Bug 226754. [sec] Confirm overwrite of the secure storage file (FIXED)
+ Bug 226991. [sec] password verification - make it rule-based (FIXED)
+ Bug 227034. [sec] secure storage dialogs: shells and syncExecs (FIXED)
The following projects have changed:
org.eclipse.equinox.launcher.win32.win32.ia64
org.eclipse.equinox.launcher.carbon.macosx
org.eclipse.equinox.launcher.win32.win32.x86_64
org.eclipse.equinox.launcher.gtk.linux.ppc
org.eclipse.equinox.launcher.motif.linux.x86
org.eclipse.equinox.security.tests
org.eclipse.osgi.tests
org.eclipse.osgi
org.eclipse.equinox.launcher.gtk.linux.x86_64
org.eclipse.equinox.security.ui
org.eclipse.equinox.launcher.motif.hpux.ia64_32
org.eclipse.equinox.security
org.eclipse.equinox.ds
org.eclipse.equinox.launcher.wpf.win32.x86
org.eclipse.equinox.launcher
org.eclipse.equinox.log
org.eclipse.equinox.launcher.win32.win32.x86
org.eclipse.equinox.launcher.gtk.solaris.sparc
org.eclipse.equinox.executable
org.eclipse.equinox.supplement
org.eclipse.equinox.launcher.motif.aix.ppc
org.eclipse.equinox.launcher.gtk.linux.x86
org.eclipse.equinox.util
Tom
___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev
Re: [equinox-dev] SCR debug output
Stoyan, Please open a bug to remind us to document any configuration system properties that are available for DS as well as the other bundles your team has contributed (IO, IP, WireAdmin etc.). Thanks. Tom From: Stoyan Boshev [EMAIL PROTECTED] To: equinox-dev@eclipse.org Date: 04/15/2008 02:36 AM Subject:Re: [equinox-dev] SCR debug output Hi Michael, You can use these boolean system properties: equinox.ds.debug - Turns on/off debugging of SCR equinox.ds.print - Specifies that logged entries should be printed to the framework runtime console equinox.ds.perf - Enables generating and printing logs about the time performance of the operations executed by the SCR (Useful when the user is interested in the time that is spent in the bind, activate, deactivate methods of his components) I would recommend you to use both equinox.ds.debug and equinox.ds.print properties set to true because you will see the debug messages printed in the console. If you turn on only the equinox.ds.debug property, the debug messages will be sent only to the LogService if available. Stoyan - Original Message - From: Michael Furtak To: equinox-dev@eclipse.org Sent: Monday, April 14, 2008 9:03 PM Subject: [equinox-dev] SCR debug output Hi, I frequently find myself in a position of trying to debug why my declarative services are not running. Is there debug output from the SCR that I could be taking advantage of to help this process? If so, what combination of bundles and settings are required to see it? Thanks, -Mike Furtak THIS MESSAGE IS INTENDED FOR THE USE OF THE PERSON TO WHOM IT IS ADDRESSED. IT MAY CONTAIN INFORMATION THAT IS PRIVILEGED, CONFIDENTIAL AND EXEMPT FROM DISCLOSURE UNDER APPLICABLE LAW. If you are not the intended recipient, your use of this message for any purpose is strictly prohibited. If you have received this communication in error, please delete the message and notify the sender so that we may correct our records. __ NOD32 3025 (20080414) Information __ This message was checked by NOD32 antivirus system. http://www.eset.com ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev __ NOD32 3025 (20080414) Information __ This message was checked by NOD32 antivirus system. http://www.eset.com___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev inline: graycol.gifinline: ecblank.gif___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
Re: [equinox-dev] Providing a callback to an OSGi bundle
The eclipse buddy policies have a number of issues. For example, when multiple versions of bundles exist it is random which version your buddy will be. Also if multiple versions of a package exist in the framework there is a potential for class space inconsistencies. Supporting legacy code and defining a concise modular framework do not always go hand in hand. Many folks in OSGi like to call these kinds of features in eclipse as legacy hacks. To a certain extent I can agree, but at this point no one has come up with a better solution that requires *no* change to the legacy code to make it work in an OSGi modular environment. In OSGi we would like to spec some solution to to help support legacy code that uses Class.forName and the context class loader in OSGi to find extensions. For many cases buddy class loading works nicely, but at this point the buddy class loading mechanism has too many limitations to be considered for the OSGi specification. Tom From: Saminda Abeyruwan [EMAIL PROTECTED] To: Equinox development mailing list equinox-dev@eclipse.org Date: 04/17/2008 11:36 AM Subject:Re: [equinox-dev] Providing a callback to an OSGi bundle Dear Tom, Thank you for the swift reply. What you have suggested solved the entire problem. I used Eclipse-BuddyPolicy, and Eclipse-RegisterBuddy bundle manifest headers to get more control over wiring buddies. I was wondering is there a provision to standardize these bundle manifest headers in future OSGi specification. IMO this would be a very important extension to have in OSGi spec. Thank you! Saminda On Thu, Apr 17, 2008 at 7:02 PM, Thomas Watson [EMAIL PROTECTED] wrote: How do you know the Bundle where the configuration file is and how do you read it from Bundle B? I assume you must be getting the Bundle object for B somehow and using Bundle.getEntry to find the configuration file. If that is the case you can just call Bundle.loadClass(String name) on the bundle that has the configuration file. But we must be missing something from your scenario because you say you are working with existing code that I assume knows nothing about OSGi, otherwise you would use services like you said. For legacy code that needs access to implementation class from other bundles that depend on it you can use the eclipse buddy class loading mechanism. Adding the following header to Bundle A's manifest will allow Bundle B (and any other bundle that depends on A) to become a buddy to Bundle A. Eclipse-BuddyPolicy: dependent Tom Inactive hide details for Saminda Abeyruwan ---04/17/2008 04:27:46 AM---Hi Devs,Saminda Abeyruwan ---04/17/2008 04:27:46 AM---Hi Devs, From: Saminda Abeyruwan [EMAIL PROTECTED] To:equinox-dev@eclipse.org Date: 04/17/2008 04:27 AM Subject: [equinox-dev] Providing a callback to an OSGi bundle Hi Devs, I have faced with a use-case where a callback need to be passed to an OSGi bundle. Scenario: Bundle A exports package x.y and a.b. These are the only packages it exports. The logic of this bundle is such that it can populate a callback, when some function is finished. Say this callback should implement interface x.y.Foo. Required callbacks are written in a configuration file, and which will be located using OSGi infrastructure. There exist another bundle B, which has classes that implemented the interface x.y.Foo say x.y.K.FooImpl1 and that bundle also contains the configuration file listing the QName of the impl classes. This bundle imports package x.y. When bundle A reads the configuration files from bundle B and tries to initiate the impl classes, bundle A would failed with class definition not found exception stating that it can't locate the implementation
[equinox-dev] tagging equinox for M7 warmup build Sunday AM
I am going to tag the Equinox projects (everything but p2) on Sunday morning for the M7 warmup build. See http://www.eclipse.org/eclipse/platform-releng/buildSchedule.html for the build schedule. If you release things after I tag then you will have to retag before the Sunday build. Tom ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
RE: [equinox-dev] New version of Equinox quits upon bundle error
More information is needed on how you are launching Equinox, including what bundles you are using and what config.ini options etc. Also, what version of Eclipse you are migrating from where your application worked. Lets move this discussion into a bug report. If you have an application that used to work in 3.2-3.3 and now does not work in 3.4 then that is the bug you should open with a description of how to reproduce or even better would be a testcase for us to reproduce. I would open that bug against Equinox-Bundles In 3.3 we split the application container out of org.eclipse.core.runtime into org.eclipse.equinox.app. You must include the org.eclipse.equinox.app bundle in your configuration to use the Eclipse application container. Hope we can help you out. Tom From: David Leangen [EMAIL PROTECTED] To: Equinox development mailing list equinox-dev@eclipse.org Date: 05/01/2008 09:06 AM Subject:RE: [equinox-dev] New version of Equinox quits upon bundle error Thank you, Tom, What would the bug be, then? Running in console requires org.eclipse.equinox.core.runtime? It is my understanding that only the osgi package should be required. BTW, when I add the -noExit option, I get an error (Unrecognized option). Is that really a valid option? Regards, David -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Thomas Watson Sent: 1 May 2008 22:17 To: Equinox development mailing list Subject: Re: [equinox-dev] New version of Equinox quits upon bundle error Please open a bug if you think you have found a regression. In the bug report please give steps to reproduce. Thanks. If you launch with the option command line option -noExit that should help keep the framework running when the application fails. Tom David Leangen ---05/01/2008 02:30:03 AM---Hello! From: David Leangen [EMAIL PROTECTED] To: equinox-dev@eclipse.org Date: 05/01/2008 02:30 AM Subject: [equinox-dev] New version of Equinox quits upon bundle error Hello! I recently updated to 3.4M6, which IIUC is the most recent release. I run my apps in the Eclipse console because it is great for debugging. However, with this version, when one of my bundles has an error, everything shuts down with a message The Application could not start How can I get the console to work like before and just run with the erroneous bundles in a RESOLVED state so I can debug the problems? BTW, the error logs are complaining that I need org.eclipse.equinox.core.runtime installed. I don't mind installing one bundle, but that bundle has lots of dependencies that I don't want. I never needed this before... so what's changed? Thank you! David ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev inline: graycol.gifinline: ecblank.gif___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
[equinox-dev] Equinox projects tagged for the build.
The map file has been updated for the following Bug changes: + Bug 229704. DefaultAuthorizationEngine should include version information in the property file (FIXED) + Bug 229799. Secure Storage recover prompt should be Yes/No (FIXED) + Bug 230204. [launcher] Info.plist contains Eclipse 3.3 (FIXED) The following projects have changed: org.eclipse.equinox.security.ui org.eclipse.equinox.executable org.eclipse.osgi Tom ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
[equinox-dev] Equinox projects tagged for next RC1 build.
The map file has been updated for the following Bug changes: + Bug 230421. [registry] Translation not found when nl pack installed through dropins (FIXED) The following projects have changed: org.eclipse.equinox.registry org.eclipse.osgi Tom ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
[equinox-dev] Equinox submission for I20080508-2000
The map file has been updated for the following Bug changes: + Bug 144995. UserAdminHashtable - Discrepancy Between In Memory Data and Data Stored to Disk When Using byte[] (FIXED) + Bug 227293. [sec] Polish UI (ASSIGNED) + Bug 229833. Password recovery option prompt question confusing (FIXED) + Bug 230867. Transforms hook is missing about.html in build.properties (FIXED) + Bug 230966. Transforms may fail when more than one bundles contributes various transform types (FIXED) The following projects have changed: org.eclipse.equinox.security.ui org.eclipse.equinox.useradmin org.eclipse.equinox.transforms.hook Tom ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
Re: [equinox-dev] Bundle start hangs
Are the bundles in the STARTING state using a lazy activation policy? The bundle would have an Eclipse-LazyStart or Bundle-ActivationPolicy manifest header. When a bundle uses a lazy activation policy it will wait in the STARTING state for the first class to be loaded out of it (the so called trigger class). Once the trigger class is loaded the bundle transition into the ACTIVE state. Tom From: Saminda Abeyruwan [EMAIL PROTECTED] To: equinox-dev@eclipse.org Date: 05/09/2008 06:12 AM Subject:[equinox-dev] Bundle start hangs Hi Devs, I use config.ini and launch.ini files to configure the Equinox environment. I have listed all the bundles with proper start level in config.ini. I also org.eclipse.update.configurator_3.2.100.v20070322.jar. When some bundles being added in config.ini, the prior bundle will be in STARTING level. Is there any way I could debug, why this happens. Thank you! Saminda -- Saminda Abeyruwan Senior Software Engineer WSO2 Inc. - www.wso2.org ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev inline: graycol.gifinline: ecblank.gif___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
[equinox-dev] Equinox Contribution
The map file has been updated for the following Bug changes: + Bug 231468. chkpii errors in I20080510-2000 (FIXED) + Bug 231588. [sec] Warning for plugin.xml translation (FIXED) + Bug 231631. [sec] Add description of runtime exceptions to Javadoc (FIXED) The following projects have changed: org.eclipse.equinox.security.ui org.eclipse.equinox.security Tom ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
[equinox-dev] Equinox build submission
The map file has been updated for the following Bug changes: + Bug 214116. [sec] Selectively display default security UI preference pages (FIXED) + Bug 229701. Authorization page should default to signed/unsigned for policy (FIXED) + Bug 231774. Wording for UI prompt (FIXED) The following projects have changed: org.eclipse.equinox.security.ui Tom ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
[equinox-dev] Equinox contribution
The map file has been updated for the following Bug changes: + Bug 232146. org.eclipse.equinox.security.ui contains an invalid item in Require-Bundle (FIXED) + Bug 232151. I20080513-2000 Linux Motif doesn't start (FIXED) The following projects have changed: org.eclipse.equinox.security.ui org.eclipse.equinox.launcher.motif.linux.x86 Tom ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
[equinox-dev] Equinox contributing to rebuild
The map file has been updated for the following Bug changes: + Bug 230421. [registry] Translation not found when nl pack installed through dropins (ASSIGNED) The following projects have changed: org.eclipse.equinox.registry Tom ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
[equinox-dev] Equinox contribution
The map file has been updated for the following Bug changes: + Bug 232636. Locale.setDefault(Locale.ROOT) crashes the framework startup (FIXED) + Bug 232736. Secure storage preference page should use dialog font (FIXED) + Bug 232861. Authorization engine filter incorrectly uses trust.engine service property (FIXED) + Bug 232866. Activator uses Security.getProperty for osgi.signedcontent.* service props? (FIXED) The following projects have changed: org.eclipse.equinox.security.ui org.eclipse.osgi Tom ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
Re: [equinox-dev] Equinox lazy bundle start and deadlocks
The deadlock you describe sounds similar to the issues we were dealing with in bug https://bugs.eclipse.org/bugs/show_bug.cgi?id=199103 and https://bugs.eclipse.org/bugs/show_bug.cgi?id=186280. Both of these bugs have been addressed in 3.4. What version of Declarative Services are you using? Is it the latest graduated implementation from Equinox? Can you try 3.4? To answer your second question we need more information on the set of eclipse bundles you need for your application. Tom From: Jan Stette [EMAIL PROTECTED] To: Equinox development mailing list equinox-dev@eclipse.org Date: 05/21/2008 07:19 AM Subject:[equinox-dev] Equinox lazy bundle start and deadlocks I'm seeing some deadlock problems with Equinox lazy bundle starting, much as described at http://wiki.eclipse.org/Lazy_Start_Bundles. This page suggests that these were only occurring in 3.2, but I'm running with Equinox 3.3. What is the status of resolving these issues? I should mention as well that I'm using Declarative Services, and that this is involved in the deadlocks I've seen so far. The problems relate to the declarative services code being registered as a bundle listener hence getting callbacks when bundles are lazily started. It then synchronously proceeds to read component specifications and activating services (hence calling out into client code). Having all this happening synchronously on a callback essentially sourced from within a classloader seems like a recipe for problems! I'm working on a server-side application so I actually don't care about lazy start at all. So to work around the problem, I tried disabling the EclipseLazyStarter hook using the osgi.hook.configurators.exclude system property. This caused problems when starting some Equinox bundles that would look for services that hadn't been registered. Presumably because the bundles providing these services depend on being started via the lazy start mechanism. I then tried working around this by ensuring I listed all necessary bundles in my config.ini with the right start level, but I found it difficult to come up with a working configuration here. Does anyone have any other suggestions for how I can run Equinox with lazy start disabled? Regards, Jan ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev inline: graycol.gifinline: ecblank.gif___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
Re: [equinox-dev] Equinox lazy bundle start and deadlocks
I'm not sure why you cannot just activate every bundle at launch if you don't care about lazy activation. Is that what you tried to do but it failed? A testcase would really help here. You mention lots of locks below but I'm not sure if these are class loader locks established by the vm or framework locks associated with Bundle lifecycles or DS impl locks. I suggest you open a bug against Equinox-Framework to track dead lock issues you are seeing with lazy activation. If class loading locks are causing the issue then I suspect you are running into a flavor of https://bugs.eclipse.org/bugs/show_bug.cgi?id=121737. Locking the class loader at the VM level is blocked by a long standing Sun http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4670071. It would be interesting to know if the VM args mentioned at https://bugs.eclipse.org/bugs/show_bug.cgi?id=121737#c8 help solve your problem. Tom From: Jan Stette [EMAIL PROTECTED] To: Equinox development mailing list equinox-dev@eclipse.org Date: 05/21/2008 08:09 AM Subject:Re: [equinox-dev] Equinox lazy bundle start and deadlocks I'm running with a fairly recent version of the ProSyst DS. I don't think this deadlock is the same as the ones in the bugs you mention though (we saw those earlier before we got patches for those). Specifically, those bugs don't involve lazy bundle starting. It seems to me that there's an inherent problem with the lazy bundle starting. What we're seeing is that one thread goes through the steps: Bundle is activated - DS is notified, gets lock - enters class loader as part of activating a service, gets lock. Whereas a second thread does: Enters class loader, gets lock - bundle is lazily loaded - DS is notified, gets lock. So in one thread, a lock in DS is held before the classloader lock is acquired, in the other thread the classloader lock is held then it calls out to DS which will acquire a lock. Maybe it would be possible to work around this specific case by juggling locks inside the DS implementation. But it just seems to me that it would be very difficult to guard against future errors along this line. Basically, the lazy bundle loading means that any innocent-looking line of code like: Widget = new Widget(); anywhere in my code can cause a very long chain of synchronous events including calling back out to my code through bundle and service listener interfaces. Ensuring that locking is correct in all situations seems completely impossible, so I'd much rather just turn lazy loading off. Any suggestions for what is the best way to do this? Regards, Jan 2008/5/21 Thomas Watson [EMAIL PROTECTED]: The deadlock you describe sounds similar to the issues we were dealing with in bug https://bugs.eclipse.org/bugs/show_bug.cgi?id=199103 and https://bugs.eclipse.org/bugs/show_bug.cgi?id=186280. Both of these bugs have been addressed in 3.4. What version of Declarative Services are you using? Is it the latest graduated implementation from Equinox? Can you try 3.4? To answer your second question we need more information on the set of eclipse bundles you need for your application. Tom Inactive hide details for Jan Stette ---05/21/2008 07:19:46 AM---I'm seeing some deadlock problems with Equinox lazy bundle sJan Stette ---05/21/2008 07:19:46 AM---I'm seeing some deadlock problems with Equinox lazy bundle starting, much as described at From:Jan Stette [EMAIL PROTECTED] To: Equinox development mailing list equinox-dev@eclipse.org Date:05/21/2008 07:19 AM Subject: [equinox-dev] Equinox lazy bundle start and deadlocks I'm seeing some deadlock problems with Equinox lazy bundle starting, much as described at http
[equinox-dev] Equinox Contribution
The map file has been updated for the following Bug changes: + Bug 232159. Can't access update site with 3.4.0 I20080502-0100 (FIXED) The following projects have changed: org.eclipse.osgi Tom ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
[equinox-dev] Equinox intends to contribute to RC3
The map file has been updated for the following Bug changes: + Bug 234439. The -debug flag no longer produces information about plugin resolution (ASSIGNED) The following projects have changed: org.eclipse.osgi Tom ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
