[jira] [Created] (FELIX-6586) Invalid startlevel ordering when startlevels are changed in Bundle Activator
Peter Kriens created FELIX-6586:
---
Summary: Invalid startlevel ordering when startlevels are changed
in Bundle Activator
Key: FELIX-6586
URL: https://issues.apache.org/jira/browse/FELIX-6586
Project: Felix
Issue Type: Bug
Components: Framework
Affects Versions: framework-6.0.2
Reporter: Peter Kriens
When a bundle A's activator modifies the start level of a bundle B that has an
adjacent startlevel to a higher level, then the FrameworkStartLevelImpl class
will still try to start the bundle B and this will throw an error because B's
startlevel is now higher than the current start level.
Example.
# startlevel(A) == 10, startlevel(B)=11.
# A.start sets startlevel(B)==30
# Framework Error thrown that B cannot be started
{code:java}
ERROR: Bundle
qivicon.felix.TestStartLevels.testFailingToSetStartLevelBecauseChanged-2 [2]
Error starting
{qivicon.felix.TestStartLevels.testFailingToSetStartLevelBecauseChanged-2={}}-0
(org.osgi.framework.BundleException: Cannot start bundle
qivicon.felix.TestStartLevels.testFailingToSetStartLevelBecauseChanged-2 [2]
because its start level is 30, which is greater than the framework's start
level of 11.)
org.osgi.framework.BundleException: Cannot start bundle
qivicon.felix.TestStartLevels.testFailingToSetStartLevelBecauseChanged-2 [2]
because its start level is 30, which is greater than the framework's start
level of 11.
at org.apache.felix.framework.Felix.startBundle(Felix.java:2175)
at org.apache.felix.framework.Felix.setActiveStartLevel(Felix.java:1539)
at
org.apache.felix.framework.FrameworkStartLevelImpl.run(FrameworkStartLevelImpl.java:308)
at java.lang.Thread.run(Thread.java:750){code}
The framework will start bundle B in the end after some delay.
The error does not occur if the startlevel(B) is not adjacent. For example, if
it is set to 12, then the error will no occur.
The following is the test code that I used to verify the bug:
{code:java}
package qivicon.felix;
import static org.assertj.core.api.Assertions.assertThat;
import java.util.concurrent.Semaphore;
import org.junit.Test;
import org.osgi.framework.Bundle;
import org.osgi.framework.BundleActivator;
import org.osgi.framework.BundleContext;
import org.osgi.framework.BundleException;
import org.osgi.framework.FrameworkEvent;
import org.osgi.framework.launch.Framework;
import org.osgi.framework.startlevel.BundleStartLevel;
import org.osgi.framework.startlevel.FrameworkStartLevel;
import aQute.launchpad.Launchpad;
import aQute.launchpad.LaunchpadBuilder;
public class TestStartLevels {
final static LaunchpadBuilder builder = new
LaunchpadBuilder().runfw("org.apache.felix.framework")
.set("felix.log.level ", "4");
private BundleContext context;
public static class ChangeSL implements BundleActivator{
@Override
public void start(BundleContext context) throws Exception {
System.out.println("In BundleActivator.start: Changing start level
of bundles with sl=11 to sl=30");
for ( Bundle b : context.getBundles()) {
BundleStartLevel sl = b.adapt(BundleStartLevel.class);
int startLevel = sl.getStartLevel();
if ( startLevel == 11)
sl.setStartLevel(30);
}
}
@Override
public void stop(BundleContext context) throws Exception {
// TODO Auto-generated method stub
}
}
@Test
public void testFailingToSetStartLevelBecauseChanged() throws Exception {
try (Launchpad lp = builder.nostart().create()) {
context = lp.getFramework().getBundleContext();
context.addFrameworkListener(fe -> event(fe, "for errors"));
Bundle changer =
lp.bundle().bundleActivator(ChangeSL.class).start();
Bundle victim = lp.bundle().start();
setStartLevel(changer, 10);
setStartLevel(victim, 11);
Framework framework = lp.getFramework();
FrameworkStartLevel fsl =
framework.adapt(FrameworkStartLevel.class);
fsl.setStartLevel(1, fe -> event(fe, "setting FW startLevel=1"));
System.out.println("starting framework up to level 1");
lp.start();
Semaphore s = new Semaphore(0);
System.out.println("reached 1, setting fw startlevel to 1000");
fsl.setStartLevel(1000, fe -> {
s.release();
event(fe, "reached startlevel 1000");
});
s.acquire();
System.out.print("the bundle is actually not started immediately: "
);
bundle(victim);
assertThat(victim.getState()).isNotEqualTo(B
[jira] [Created] (FELIX-6543) Skip non-config files in Dictionary enumeration
Peter Kriens created FELIX-6543: --- Summary: Skip non-config files in Dictionary enumeration Key: FELIX-6543 URL: https://issues.apache.org/jira/browse/FELIX-6543 Project: Felix Issue Type: Improvement Components: Configuration Admin Reporter: Peter Kriens Configuration Admin enumerates a directory to find existing configuration files. This enumeration skips temporary files but it does not check of the file is actually a configuration file. I can create a PR that changes line [https://github.com/apache/felix-dev/blob/eb99876e44791648939cb0fc7fdee22f00ed27b8/configadmin/src/main/java/org/apache/felix/cm/file/FilePersistenceManager.java#L884] so that only files with the .config extension are enumerated. This is problematic for a customer since they might have alternative files in this directory. Although this might not be the best practice, some file systems add files, like Apple adds a `.DS_Store` file and sometimes you a .gitignore in testing directories. Also, the current code can as far as I know not create any but ending in `.config` so enumerating other files is fragile. Would such a PR be acceptable in principle? -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Created] (FELIX-6377) Configuration Admin depends on Log
Peter Kriens created FELIX-6377: --- Summary: Configuration Admin depends on Log Key: FELIX-6377 URL: https://issues.apache.org/jira/browse/FELIX-6377 Project: Felix Issue Type: Improvement Components: Configuration Admin Affects Versions: configadmin-1.9.20 Reporter: Peter Kriens Configuration Admin has an optional dependency on the Log Service but in reality it does not start without one. It should either declare this requirement mandatory or work without a log service. -- This message was sent by Atlassian Jira (v8.3.4#803005)
Re: [VOTE] Apache Felix SCR 2.1.24 release
+1 > On 17 Sep 2020, at 10:58, Jean-Baptiste Onofre wrote: > > Hi guys, > > As discussed on the mailing list, I submit Apache Felix SCR 2.1.24 release to > your vote. > This release avoid the requirement to log service, potential > NoSuchElementException when services are removed, and fix factory component > eager deactivation. > > Release Notes: > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310100&version=12348738 > > Staging Repository: > https://repository.apache.org/content/repositories/orgapachefelix-1348/ > > Staging Dist: > https://dist.apache.org/repos/dist/dev/felix/scr/2.1.24/ > > Git tag: > org.apache.felix.scr-2.1.24 > > Please vote to approve this release: > > [ ] +1 Approve the release > [ ] -1 Don't approve the release (please provide specific comments) > > This vote will be open for at least 72 hours. > > Thanks, > Regards > JB >
Re: [VOTE] Apache Felix SCR 2.1.21 release
+1 Peter Kriens > On 30 Aug 2020, at 20:45, Jean-Baptiste Onofre wrote: > > Hi guys, > > As discussed on the mailing list, I submit Apache Felix SCR 2.1.21 release to > your vote. > > Release Notes: > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310100&version=12348094 > > <https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310100&version=12348094> > > Staging Repository: > https://repository.apache.org/content/repositories/orgapachefelix-1345/ > <https://repository.apache.org/content/repositories/orgapachefelix-1345/> > > Staging Dist: > https://dist.apache.org/repos/dist/dev/felix/scr/2.1.21/ > <https://dist.apache.org/repos/dist/dev/felix/scr/2.1.21/> > > Git tag: > org.apache.felix.scr-2.1.21 > > Please vote to approve this release: > > [ ] +1 Approve the release > [ ] -1 Don't approve the release (please provide specific comments) > > This vote will be open for at least 72 hours. > > Thanks, > Regards > JB
[jira] [Commented] (FELIX-6322) Unable to read persisted state from state.ser
[
https://issues.apache.org/jira/browse/FELIX-6322?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17183323#comment-17183323
]
Peter Kriens commented on FELIX-6322:
-
I changed to major because this creates ERRORs in the log.
> Unable to read persisted state from state.ser
> -
>
> Key: FELIX-6322
> URL: https://issues.apache.org/jira/browse/FELIX-6322
> Project: Felix
> Issue Type: Bug
> Components: Configurator
>Affects Versions: configurator-1.0.12
>Reporter: Amit Mondal
>Priority: Major
>
> The following exception occurs in runtime if we update the configurator from
> v1.0.10 to v1.0.12:
> {code:java}
> java.io.StreamCorruptedException: unexpected block data
> at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1641)
> at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:2341)
> at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:2221)
> at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:2123)
> at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1624)
> at java.io.ObjectInputStream.readObject(ObjectInputStream.java:464)
> at java.io.ObjectInputStream.readObject(ObjectInputStream.java:422)
> at
> org.apache.felix.configurator.impl.model.State.createOrReadState(State.java:87)
> at
> org.apache.felix.configurator.impl.Configurator.(Configurator.java:91)
> at
> org.apache.felix.configurator.impl.ServicesListener.notifyChange(ServicesListener.java:113)
> at
> org.apache.felix.configurator.impl.ServicesListener$1.addingService(ServicesListener.java:73)
> at
> org.apache.felix.configurator.impl.ServicesListener$1.addingService(ServicesListener.java:65)
> at
> org.osgi.util.tracker.ServiceTracker$Tracked.customizerAdding(ServiceTracker.java:943)
> at
> org.osgi.util.tracker.ServiceTracker$Tracked.customizerAdding(ServiceTracker.java:871)
> at
> org.osgi.util.tracker.AbstractTracked.trackAdding(AbstractTracked.java:256)
> at
> org.osgi.util.tracker.AbstractTracked.trackInitial(AbstractTracked.java:183)
> at org.osgi.util.tracker.ServiceTracker.open(ServiceTracker.java:321)
> at org.osgi.util.tracker.ServiceTracker.open(ServiceTracker.java:264)
> at
> org.apache.felix.configurator.impl.ServicesListener.(ServicesListener.java:93)
> at org.apache.felix.configurator.impl.Activator.start(Activator.java:36)
> at
> org.apache.felix.framework.util.SecureAction.startActivator(SecureAction.java:698)
> at org.apache.felix.framework.Felix.activateBundle(Felix.java:2402)
> at org.apache.felix.framework.Felix.startBundle(Felix.java:2308)
> at org.apache.felix.framework.BundleImpl.start(BundleImpl.java:998)
> at org.apache.felix.framework.BundleImpl.start(BundleImpl.java:984){code}
> I had looked into it and found that the problem probably lies in the serial
> version number of _*OrderedDictionary*_ which is part of
> _*org.apache.felix.cm.json*_ and was never required for Configurator
> v1.0.10.
> I have compared the hexdumps of both the _*state.ser*_ files and the files
> started to differ in _*OrderedDictionary.*_
> The exception doesn't harm since if the previous state cannot be read
> properly, a new state gets created.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (FELIX-6322) Unable to read persisted state from state.ser
[
https://issues.apache.org/jira/browse/FELIX-6322?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Peter Kriens updated FELIX-6322:
Priority: Major (was: Minor)
> Unable to read persisted state from state.ser
> -
>
> Key: FELIX-6322
> URL: https://issues.apache.org/jira/browse/FELIX-6322
> Project: Felix
> Issue Type: Bug
> Components: Configurator
>Affects Versions: configurator-1.0.12
>Reporter: Amit Mondal
>Priority: Major
>
> The following exception occurs in runtime if we update the configurator from
> v1.0.10 to v1.0.12:
> {code:java}
> java.io.StreamCorruptedException: unexpected block data
> at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1641)
> at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:2341)
> at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:2221)
> at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:2123)
> at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1624)
> at java.io.ObjectInputStream.readObject(ObjectInputStream.java:464)
> at java.io.ObjectInputStream.readObject(ObjectInputStream.java:422)
> at
> org.apache.felix.configurator.impl.model.State.createOrReadState(State.java:87)
> at
> org.apache.felix.configurator.impl.Configurator.(Configurator.java:91)
> at
> org.apache.felix.configurator.impl.ServicesListener.notifyChange(ServicesListener.java:113)
> at
> org.apache.felix.configurator.impl.ServicesListener$1.addingService(ServicesListener.java:73)
> at
> org.apache.felix.configurator.impl.ServicesListener$1.addingService(ServicesListener.java:65)
> at
> org.osgi.util.tracker.ServiceTracker$Tracked.customizerAdding(ServiceTracker.java:943)
> at
> org.osgi.util.tracker.ServiceTracker$Tracked.customizerAdding(ServiceTracker.java:871)
> at
> org.osgi.util.tracker.AbstractTracked.trackAdding(AbstractTracked.java:256)
> at
> org.osgi.util.tracker.AbstractTracked.trackInitial(AbstractTracked.java:183)
> at org.osgi.util.tracker.ServiceTracker.open(ServiceTracker.java:321)
> at org.osgi.util.tracker.ServiceTracker.open(ServiceTracker.java:264)
> at
> org.apache.felix.configurator.impl.ServicesListener.(ServicesListener.java:93)
> at org.apache.felix.configurator.impl.Activator.start(Activator.java:36)
> at
> org.apache.felix.framework.util.SecureAction.startActivator(SecureAction.java:698)
> at org.apache.felix.framework.Felix.activateBundle(Felix.java:2402)
> at org.apache.felix.framework.Felix.startBundle(Felix.java:2308)
> at org.apache.felix.framework.BundleImpl.start(BundleImpl.java:998)
> at org.apache.felix.framework.BundleImpl.start(BundleImpl.java:984){code}
> I had looked into it and found that the problem probably lies in the serial
> version number of _*OrderedDictionary*_ which is part of
> _*org.apache.felix.cm.json*_ and was never required for Configurator
> v1.0.10.
> I have compared the hexdumps of both the _*state.ser*_ files and the files
> started to differ in _*OrderedDictionary.*_
> The exception doesn't harm since if the previous state cannot be read
> properly, a new state gets created.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Issue Comment Deleted] (FELIX-6293) Apache Felix SCR Logging
[ https://issues.apache.org/jira/browse/FELIX-6293?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Peter Kriens updated FELIX-6293: Comment: was deleted (was: I also noticed that we're not closing the Service Trackers and holding on to old Logger objects when the LoggerFactory is unregistered. Should we also handle this?) > Apache Felix SCR Logging > > > Key: FELIX-6293 > URL: https://issues.apache.org/jira/browse/FELIX-6293 > Project: Felix > Issue Type: Improvement > Components: Declarative Services (SCR) > Reporter: Peter Kriens >Priority: Minor > Attachments: image-2020-07-20-15-22-24-373.png > > > Apache Felix SCR uses the component's logger name to find the level to log > at. If the component happens to be on DEBUG, this then floods the log and > makes it hard to debug the component. > I'd like to add a System property that would provide the log name for SCR. If > it is not set, the current behaviour is used. > I can make this change if I get some feedback it is an acceptable idea. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (FELIX-6293) Apache Felix SCR Logging
[ https://issues.apache.org/jira/browse/FELIX-6293?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17161877#comment-17161877 ] Peter Kriens commented on FELIX-6293: - I also noticed that we're not closing the Service Trackers and holding on to old Logger objects when the LoggerFactory is unregistered. Should we also handle this? > Apache Felix SCR Logging > > > Key: FELIX-6293 > URL: https://issues.apache.org/jira/browse/FELIX-6293 > Project: Felix > Issue Type: Improvement > Components: Declarative Services (SCR) >Reporter: Peter Kriens >Priority: Minor > Attachments: image-2020-07-20-15-22-24-373.png > > > Apache Felix SCR uses the component's logger name to find the level to log > at. If the component happens to be on DEBUG, this then floods the log and > makes it hard to debug the component. > I'd like to add a System property that would provide the log name for SCR. If > it is not set, the current behaviour is used. > I can make this change if I get some feedback it is an acceptable idea. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (FELIX-6293) Apache Felix SCR Logging
[ https://issues.apache.org/jira/browse/FELIX-6293?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17161826#comment-17161826 ] Peter Kriens commented on FELIX-6293: - After looking at the code I do agree it is heavily over-engineered. I would be much more comfortable having a single logger type with different names + the spec mode. I am not sure how we make decisions here. Is there an owner/architect? Can we make the decision? Shall I make a proposal and we can look on Github? > Apache Felix SCR Logging > > > Key: FELIX-6293 > URL: https://issues.apache.org/jira/browse/FELIX-6293 > Project: Felix > Issue Type: Improvement > Components: Declarative Services (SCR) > Reporter: Peter Kriens >Priority: Minor > Attachments: image-2020-07-20-15-22-24-373.png > > > Apache Felix SCR uses the component's logger name to find the level to log > at. If the component happens to be on DEBUG, this then floods the log and > makes it hard to debug the component. > I'd like to add a System property that would provide the log name for SCR. If > it is not set, the current behaviour is used. > I can make this change if I get some feedback it is an acceptable idea. -- This message was sent by Atlassian Jira (v8.3.4#803005)
Re: [VOTE] Release Apache Felix Configurator 1.0.12
The question is of course, does my vote _mean_ anything? :-) Kind regards, Peter Kriens > On 20 Jul 2020, at 16:32, David Bosschaert wrote: > >> >> Peter Kriens (I guess I can also vote?) >> > > AFAIK anyone can vote: pmc member, committer or not. > > But FYI you _are_ a Felix committer, Peter :) > https://people.apache.org/phonebook.html?pmc=felix > > Best, > > David
Re: [VOTE] Release Apache Felix Configurator 1.0.12
+1 Peter Kriens (I guess I can also vote?) > On 20 Jul 2020, at 16:12, Carsten Ziegeler wrote: > > Hi, > we solved two issues in this > release:https://issues.apache.org/jira/browse/FELIX-6256?jql=project%20%3D%20FELIX%20AND%20fixVersion%20%3D%20configurator-1.0.12 > > Staging repositories: > https://repository.apache.org/content/repositories/orgapachefelix-1344 > > You can use this UNIX script to download the release and verify the > signatures: > https://github.com/apache/felix-dev/blob/master/check_staged_release.sh > > Usage: > sh check_staged_release.sh 1344 /tmp/felix-staging > > Please vote to approve this release: > > [ ] +1 Approve the release > [ ] -1 Veto the release (please provide specific comments) > > Regards > Carsten > -- > Carsten Ziegeler > Adobe Research Switzerland > cziege...@apache.org
[jira] [Commented] (FELIX-6279) Configurator does not update 'force' configurations when bundle is unchanged
[
https://issues.apache.org/jira/browse/FELIX-6279?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17161259#comment-17161259
]
Peter Kriens commented on FELIX-6279:
-
Fix in [https://github.com/apache/felix-dev/pull/35]
> Configurator does not update 'force' configurations when bundle is unchanged
>
>
> Key: FELIX-6279
> URL: https://issues.apache.org/jira/browse/FELIX-6279
> Project: Felix
> Issue Type: Bug
> Components: Configurator
>Reporter: Peter Kriens
>Priority: Major
>
> We have a situation where the force policy is used. We expected that this
> configuration overwrites any local changes. It did, however, not write the
> configuration in Felix Configurator. After debugging, we found that if the
> bundle's configuration file was unchanged *from its previous version*, the
> configuration was never applied to Configuration Admin.
> However, if there was a change locally in Configuration Admin, the force
> policy should overwrite this to the configuration in the bundle. This does
> not happen if the bundle is unchanged.
> - make a bundle B, configuration file: {{pid.A | :force: foo=1}}
> - Install B
> - change {{pid.A | foo=2}}
> - update B (without changing it)
> - Note that CA still is {{pid.A | foo=2}}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Issue Comment Deleted] (FELIX-6293) Apache Felix SCR Logging
[ https://issues.apache.org/jira/browse/FELIX-6293?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Peter Kriens updated FELIX-6293: Comment: was deleted (was: This proposal is currently implemented in See [https://github.com/apache/felix-dev/pull/35]) > Apache Felix SCR Logging > > > Key: FELIX-6293 > URL: https://issues.apache.org/jira/browse/FELIX-6293 > Project: Felix > Issue Type: Improvement > Components: Declarative Services (SCR) > Reporter: Peter Kriens >Priority: Minor > Attachments: image-2020-07-20-15-22-24-373.png > > > Apache Felix SCR uses the component's logger name to find the level to log > at. If the component happens to be on DEBUG, this then floods the log and > makes it hard to debug the component. > I'd like to add a System property that would provide the log name for SCR. If > it is not set, the current behaviour is used. > I can make this change if I get some feedback it is an acceptable idea. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (FELIX-6293) Apache Felix SCR Logging
[
https://issues.apache.org/jira/browse/FELIX-6293?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17161239#comment-17161239
]
Peter Kriens commented on FELIX-6293:
-
I dived into the code.
Logging happens in a hierarchy. If a logger is not enabled for logging, it is
reported to the parent. Each logger tries to create an internal OSGiLogger.
There are 3 different Scr loggers used throughout the code-base:
# `ScrLogger` – Logs the main SCR code. It uses the default bundle level of
the SCR bundle.
# `BundleLogger` – Logs bundle related messages. It uses the default bundle of
the bundle that holds the component. If the internal is not enabled, it will
log to the Scr Logger
# `ComponentLogger` – Logs the component related messages, it uses the
implementation class name + the bundle it resides in. If the internal logger is
disabled for a level, it logs the message on the Bundle Logger.
Each logger refers to an _internal logger_. This is either a Std Out Logger or
OSGiLogger.
!image-2020-07-20-15-22-24-373.png!
So I think we can achieve what we want if we change the ComponentLogger.
Currently, it gets a Logger from LoggerFactory using:
# The component's bundle
# the fully qualified implementation class name of the component
This behaviour is explicitly specified by OSGi and must, therefore, remain the
case as default.
I propose to introduce a `ds.log.bundle` configuration parameter of a boolean
type. Default is true and makes the code behave as it is today. When it is
explicitly set to {{false}} via framework properties or configuration, it will
_always_ use the Scr's bundle logger. However, it will use the following logger
names:
# BundleLogger – The logger name in the Scr bundle's logger will be the
_bundle symbolic name_
# ComponentLogger – The logger name in the Scr bundle's logger will be the
bundle symbolic name of its bundle, a dot and the implementation class name.
For example, if the ban is {{com.example.foo}} and the implementation is
{{com.example.foo.impl.Foo}} then the logger name is
{{com.example.foo.com.example.foo.impl.Foo}}
Therefore, to see (with {{ds.log.bundle}}=false):
# component – Enable . on scr bundle
# bundle – Enable on scr bundle (includes components, this cannot be
disabled since a component uses its parent bundle logger if not enabled for a
level. A bit bizarre)
> Apache Felix SCR Logging
>
>
> Key: FELIX-6293
> URL: https://issues.apache.org/jira/browse/FELIX-6293
> Project: Felix
> Issue Type: Improvement
> Components: Declarative Services (SCR)
>Reporter: Peter Kriens
>Priority: Minor
> Attachments: image-2020-07-20-15-22-24-373.png
>
>
> Apache Felix SCR uses the component's logger name to find the level to log
> at. If the component happens to be on DEBUG, this then floods the log and
> makes it hard to debug the component.
> I'd like to add a System property that would provide the log name for SCR. If
> it is not set, the current behaviour is used.
> I can make this change if I get some feedback it is an acceptable idea.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (FELIX-6293) Apache Felix SCR Logging
[ https://issues.apache.org/jira/browse/FELIX-6293?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17161240#comment-17161240 ] Peter Kriens commented on FELIX-6293: - This proposal is currently implemented in See [https://github.com/apache/felix-dev/pull/35] > Apache Felix SCR Logging > > > Key: FELIX-6293 > URL: https://issues.apache.org/jira/browse/FELIX-6293 > Project: Felix > Issue Type: Improvement > Components: Declarative Services (SCR) > Reporter: Peter Kriens >Priority: Minor > Attachments: image-2020-07-20-15-22-24-373.png > > > Apache Felix SCR uses the component's logger name to find the level to log > at. If the component happens to be on DEBUG, this then floods the log and > makes it hard to debug the component. > I'd like to add a System property that would provide the log name for SCR. If > it is not set, the current behaviour is used. > I can make this change if I get some feedback it is an acceptable idea. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (FELIX-6293) Apache Felix SCR Logging
[ https://issues.apache.org/jira/browse/FELIX-6293?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Peter Kriens updated FELIX-6293: Attachment: image-2020-07-20-15-22-24-373.png > Apache Felix SCR Logging > > > Key: FELIX-6293 > URL: https://issues.apache.org/jira/browse/FELIX-6293 > Project: Felix > Issue Type: Improvement > Components: Declarative Services (SCR) > Reporter: Peter Kriens >Priority: Minor > Attachments: image-2020-07-20-15-22-24-373.png > > > Apache Felix SCR uses the component's logger name to find the level to log > at. If the component happens to be on DEBUG, this then floods the log and > makes it hard to debug the component. > I'd like to add a System property that would provide the log name for SCR. If > it is not set, the current behaviour is used. > I can make this change if I get some feedback it is an acceptable idea. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (FELIX-2899) [GSoc 2011]Bndtools based OSGi bundles maker project
[ https://issues.apache.org/jira/browse/FELIX-2899?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Peter Kriens closed FELIX-2899. --- Resolution: Fixed Was a disaster > [GSoc 2011]Bndtools based OSGi bundles maker project > > > Key: FELIX-2899 > URL: https://issues.apache.org/jira/browse/FELIX-2899 > Project: Felix > Issue Type: Task > Environment: Eclipse platform, this project add a new tool for Felix > users to improve OSGi bundles development process in Eclipse environment >Reporter: Tiger Gui > Assignee: Peter Kriens >Priority: Major > Labels: gsoc, gsoc2011, mentor, mentoring > Original Estimate: 1,680h > Remaining Estimate: 1,680h > > OSGi(Open Service Gateway Initiative) is a worldwide consortium of technology > innovators that advances a proven and > mature process to create open specifications that enable the modular assembly > of software built with Java technology. > It is becoming more and more popular in Java Desktop or Web application > developmenent especially when we are working on > some huge project, as it is growing more and more complex, OSGi can help > us.Developing with OSGi technology means > developing bundles: the OSGi components. Bundles are modules. > OSGi is a good thing, but coin has two sides. Usually the development process > with OSGi will be more troublesome. Suppose > that we are in this scenario. We use a interface Greeting to say hello to our > customers , but we should say different words to different kind of customers > , so we have two implemention class for Greeting interface, we > name them BasicGreeting and GreatGreeting. > If we develop this application in a traditional OSGi way, we should create at > lease 3 projects (or bundles) in our IDE (Eclipse for example). > one service define bundle, two service supply bundles, it's a long list in > our workspace.Isn't it troublesome? If we just > write these codes in a Jave project and some tool can help us to split this > project in OSGi way and export 3 jar files, isn't it cool? > So i want to build OSGi split tool for Java project, it can also be used to > split and refactor our exist huge project in OSGi way. This > is very important. In some huge application, how to manage components in a > convinent way is an art, so far, OSGi is the best solution > that we can find. But the refactor and split for exist huge project is > complex and painful. This tool will help us to do this job. > We want to build a bnd(tools) based OSGi bunlles maker project, it will help > us analyse java application and split the whole project into several OSGi > bundles. > Suppose that we write code in good style, define service in interface, > implement the service by the implemention class of the interface > and put similar service in a package. This tool can analyse source code, > supply vari-size grained split and refactor suggestions, show > the analyse result in a GUI view and we can change split solution manually, > then it will split the project into several projects. > Function lists: > 1. configuration > Define default split/refactor solution for this tool. For example,assign > default interface split particle or package split partical. Or may be > we can just split the project by function module define, similar with > M(Module)-V(View)-C(control) develop pattern. Or in some other ways. > 2. analyse module > It can analyse project source code, make clear of class dependency > relationship and give us a graphical view analyse result, this is default > split solution, and we can change it as we like. > The trick is to find strongly coupled packages. These are packages that are > in a cycle. A -> B -> C -> A. Normally I find that these packages should be > in the same bundle. In bnd (the current next branch) I already can calculate > those strongly connected packages. In general, I find that many, especially > larger, bundles consist of a number of subsystems. > These subsystems have dependencies on each other, however, by definition > there is no cycle between these subsystem dependencies (otherwise they would > be strongly connected and be part of the same subsystem). > There should be the following types of subsystems: > API - Self contained, no internal dependencies. All exported/imported. Very > few dependencies. The OSGi specification packages are prime examples. Having > imports in these packages is always suspect. In my experience, API must be > maintained independently but carried in the bundle that implements
[jira] [Commented] (FELIX-6293) Apache Felix SCR Logging
[ https://issues.apache.org/jira/browse/FELIX-6293?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17150344#comment-17150344 ] Peter Kriens commented on FELIX-6293: - so `org.apache.felix.scr` = overall logging and `org.apache.felix.scr.` would use for the component? (I am severely challenged concerning logging, tried to avoid it like the plague and somehow never felt a strong need.) > Apache Felix SCR Logging > > > Key: FELIX-6293 > URL: https://issues.apache.org/jira/browse/FELIX-6293 > Project: Felix > Issue Type: Improvement > Components: Declarative Services (SCR) > Reporter: Peter Kriens >Priority: Minor > > Apache Felix SCR uses the component's logger name to find the level to log > at. If the component happens to be on DEBUG, this then floods the log and > makes it hard to debug the component. > I'd like to add a System property that would provide the log name for SCR. If > it is not set, the current behaviour is used. > I can make this change if I get some feedback it is an acceptable idea. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (FELIX-6293) Apache Felix SCR Logging
[ https://issues.apache.org/jira/browse/FELIX-6293?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Peter Kriens updated FELIX-6293: Component/s: Declarative Services (SCR) > Apache Felix SCR Logging > > > Key: FELIX-6293 > URL: https://issues.apache.org/jira/browse/FELIX-6293 > Project: Felix > Issue Type: Improvement > Components: Declarative Services (SCR) > Reporter: Peter Kriens >Priority: Minor > > Apache Felix SCR uses the component's logger name to find the level to log > at. If the component happens to be on DEBUG, this then floods the log and > makes it hard to debug the component. > I'd like to add a System property that would provide the log name for SCR. If > it is not set, the current behaviour is used. > I can make this change if I get some feedback it is an acceptable idea. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (FELIX-6293) Apache Felix SCR Logging
Peter Kriens created FELIX-6293: --- Summary: Apache Felix SCR Logging Key: FELIX-6293 URL: https://issues.apache.org/jira/browse/FELIX-6293 Project: Felix Issue Type: Improvement Reporter: Peter Kriens Apache Felix SCR uses the component's logger name to find the level to log at. If the component happens to be on DEBUG, this then floods the log and makes it hard to debug the component. I'd like to add a System property that would provide the log name for SCR. If it is not set, the current behaviour is used. I can make this change if I get some feedback it is an acceptable idea. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (FELIX-6279) Configurator does not update 'force' configurations when bundle is unchanged
[
https://issues.apache.org/jira/browse/FELIX-6279?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17150101#comment-17150101
]
Peter Kriens commented on FELIX-6279:
-
Carsten, to move this forward, would it help if I fix it in the build? I would
you to do a release because that did not go very well last time but I can fix
it and maybe pickup some other bugs?
> Configurator does not update 'force' configurations when bundle is unchanged
>
>
> Key: FELIX-6279
> URL: https://issues.apache.org/jira/browse/FELIX-6279
> Project: Felix
> Issue Type: Bug
> Components: Configurator
>Reporter: Peter Kriens
>Priority: Major
>
> We have a situation where the force policy is used. We expected that this
> configuration overwrites any local changes. It did, however, not write the
> configuration in Felix Configurator. After debugging, we found that if the
> bundle's configuration file was unchanged *from its previous version*, the
> configuration was never applied to Configuration Admin.
> However, if there was a change locally in Configuration Admin, the force
> policy should overwrite this to the configuration in the bundle. This does
> not happen if the bundle is unchanged.
> - make a bundle B, configuration file: {{pid.A | :force: foo=1}}
> - Install B
> - change {{pid.A | foo=2}}
> - update B (without changing it)
> - Note that CA still is {{pid.A | foo=2}}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (FELIX-6288) Apache Felix SCR Lock timeout
[ https://issues.apache.org/jira/browse/FELIX-6288?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17143038#comment-17143038 ] Peter Kriens commented on FELIX-6288: - After discussing further with a customer, maybe the component should also be automatically be rescheduled. > Apache Felix SCR Lock timeout > - > > Key: FELIX-6288 > URL: https://issues.apache.org/jira/browse/FELIX-6288 > Project: Felix > Issue Type: Bug > Components: Declarative Services (SCR) > Reporter: Peter Kriens >Priority: Minor > > The SCR timeout for obtaining the lock to create a component instance (state > lock) is 5 secs. We ran into a case where this was not sufficient on embedded > hardware. Clearly an activate method/constructor should not take this amount > of time. However, while tracing this it was clear that this time included a > large number of activate methods. If you have a set of lazy services in a > dependency chain, and someone activates the top of the chain, all downstream > activate methods will be running. > The purpose of the 5 secs is imho to break deadlocks, there seems nothing to > win by breaking an application because you only want to wait 5 secs. If an > application takes too long to startup, it is far superior to let the > application finish correctly than put it in an unknown state by failing the > component creation. > I suggest increasing the default timeout to something like 30sec. This will > break deadlocks and should handle the 99,999% of the cases slowly but > correctly. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (FELIX-6288) Apache Felix SCR Lock timeout
Peter Kriens created FELIX-6288: --- Summary: Apache Felix SCR Lock timeout Key: FELIX-6288 URL: https://issues.apache.org/jira/browse/FELIX-6288 Project: Felix Issue Type: Bug Components: Declarative Services (SCR) Reporter: Peter Kriens The SCR timeout for obtaining the lock to create a component instance (state lock) is 5 secs. We ran into a case where this was not sufficient on embedded hardware. Clearly an activate method/constructor should not take this amount of time. However, while tracing this it was clear that this time included a large number of activate methods. If you have a set of lazy services in a dependency chain, and someone activates the top of the chain, all downstream activate methods will be running. The purpose of the 5 secs is imho to break deadlocks, there seems nothing to win by breaking an application because you only want to wait 5 secs. If an application takes too long to startup, it is far superior to let the application finish correctly than put it in an unknown state by failing the component creation. I suggest increasing the default timeout to something like 30sec. This will break deadlocks and should handle the 99,999% of the cases slowly but correctly. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (FELIX-6279) Configurator does not update 'force' configurations when bundle is unchanged
Peter Kriens created FELIX-6279:
---
Summary: Configurator does not update 'force' configurations when
bundle is unchanged
Key: FELIX-6279
URL: https://issues.apache.org/jira/browse/FELIX-6279
Project: Felix
Issue Type: Bug
Components: Configurator
Reporter: Peter Kriens
We have a situation where the force policy is used. We expected that this
configuration overwrites any local changes. It did, however, not write the
configuration in Felix Configurator. After debugging, we found that if the
bundle's configuration file was unchanged *from its previous version*, the
configuration was never applied to Configuration Admin.
However, if there was a change locally in Configuration Admin, the force policy
should overwrite this to the configuration in the bundle. This does not happen
if the bundle is unchanged.
- make a bundle B, configuration file: {{pid.A | :force: foo=1}}
- Install B
- change {{pid.A | foo=2}}
- update B (without changing it)
- Note that CA still is {{pid.A | foo=2}}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
Android
A customer asked me to look into OSGi on Android. I read
https://felix.apache.org/documentation/subprojects/apache-felix-framework/apache-felix-framework-and-google-android.html
<https://felix.apache.org/documentation/subprojects/apache-felix-framework/apache-felix-framework-and-google-android.html>
but the download file osgi.android.zip is missing (or the link is pointing to
the html file), and the tool chain seemed to have changed in the mean time.
Anybody information you can help me with? I can update the doc if I can get it
to work.
Kind regards,
Peter Kriens
Re: JPMS & Felix
Thanks. Kind regards, Peter Kriens > On 28 Jan 2020, at 17:13, Karl Pauls wrote: > > Yes, it will be fixed eventually - i have some fixes for it in connect > fork. Until then, you can ignore it or start with --add-opens to make > it go aways (makes the commandline somewhat ugly so :-). > > regards, > > Karl > > On Tue, Jan 28, 2020 at 5:11 PM Peter Kriens wrote: >> >> I am normally a happy camper with Java 8 but I now got some questions >> running OSGi on Java 13. I got the following warning: >> >>WARNING: An illegal reflective access operation has occurred >>WARNING: Illegal reflective access by >> org.apache.felix.framework.ext.ClassPathExtenderFactory$DefaultClassLoaderExtender >> >> (file:/Users/aqute/.m2/repository/org/apache/felix/org.apache.felix.framework/6.0.3/org.apache.felix.framework-6.0.3.jar) >> to method java.net.URLClassLoader.addURL(java.net.URL) >>WARNING: Please consider reporting this to the maintainers of >> org.apache.felix.framework.ext.ClassPathExtenderFactory$DefaultClassLoaderExtender >>WARNING: Use --illegal-access=warn to enable warnings of further >> illegal reflective access operations >>WARNING: All illegal access operations will be denied in a future >> release >> >>Welcome to Apache Felix Gogo >> >>g! >> >> It looks rather ugly and it promises death in the next release. I looked at >> JIRA but could not find any discussion of this. Will this be fixed? >> >> Kind regards, >> >>Peter Kriens > > > > -- > Karl Pauls > karlpa...@gmail.com
JPMS & Felix
I am normally a happy camper with Java 8 but I now got some questions running OSGi on Java 13. I got the following warning: WARNING: An illegal reflective access operation has occurred WARNING: Illegal reflective access by org.apache.felix.framework.ext.ClassPathExtenderFactory$DefaultClassLoaderExtender (file:/Users/aqute/.m2/repository/org/apache/felix/org.apache.felix.framework/6.0.3/org.apache.felix.framework-6.0.3.jar) to method java.net.URLClassLoader.addURL(java.net.URL) WARNING: Please consider reporting this to the maintainers of org.apache.felix.framework.ext.ClassPathExtenderFactory$DefaultClassLoaderExtender WARNING: Use --illegal-access=warn to enable warnings of further illegal reflective access operations WARNING: All illegal access operations will be denied in a future release Welcome to Apache Felix Gogo g! It looks rather ugly and it promises death in the next release. I looked at JIRA but could not find any discussion of this. Will this be fixed? Kind regards, Peter Kriens
[RESULT] [VOTE] Release Felix User Admin version 1.6
hi, The vote has passed with the following result +1 (binding)1 +1 4 I will copy this release to the Felix dist directory and promote the artifacts to the central Maven repository. Kind regards, Peter Kriens
[VOTE] Release Felix UserAdmin version 1.6
Hi, We've added a service capability to UserAdmin in this release:
https://issues.apache.org/jira/browse/FELIX-6093
Staging repository:
https://repository.apache.org/content/repositories/orgapachefelix-1310
You can use this UNIX script to download the release and verify the signatures:
http://svn.apache.org/repos/asf/felix/trunk/check_staged_release.sh
Usage:
sh check_staged_release.sh 1310 /tmp/felix-staging
Please vote to approve this release:
[ ] +1 Approve the release
[ ] -1 Veto the release (please provide specific comments)
This vote will be open for 72 hours.
Kind regards,
Peter Kriens
[jira] [Commented] (FELIX-6056) SCR exports promises
[ https://issues.apache.org/jira/browse/FELIX-6056?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16767147#comment-16767147 ] Peter Kriens commented on FELIX-6056: - Since when are you guys so easy to convince? You spoil all the fun! :) BTW, I drove by Bielefeld last week and it was much nicer than I thought! :) Thx > SCR exports promises > > > Key: FELIX-6056 > URL: https://issues.apache.org/jira/browse/FELIX-6056 > Project: Felix > Issue Type: Bug > Components: Declarative Services (SCR) > Reporter: Peter Kriens >Priority: Major > > Apache Felix SCR exports promises 1.0 as a convenience. However, since this > package contains the implementation it is a +provider+. Originally, the > import was correct for a provider, [1,1.1). however, last July it was > increased to [1,2). This therefore against the semantic versioning > specification that prescribes a minor import range when providing the > implementation of an API. > Exporting an package like Promises is not a good idea anyway. It is only a > convenience, promises have nothing to do with SCR in itself and that will > always back fire in the end. Even exporting it correctly causes unnecessary > version constraints since the order of resolving cannot be controlled. So if > you have Promises 1.1 it depends on the order of resolving if SCR uses 1.0 or > 1.1 and it creates nasty class spaces. > It is inconvenient to make SCR depend on Promises. Personally I would not > have used promises or would have included the package privately. (No API of > SCR depends on Promises) Since SCR is such a crucial base component I > strongly recommend to not export it from SCR. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (FELIX-6056) SCR exports promises
[
https://issues.apache.org/jira/browse/FELIX-6056?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16767071#comment-16767071
]
Peter Kriens commented on FELIX-6056:
-
By wrapping it in a single bundle you force others to follow
{color:#33}your{color} Promises' {color:#FF}implementation{color} and
that version is not always compatible. in a runtime (The version we currently
use for R7 is R6 promises.) Since SCR is such a fundamental bundle it should
not force such constraints on other people's runtime.
Notice that this is mostly caused because it includes API
{color:#FF}and{color} an implementation. An API only would still be not
cohesive but would work ok. Since others do this as well, there is no backward
compatibility on the API possible. You therefore must import it [1,1.1) This
constrained will then likely cause multiple class spaces in more complex
runtimes and that is almost always havoc. That is why importing [1,2) for a
provided package is basically throwing a big wrench in the semantic versioning.
Exporting a package that is not part of your primary responsibility is
fundamentally wrong in component based design. Yes, I feel we messed up on the
SCR Runtime API to force Promises in the ScrComponentRuntime methods and it is
inconvenient to require 3 instead of 1 bundle but the cause is the bad API
design that references another spec, this causes an _external_ reference.
Solving this problem by exporting those references is a hack and will cause
problems.
At my customers I see the problems always around the bundles that start doing
these hacks, never around simple clean honest manifests that refer to what they
should refer to. Apache Felix has always been extremely good in this respect so
I was quite surprised when I learned about this.
> SCR exports promises
>
>
> Key: FELIX-6056
> URL: https://issues.apache.org/jira/browse/FELIX-6056
> Project: Felix
> Issue Type: Bug
> Components: Declarative Services (SCR)
>Reporter: Peter Kriens
>Priority: Major
>
> Apache Felix SCR exports promises 1.0 as a convenience. However, since this
> package contains the implementation it is a +provider+. Originally, the
> import was correct for a provider, [1,1.1). however, last July it was
> increased to [1,2). This therefore against the semantic versioning
> specification that prescribes a minor import range when providing the
> implementation of an API.
> Exporting an package like Promises is not a good idea anyway. It is only a
> convenience, promises have nothing to do with SCR in itself and that will
> always back fire in the end. Even exporting it correctly causes unnecessary
> version constraints since the order of resolving cannot be controlled. So if
> you have Promises 1.1 it depends on the order of resolving if SCR uses 1.0 or
> 1.1 and it creates nasty class spaces.
> It is inconvenient to make SCR depend on Promises. Personally I would not
> have used promises or would have included the package privately. (No API of
> SCR depends on Promises) Since SCR is such a crucial base component I
> strongly recommend to not export it from SCR.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (FELIX-6056) SCR exports promises
[ https://issues.apache.org/jira/browse/FELIX-6056?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16766917#comment-16766917 ] Peter Kriens commented on FELIX-6056: - Come on Tom! That was way too easy, this way you spoil all the fun! :) Thanks a lot, any idea of a time frame? > SCR exports promises > > > Key: FELIX-6056 > URL: https://issues.apache.org/jira/browse/FELIX-6056 > Project: Felix > Issue Type: Bug > Components: Declarative Services (SCR) > Reporter: Peter Kriens >Priority: Major > > Apache Felix SCR exports promises 1.0 as a convenience. However, since this > package contains the implementation it is a +provider+. Originally, the > import was correct for a provider, [1,1.1). however, last July it was > increased to [1,2). This therefore against the semantic versioning > specification that prescribes a minor import range when providing the > implementation of an API. > Exporting an package like Promises is not a good idea anyway. It is only a > convenience, promises have nothing to do with SCR in itself and that will > always back fire in the end. Even exporting it correctly causes unnecessary > version constraints since the order of resolving cannot be controlled. So if > you have Promises 1.1 it depends on the order of resolving if SCR uses 1.0 or > 1.1 and it creates nasty class spaces. > It is inconvenient to make SCR depend on Promises. Personally I would not > have used promises or would have included the package privately. (No API of > SCR depends on Promises) Since SCR is such a crucial base component I > strongly recommend to not export it from SCR. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (FELIX-6056) SCR exports promises
[ https://issues.apache.org/jira/browse/FELIX-6056?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16766042#comment-16766042 ] Peter Kriens commented on FELIX-6056: - Yes, the API dependency is unfortunate since very few bundles use this class (let alone these rarely used methods). it is one of the few places where an OSGi spec references another spec than the framework. We always tried to keep these separate, which is imho good design. Not sure what happened here. The cost of not letting these functions use Promises would have been negligent. The reason they export functions as well is I assume that Promises needs requires them. Another good reason not to export a package that is not yours. > SCR exports promises > > > Key: FELIX-6056 > URL: https://issues.apache.org/jira/browse/FELIX-6056 > Project: Felix > Issue Type: Bug > Components: Declarative Services (SCR) > Reporter: Peter Kriens >Priority: Major > > Apache Felix SCR exports promises 1.0 as a convenience. However, since this > package contains the implementation it is a +provider+. Originally, the > import was correct for a provider, [1,1.1). however, last July it was > increased to [1,2). This therefore against the semantic versioning > specification that prescribes a minor import range when providing the > implementation of an API. > Exporting an package like Promises is not a good idea anyway. It is only a > convenience, promises have nothing to do with SCR in itself and that will > always back fire in the end. Even exporting it correctly causes unnecessary > version constraints since the order of resolving cannot be controlled. So if > you have Promises 1.1 it depends on the order of resolving if SCR uses 1.0 or > 1.1 and it creates nasty class spaces. > It is inconvenient to make SCR depend on Promises. Personally I would not > have used promises or would have included the package privately. (No API of > SCR depends on Promises) Since SCR is such a crucial base component I > strongly recommend to not export it from SCR. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (FELIX-6056) SCR exports promises
Peter Kriens created FELIX-6056: --- Summary: SCR exports promises Key: FELIX-6056 URL: https://issues.apache.org/jira/browse/FELIX-6056 Project: Felix Issue Type: Bug Components: Declarative Services (SCR) Reporter: Peter Kriens Apache Felix SCR exports promises 1.0 as a convenience. However, since this package contains the implementation it is a +provider+. Originally, the import was correct for a provider, [1,1.1). however, last July it was increased to [1,2). This therefore against the semantic versioning specification that prescribes a minor import range when providing the implementation of an API. Exporting an package like Promises is not a good idea anyway. It is only a convenience, promises have nothing to do with SCR in itself and that will always back fire in the end. Even exporting it correctly causes unnecessary version constraints since the order of resolving cannot be controlled. So if you have Promises 1.1 it depends on the order of resolving if SCR uses 1.0 or 1.1 and it creates nasty class spaces. It is inconvenient to make SCR depend on Promises. Personally I would not have used promises or would have included the package privately. (No API of SCR depends on Promises) Since SCR is such a crucial base component I strongly recommend to not export it from SCR. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (FELIX-5875) org.osgi.framework.os.name et.al. are not obeyed
[ https://issues.apache.org/jira/browse/FELIX-5875?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16527686#comment-16527686 ] Peter Kriens commented on FELIX-5875: - Wow! That was quick! Thanks > org.osgi.framework.os.name et.al. are not obeyed > > > Key: FELIX-5875 > URL: https://issues.apache.org/jira/browse/FELIX-5875 > Project: Felix > Issue Type: Bug > Components: Framework >Affects Versions: framework-5.6.10 >Reporter: Peter Kriens >Assignee: Karl Pauls >Priority: Major > Fix For: framework-6.0.0 > > > The OSGi specification states that org.osgi.framework.os.name is a > configuration property. If it is not set then the framework should provide an > appropriate value. > However, the Felix code always sets this property itself, regardless if there > is already a value set. This makes it impossible to override. > > I've created a patch on Github https://github.com/apache/felix/pull/145 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (FELIX-5875) org.osgi.framework.os.name et.al. are not obeyed
[ https://issues.apache.org/jira/browse/FELIX-5875?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16527620#comment-16527620 ] Peter Kriens commented on FELIX-5875: - I feel more comfortable when you do it ... But the patch on Github should be a good start. (Github PR's work? Isn't Felix not still in SVN?) > org.osgi.framework.os.name et.al. are not obeyed > > > Key: FELIX-5875 > URL: https://issues.apache.org/jira/browse/FELIX-5875 > Project: Felix > Issue Type: Bug > Components: Framework >Affects Versions: framework-5.6.10 >Reporter: Peter Kriens >Priority: Major > Fix For: framework-6.0.0 > > > The OSGi specification states that org.osgi.framework.os.name is a > configuration property. If it is not set then the framework should provide an > appropriate value. > However, the Felix code always sets this property itself, regardless if there > is already a value set. This makes it impossible to override. > > I've created a patch on Github https://github.com/apache/felix/pull/145 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (FELIX-5875) org.osgi.framework.os.name et.al. are not obeyed
Peter Kriens created FELIX-5875: --- Summary: org.osgi.framework.os.name et.al. are not obeyed Key: FELIX-5875 URL: https://issues.apache.org/jira/browse/FELIX-5875 Project: Felix Issue Type: Bug Components: Framework Affects Versions: framework-5.6.10 Reporter: Peter Kriens The OSGi specification states that org.osgi.framework.os.name is a configuration property. If it is not set then the framework should provide an appropriate value. However, the Felix code always sets this property itself, regardless if there is already a value set. This makes it impossible to override. I've created a patch on Github https://github.com/apache/felix/pull/145 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (FELIX-5618) Cycles in DS depending on bundle order
[ https://issues.apache.org/jira/browse/FELIX-5618?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16343390#comment-16343390 ] Peter Kriens commented on FELIX-5618: - Where is the clone? > Cycles in DS depending on bundle order > -- > > Key: FELIX-5618 > URL: https://issues.apache.org/jira/browse/FELIX-5618 > Project: Felix > Issue Type: Bug > Components: Declarative Services (SCR) > Environment: MacOS + Windows + Linux >Reporter: Peter Kriens >Assignee: David Jencks >Priority: Blocker > Fix For: scr-2.0.14 > > Attachments: scr-cycle-2.0.2-bottom-top.txt, > scr-cycle-2.0.2-top-bottom.txt, scr-cycle-2.0.6-bottom-top.txt, > scr-cycle-2.0.6-top-bottom.txt > > > Following test case: >top.jar: Top @Reference volatile List >bottom.jar: Bottom @Reference Top > In SCR 2.0.2: > top.jar, bottom.jar -> OK, see trace >new Top() >Top.activate() >new Bottom() >Bottom.top= >Bottom.activate() > Top.bottom += > bottom.jar, top.jar -> FAILS but recovers > [osgi.enroute.examples.concurrency.cycle.bottom.Bottom(1)] > Circular reference detected, getService returning null > new Top() > Top.activate() > new Bottom() > Bottom.top= > Bottom.activate() > Top.bottom += > In SCR 2.0.4 and later > top.jar,bottom.jar -> OK >new Top() >Top.activate() >new Bottom() >Bottom.top= >Bottom.activate() >Top.bottom += > bottom.jar, top.jar -> FAILS and DOES NOT RECOVER! >new Bottom() >new Top() >Top.activate() >new Bottom() > The Bottom component never gets added to Top. This is a very serious problem > for reliable systems. I see this behaviour on 2.0.4, 2.0.6, and 2.0.8 > -- > I've traced the cycle problem in 2.0.2. What happens is: > 1) The Bottom configuration is started. There is no Top, so it is not > satisfied > 2) The Top configuration is started. It is satisfied since it can live with 0 > Bottoms. > 3) The top configuration registers Top > 4) The bottom configuration sees a Top and initiates Bottom > 5) The bottom configuration gets Top (which is under construction) > 6) The top configuration looks at its dependencies > 7) The top configuration sees there is a Bottom now and tries to get it > 8) The bottom factory is called again on the same thread and blows up > I am not sure what happens in 2.0.4 and later but it does look scary that > Bottom is now never added to the Top. > Fix > I tried to do the activation in a background thread that but that failed. I > think the cycle should be detected and and de Top should not get its dynamic > dependencies after the activate method returned. But, just a guess, this is > complicated stuff. > Workaround > The workaround is to not let Top register as a service but manually register > it at the end of the activate method. Since the service is then already > initialized and registered, the Bottom will not get activated until the Top > is done. > There is a bnd workspace that consistently shows this output. > https://github.com/pkriens/felix.scr.cycle > I've added 4 log files. 2.0.4 and 2.0.8 seem to act very similar -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Reopened] (FELIX-5618) Cycles in DS depending on bundle order
[ https://issues.apache.org/jira/browse/FELIX-5618?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Peter Kriens reopened FELIX-5618: - Problem unfortunately still present in 2.0.14 after testing on [https://github.com/pkriens/felix.scr.cycle] with the latest release of SCR. I did update the dependency to 2.0.14. Sorry :( > Cycles in DS depending on bundle order > -- > > Key: FELIX-5618 > URL: https://issues.apache.org/jira/browse/FELIX-5618 > Project: Felix > Issue Type: Bug > Components: Declarative Services (SCR) > Environment: MacOS + Windows + Linux >Reporter: Peter Kriens >Assignee: David Jencks >Priority: Blocker > Fix For: scr-2.0.14 > > Attachments: scr-cycle-2.0.2-bottom-top.txt, > scr-cycle-2.0.2-top-bottom.txt, scr-cycle-2.0.6-bottom-top.txt, > scr-cycle-2.0.6-top-bottom.txt > > > Following test case: >top.jar: Top @Reference volatile List >bottom.jar: Bottom @Reference Top > In SCR 2.0.2: > top.jar, bottom.jar -> OK, see trace >new Top() >Top.activate() >new Bottom() >Bottom.top= >Bottom.activate() > Top.bottom += > bottom.jar, top.jar -> FAILS but recovers > [osgi.enroute.examples.concurrency.cycle.bottom.Bottom(1)] > Circular reference detected, getService returning null > new Top() > Top.activate() > new Bottom() > Bottom.top= > Bottom.activate() > Top.bottom += > In SCR 2.0.4 and later > top.jar,bottom.jar -> OK >new Top() >Top.activate() >new Bottom() >Bottom.top= >Bottom.activate() >Top.bottom += > bottom.jar, top.jar -> FAILS and DOES NOT RECOVER! >new Bottom() >new Top() >Top.activate() >new Bottom() > The Bottom component never gets added to Top. This is a very serious problem > for reliable systems. I see this behaviour on 2.0.4, 2.0.6, and 2.0.8 > -- > I've traced the cycle problem in 2.0.2. What happens is: > 1) The Bottom configuration is started. There is no Top, so it is not > satisfied > 2) The Top configuration is started. It is satisfied since it can live with 0 > Bottoms. > 3) The top configuration registers Top > 4) The bottom configuration sees a Top and initiates Bottom > 5) The bottom configuration gets Top (which is under construction) > 6) The top configuration looks at its dependencies > 7) The top configuration sees there is a Bottom now and tries to get it > 8) The bottom factory is called again on the same thread and blows up > I am not sure what happens in 2.0.4 and later but it does look scary that > Bottom is now never added to the Top. > Fix > I tried to do the activation in a background thread that but that failed. I > think the cycle should be detected and and de Top should not get its dynamic > dependencies after the activate method returned. But, just a guess, this is > complicated stuff. > Workaround > The workaround is to not let Top register as a service but manually register > it at the end of the activate method. Since the service is then already > initialized and registered, the Bottom will not get activated until the Top > is done. > There is a bnd workspace that consistently shows this output. > https://github.com/pkriens/felix.scr.cycle > I've added 4 log files. 2.0.4 and 2.0.8 seem to act very similar -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (FELIX-5618) Cycles in DS depending on bundle order
[ https://issues.apache.org/jira/browse/FELIX-5618?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16339441#comment-16339441 ] Peter Kriens commented on FELIX-5618: - I can confirm that the bug is not fixed in 2.0.14 :( The original workspace at [https://github.com/pkriens/felix.scr.cycle] still shows the problem depending on the bundle order. > Cycles in DS depending on bundle order > -- > > Key: FELIX-5618 > URL: https://issues.apache.org/jira/browse/FELIX-5618 > Project: Felix > Issue Type: Bug > Components: Declarative Services (SCR) > Environment: MacOS + Windows + Linux >Reporter: Peter Kriens >Assignee: David Jencks >Priority: Blocker > Fix For: scr-2.0.14 > > Attachments: scr-cycle-2.0.2-bottom-top.txt, > scr-cycle-2.0.2-top-bottom.txt, scr-cycle-2.0.6-bottom-top.txt, > scr-cycle-2.0.6-top-bottom.txt > > > Following test case: >top.jar: Top @Reference volatile List >bottom.jar: Bottom @Reference Top > In SCR 2.0.2: > top.jar, bottom.jar -> OK, see trace >new Top() >Top.activate() >new Bottom() >Bottom.top= >Bottom.activate() > Top.bottom += > bottom.jar, top.jar -> FAILS but recovers > [osgi.enroute.examples.concurrency.cycle.bottom.Bottom(1)] > Circular reference detected, getService returning null > new Top() > Top.activate() > new Bottom() > Bottom.top= > Bottom.activate() > Top.bottom += > In SCR 2.0.4 and later > top.jar,bottom.jar -> OK >new Top() >Top.activate() >new Bottom() >Bottom.top= >Bottom.activate() >Top.bottom += > bottom.jar, top.jar -> FAILS and DOES NOT RECOVER! >new Bottom() >new Top() >Top.activate() >new Bottom() > The Bottom component never gets added to Top. This is a very serious problem > for reliable systems. I see this behaviour on 2.0.4, 2.0.6, and 2.0.8 > -- > I've traced the cycle problem in 2.0.2. What happens is: > 1) The Bottom configuration is started. There is no Top, so it is not > satisfied > 2) The Top configuration is started. It is satisfied since it can live with 0 > Bottoms. > 3) The top configuration registers Top > 4) The bottom configuration sees a Top and initiates Bottom > 5) The bottom configuration gets Top (which is under construction) > 6) The top configuration looks at its dependencies > 7) The top configuration sees there is a Bottom now and tries to get it > 8) The bottom factory is called again on the same thread and blows up > I am not sure what happens in 2.0.4 and later but it does look scary that > Bottom is now never added to the Top. > Fix > I tried to do the activation in a background thread that but that failed. I > think the cycle should be detected and and de Top should not get its dynamic > dependencies after the activate method returned. But, just a guess, this is > complicated stuff. > Workaround > The workaround is to not let Top register as a service but manually register > it at the end of the activate method. Since the service is then already > initialized and registered, the Bottom will not get activated until the Top > is done. > There is a bnd workspace that consistently shows this output. > https://github.com/pkriens/felix.scr.cycle > I've added 4 log files. 2.0.4 and 2.0.8 seem to act very similar -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (FELIX-5618) Cycles in DS depending on bundle order
[ https://issues.apache.org/jira/browse/FELIX-5618?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16339340#comment-16339340 ] Peter Kriens commented on FELIX-5618: - I mean the main trunk. David says something about r7 copy? There are no snapshots build for that? > Cycles in DS depending on bundle order > -- > > Key: FELIX-5618 > URL: https://issues.apache.org/jira/browse/FELIX-5618 > Project: Felix > Issue Type: Bug > Components: Declarative Services (SCR) > Environment: MacOS + Windows + Linux >Reporter: Peter Kriens >Assignee: David Jencks >Priority: Blocker > Fix For: scr-2.0.14 > > Attachments: scr-cycle-2.0.2-bottom-top.txt, > scr-cycle-2.0.2-top-bottom.txt, scr-cycle-2.0.6-bottom-top.txt, > scr-cycle-2.0.6-top-bottom.txt > > > Following test case: >top.jar: Top @Reference volatile List >bottom.jar: Bottom @Reference Top > In SCR 2.0.2: > top.jar, bottom.jar -> OK, see trace >new Top() >Top.activate() >new Bottom() >Bottom.top= >Bottom.activate() > Top.bottom += > bottom.jar, top.jar -> FAILS but recovers > [osgi.enroute.examples.concurrency.cycle.bottom.Bottom(1)] > Circular reference detected, getService returning null > new Top() > Top.activate() > new Bottom() > Bottom.top= > Bottom.activate() > Top.bottom += > In SCR 2.0.4 and later > top.jar,bottom.jar -> OK >new Top() >Top.activate() >new Bottom() >Bottom.top= >Bottom.activate() >Top.bottom += > bottom.jar, top.jar -> FAILS and DOES NOT RECOVER! >new Bottom() >new Top() >Top.activate() >new Bottom() > The Bottom component never gets added to Top. This is a very serious problem > for reliable systems. I see this behaviour on 2.0.4, 2.0.6, and 2.0.8 > -- > I've traced the cycle problem in 2.0.2. What happens is: > 1) The Bottom configuration is started. There is no Top, so it is not > satisfied > 2) The Top configuration is started. It is satisfied since it can live with 0 > Bottoms. > 3) The top configuration registers Top > 4) The bottom configuration sees a Top and initiates Bottom > 5) The bottom configuration gets Top (which is under construction) > 6) The top configuration looks at its dependencies > 7) The top configuration sees there is a Bottom now and tries to get it > 8) The bottom factory is called again on the same thread and blows up > I am not sure what happens in 2.0.4 and later but it does look scary that > Bottom is now never added to the Top. > Fix > I tried to do the activation in a background thread that but that failed. I > think the cycle should be detected and and de Top should not get its dynamic > dependencies after the activate method returned. But, just a guess, this is > complicated stuff. > Workaround > The workaround is to not let Top register as a service but manually register > it at the end of the activate method. Since the service is then already > initialized and registered, the Bottom will not get activated until the Top > is done. > There is a bnd workspace that consistently shows this output. > https://github.com/pkriens/felix.scr.cycle > I've added 4 log files. 2.0.4 and 2.0.8 seem to act very similar -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (FELIX-5618) Cycles in DS depending on bundle order
[ https://issues.apache.org/jira/browse/FELIX-5618?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16339309#comment-16339309 ] Peter Kriens commented on FELIX-5618: - I just verified that this is _not_ fixed in 2.0.14 yet. Is there any way we can get this fix in 2.0.14? If not, are there snapshots of a fixed version or do I need to build it myself? > Cycles in DS depending on bundle order > -- > > Key: FELIX-5618 > URL: https://issues.apache.org/jira/browse/FELIX-5618 > Project: Felix > Issue Type: Bug > Components: Declarative Services (SCR) > Environment: MacOS + Windows + Linux >Reporter: Peter Kriens >Assignee: David Jencks >Priority: Blocker > Fix For: scr-2.0.14 > > Attachments: scr-cycle-2.0.2-bottom-top.txt, > scr-cycle-2.0.2-top-bottom.txt, scr-cycle-2.0.6-bottom-top.txt, > scr-cycle-2.0.6-top-bottom.txt > > > Following test case: >top.jar: Top @Reference volatile List >bottom.jar: Bottom @Reference Top > In SCR 2.0.2: > top.jar, bottom.jar -> OK, see trace >new Top() >Top.activate() >new Bottom() >Bottom.top= >Bottom.activate() > Top.bottom += > bottom.jar, top.jar -> FAILS but recovers > [osgi.enroute.examples.concurrency.cycle.bottom.Bottom(1)] > Circular reference detected, getService returning null > new Top() > Top.activate() > new Bottom() > Bottom.top= > Bottom.activate() > Top.bottom += > In SCR 2.0.4 and later > top.jar,bottom.jar -> OK >new Top() >Top.activate() >new Bottom() >Bottom.top= >Bottom.activate() >Top.bottom += > bottom.jar, top.jar -> FAILS and DOES NOT RECOVER! >new Bottom() >new Top() >Top.activate() >new Bottom() > The Bottom component never gets added to Top. This is a very serious problem > for reliable systems. I see this behaviour on 2.0.4, 2.0.6, and 2.0.8 > -- > I've traced the cycle problem in 2.0.2. What happens is: > 1) The Bottom configuration is started. There is no Top, so it is not > satisfied > 2) The Top configuration is started. It is satisfied since it can live with 0 > Bottoms. > 3) The top configuration registers Top > 4) The bottom configuration sees a Top and initiates Bottom > 5) The bottom configuration gets Top (which is under construction) > 6) The top configuration looks at its dependencies > 7) The top configuration sees there is a Bottom now and tries to get it > 8) The bottom factory is called again on the same thread and blows up > I am not sure what happens in 2.0.4 and later but it does look scary that > Bottom is now never added to the Top. > Fix > I tried to do the activation in a background thread that but that failed. I > think the cycle should be detected and and de Top should not get its dynamic > dependencies after the activate method returned. But, just a guess, this is > complicated stuff. > Workaround > The workaround is to not let Top register as a service but manually register > it at the end of the activate method. Since the service is then already > initialized and registered, the Bottom will not get activated until the Top > is done. > There is a bnd workspace that consistently shows this output. > https://github.com/pkriens/felix.scr.cycle > I've added 4 log files. 2.0.4 and 2.0.8 seem to act very similar -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (FELIX-5693) Improve persistent manager handling
[ https://issues.apache.org/jira/browse/FELIX-5693?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16174461#comment-16174461 ] Peter Kriens commented on FELIX-5693: - Great! Thanks. > Improve persistent manager handling > --- > > Key: FELIX-5693 > URL: https://issues.apache.org/jira/browse/FELIX-5693 > Project: Felix > Issue Type: Improvement > Components: Configuration Admin >Reporter: Carsten Ziegeler >Assignee: Carsten Ziegeler > Fix For: configadmin-1.9.0 > > > The current handling of persistence managers is a little bit fragile and not > really deterministic. > I propose the following enhancements: > - Persistence managers can be registered with a "name" service property. The > FilePersistenceManager gets a name, e.g. "file" > - we add a new framework property configuration - if that's empty or not > there, CM acts as today > - if a value is configured, it's interpreted as a comma separated list of > names. This list of names makes up the PMs to be used by the implementation. > All of them must be registered and only these are used. > - the PMs are used in the order they are specified in the list > With this we have deterministic behaviour and full control while the default > ootb behaviour is still maintained. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (FELIX-5618) Cycles in DS depending on bundle order
[ https://issues.apache.org/jira/browse/FELIX-5618?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16108502#comment-16108502 ] Peter Kriens commented on FELIX-5618: - Thanks! > Cycles in DS depending on bundle order > -- > > Key: FELIX-5618 > URL: https://issues.apache.org/jira/browse/FELIX-5618 > Project: Felix > Issue Type: Bug > Components: Declarative Services (SCR) > Environment: MacOS + Windows + Linux >Reporter: Peter Kriens >Priority: Blocker > Attachments: scr-cycle-2.0.2-bottom-top.txt, > scr-cycle-2.0.2-top-bottom.txt, scr-cycle-2.0.6-bottom-top.txt, > scr-cycle-2.0.6-top-bottom.txt > > > Following test case: >top.jar: Top @Reference volatile List >bottom.jar: Bottom @Reference Top > In SCR 2.0.2: > top.jar, bottom.jar -> OK, see trace >new Top() >Top.activate() >new Bottom() >Bottom.top= >Bottom.activate() > Top.bottom += > bottom.jar, top.jar -> FAILS but recovers > [osgi.enroute.examples.concurrency.cycle.bottom.Bottom(1)] > Circular reference detected, getService returning null > new Top() > Top.activate() > new Bottom() > Bottom.top= > Bottom.activate() > Top.bottom += > In SCR 2.0.4 and later > top.jar,bottom.jar -> OK >new Top() >Top.activate() >new Bottom() >Bottom.top= >Bottom.activate() >Top.bottom += > bottom.jar, top.jar -> FAILS and DOES NOT RECOVER! >new Bottom() >new Top() >Top.activate() >new Bottom() > The Bottom component never gets added to Top. This is a very serious problem > for reliable systems. I see this behaviour on 2.0.4, 2.0.6, and 2.0.8 > -- > I've traced the cycle problem in 2.0.2. What happens is: > 1) The Bottom configuration is started. There is no Top, so it is not > satisfied > 2) The Top configuration is started. It is satisfied since it can live with 0 > Bottoms. > 3) The top configuration registers Top > 4) The bottom configuration sees a Top and initiates Bottom > 5) The bottom configuration gets Top (which is under construction) > 6) The top configuration looks at its dependencies > 7) The top configuration sees there is a Bottom now and tries to get it > 8) The bottom factory is called again on the same thread and blows up > I am not sure what happens in 2.0.4 and later but it does look scary that > Bottom is now never added to the Top. > Fix > I tried to do the activation in a background thread that but that failed. I > think the cycle should be detected and and de Top should not get its dynamic > dependencies after the activate method returned. But, just a guess, this is > complicated stuff. > Workaround > The workaround is to not let Top register as a service but manually register > it at the end of the activate method. Since the service is then already > initialized and registered, the Bottom will not get activated until the Top > is done. > There is a bnd workspace that consistently shows this output. > https://github.com/pkriens/felix.scr.cycle > I've added 4 log files. 2.0.4 and 2.0.8 seem to act very similar -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (FELIX-5618) Cycles in DS depending on bundle order
[ https://issues.apache.org/jira/browse/FELIX-5618?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16107063#comment-16107063 ] Peter Kriens commented on FELIX-5618: - Help! Any progress here? > Cycles in DS depending on bundle order > -- > > Key: FELIX-5618 > URL: https://issues.apache.org/jira/browse/FELIX-5618 > Project: Felix > Issue Type: Bug > Components: Declarative Services (SCR) > Environment: MacOS + Windows + Linux >Reporter: Peter Kriens >Priority: Blocker > Attachments: scr-cycle-2.0.2-bottom-top.txt, > scr-cycle-2.0.2-top-bottom.txt, scr-cycle-2.0.6-bottom-top.txt, > scr-cycle-2.0.6-top-bottom.txt > > > Following test case: >top.jar: Top @Reference volatile List >bottom.jar: Bottom @Reference Top > In SCR 2.0.2: > top.jar, bottom.jar -> OK, see trace >new Top() >Top.activate() >new Bottom() >Bottom.top= >Bottom.activate() > Top.bottom += > bottom.jar, top.jar -> FAILS but recovers > [osgi.enroute.examples.concurrency.cycle.bottom.Bottom(1)] > Circular reference detected, getService returning null > new Top() > Top.activate() > new Bottom() > Bottom.top= > Bottom.activate() > Top.bottom += > In SCR 2.0.4 and later > top.jar,bottom.jar -> OK >new Top() >Top.activate() >new Bottom() >Bottom.top= >Bottom.activate() >Top.bottom += > bottom.jar, top.jar -> FAILS and DOES NOT RECOVER! >new Bottom() >new Top() >Top.activate() >new Bottom() > The Bottom component never gets added to Top. This is a very serious problem > for reliable systems. I see this behaviour on 2.0.4, 2.0.6, and 2.0.8 > -- > I've traced the cycle problem in 2.0.2. What happens is: > 1) The Bottom configuration is started. There is no Top, so it is not > satisfied > 2) The Top configuration is started. It is satisfied since it can live with 0 > Bottoms. > 3) The top configuration registers Top > 4) The bottom configuration sees a Top and initiates Bottom > 5) The bottom configuration gets Top (which is under construction) > 6) The top configuration looks at its dependencies > 7) The top configuration sees there is a Bottom now and tries to get it > 8) The bottom factory is called again on the same thread and blows up > I am not sure what happens in 2.0.4 and later but it does look scary that > Bottom is now never added to the Top. > Fix > I tried to do the activation in a background thread that but that failed. I > think the cycle should be detected and and de Top should not get its dynamic > dependencies after the activate method returned. But, just a guess, this is > complicated stuff. > Workaround > The workaround is to not let Top register as a service but manually register > it at the end of the activate method. Since the service is then already > initialized and registered, the Bottom will not get activated until the Top > is done. > There is a bnd workspace that consistently shows this output. > https://github.com/pkriens/felix.scr.cycle > I've added 4 log files. 2.0.4 and 2.0.8 seem to act very similar -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (FELIX-5618) Cycles in DS depending on bundle order
[ https://issues.apache.org/jira/browse/FELIX-5618?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16040897#comment-16040897 ] Peter Kriens commented on FELIX-5618: - Where are we with this? > Cycles in DS depending on bundle order > -- > > Key: FELIX-5618 > URL: https://issues.apache.org/jira/browse/FELIX-5618 > Project: Felix > Issue Type: Bug > Components: Declarative Services (SCR) > Environment: MacOS + Windows + Linux >Reporter: Peter Kriens >Priority: Blocker > Attachments: scr-cycle-2.0.2-bottom-top.txt, > scr-cycle-2.0.2-top-bottom.txt, scr-cycle-2.0.6-bottom-top.txt, > scr-cycle-2.0.6-top-bottom.txt > > > Following test case: >top.jar: Top @Reference volatile List >bottom.jar: Bottom @Reference Top > In SCR 2.0.2: > top.jar, bottom.jar -> OK, see trace >new Top() >Top.activate() >new Bottom() >Bottom.top= >Bottom.activate() > Top.bottom += > bottom.jar, top.jar -> FAILS but recovers > [osgi.enroute.examples.concurrency.cycle.bottom.Bottom(1)] > Circular reference detected, getService returning null > new Top() > Top.activate() > new Bottom() > Bottom.top= > Bottom.activate() > Top.bottom += > In SCR 2.0.4 and later > top.jar,bottom.jar -> OK >new Top() >Top.activate() >new Bottom() >Bottom.top= >Bottom.activate() >Top.bottom += > bottom.jar, top.jar -> FAILS and DOES NOT RECOVER! >new Bottom() >new Top() >Top.activate() >new Bottom() > The Bottom component never gets added to Top. This is a very serious problem > for reliable systems. I see this behaviour on 2.0.4, 2.0.6, and 2.0.8 > -- > I've traced the cycle problem in 2.0.2. What happens is: > 1) The Bottom configuration is started. There is no Top, so it is not > satisfied > 2) The Top configuration is started. It is satisfied since it can live with 0 > Bottoms. > 3) The top configuration registers Top > 4) The bottom configuration sees a Top and initiates Bottom > 5) The bottom configuration gets Top (which is under construction) > 6) The top configuration looks at its dependencies > 7) The top configuration sees there is a Bottom now and tries to get it > 8) The bottom factory is called again on the same thread and blows up > I am not sure what happens in 2.0.4 and later but it does look scary that > Bottom is now never added to the Top. > Fix > I tried to do the activation in a background thread that but that failed. I > think the cycle should be detected and and de Top should not get its dynamic > dependencies after the activate method returned. But, just a guess, this is > complicated stuff. > Workaround > The workaround is to not let Top register as a service but manually register > it at the end of the activate method. Since the service is then already > initialized and registered, the Bottom will not get activated until the Top > is done. > There is a bnd workspace that consistently shows this output. > https://github.com/pkriens/felix.scr.cycle > I've added 4 log files. 2.0.4 and 2.0.8 seem to act very similar -- This message was sent by Atlassian JIRA (v6.3.15#6346)
Re: memory visibility of @Reference service references
Late to the discussion but just want to shed some light on this. This
discussion has been held before.
Volatile fields are not required for STATIC references because there is an
implicit lock in the execution path from BundleContext.getService to the
instance. Since this is the only way you can officially get an instance it is
perfectly safe to not make the field volatile.
The spec prescribes or implies the following:
The activation is executed exactly once
No caller of getService can see the object before activate has finished
So what must happen under the hood
Tscr: Register Service Factory SF for S
Tscr: notify service event
T1 -> getService S
T2 -> getService S
Since the spec mandates that an activate for instance I must be run exactly
once AND you cannot access an unactivated instance, SF MUST have a lock. Since
T1 was first, it gets it, T2 is blocked
T1: get lock L -> pass
T2: get L -> block
T1: create instance I
T1: inject fields in I
T1: activate I
T1: unlock L
T2: get lock L -> pass
T2: get initialized instance I
T2: unlock L
T2: use I
T1: use I
Since I can only be reached through the getService call, which will call the
ServiceFactory.getService, it is impossible for a thread Tx to not pass the
lock in the Service Factory SF for S. Thus, T2 always sees I after T1 finished
activating it. Ergo, there is no need to use volatile for a static variable.
Kind regards,
Peter Kriens
[jira] [Commented] (FELIX-5618) Cycles in DS depending on bundle order
[ https://issues.apache.org/jira/browse/FELIX-5618?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15980355#comment-15980355 ] Peter Kriens commented on FELIX-5618: - That would be great! And about bndtools, what's stopping you? We now fully support using a POM as repository. > Cycles in DS depending on bundle order > -- > > Key: FELIX-5618 > URL: https://issues.apache.org/jira/browse/FELIX-5618 > Project: Felix > Issue Type: Bug > Components: Declarative Services (SCR) > Environment: MacOS + Windows + Linux >Reporter: Peter Kriens >Priority: Blocker > Attachments: scr-cycle-2.0.2-bottom-top.txt, > scr-cycle-2.0.2-top-bottom.txt, scr-cycle-2.0.6-bottom-top.txt, > scr-cycle-2.0.6-top-bottom.txt > > > Following test case: >top.jar: Top @Reference volatile List >bottom.jar: Bottom @Reference Top > In SCR 2.0.2: > top.jar, bottom.jar -> OK, see trace >new Top() >Top.activate() >new Bottom() >Bottom.top= >Bottom.activate() > Top.bottom += > bottom.jar, top.jar -> FAILS but recovers > [osgi.enroute.examples.concurrency.cycle.bottom.Bottom(1)] > Circular reference detected, getService returning null > new Top() > Top.activate() > new Bottom() > Bottom.top= > Bottom.activate() > Top.bottom += > In SCR 2.0.4 and later > top.jar,bottom.jar -> OK >new Top() >Top.activate() >new Bottom() >Bottom.top= >Bottom.activate() >Top.bottom += > bottom.jar, top.jar -> FAILS and DOES NOT RECOVER! >new Bottom() >new Top() >Top.activate() >new Bottom() > The Bottom component never gets added to Top. This is a very serious problem > for reliable systems. I see this behaviour on 2.0.4, 2.0.6, and 2.0.8 > -- > I've traced the cycle problem in 2.0.2. What happens is: > 1) The Bottom configuration is started. There is no Top, so it is not > satisfied > 2) The Top configuration is started. It is satisfied since it can live with 0 > Bottoms. > 3) The top configuration registers Top > 4) The bottom configuration sees a Top and initiates Bottom > 5) The bottom configuration gets Top (which is under construction) > 6) The top configuration looks at its dependencies > 7) The top configuration sees there is a Bottom now and tries to get it > 8) The bottom factory is called again on the same thread and blows up > I am not sure what happens in 2.0.4 and later but it does look scary that > Bottom is now never added to the Top. > Fix > I tried to do the activation in a background thread that but that failed. I > think the cycle should be detected and and de Top should not get its dynamic > dependencies after the activate method returned. But, just a guess, this is > complicated stuff. > Workaround > The workaround is to not let Top register as a service but manually register > it at the end of the activate method. Since the service is then already > initialized and registered, the Bottom will not get activated until the Top > is done. > There is a bnd workspace that consistently shows this output. > https://github.com/pkriens/felix.scr.cycle > I've added 4 log files. 2.0.4 and 2.0.8 seem to act very similar -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (FELIX-5618) Cycles in DS depending on bundle order
[ https://issues.apache.org/jira/browse/FELIX-5618?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15978205#comment-15978205 ] Peter Kriens commented on FELIX-5618: - If you checkout the workspace in bndtools then double click the bnd.bnd file in the osgi.enrout.examples.concurrency.cycle project, select the Run tab, click on the Run or Debug icon right top of the window. You can switch the order of the bundles by going to the Source tab and reorder the -runbundles list. The problem is both in the field and event strategy. I switch to the even strategy to show the ordering with sysouts. If you want it with different versions you can change the -runbundles. Extra dependencies can be added via https://github.com/pkriens/felix.scr.cycle/blob/master/cnf/central.xml, which is a normal POM. In bndtools, you need to trigger the update by modifying build.bnd to kick it. (Add a space or so) > Cycles in DS depending on bundle order > -- > > Key: FELIX-5618 > URL: https://issues.apache.org/jira/browse/FELIX-5618 > Project: Felix > Issue Type: Bug > Components: Declarative Services (SCR) > Environment: MacOS + Windows + Linux >Reporter: Peter Kriens >Priority: Blocker > Attachments: scr-cycle-2.0.2-bottom-top.txt, > scr-cycle-2.0.2-top-bottom.txt, scr-cycle-2.0.6-bottom-top.txt, > scr-cycle-2.0.6-top-bottom.txt > > > Following test case: >top.jar: Top @Reference volatile List >bottom.jar: Bottom @Reference Top > In SCR 2.0.2: > top.jar, bottom.jar -> OK, see trace >new Top() >Top.activate() >new Bottom() >Bottom.top= >Bottom.activate() > Top.bottom += > bottom.jar, top.jar -> FAILS but recovers > [osgi.enroute.examples.concurrency.cycle.bottom.Bottom(1)] > Circular reference detected, getService returning null > new Top() > Top.activate() > new Bottom() > Bottom.top= > Bottom.activate() > Top.bottom += > In SCR 2.0.4 and later > top.jar,bottom.jar -> OK >new Top() >Top.activate() >new Bottom() >Bottom.top= >Bottom.activate() >Top.bottom += > bottom.jar, top.jar -> FAILS and DOES NOT RECOVER! >new Bottom() >new Top() >Top.activate() >new Bottom() > The Bottom component never gets added to Top. This is a very serious problem > for reliable systems. I see this behaviour on 2.0.4, 2.0.6, and 2.0.8 > -- > I've traced the cycle problem in 2.0.2. What happens is: > 1) The Bottom configuration is started. There is no Top, so it is not > satisfied > 2) The Top configuration is started. It is satisfied since it can live with 0 > Bottoms. > 3) The top configuration registers Top > 4) The bottom configuration sees a Top and initiates Bottom > 5) The bottom configuration gets Top (which is under construction) > 6) The top configuration looks at its dependencies > 7) The top configuration sees there is a Bottom now and tries to get it > 8) The bottom factory is called again on the same thread and blows up > I am not sure what happens in 2.0.4 and later but it does look scary that > Bottom is now never added to the Top. > Fix > I tried to do the activation in a background thread that but that failed. I > think the cycle should be detected and and de Top should not get its dynamic > dependencies after the activate method returned. But, just a guess, this is > complicated stuff. > Workaround > The workaround is to not let Top register as a service but manually register > it at the end of the activate method. Since the service is then already > initialized and registered, the Bottom will not get activated until the Top > is done. > There is a bnd workspace that consistently shows this output. > https://github.com/pkriens/felix.scr.cycle > I've added 4 log files. 2.0.4 and 2.0.8 seem to act very similar -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (FELIX-5618) Cycles in DS depending on bundle order
Peter Kriens created FELIX-5618: --- Summary: Cycles in DS depending on bundle order Key: FELIX-5618 URL: https://issues.apache.org/jira/browse/FELIX-5618 Project: Felix Issue Type: Bug Components: Declarative Services (SCR) Environment: MacOS + Windows + Linux Reporter: Peter Kriens Priority: Blocker Attachments: scr-cycle-2.0.2-bottom-top.txt, scr-cycle-2.0.2-top-bottom.txt, scr-cycle-2.0.6-bottom-top.txt, scr-cycle-2.0.6-top-bottom.txt Following test case: top.jar: Top @Reference volatile List bottom.jar: Bottom @Reference Top In SCR 2.0.2: top.jar, bottom.jar -> OK, see trace new Top() Top.activate() new Bottom() Bottom.top= Bottom.activate() Top.bottom += bottom.jar, top.jar -> FAILS but recovers [osgi.enroute.examples.concurrency.cycle.bottom.Bottom(1)] Circular reference detected, getService returning null new Top() Top.activate() new Bottom() Bottom.top= Bottom.activate() Top.bottom += In SCR 2.0.4 and later top.jar,bottom.jar -> OK new Top() Top.activate() new Bottom() Bottom.top= Bottom.activate() Top.bottom += bottom.jar, top.jar -> FAILS and DOES NOT RECOVER! new Bottom() new Top() Top.activate() new Bottom() The Bottom component never gets added to Top. This is a very serious problem for reliable systems. I see this behaviour on 2.0.4, 2.0.6, and 2.0.8 -- I've traced the cycle problem in 2.0.2. What happens is: 1) The Bottom configuration is started. There is no Top, so it is not satisfied 2) The Top configuration is started. It is satisfied since it can live with 0 Bottoms. 3) The top configuration registers Top 4) The bottom configuration sees a Top and initiates Bottom 5) The bottom configuration gets Top (which is under construction) 6) The top configuration looks at its dependencies 7) The top configuration sees there is a Bottom now and tries to get it 8) The bottom factory is called again on the same thread and blows up I am not sure what happens in 2.0.4 and later but it does look scary that Bottom is now never added to the Top. Fix I tried to do the activation in a background thread that but that failed. I think the cycle should be detected and and de Top should not get its dynamic dependencies after the activate method returned. But, just a guess, this is complicated stuff. Workaround The workaround is to not let Top register as a service but manually register it at the end of the activate method. Since the service is then already initialized and registered, the Bottom will not get activated until the Top is done. There is a bnd workspace that consistently shows this output. https://github.com/pkriens/felix.scr.cycle I've added 4 log files. 2.0.4 and 2.0.8 seem to act very similar -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (FELIX-5604) Multi value attribute in Require Capability with List type isn't
Peter Kriens created FELIX-5604: --- Summary: Multi value attribute in Require Capability with List type isn't Key: FELIX-5604 URL: https://issues.apache.org/jira/browse/FELIX-5604 Project: Felix Issue Type: Bug Reporter: Peter Kriens A Require-Capability like 'com.example.other;theList:List=\"one,two,three\"' returns the String "one,two,three" instead of ["one","two","three"]. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (FELIX-5586) Gogo runtime overloads the addCommand in the wrong way
Peter Kriens created FELIX-5586: --- Summary: Gogo runtime overloads the addCommand in the wrong way Key: FELIX-5586 URL: https://issues.apache.org/jira/browse/FELIX-5586 Project: Felix Issue Type: Bug Reporter: Peter Kriens Priority: Minor The addCommand(scope,target) is very uncomfortable to use with a class. It is extremely useful to add all static methods of a class as commands. However, due to the overloading one cannot call the proper method. The consequence is that you need to load the class through a bundle which is yucky. Easiest to add an addStatic method that that takes (String scope, Class target). -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (FELIX-5091) Allow to exclude system packages without redefining all exports
[ https://issues.apache.org/jira/browse/FELIX-5091?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14977993#comment-14977993 ] Peter Kriens commented on FELIX-5091: - The format of the org.osgi.framework.system.packages.extra is standardized by the OSGi so you are creating proprietary extensions. In this particular case it is a bad idea anyway since you can run into problems with the uses constraints. I think sql packages referent to jta. Since the sql packages come from the JVM, you create a nice mess. The only proper solution Ive found is to put the correct JTA package on the same class path as where framework resides. This will then fill in the missing package from the JVM. In bndtools this is easily done by placing the jar on the -runpath -runpath: javax.transaction;version=1.1 If it has an exports they will be automatically added to the system packages. > Allow to exclude system packages without redefining all exports > --- > > Key: FELIX-5091 > URL: https://issues.apache.org/jira/browse/FELIX-5091 > Project: Felix > Issue Type: Improvement > Components: Framework >Affects Versions: framework-5.4.0 >Reporter: Christian Schneider > Fix For: framework-5.6.0 > > > There are several cases where the OSGi framework exports system packages by > default but the result is not usable. > For example javax.transaction is exported but the package is not complete. So > a regular case is to exclude this package and provide it as a bundle. > Currently this can be done by redefining org.osgi.framework.system.packages. > The problem is that you then need to redefine all the system packages which > is a big list and additionally differs between java versions. > So I propose to allow to exclude single packages without having to redefine > them all. > One simple solution would be to use org.osgi.framework.system.packages.extra > and allow to specify a package to exclude by prefixing it with "-". > E.g. > org.osgi.framework.system.packages.extra=-javax.transaction,-javax.transaction.xa > This would avoid creating another framework property. > Alternatively we could introduce a new property like: > org.osgi.framework.system.packages.exclude=javax.transaction,javax.transaction.xa > This property would then only allow to exclude exports. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Re: git?
And it takes .3 secs to switch your workspace between your two branches/tags … Don’t forget that a lot of things that are heavy in SVN are feather weight in Git. Kind regards, Peter Kriens > On 26 okt. 2015, at 10:03, Carsten Ziegeler wrote: > > Am 25.10.15 um 17:12 schrieb David Jencks: >> Hi, >> >> In the 12+ years I’ve been working on apache projects I can’t recall any >> time when I’ve wanted to simultaneously check out different branches of >> modules of the same top level project. Therefore, unless anyone has actual >> contrary experience, I’d be in favor of trying a single git repo and >> refining it into multiple repos if we discover problems in real life use. >> (I have wanted to check out different branches of the same project >> simultaneously, but with git this is not helped by more repos). > > But if you to look at two modules in detail, like .e.g. a specific tag > or branch of event admin and a tag/branch of metatype, you can't do this > with a single git repo. You can only see one or the other. > Therefore I don't think a single git repo is a good thing. > > Carsten >> >> thanks >> david jencks >> >>> On Oct 25, 2015, at 2:47 AM, Christian Schneider >>> wrote: >>> >>> I am not sure if one git repo for everything would be a good idea. The main >>> reason is that in git (unlike in subversion) each branch and tag you do >>> contains all the other unrelated projects too. >>> I think it would also be quite difficult to checkout a state of the repo >>> where you need bundle A in branch A1 and bundle B in branch B2. Probably >>> this would mean that you need to checkout two instances of the repo >>> to have both branches visisble at the same time. You would then also have >>> to be really careful to not pick a project from the wrong checkout as it >>> would be in kind of an undefined state there. >>> >>> The other solution of having one git repo per bundle also seems to be quite >>> difficult to manage as you need to checkout and sync every such checkout in >>> the correct way. I have seen a project that does this at a customer and it >>> is not very easy to work in this structure. >>> >>> In the Aries project we went for kind of a compromise. >>> >>> We aim for releases by subproject. So each subproject can go into one git >>> repo. >>> The advantage is that each tag in git really covers the whole subproject. >>> So from the git side this is natural. >>> >>> The downside is of course that in many cases bundles are released that did >>> not change at all. >>> We make sure the package versions are done with semantic versioning. So >>> from the OSGi point of view the versioning >>> is still working as before. >>> >>> At the moment we have not yet done the migration to git but it is planned. >>> We are currently moving each subproject to the release by subproject model >>> gradually. >>> Theoretically we can then move each subproject to git independently. I am >>> not sure though how to move the change history over in that case. >>> In any case the Aries JPA project is the first one that is fully converted >>> to the release by subproject model if you want to take a look. >>> https://github.com/apache/aries/tree/trunk/jpa >>> >>> Christian >>> >>> Am 24.10.2015 um 23:32 schrieb Benson Margulies: >>>> On Sat, Oct 24, 2015 at 4:21 PM, David Jencks >>>> wrote: >>>>> I like having several felix subprojects open in one eclipse instance at >>>>> once, which the current svn structure facilitates. Having just one git >>>>> svn rebase to run is nice. Is there a way to stitch together several >>>>> smaller git repos that would work similarly? Not knowing how to do this, >>>>> I am starting to lean towards one big repo. >>>> Well, there are git submodules. But I hate to take everyone into that >>>> rabbit hole. I think we should aim to start with one big repo and >>>> assume we can tame the maven-release-plugin to start with. >>>> >>>> >>>>> FWIW, I’m hoping to move DS onto a gradle based build soon. >>>>> >>>>> thanks >>>>> david jencks >>>>> >>>>>> On Oct 24, 2015, at 2:51 PM, Benson Margulies >>>>>> wrote: >>>>>> >>>>>> Greeting, Marcel
Re: [http] Should we include the api bundle in the jetty one?
Yeah! Providers of an API should provide their API since they have a very small import range anyway. Kind regards, Peter Kriens > On 1 okt. 2015, at 17:44, Carsten Ziegeler wrote: > > I think we're making the use of our standard http implementation based > on jetty too complicated: it requires to install the api and the jetty > bundle, although without the api bundle, the jetty one is totally > useless. And as the jetty bundle implements the api bundle, it's tied to > a specific version. > > Therefore I think we should simply include the api bundle in the jetty > bundle. > > If no one objects, I'll do the changes. > > Thanks > Carsten > -- > Carsten Ziegeler > Adobe Research Switzerland > cziege...@apache.org
[jira] [Commented] (FELIX-4720) Web Console and Gogo rely on Log history buffer in the Log Service
[ https://issues.apache.org/jira/browse/FELIX-4720?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14248087#comment-14248087 ] Peter Kriens commented on FELIX-4720: - I also added a new log command in Basic that takes options but can also be called without any arguments. log scope: felix flags: -n, --noexceptions Do not print exceptions. -r, --reverse Reverse the printout order to oldest is last options: -l, --level Minimum level (error,warning,info,debug). Default is warning. [optional] -m, --max Maximum number of entries to print [optional] -s, --skip Skip the first entries [optional] -y, --style Print style (classic,abbr) [optional] > Web Console and Gogo rely on Log history buffer in the Log Service > -- > > Key: FELIX-4720 > URL: https://issues.apache.org/jira/browse/FELIX-4720 > Project: Felix > Issue Type: Bug > Components: Gogo Command, Web Console > Reporter: Peter Kriens > > The OSGi Log Reader Service has a command to get the history of the log. > However, the specification states that this history can be empty. The Equinox > framework is nowadays registering a Log Reader Service that has such an empty > history to prevent pinning objects in memory. > Using the history this way was always at odds with the specification since > the history was only intended to hold the start up events. The primary model > of the Log Service is a dispatcher. > I suggest that the Gogo log command and the Web Console maintain their own > history buffer to become independent on this fragile history buffer in the > Log Reader service. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (FELIX-4720) Web Console and Gogo rely on Log history buffer in the Log Service
[ https://issues.apache.org/jira/browse/FELIX-4720?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14248086#comment-14248086 ] Peter Kriens commented on FELIX-4720: - I just did this work for Gogo, if this is okayed, then the LogTracker class can also be copied to Web Console > Web Console and Gogo rely on Log history buffer in the Log Service > -- > > Key: FELIX-4720 > URL: https://issues.apache.org/jira/browse/FELIX-4720 > Project: Felix > Issue Type: Bug > Components: Gogo Command, Web Console > Reporter: Peter Kriens > > The OSGi Log Reader Service has a command to get the history of the log. > However, the specification states that this history can be empty. The Equinox > framework is nowadays registering a Log Reader Service that has such an empty > history to prevent pinning objects in memory. > Using the history this way was always at odds with the specification since > the history was only intended to hold the start up events. The primary model > of the Log Service is a dispatcher. > I suggest that the Gogo log command and the Web Console maintain their own > history buffer to become independent on this fragile history buffer in the > Log Reader service. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (FELIX-4720) Web Console and Gogo rely on Log history buffer in the Log Service
[ https://issues.apache.org/jira/browse/FELIX-4720?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14248084#comment-14248084 ] Peter Kriens commented on FELIX-4720: - I've created a new version of Basic and added a separate LogTracker class that handles all the log details now. I've not committed anything for a long time ... is everybody ok if I commit this after which a few people will review? > Web Console and Gogo rely on Log history buffer in the Log Service > -- > > Key: FELIX-4720 > URL: https://issues.apache.org/jira/browse/FELIX-4720 > Project: Felix > Issue Type: Bug > Components: Gogo Command, Web Console >Reporter: Peter Kriens > > The OSGi Log Reader Service has a command to get the history of the log. > However, the specification states that this history can be empty. The Equinox > framework is nowadays registering a Log Reader Service that has such an empty > history to prevent pinning objects in memory. > Using the history this way was always at odds with the specification since > the history was only intended to hold the start up events. The primary model > of the Log Service is a dispatcher. > I suggest that the Gogo log command and the Web Console maintain their own > history buffer to become independent on this fragile history buffer in the > Log Reader service. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (FELIX-4720) Web Console and Gogo rely on Log history buffer in the Log Service
[ https://issues.apache.org/jira/browse/FELIX-4720?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14241202#comment-14241202 ] Peter Kriens commented on FELIX-4720: - It feels a bit like I am on candid camera :-) In the end the user sees that Gogo & Webconsole do not work against a valid OSGi implementation of Log (Reader) Service that passes the TCK I'll provide a patch because as Carsten says this discussion is taking me more time than fixing it :-( > Web Console and Gogo rely on Log history buffer in the Log Service > -- > > Key: FELIX-4720 > URL: https://issues.apache.org/jira/browse/FELIX-4720 > Project: Felix > Issue Type: Bug > Components: Gogo Command, Web Console >Reporter: Peter Kriens > > The OSGi Log Reader Service has a command to get the history of the log. > However, the specification states that this history can be empty. The Equinox > framework is nowadays registering a Log Reader Service that has such an empty > history to prevent pinning objects in memory. > Using the history this way was always at odds with the specification since > the history was only intended to hold the start up events. The primary model > of the Log Service is a dispatcher. > I suggest that the Gogo log command and the Web Console maintain their own > history buffer to become independent on this fragile history buffer in the > Log Reader service. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (FELIX-4720) Web Console and Gogo rely on Log history buffer in the Log Service
[ https://issues.apache.org/jira/browse/FELIX-4720?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14240546#comment-14240546 ] Peter Kriens commented on FELIX-4720: - @Marcel: I disagree. The simplest solution is just to create an internal queue and fill it with the log history, whatever that is, and the just add the new events. This is a few lines of code and requires no special handling. KISS! > Web Console and Gogo rely on Log history buffer in the Log Service > -- > > Key: FELIX-4720 > URL: https://issues.apache.org/jira/browse/FELIX-4720 > Project: Felix > Issue Type: Bug > Components: Gogo Command, Web Console > Reporter: Peter Kriens > > The OSGi Log Reader Service has a command to get the history of the log. > However, the specification states that this history can be empty. The Equinox > framework is nowadays registering a Log Reader Service that has such an empty > history to prevent pinning objects in memory. > Using the history this way was always at odds with the specification since > the history was only intended to hold the start up events. The primary model > of the Log Service is a dispatcher. > I suggest that the Gogo log command and the Web Console maintain their own > history buffer to become independent on this fragile history buffer in the > Log Reader service. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (FELIX-4720) Web Console and Gogo rely on Log history buffer in the Log Service
[ https://issues.apache.org/jira/browse/FELIX-4720?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14239466#comment-14239466 ] Peter Kriens commented on FELIX-4720: - Surprised about the reactions. Fact is, it does not work ... You can blame Equinox but that is not going to help anybody. I filed a bug with Equinox to or disable or create a buffer but fact is they are compliant however you want to interpret the spec. If this was my project I would already have implemented :-) How hard can it be? P.S. The Log Reader Service not a whiteboard ... I can honestly tell you that I tried very hard to make it whiteboard but failed just before OSGi Release 1. That loss also was the reason HttpService is not whiteboard. So don't blame me ... :-) > Web Console and Gogo rely on Log history buffer in the Log Service > -- > > Key: FELIX-4720 > URL: https://issues.apache.org/jira/browse/FELIX-4720 > Project: Felix > Issue Type: Bug > Components: Gogo Command, Web Console >Reporter: Peter Kriens > > The OSGi Log Reader Service has a command to get the history of the log. > However, the specification states that this history can be empty. The Equinox > framework is nowadays registering a Log Reader Service that has such an empty > history to prevent pinning objects in memory. > Using the history this way was always at odds with the specification since > the history was only intended to hold the start up events. The primary model > of the Log Service is a dispatcher. > I suggest that the Gogo log command and the Web Console maintain their own > history buffer to become independent on this fragile history buffer in the > Log Reader service. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (FELIX-4720) Web Console and Gogo rely on Log history buffer in the Log Service
[ https://issues.apache.org/jira/browse/FELIX-4720?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14238983#comment-14238983 ] Peter Kriens commented on FELIX-4720: - a) Pinning by the framework is quite different from pinning by a bundle, especially if the bundle is geared towards debugging. It then becomes a choice of the bundle how to do this (i.e.they could turn the log entry exceptions that are the pinning culprit into strings or so. The framework cannot do it. b) The OSGi spec does not give you any guarantee about the history, so yes, you could already lose events. c) The bug explains why you cannot override the Equinox log service in an easy way d) The OSGi services are enablers, not trying to be efficient, that is up to implementations I do not think there is any reason to become defensive. The Equinox log is a perfectly valid Log Service implementation that show that WebConsols & Gogo fail a compliant implementation. Of course you can ignore this issue (and I filed a corresponding bug on Eclipse to disable the built-in Log Service or provide a buffer) but the fact is that WebConsole fails on a perfectly legitimate implementation. Since it is not hat hard to fix, I would fix it. > Web Console and Gogo rely on Log history buffer in the Log Service > -- > > Key: FELIX-4720 > URL: https://issues.apache.org/jira/browse/FELIX-4720 > Project: Felix > Issue Type: Bug > Components: Gogo Command, Web Console >Reporter: Peter Kriens > > The OSGi Log Reader Service has a command to get the history of the log. > However, the specification states that this history can be empty. The Equinox > framework is nowadays registering a Log Reader Service that has such an empty > history to prevent pinning objects in memory. > Using the history this way was always at odds with the specification since > the history was only intended to hold the start up events. The primary model > of the Log Service is a dispatcher. > I suggest that the Gogo log command and the Web Console maintain their own > history buffer to become independent on this fragile history buffer in the > Log Reader service. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (FELIX-4720) Web Console and Gogo rely on Log history buffer in the Log Service
Peter Kriens created FELIX-4720: --- Summary: Web Console and Gogo rely on Log history buffer in the Log Service Key: FELIX-4720 URL: https://issues.apache.org/jira/browse/FELIX-4720 Project: Felix Issue Type: Bug Components: Gogo Command, Web Console Reporter: Peter Kriens The OSGi Log Reader Service has a command to get the history of the log. However, the specification states that this history can be empty. The Equinox framework is nowadays registering a Log Reader Service that has such an empty history to prevent pinning objects in memory. Using the history this way was always at odds with the specification since the history was only intended to hold the start up events. The primary model of the Log Service is a dispatcher. I suggest that the Gogo log command and the Web Console maintain their own history buffer to become independent on this fragile history buffer in the Log Reader service. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Apache Felix Maven plugin
In the bnd(tools) group We currently are discussing the maven bundle plugin.
The idea was raised to build this plugin during the normal continuous
integration so we can keep the version current. We are already building another
maven plugin in our build and releasing it so it should be quite
straightforward for us. This would have the benefit that whenever we release a
candidate or a final version we would put it in maven central as quickly as
possible. From a logical point of view it seems to make sense to move the
Apache Felix Bundle plugin into the bnd build since it is so closely coupled to
bnd.
That said, logical is sometimes to rational (and there might be drawbacks we
have not considered). Obviously we do not want to do anything that goes against
the wishes of the Apache Felix group, we value this group way too highly to
offend it so if the feelings here are not abundantly positive then we won't
even look in that direction.
Are there any drawbacks? How does this group feel about this?
Kind regards,
Peter Kriens
smime.p7s
Description: S/MIME cryptographic signature
Re: Any plans to make PojoSR part of Apache Felix
Great name!!! Wonderful idea, it is still one of the least recognized jewels in the toolbox to move to OSGi. Kind regards, Peter Kriens On 5 mrt. 2014, at 13:43, Karl Pauls wrote: > Hi Chetan, > > im more than willing to have PojoSR move to Felix - provided you (or > somebody else) is willing to do the legwork. I guess we'll have to funnel > it through the incubator ip clearance, rename the packages, and cut a > release. If somebody volunteers to drive this then lets do it (and yes, I'm > looking at you, Clement :-). > > Perspectively, it would be nice to really integrate it with the framework > - i.e., we should make it so that it gets the parts it needs from the > framework either directly from the framework subproject or factor out the > service registry and have framework and PojoSR depend on it. However, for > starters, just renaming what is there and worry about something like this > later is fine too. > > Btw., if so, we should maybe rename it - I'm pretty sure nobody is going to > complain if we call it Apache Felix Connect :-). > > regards, > > Karl > > > On Wed, Mar 5, 2014 at 5:46 AM, Chetan Mehrotra > wrote: >> >> Hi, >> >> <> to both group sending it to both groups>> >> >> In Apache Jackrabbit Oak [1] we have inbuilt support for OSGi based >> deployments. To reuse the logic for non OSGi env I was investigating >> [2] PojoSR [3] and it looks pretty useful and most of the stuff works >> out of the box without requiring any change. >> >> Wanted to check if there were any thoughts on moving this project to >> Apache Felix >> >> Chetan Mehrotra >> [1] http://jackrabbit.apache.org/oak/ >> [2] http://jackrabbit-oak.markmail.org/thread/7zpux64mj6vecwzf >> [3] https://code.google.com/p/pojosr/ >> >> -- >> Sie erhalten diese Nachricht, weil Sie Mitglied der Google Groups-Gruppe > "pojosr-discuss" sind. >> Um Ihr Abonnement für diese Gruppe zu beenden und keine E-Mails mehr von > dieser Gruppe zu erhalten, senden Sie eine E-Mail an > pojosr-discuss+unsubscr...@googlegroups.com. >> Weitere Optionen: https://groups.google.com/groups/opt_out > > > > > -- > Karl Pauls > karlpa...@gmail.com > http://twitter.com/karlpauls > http://www.linkedin.com/in/karlpauls > https://profiles.google.com/karlpauls
[jira] [Created] (FELIX-4302) Config Admin can create illegal names on windows
Peter Kriens created FELIX-4302: --- Summary: Config Admin can create illegal names on windows Key: FELIX-4302 URL: https://issues.apache.org/jira/browse/FELIX-4302 Project: Felix Issue Type: Bug Components: Configuration Admin Reporter: Peter Kriens The following names are not allowed to be used in a path on Windows: CON, PRN, AUX, CLOCK$, NUL, COM1 ... COM9, LPT1 ... LPT9. If the last part of the PID is one of these names then an exception results. I guess adding an extension (.cfg) to this file would prevent this clash. There might actually java.io.IOException: Het systeem kan het opgegeven pad niet vinden at java.io.WinNTFileSystem.createFileExclusively(Native Method) at java.io.File.createNewFile(File.java:1006) at java.io.File.createTempFile(File.java:1989) at org.apache.felix.cm.file.FilePersistenceManager._store(FilePersistenceManager.java:621) at org.apache.felix.cm.file.FilePersistenceManager.store(FilePersistenceManager.java:582) at org.apache.felix.cm.impl.CachingPersistenceManagerProxy.store(CachingPersistenceManagerProxy.java:173) at org.apache.felix.cm.impl.ConfigurationImpl.update(ConfigurationImpl.java:387) at org.apache.felix.cm.impl.ConfigurationAdapter.update(ConfigurationAdapter.java:131) at aQute.impl.configurer.Configurer.configure(Configurer.java:147) -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (FELIX-4291) maven-bundle-plugin issue with blueprint and inner-classes
[ https://issues.apache.org/jira/browse/FELIX-4291?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13805093#comment-13805093 ] Peter Kriens commented on FELIX-4291: - Even !*.*[A-Z]* might work :-) I filed a bnd issue : https://github.com/bndtools/bnd/issues/423 > maven-bundle-plugin issue with blueprint and inner-classes > -- > > Key: FELIX-4291 > URL: https://issues.apache.org/jira/browse/FELIX-4291 > Project: Felix > Issue Type: Bug > Components: Maven Bundle Plugin >Affects Versions: maven-bundle-plugin-2.4.0 >Reporter: Jean-Philippe CLEMENT > > Maven Bundle plugin generates an invalid package when an inner class is used > to instantiate a blueprint bean. > For instance the following blueprint: > > Generates the following entry in the manifest.mf Import-Package section: > Import-Package: org.test.MyClass > As MyClass is not a package and is part of the bundle, no Import-Package > entry should be generated in the manifest file. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (FELIX-4181) Provide a goal to generate Javadoc configuration
[ https://issues.apache.org/jira/browse/FELIX-4181?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13718193#comment-13718193 ] Peter Kriens commented on FELIX-4181: - Major Priority??? Sounds overdone for this issue. However, if this is done it would be nice if all the macros of the bnd plugin would be exportable to other plugins. > Provide a goal to generate Javadoc configuration > > > Key: FELIX-4181 > URL: https://issues.apache.org/jira/browse/FELIX-4181 > Project: Felix > Issue Type: Improvement > Components: Maven Bundle Plugin >Affects Versions: maven-bundle-plugin-2.4.0 >Reporter: Florian Brunner > Labels: maven > > Please provide a goal to generate the value for the excludePackageNames > property used by the Maven Javadoc Plugin. > Currently, this property has to be kept in sync manually with the exported > packages, e.g.: > *.internal.*:*.impl.* > See discussion: > http://stackoverflow.com/questions/11619744/osgi-apache-felix-maven-bundle-plugin-and-javadoc -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (FELIX-3477) NPE in BundleWiringImpl.searchImports
[ https://issues.apache.org/jira/browse/FELIX-3477?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13434895#comment-13434895 ] Peter Kriens commented on FELIX-3477: - I found another one: java.lang.NullPointerException at org.apache.felix.framework.BundleWiringImpl.findClassOrResourceByDelegation(BundleWiringImpl.java:1432) at org.apache.felix.framework.BundleWiringImpl.access$400(BundleWiringImpl.java:72) at org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.loadClass(BundleWiringImpl.java:1843) at java.lang.ClassLoader.loadClass(ClassLoader.java:247) at java.lang.Class.forName0(Native Method) at java.lang.Class.forName(Class.java:247) at sun.reflect.generics.factory.CoreReflectionFactory.makeNamedType(CoreReflectionFactory.java:95) at sun.reflect.generics.visitor.Reifier.visitClassTypeSignature(Reifier.java:107) at sun.reflect.generics.tree.ClassTypeSignature.accept(ClassTypeSignature.java:31) at sun.reflect.generics.visitor.Reifier.reifyTypeArguments(Reifier.java:50) at sun.reflect.generics.visitor.Reifier.visitClassTypeSignature(Reifier.java:120) at sun.reflect.generics.tree.ClassTypeSignature.accept(ClassTypeSignature.java:31) at sun.reflect.generics.repository.FieldRepository.getGenericType(FieldRepository.java:67) at java.lang.reflect.Field.getGenericType(Field.java:223) at aQute.lib.json.ObjectHandler.(ObjectHandler.java:32) > NPE in BundleWiringImpl.searchImports > - > > Key: FELIX-3477 > URL: https://issues.apache.org/jira/browse/FELIX-3477 > Project: Felix > Issue Type: Bug > Components: Framework >Affects Versions: framework-4.0.2 > Environment: JDK 6u31, Ubuntu >Reporter: Jesse Glick > > NetBeans unit tests in the org.netbeans.core.osgi module pass but print a lot > of stack traces when run against Felix 4.0.2: > Apr 23, 2012 7:06:57 PM org.openide.util.lookup.implspi.ActiveQueue$Daemon run > WARNING: Cannot process > org.openide.util.WeakListenerImpl$ListenerReference@1ce1bea > java.lang.NullPointerException > at > org.apache.felix.framework.BundleWiringImpl.searchImports(BundleWiringImpl.java:1508) > at > org.apache.felix.framework.BundleWiringImpl.findClassOrResourceByDelegation(BundleWiringImpl.java:1427) > at > org.apache.felix.framework.BundleWiringImpl.access$400(BundleWiringImpl.java:72) > at > org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.loadClass(BundleWiringImpl.java:1843) > at java.lang.ClassLoader.loadClass(ClassLoader.java:247) > at java.lang.Class.getDeclaredMethods0(Native Method) > at java.lang.Class.privateGetDeclaredMethods(Class.java:2427) > at java.lang.Class.getMethod0(Class.java:2670) > at java.lang.Class.getMethod(Class.java:1603) > at > org.openide.util.WeakListenerImpl$ListenerReference.getRemoveMethod(WeakListenerImpl.java:614) > at > org.openide.util.WeakListenerImpl$ListenerReference.run(WeakListenerImpl.java:572) > at > org.openide.util.lookup.implspi.ActiveQueue$Daemon.run(ActiveQueue.java:185) > (The ActiveQueue thread in this case is looking for listeners attached via > weak references which have since been collected, so that the stub listener > can be cleanly detached from the observable object. It is impossible to > guarantee exactly when this cleanup will run.) > Presumably BundleRevisionImpl.m_wiring is null. searchImports should I think > just treat this as if result==null. Can offer a patch if you like. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Is bundle plugin ready for a release ?
Sahoo,
Your original report was quite short, I had to "guess" what the problem was.
Richard told me that you were going to try to diagnose this further.
Stuart, could you make a new plugin? There has been some more renaming
unfortunately but bnd is now slowly becoming a decent public library with
semantic versioning. I never intended it to be a general library but it is
turning into one.
Kind regards,
Peter Kriens
On 20 jul. 2012, at 18:03, Peter Kriens wrote:
> Sahoo, I sent you a mail on June 25 for more information about the bug you
> reported. I think I fixed it but the original report did not provide enough
> information to be sure.
>
> Now I saw I sent it to the Sun address, does this no longer work for you?
>
> Kind regards,
>
> Peter Kriens
>
>
> On 19 jul. 2012, at 17:38, Sahoo wrote:
>
>> On Thursday 19 July 2012 06:27 PM, Stuart McCulloch wrote:
>>> On 19 Jul 2012, at 08:13, Guillaume Nodet wrote:
>>>
>>>> I'd like to do a release of the maven bundle plugin, but it has underdone
>>>> a lot of changes recetnly around new bnd code.
>>>> Is it ready to be released ?
>>> It currently uses a local copy of the latest bndlib code - I'd prefer to
>>> wait for bndlib to be released and deployed to central (hopefully not long
>>> to go) before releasing the plugin.
>>>
>> I was given a snapshot to try with glassfish build and I had reported an
>> issue to Peter. I hvn't heard anything since then.
>>
>> Sahoo
>
smime.p7s
Description: S/MIME cryptographic signature
Re: Is bundle plugin ready for a release ?
Sahoo, I sent you a mail on June 25 for more information about the bug you reported. I think I fixed it but the original report did not provide enough information to be sure. Now I saw I sent it to the Sun address, does this no longer work for you? Kind regards, Peter Kriens On 19 jul. 2012, at 17:38, Sahoo wrote: > On Thursday 19 July 2012 06:27 PM, Stuart McCulloch wrote: >> On 19 Jul 2012, at 08:13, Guillaume Nodet wrote: >> >>> I'd like to do a release of the maven bundle plugin, but it has underdone a >>> lot of changes recetnly around new bnd code. >>> Is it ready to be released ? >> It currently uses a local copy of the latest bndlib code - I'd prefer to >> wait for bndlib to be released and deployed to central (hopefully not long >> to go) before releasing the plugin. >> > I was given a snapshot to try with glassfish build and I had reported an > issue to Peter. I hvn't heard anything since then. > > Sahoo smime.p7s Description: S/MIME cryptographic signature
Re: [donation] UserAdmin implementation
It comes as a godsend ... :-) I do highly support including this in Apache. Will it include a mongodb backend? Kind regards, Peter Kriens On 18 jul. 2012, at 12:36, Jan Willem Janssen wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Hi list, > > I've written a UserAdmin implementation that I'd like to donate to the > Felix project, see [1]. > > One of the main reasons for writing another implementation is that all > current implementations seems to have serious performance issues and > the lack of a proper test suite. > > As I've also written in the JIRA issue, I'm willing to maintain this > implementation in the future if needed. > > One question I've got about this donation: does it need to include a > Software Grant document as well? I'm already an Apache committer for > the ACE project, so I'm not entirely sure it is necessary?! > > [1] https://issues.apache.org/jira/browse/FELIX-3600 > > - -- > Met vriendelijke groeten | Kind regards > > Jan Willem Janssen | Software Architect > +31 631 765 814 > > /My world is:/ > > Luminis Technologies B.V. > IJsselburcht 3 > 6825 BS Arnhem > +31 88 586 46 30 > > http://www.luminis-technologies.com > http://www.luminis.eu > > KvK (CoC) 09 16 28 93 > BTW (VAT) NL8169.78.566.B.01 > > -BEGIN PGP SIGNATURE- > Version: GnuPG/MacGPG2 v2.0.17 (Darwin) > Comment: GPGTools - http://gpgtools.org > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iQIcBAEBAgAGBQJQBpGrAAoJEKF/mP2eHDc4xmAP/38F7UayT6OlvMYdiR+ZRq6h > qR4AvUHuikxIreT7p3kqFSrw1uzV56jI4bCmsnDPE0likG6ac1Oh3IpczFz0ggXS > YRiYOojnJ5p78VtXE3zswyzou0bzblVwb1F7k5jPuh3ptgzg1oGsRIcbs1PkK+OR > UUcpLc+ZOY0jO4nH7J9e1wPbdwHzWdU6t8qvRDqERmtTlA+FZ7FJVpdx1d7X50g/ > hZgWTPvpAAI3/sVXsqvTn9FJDbDYusu4L3R+pJxx/dmeHwigTmimZAB+cQZ1+Ozo > NSD8uLL8JE56g+M0T3xN0Kyfl40Lzuxo7U4xu8RyXkFCEzt+gdRMbaFJtgvrwlWc > 9atvh5AvhOnfo8IcUbTZxTTwAi+fLUirq0PyfCOuIhbeilECI5yXBgJqDXF/mZat > myvoa2NSR8uzdQaBEoT6U2wUQGzxNvCmuNPwtXT0OocG9WbksWcA94lp9Q0SNVdE > DGoqkqZZHXWP5nc2zWIiiS+qpVJEMl8kinTMl6ixT8b5mPQLnTtV6vJDXcMRZeL0 > DexnxIyjxx4D9ygGsBoxWWziaOENI3rq6M1paLqNM0ca0QV7pa2GdRic+jBKFjs3 > kqjN5oPYDJG4IO3BSmixn/tyRX/VEE0wAcPl2a/oh1d7Zc79ul9WHyhq0pwkIEci > 921tazccS8gJ2IEo53rk > =R/ja > -END PGP SIGNATURE- > smime.p7s Description: S/MIME cryptographic signature
[jira] [Comment Edited] (FELIX-3407) Imports are missed for generics
[
https://issues.apache.org/jira/browse/FELIX-3407?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13285004#comment-13285004
]
Peter Kriens edited comment on FELIX-3407 at 5/29/12 6:45 PM:
--
It turns out that I had commented out a section due to a not understanding of
the JVM spec class file format caused this.
That said, it took a long time to work out since the example is rather
convoluted since it contains Blueprint and hard to parse names. The following
minimal example showed the problem:
bundle a: class a.A implements B { }
bundle b: public interface b.B { }
bundle c: public class c.C {}
It really helps if the problems are brought back to their absolute minimum
since I can then create a test case without too much effort.
Anyway, this is in the next branch and will be released in about 3 weeks.
was (Author: pkriens):
It turns out that I had commented out a section due to a not understanding
of the JVM spec class file format caused this.
That said, it took a long time to work out since the example is rather
convoluted since it contains Blueprint and hard to parse names. The following
minimal example showed the problem:
a: class A implements B { }
b: public interface B { }
c: public class C {}
It really helps if the problems are brought back to their absolute minimum
since I can then create a test case without too much effort.
Anyway, this is in the next branch and will be released in about 3 weeks.
> Imports are missed for generics
> ---
>
> Key: FELIX-3407
> URL: https://issues.apache.org/jira/browse/FELIX-3407
> Project: Felix
> Issue Type: Bug
> Components: Maven Bundle Plugin
>Affects Versions: maven-bundle-plugin-2.3.7
>Reporter: Tomas Forsman
> Attachments: example.zip
>
>
> The bundle plugin miss to add imports to classes/interfaces that are used in
> generic blocks due to type erasure.
> Consider the following (the code is in the attached zip):
> bundle-a:
> package example.a.one;
> public interface ExampleInterfaceA {
> String getGreeting(T example);
> }
> package example.a.two;
> public interface ExampleInterfaceB {
> }
> bundle-b:
> package example.b.two;
> import example.a.two.ExampleInterfaceB;
> public interface ExampleImplementationB extends ExampleInterfaceB {
> }
> bundle-c:
> package example.c;
> import example.a.one.ExampleInterfaceA;
> import example.b.two.ExampleImplementationB;
> public interface ExampleExtendedInterfaceA extends
> ExampleInterfaceA {
> }
> package example.c;
> public class ExampleReferenceListener {
> public void register(final ExampleExtendedInterfaceA example) {
> }
> public void unregister(final ExampleExtendedInterfaceA example) {
> }
> }
> OSGI-INF/blueprint/services.xml
>
> http://www.w3.org/2001/XMLSchema-instance";
>xmlns="http://www.osgi.org/xmlns/blueprint/v1.0.0";
>xsi:schemaLocation="http://www.osgi.org/xmlns/blueprint/v1.0.0
> http://www.osgi.org/xmlns/blueprint/v1.0.0/blueprint.xsd";>
> interface="example.c.ExampleExtendedInterfaceA"
> availability="optional">
>
>
>
>
>
> bundle-d:
> package example.d;
> import example.b.two.ExampleImplementationB;
> import example.c.ExampleExtendedInterfaceA;
> public class ExampleExtendedImplementation implements
> ExampleExtendedInterfaceA {
> public String getGreeting(final ExampleImplementationB example) {
> return "Hello World";
> }
> }
> OSGI-INF/blueprint/services.xml
>
> http://www.w3.org/2001/XMLSchema-instance";
>xmlns="http://www.osgi.org/xmlns/blueprint/v1.0.0";
>xsi:schemaLocation="http://www.osgi.org/xmlns/blueprint/v1.0.0
> http://www.osgi.org/xmlns/blueprint/v1.0.0/blueprint.xsd";>
>
> interface="example.c.ExampleExtendedInterfaceA" ref="exampleBean"/>
>
> Since the bundle plugin uses byte-code to find out which imports to add to
> the manifest, the bundle-c manifest look like this:
> Manifest-Version: 1.0
> Bnd-LastModified: 1332925553008
> Build-Jdk: 1.6.0_26
> Built-By: tofo01
> Bundle-ManifestVersion: 2
> Bundle-Name: example.bundle-c
> Bundle-SymbolicName: example.bundle-c
> Bundle-Version: 1.0.0.SNAPSHOT
> Created-By: Apache Maven Bundle Plugin
> Export-Package: example.c;uses:="example.a.one";version="1.0.0.SNAPSHOT"
> I
[jira] [Commented] (FELIX-3407) Imports are missed for generics
[
https://issues.apache.org/jira/browse/FELIX-3407?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13285004#comment-13285004
]
Peter Kriens commented on FELIX-3407:
-
It turns out that I had commented out a section due to a not understanding of
the JVM spec class file format caused this.
That said, it took a long time to work out since the example is rather
convoluted since it contains Blueprint and hard to parse names. The following
minimal example showed the problem:
a: class A implements B { }
b: public interface B { }
c: public class C {}
It really helps if the problems are brought back to their absolute minimum
since I can then create a test case without too much effort.
Anyway, this is in the next branch and will be released in about 3 weeks.
> Imports are missed for generics
> ---
>
> Key: FELIX-3407
> URL: https://issues.apache.org/jira/browse/FELIX-3407
> Project: Felix
> Issue Type: Bug
> Components: Maven Bundle Plugin
>Affects Versions: maven-bundle-plugin-2.3.7
>Reporter: Tomas Forsman
> Attachments: example.zip
>
>
> The bundle plugin miss to add imports to classes/interfaces that are used in
> generic blocks due to type erasure.
> Consider the following (the code is in the attached zip):
> bundle-a:
> package example.a.one;
> public interface ExampleInterfaceA {
> String getGreeting(T example);
> }
> package example.a.two;
> public interface ExampleInterfaceB {
> }
> bundle-b:
> package example.b.two;
> import example.a.two.ExampleInterfaceB;
> public interface ExampleImplementationB extends ExampleInterfaceB {
> }
> bundle-c:
> package example.c;
> import example.a.one.ExampleInterfaceA;
> import example.b.two.ExampleImplementationB;
> public interface ExampleExtendedInterfaceA extends
> ExampleInterfaceA {
> }
> package example.c;
> public class ExampleReferenceListener {
> public void register(final ExampleExtendedInterfaceA example) {
> }
> public void unregister(final ExampleExtendedInterfaceA example) {
> }
> }
> OSGI-INF/blueprint/services.xml
>
> http://www.w3.org/2001/XMLSchema-instance";
>xmlns="http://www.osgi.org/xmlns/blueprint/v1.0.0";
>xsi:schemaLocation="http://www.osgi.org/xmlns/blueprint/v1.0.0
> http://www.osgi.org/xmlns/blueprint/v1.0.0/blueprint.xsd";>
> interface="example.c.ExampleExtendedInterfaceA"
> availability="optional">
>
>
>
>
>
> bundle-d:
> package example.d;
> import example.b.two.ExampleImplementationB;
> import example.c.ExampleExtendedInterfaceA;
> public class ExampleExtendedImplementation implements
> ExampleExtendedInterfaceA {
> public String getGreeting(final ExampleImplementationB example) {
> return "Hello World";
> }
> }
> OSGI-INF/blueprint/services.xml
>
> http://www.w3.org/2001/XMLSchema-instance";
>xmlns="http://www.osgi.org/xmlns/blueprint/v1.0.0";
>xsi:schemaLocation="http://www.osgi.org/xmlns/blueprint/v1.0.0
> http://www.osgi.org/xmlns/blueprint/v1.0.0/blueprint.xsd";>
>
> interface="example.c.ExampleExtendedInterfaceA" ref="exampleBean"/>
>
> Since the bundle plugin uses byte-code to find out which imports to add to
> the manifest, the bundle-c manifest look like this:
> Manifest-Version: 1.0
> Bnd-LastModified: 1332925553008
> Build-Jdk: 1.6.0_26
> Built-By: tofo01
> Bundle-ManifestVersion: 2
> Bundle-Name: example.bundle-c
> Bundle-SymbolicName: example.bundle-c
> Bundle-Version: 1.0.0.SNAPSHOT
> Created-By: Apache Maven Bundle Plugin
> Export-Package: example.c;uses:="example.a.one";version="1.0.0.SNAPSHOT"
> Import-Package:
> example.a.one;version="[1.0,2)",org.osgi.service.blueprint;version="[1.0.0,2.0.0)"
> Import-Service:
> example.c.ExampleExtendedInterfaceA;multiple:=true;availability:=optional
> Tool: Bnd-1.50.0
> The "example.a.two" package import is missing since type-erasure removes the
> generic part of ExampleInterfaceA in the bundle-c interface.
> This results in a NoClassDefFondError of example.a.two.ExampleInterfaceB from
> bundle-c when trying to deploy bundle-d.
> "Error tracking new service reference java.lang.NoClassDefFoundError:
> example.a.two.ExampleInterfaceB not found by example.bundle-c [159]"
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (FELIX-3407) Imports are missed for generics
[
https://issues.apache.org/jira/browse/FELIX-3407?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13266635#comment-13266635
]
Peter Kriens commented on FELIX-3407:
-
I can't see the reference to the example.a.two package in your listing?
I looked at this and I can only see this as an error in proxy generation. It
looks like they use a class loader that has not the full visibility as
described in a blog
http://blog.osgi.org/2008/08/classy-solutions-to-tricky-proxies.html
I would like to close this.
> Imports are missed for generics
> ---
>
> Key: FELIX-3407
> URL: https://issues.apache.org/jira/browse/FELIX-3407
> Project: Felix
> Issue Type: Bug
> Components: Maven Bundle Plugin
>Affects Versions: maven-bundle-plugin-2.3.7
>Reporter: Tomas Forsman
> Attachments: example.zip
>
>
> The bundle plugin miss to add imports to classes/interfaces that are used in
> generic blocks due to type erasure.
> Consider the following (the code is in the attached zip):
> bundle-a:
> package example.a.one;
> public interface ExampleInterfaceA {
> String getGreeting(T example);
> }
> package example.a.two;
> public interface ExampleInterfaceB {
> }
> bundle-b:
> package example.b.two;
> import example.a.two.ExampleInterfaceB;
> public interface ExampleImplementationB extends ExampleInterfaceB {
> }
> bundle-c:
> package example.c;
> import example.a.one.ExampleInterfaceA;
> import example.b.two.ExampleImplementationB;
> public interface ExampleExtendedInterfaceA extends
> ExampleInterfaceA {
> }
> package example.c;
> public class ExampleReferenceListener {
> public void register(final ExampleExtendedInterfaceA example) {
> }
> public void unregister(final ExampleExtendedInterfaceA example) {
> }
> }
> OSGI-INF/blueprint/services.xml
>
> http://www.w3.org/2001/XMLSchema-instance";
>xmlns="http://www.osgi.org/xmlns/blueprint/v1.0.0";
>xsi:schemaLocation="http://www.osgi.org/xmlns/blueprint/v1.0.0
> http://www.osgi.org/xmlns/blueprint/v1.0.0/blueprint.xsd";>
> interface="example.c.ExampleExtendedInterfaceA"
> availability="optional">
>
>
>
>
>
> bundle-d:
> package example.d;
> import example.b.two.ExampleImplementationB;
> import example.c.ExampleExtendedInterfaceA;
> public class ExampleExtendedImplementation implements
> ExampleExtendedInterfaceA {
> public String getGreeting(final ExampleImplementationB example) {
> return "Hello World";
> }
> }
> OSGI-INF/blueprint/services.xml
>
> http://www.w3.org/2001/XMLSchema-instance";
>xmlns="http://www.osgi.org/xmlns/blueprint/v1.0.0";
>xsi:schemaLocation="http://www.osgi.org/xmlns/blueprint/v1.0.0
> http://www.osgi.org/xmlns/blueprint/v1.0.0/blueprint.xsd";>
>
> interface="example.c.ExampleExtendedInterfaceA" ref="exampleBean"/>
>
> Since the bundle plugin uses byte-code to find out which imports to add to
> the manifest, the bundle-c manifest look like this:
> Manifest-Version: 1.0
> Bnd-LastModified: 1332925553008
> Build-Jdk: 1.6.0_26
> Built-By: tofo01
> Bundle-ManifestVersion: 2
> Bundle-Name: example.bundle-c
> Bundle-SymbolicName: example.bundle-c
> Bundle-Version: 1.0.0.SNAPSHOT
> Created-By: Apache Maven Bundle Plugin
> Export-Package: example.c;uses:="example.a.one";version="1.0.0.SNAPSHOT"
> Import-Package:
> example.a.one;version="[1.0,2)",org.osgi.service.blueprint;version="[1.0.0,2.0.0)"
> Import-Service:
> example.c.ExampleExtendedInterfaceA;multiple:=true;availability:=optional
> Tool: Bnd-1.50.0
> The "example.a.two" package import is missing since type-erasure removes the
> generic part of ExampleInterfaceA in the bundle-c interface.
> This results in a NoClassDefFondError of example.a.two.ExampleInterfaceB from
> bundle-c when trying to deploy bundle-d.
> "Error tracking new service reference java.lang.NoClassDefFoundError:
> example.a.two.ExampleInterfaceB not found by example.bundle-c [159]"
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: How do I avoid ClassCastExceptions with a split package?
The cometd support looks very interesting but it does not work for me. I want to start using your bundle but I get the same class cast exception. I also do not understand how it could work since the HTTP bundle does not export the org.mortbay classes but the cometd must use them? I also do not understand how your sample bundle works, where does it gets the dojo.js from? Would be great if this works though! Kind regards, Peter Kriens On 15 jul. 2008, at 04:53, Tim Moloney wrote: > Tim Moloney wrote: >> Tim Moloney wrote: >>> >>> I'm trying to get cometd working with Felix. I believe that I have it >>> mostly working but I'm getting a ClassCastException on cometd requests, >>> specifically "can not cast >>> org.mortbay.jetty.nio.SelectChannelConnector$RetryContinuation to >>> org.mortbay.util.ajax.Continuation" (this is from memory so it may be a bit >>> off). I think that this is a classloader issue since the RetryContinuation >>> class implements the Continuation interface. I know that split packages >>> can cause ClassCastExceptions due to different classloaders but I'm not >>> sure this is the problem. >>> >>> I'm using the following bundles: >>> - org.apache.felix:org.apache.felix.http.jetty:0.9.0-SNAPSHOT (modified to >>> use jetty 6.1.11) >>> - org.mortbay.jetty:jetty:6.1.11 >>> - org.mortbay.jetty:jetty-util:6.1.11 >>> - org.mortbay.jetty:servlet-api-2.5:6.1.11 >>> - a custom comet bundle that >>> - inlines org.mortbay.jetty:cometd-api:0.9.20080221and >>> org.mortbay.jetty:cometd-bayeux:6.1.11 >>> - maps org.mortbay.cometd.continuation.ContinuationCometdServlet to /cometd >>> >>> jetty-util exports org.mortbay.util but cometd-bayeux has >>> org.mortbay.util.ArrayQueue. I managed to get my custom comet bundle to >>> compile by making org.mortbay.util a private package. However, this >>> duplicates all of org.mortbay.util in my bundle which I think is causing >>> the ClassCastException. >>> >>> What is the best way to handle the split package and avoid >>> ClassCastExceptions? >>> >>> Tim >>> >> >> I found the split-package command in the bnd documentation. I tried both >> merge-first and merge-last but I still got the ClassCastExceptions. I think >> this is because the org.mortbay.util package was still being duplicated in >> my bundle. I then tried first which only copied org.mortbay.util.ArrayQueue >> into my bundle but then the rest of org.mortbay.util couldn't be found. I >> finally tried using the following but I'm still getting the original >> ClassCastExceptions. >> >> org.mortbay.util;-split-package:=first >> !org.mortbay.log,!org.mortbay.thread,!org.mortbay.util.ajax,* >> >> org.mortbay.jetty.util >> >> I'm out of ideas. Does anyone have any suggestions? >> >> Tim >> > > I managed to get things working by adding ArrayQueue to the jetty-util bundle > and modifying how http.jetty is packaged. > > For http.jetty, I simply changed the Private-Package instruction as shown > below. Can someone review the change and commit it, if it doesn't break > anything? > > Tomorrow, I'll investigate if I really needed to move ArrayQueue to the > jetty-util bundle. > > Index: pom.xml > === > --- pom.xml (revision 676451) > +++ pom.xml (working copy) > @@ -97,7 +97,7 @@ > > >org.apache.felix.http.jetty, > -org.mortbay.*;-split-package:=merge-first > +org.mortbay.jetty.*;-split-package:=merge-first > > >javax.net.ssl; javax.security.cert; > > > Tim >
Re: Feedback
What would be nice if you could zoom into a bundle and see the package relations inside the bundle/group. Then zoom in the packages and see the classes. The connections between the classes/packages/bundles could also use some color/transparency coding. So that an expensive connection would look dark red and an expensive connection light gray. Note hat expensive is not many but shared by very few entities inside the enclosure. I.e. if only one class in a package of 10 classes causes a certain dependency then that is an expensive dependency. You could also take a loot at this article for ideas how to visualize classes/packages/modules: https://docs.google.com/document/pub?id=1_yOUl4mGq9ZTPIAR-sB2Q1kcS7N0U0D5z97zUx0hCDY Kind regards, Peter Kriens On 11 aug 2011, at 08:14, Tiger Gui wrote: > Ok, i will keep on improving the visualization things and improve the > split algorithm according to the visualization result :-) > > 2011/8/10 Peter Kriens : >> Make sure you get the naming + layout right on these examples before you >> take other products. This is the stage where you really want to focus on the >> tool. You now get more understanding of the problem because you now know the >> structure. So I really think we now should do: >> >>- better visualization of the contents (naming mostly, maybe show the >> inside package names when zoomed) >>- show the imports somehow >> >> It is not that useful to now analyze a lot of projects, it is understanding >> the structure of the projects that counts. These lessons must then be >> applied to other projects, which will give new problems, solve them, ad >> nauseum. >> >> But this is really starting to look interestingly. >> >> Kind regards, >> >>Peter Kriens >> >> >> On 10 aug 2011, at 08:29, Tiger Gui wrote: >> >>> And this is Spring's packages relation figure and bundles relationship >>> figure in the attach png files. And you can get the bundle details in >>> the html split report generated by OSGiMaker. >>> >>> Now, we use Jung to read the visualize the split result of OSGiMaker, >>> in the next few days, i will integrate the visualize tool with >>> OSGiMaker, help users to check the bundles relation in the Eclipse >>> once he use OSGiMaker to split the application. >>> >>> 2011/8/9 Peter Kriens : >>>> This is starting to look really interesting! >>>> >>>> Can you make your own layout? Would be nice to sort the "bundles" in >>>> layers. The core should be at the bottom and when you go up, you should >>>> see the higher layers depend on the lower layers. This is never perfect >>>> but you cannot have cycles by definition, they've been removed earlier. >>>> >>>> It is important to minimize the number of imports so they need also be >>>> grouped in such a way that you have a minimum set of import groups. They >>>> should be visible on the edge of the picture >>>> >>>> Also spend some time on shortening the names without loosing the >>>> recognition. >>>> >>>> Good work! As I said, visualizing this stuff is all important. >>>> >>>> Kind regards, >>>> >>>>Peter Kriens >>>> >>>> >>>> On 9 aug 2011, at 08:43, Tiger Gui wrote: >>>> >>>>> Hi Peter, >>>>> >>>>> This is Tomcat's bundles relationship figure, i use Jung to visualize >>>>> the dependencies, arrow from A to B means bundle A need bundle B. And >>>>> the html attach file is the bundles relationship report >>>>> >>>>> 2011/8/2 Tiger Gui : >>>>>> Yeah, the imports are too much, but there is not any problem. >>>>>> >>>>>> The good new is that i am working for the visualize job of the >>>>>> dependencies, it will give us a more clear graph about the bundles >>>>>> relationship, just wait for 2 -3 days, I am on my way of playing with >>>>>> JUNG >>>>>> >>>>>> 2011/8/2 Peter Kriens : >>>>>>> Can you take a look at the imports? There seems to be many class names? >>>>>>> >>>>>>> I also think you should try to shorten the package names. Maybe names >>>>>>> like oac.comet (org.apache.catalina.comet) would already help. >>>>>>> >>&
Re: Feedback
Make sure you get the naming + layout right on these examples before you take other products. This is the stage where you really want to focus on the tool. You now get more understanding of the problem because you now know the structure. So I really think we now should do: - better visualization of the contents (naming mostly, maybe show the inside package names when zoomed) - show the imports somehow It is not that useful to now analyze a lot of projects, it is understanding the structure of the projects that counts. These lessons must then be applied to other projects, which will give new problems, solve them, ad nauseum. But this is really starting to look interestingly. Kind regards, Peter Kriens On 10 aug 2011, at 08:29, Tiger Gui wrote: > And this is Spring's packages relation figure and bundles relationship > figure in the attach png files. And you can get the bundle details in > the html split report generated by OSGiMaker. > > Now, we use Jung to read the visualize the split result of OSGiMaker, > in the next few days, i will integrate the visualize tool with > OSGiMaker, help users to check the bundles relation in the Eclipse > once he use OSGiMaker to split the application. > > 2011/8/9 Peter Kriens : >> This is starting to look really interesting! >> >> Can you make your own layout? Would be nice to sort the "bundles" in layers. >> The core should be at the bottom and when you go up, you should see the >> higher layers depend on the lower layers. This is never perfect but you >> cannot have cycles by definition, they've been removed earlier. >> >> It is important to minimize the number of imports so they need also be >> grouped in such a way that you have a minimum set of import groups. They >> should be visible on the edge of the picture >> >> Also spend some time on shortening the names without loosing the recognition. >> >> Good work! As I said, visualizing this stuff is all important. >> >> Kind regards, >> >>Peter Kriens >> >> >> On 9 aug 2011, at 08:43, Tiger Gui wrote: >> >>> Hi Peter, >>> >>> This is Tomcat's bundles relationship figure, i use Jung to visualize >>> the dependencies, arrow from A to B means bundle A need bundle B. And >>> the html attach file is the bundles relationship report >>> >>> 2011/8/2 Tiger Gui : >>>> Yeah, the imports are too much, but there is not any problem. >>>> >>>> The good new is that i am working for the visualize job of the >>>> dependencies, it will give us a more clear graph about the bundles >>>> relationship, just wait for 2 -3 days, I am on my way of playing with >>>> JUNG >>>> >>>> 2011/8/2 Peter Kriens : >>>>> Can you take a look at the imports? There seems to be many class names? >>>>> >>>>> I also think you should try to shorten the package names. Maybe names >>>>> like oac.comet (org.apache.catalina.comet) would already help. >>>>> >>>>> And we really need visualize the dependencies ... This is however a great >>>>> start. >>>>> >>>>> Kind regards, >>>>> >>>>>Peter Kriens >>>>> >>>>> On 30 jul 2011, at 16:02, Tiger Gui wrote: >>>>> >>>>>> Hi Peter, >>>>>> >>>>>> I changed the merge situation a little, >>>>>> >>>>>> FROM: >>>>>> boolean condition4 = 4 * sameUB >= one.usedByList.size() + >>>>>> two.usedByList.size(); >>>>>> TO: >>>>>> boolean condition4 = 3 * sameUB >= one.usedByList.size() + >>>>>> two.usedByList.size(); >>>>>> >>>>>> Try the analyse and split algorithm in Tomcat application again, and >>>>>> we got another report, in the attach file. It seems that this bundle >>>>>> structure is more reasonable >>>>>> >>>>>> 2011/7/30 Tiger Gui : >>>>>>> Hi Peter, >>>>>>> >>>>>>> I have generated the report for Tomcat too, in the attach file, and >>>>>>> improve the report as you wish, just see the comments >>>>>>> >>>>>>> 2011/7/29 Peter Kriens : >>>>>>>> Now we're getting somewhere! Could you: >>>>>>>> >>>>>>>> 1)
Re: Feedback
This is starting to look really interesting!
Can you make your own layout? Would be nice to sort the "bundles" in layers.
The core should be at the bottom and when you go up, you should see the higher
layers depend on the lower layers. This is never perfect but you cannot have
cycles by definition, they've been removed earlier.
It is important to minimize the number of imports so they need also be grouped
in such a way that you have a minimum set of import groups. They should be
visible on the edge of the picture
Also spend some time on shortening the names without loosing the recognition.
Good work! As I said, visualizing this stuff is all important.
Kind regards,
Peter Kriens
On 9 aug 2011, at 08:43, Tiger Gui wrote:
> Hi Peter,
>
> This is Tomcat's bundles relationship figure, i use Jung to visualize
> the dependencies, arrow from A to B means bundle A need bundle B. And
> the html attach file is the bundles relationship report
>
> 2011/8/2 Tiger Gui :
>> Yeah, the imports are too much, but there is not any problem.
>>
>> The good new is that i am working for the visualize job of the
>> dependencies, it will give us a more clear graph about the bundles
>> relationship, just wait for 2 -3 days, I am on my way of playing with
>> JUNG
>>
>> 2011/8/2 Peter Kriens :
>>> Can you take a look at the imports? There seems to be many class names?
>>>
>>> I also think you should try to shorten the package names. Maybe names like
>>> oac.comet (org.apache.catalina.comet) would already help.
>>>
>>> And we really need visualize the dependencies ... This is however a great
>>> start.
>>>
>>> Kind regards,
>>>
>>>Peter Kriens
>>>
>>> On 30 jul 2011, at 16:02, Tiger Gui wrote:
>>>
>>>> Hi Peter,
>>>>
>>>> I changed the merge situation a little,
>>>>
>>>> FROM:
>>>> boolean condition4 = 4 * sameUB >= one.usedByList.size() +
>>>> two.usedByList.size();
>>>> TO:
>>>> boolean condition4 = 3 * sameUB >= one.usedByList.size() +
>>>> two.usedByList.size();
>>>>
>>>> Try the analyse and split algorithm in Tomcat application again, and
>>>> we got another report, in the attach file. It seems that this bundle
>>>> structure is more reasonable
>>>>
>>>> 2011/7/30 Tiger Gui :
>>>>> Hi Peter,
>>>>>
>>>>> I have generated the report for Tomcat too, in the attach file, and
>>>>> improve the report as you wish, just see the comments
>>>>>
>>>>> 2011/7/29 Peter Kriens :
>>>>>> Now we're getting somewhere! Could you:
>>>>>>
>>>>>> 1) Please rename names like round1MergeBundle8 to just R18 or so ...
>>>>>
>>>>> I have renamed round1MergeBundle8 to just R1B8, BTW, you should know
>>>>> that users can change the bundle name as he wish in our tools,
>>>>> OSGiMaker has supplies the feature already, we have a GUI bundle edit
>>>>> editor
>>>>>
>>>>>> 2) The imports look like they sometimes contain classes? And it would be
>>>>>> nice if you put a after each one of them (maybe combine the ones
>>>>>> with the same prefix?)
>>>>>
>>>>> No, the imports are all package, i add a "" every 5 imports, if
>>>>> we add a "" after each of them, it will be a long list, not very
>>>>> comfortable to read
>>>>>
>>>>>> 3) Can you sort on the number of contains entries? I.e. biggest bundle
>>>>>> first
>>>>>
>>>>> Yeah, i have sorted it already, the biggest first
>>>>>
>>>>>> 4) Could you link the bundles with an R18?
>>>>>
>>>>> Yeah, i have add the http link already in the report
>>>>>
>>>>>> 5) Could you make the names of the
>>>>>
>>>>> ???
>>>>>
>>>>>
>>>>>> 6) Get rid of the .*?
>>>>>
>>>>> It is easy to get rid of the .*, but i think it make things more
>>>>> clear, make us know, the bundles includes all the classes in the
>>>>> packages
>>>>>
>>>>>> 7) Also generate one of these for catalina/Tomcat?
>>>>>>
>>>>>> Actually, this sp
Re: Feedback
Can you take a look at the imports? There seems to be many class names? I also think you should try to shorten the package names. Maybe names like oac.comet (org.apache.catalina.comet) would already help. And we really need visualize the dependencies ... This is however a great start. Kind regards, Peter Kriens On 30 jul 2011, at 16:02, Tiger Gui wrote: > Hi Peter, > > I changed the merge situation a little, > > FROM: > boolean condition4 = 4 * sameUB >= one.usedByList.size() + > two.usedByList.size(); > TO: > boolean condition4 = 3 * sameUB >= one.usedByList.size() + > two.usedByList.size(); > > Try the analyse and split algorithm in Tomcat application again, and > we got another report, in the attach file. It seems that this bundle > structure is more reasonable > > 2011/7/30 Tiger Gui : >> Hi Peter, >> >> I have generated the report for Tomcat too, in the attach file, and >> improve the report as you wish, just see the comments >> >> 2011/7/29 Peter Kriens : >>> Now we're getting somewhere! Could you: >>> >>> 1) Please rename names like round1MergeBundle8 to just R18 or so ... >> >> I have renamed round1MergeBundle8 to just R1B8, BTW, you should know >> that users can change the bundle name as he wish in our tools, >> OSGiMaker has supplies the feature already, we have a GUI bundle edit >> editor >> >>> 2) The imports look like they sometimes contain classes? And it would be >>> nice if you put a after each one of them (maybe combine the ones with >>> the same prefix?) >> >> No, the imports are all package, i add a "" every 5 imports, if >> we add a "" after each of them, it will be a long list, not very >> comfortable to read >> >>> 3) Can you sort on the number of contains entries? I.e. biggest bundle first >> >> Yeah, i have sorted it already, the biggest first >> >>> 4) Could you link the bundles with an R18? >> >> Yeah, i have add the http link already in the report >> >>> 5) Could you make the names of the >> >> ??? >> >> >>> 6) Get rid of the .*? >> >> It is easy to get rid of the .*, but i think it make things more >> clear, make us know, the bundles includes all the classes in the >> packages >> >>> 7) Also generate one of these for catalina/Tomcat? >>> >>> Actually, this spring one is pretty neat. >>> >>> I am a bit curious about the jdbc stuff. I assume all the packages in >>> org.springframework.jdbc11 are strongly connected? What are the packages >>> that refer to com.ibm.websphere.rsadapter and com.mchange.v2.c3p0, etc? >>> These are the VERY expensive dependencies and I wonder how they get merged >>> in so badly in this bundle. >>> >>> Similar to the orm bundle, who is the culprit (class?) that points to >>> hibernate? You see why this is bad? In a good design the >>> org.springframework.orm should not be strongly connected to something like >>> hibernate. The hibernate should be a bridge package but not have internal >>> references. >> >>> >>> Interesting! Kind regards, >>> >>>Peter Kriens >>> >>> >>> >>> >>> On 29 jul 2011, at 11:32, Tiger Gui wrote: >>> >>>> Hi Peter, >>>> >>>> To visualize things, i have a simple review to JUNG, it seems that it >>>> is good solution for display graph or tree in a canvas, but it is a >>>> problem that JUNG is developed for AWT/SWING, not suitable for Eclipse >>>> SWT/JFace environment, so, i will continue searching for the best >>>> solution, may be we can even consider Eclipse GMF technology >>>> >>>> >>>> To report things: >>>> I have changed the report to a HTML file in the attach file, it's >>>> still Spring's OSGi split report, it looks much better :-) >>>> >>>> 2011/7/29 Peter Kriens : >>>>> Rule #1, as long as I see you're engaged you do not have to worry about >>>>> the evaluation. So do not do things for my sake, do them because you >>>>> believe it is the best way forward. I think Tinkerpop and JUNG are a >>>>> great way to visualize, but do not take my word. I have the greatest >>>>> respect for people who do not listen to me because they are convinced >>>>> they know better. That out of the way. >>&g
Re: Feedback
Now we're getting somewhere! Could you:
1) Please rename names like round1MergeBundle8 to just R18 or so ...
2) The imports look like they sometimes contain classes? And it would be nice
if you put a after each one of them (maybe combine the ones with the same
prefix?)
3) Can you sort on the number of contains entries? I.e. biggest bundle first
4) Could you link the bundles with an R18?
5) Could you make the names of the
6) Get rid of the .*?
7) Also generate one of these for catalina/Tomcat?
Actually, this spring one is pretty neat.
I am a bit curious about the jdbc stuff. I assume all the packages in
org.springframework.jdbc11 are strongly connected? What are the packages that
refer to com.ibm.websphere.rsadapter and com.mchange.v2.c3p0, etc? These are
the VERY expensive dependencies and I wonder how they get merged in so badly in
this bundle.
Similar to the orm bundle, who is the culprit (class?) that points to
hibernate? You see why this is bad? In a good design the
org.springframework.orm should not be strongly connected to something like
hibernate. The hibernate should be a bridge package but not have internal
references.
Interesting! Kind regards,
Peter Kriens
On 29 jul 2011, at 11:32, Tiger Gui wrote:
> Hi Peter,
>
> To visualize things, i have a simple review to JUNG, it seems that it
> is good solution for display graph or tree in a canvas, but it is a
> problem that JUNG is developed for AWT/SWING, not suitable for Eclipse
> SWT/JFace environment, so, i will continue searching for the best
> solution, may be we can even consider Eclipse GMF technology
>
>
> To report things:
> I have changed the report to a HTML file in the attach file, it's
> still Spring's OSGi split report, it looks much better :-)
>
> 2011/7/29 Peter Kriens :
>> Rule #1, as long as I see you're engaged you do not have to worry about the
>> evaluation. So do not do things for my sake, do them because you believe it
>> is the best way forward. I think Tinkerpop and JUNG are a great way to
>> visualize, but do not take my word. I have the greatest respect for people
>> who do not listen to me because they are convinced they know better. That
>> out of the way.
>>
>> This whole things is very much about understanding and our visual brains is
>> by far the most powerful tool on earth to understand things. And you're not
>> taking advantage of it :-) We are looking for structure here, the names are
>> only relevant later. So to see structure, tables are perfect. Which means
>> you have to have short names. Just using the last part of a package
>> (com.springframework.jca, take jca). I.e. a name like round1MergeBundle8 is
>> ok to call b8. You can always later provide a list of translations. This is
>> also the reason why we need to use packages, classes are too many off.
>> Visualization is everything in this phase because we need to find the rules
>> of the structure.
>>
>> So lets retry. First give me a list of all groups (named g1 .. gn) and their
>> package content
>>
>>
>> Group Contains Uses Used By
>> External
>> g3 com.springframework.{jca,jdbc,...}, g4, g5, g7 g2
>> org.w3.xml, javax.persistence,
>> ...
>> com.oracle.g11.{impl,whatever}
>>
>> It might be easiest to generate HTML so you can use tables. Don't make it
>> look fancy, just use the tools to get insight in the structure:
>>
>>
>>
>>
>>
>> Group
>> Contains
>> Uses
>> Used By
>> External
>>
>>
>>g3
>> com.springframework.{jca,jdbc,...},...
>>g4, g5, g7
>>g2
>>org.w3.xml,
>> javax.persistence,com.oracle.g11.{impl,whatever}
>>
>>
>>
>>
>>
>> Shortening the names is everything or else your eyes drown in a sea of
>> characters.
>>
>> Kind regards,
>>
>>Peter Kriens
>>
>>
>>
>> On 29 jul 2011, at 05:16, Tiger Gui wrote:
>>
>>> Hi Peter,
>>>
>>> Thank you for your reply first, please see the following comments
>>>
>>> 2011/7/28 Peter Kriens :
>>>> It is good that you use a real project now. What I like to see how many
>>>> "bundles" we have after the first round, where you group strongly
>>>> connected packages. This should
Re: Feedback
Rule #1, as long as I see you're engaged you do not have to worry about the
evaluation. So do not do things for my sake, do them because you believe it is
the best way forward. I think Tinkerpop and JUNG are a great way to visualize,
but do not take my word. I have the greatest respect for people who do not
listen to me because they are convinced they know better. That out of the way.
This whole things is very much about understanding and our visual brains is by
far the most powerful tool on earth to understand things. And you're not taking
advantage of it :-) We are looking for structure here, the names are only
relevant later. So to see structure, tables are perfect. Which means you have
to have short names. Just using the last part of a package
(com.springframework.jca, take jca). I.e. a name like round1MergeBundle8 is ok
to call b8. You can always later provide a list of translations. This is also
the reason why we need to use packages, classes are too many off. Visualization
is everything in this phase because we need to find the rules of the structure.
So lets retry. First give me a list of all groups (named g1 .. gn) and their
package content
Group Contains Uses Used By
External
g3 com.springframework.{jca,jdbc,...}, g4, g5, g7 g2
org.w3.xml, javax.persistence,
...
com.oracle.g11.{impl,whatever}
It might be easiest to generate HTML so you can use tables. Don't make it look
fancy, just use the tools to get insight in the structure:
Group
Contains
Uses
Used By
External
g3
com.springframework.{jca,jdbc,...},...
g4, g5, g7
g2
org.w3.xml,
javax.persistence,com.oracle.g11.{impl,whatever}
Shortening the names is everything or else your eyes drown in a sea of
characters.
Kind regards,
Peter Kriens
On 29 jul 2011, at 05:16, Tiger Gui wrote:
> Hi Peter,
>
> Thank you for your reply first, please see the following comments
>
> 2011/7/28 Peter Kriens :
>> It is good that you use a real project now. What I like to see how many
>> "bundles" we have after the first round, where you group strongly connected
>> packages. This should already simplify because the nr of entities will be
>> smaller.
>>
>> I need to see a real case. Step 1 is ok, but maybe you can add merging of
>> bundles that have identical usesExternal (imports).
>
> Yes, I do merge the bundles that have identical usesExternal
> (imports), i described in the former mail,
>
> We define sameUE: it menas the number of two bundles have same
> usedExternal external package rely elements.
>
> boolean condition2 = 3 * sameUE >= one.usedExternalList.size() +
> two.usedExternalList.size();
>
> if(condition2 == true) i will merge bundles one and two,In the process
> of real case test(Spring and Tomcat), i found that it's hardly to find
> two bundles which have exactly the same usesExternal items, we should
> also merge bundles who have *proportional* usesExternal items. In my
> test case, it works good.
>
>> And make sure you ignore all java.* to make the info smaller (in OSGi, java
>> is always provided by the VM). Can you just print out something like
>
> Yes, i have considered this situation, in the whole merge process, we
> do not consider jdk supplies java.* classes.
>
>>
>> nameusesInternalusesExternal
>> g1 g2 a,b,c
>> g2 d,e,f
>>
>
> Let's take example of Spring, this report is like this:
> Name ---
> usesInternal
> org.springframework.jms2
> ---round1MergeBundle8,mergedBundle9,org.springframework.jca22,org.springframework.scheduling15,org.springframework.context14,round1MergeBundle5
> org.springframework.jdbc11 ---
> round1MergeBundle8,mergedBundle9
> org.springframework.orm13
> ---
> round1MergeBundle8,org.springframework.jdbc11,mergedBundle9,round1MergeBundle3
> org.springframework.context14
> --- round1MergeBundle8,round1MergeBundle1,mergedBundle9
> org.springframework.scheduling15
> ---
> round1MergeBundle8,mergedBundle9,org.springframework.context14,org.springframework.jdbc11
> org.springframework.jca22
> ---
> round1MergeBundle8,mergedBundle9,org.springframework.context14,org.springframework.scheduling15
> round1MergeBundle1
> --- ro
Re: Feedback
It is good that you use a real project now. What I like to see how many
"bundles" we have after the first round, where you group strongly connected
packages. This should already simplify because the nr of entities will be
smaller.
I need to see a real case. Step 1 is ok, but maybe you can add merging of
bundles that have identical usesExternal (imports). And make sure you ignore
all java.* to make the info smaller (in OSGi, java is always provided by the
VM). Can you just print out something like
nameusesInternalusesExternal
g1 g2 a,b,c
g2 d,e,f
I hope we see one big bundle which is the core and then have to find rules to
classify the remaining bundles. I expect there are the following categories:
coreimplementation classes, lots of strongly connected packages
api api classes, do not refer to core, very few imports
bridge refer strongly to core and have expensive imports
At this stage, the trick is to do some work by hand until you find you really
understand the problem.
It would be perfect if you could take a look at Tinkerpop and JUNG. I think it
would be quite easy to visualize the graph of dependencies.
Kind regards,
Peter Kriens
On 26 jul 2011, at 16:24, Tiger Gui wrote:
> Hi Peter,
>
> This is the whole application split algorithm here. After application
> source code analyse algorithm described here[1], we can know each
> package/class use which packages/classes and be used by which
> packages/classes. Now, we just discuss package here, we treat package
> as a single atom, each package has three important attributes, usedBy,
> usesExternal and usesInternal, just like below:
>
> sources="/E:/GSoC/gsoc2011osgi/runtime-New_configuration/TomcatJava/bin"
> size="30" usedBy="8" usesInternal="11" usesExternal="14" layer="6"
> cycle="org.apache.catalina et al.">
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> usedBy means who use current package;
> usesInternal means which packages current package use in current
> application source code;
> usesExternal means which packages current pakcage use not in current
> application's source code.
>
> Now, we start split the whole application in to bundles, according to
> above algorithm source code analyse algorithm, we can also know
> package cycles in current application.
>
> 1. Treat each package cycle as a single bundle;
> 2. Treat each packages not in cycle as a single bundle;
> 3. Then we should decide which bundles can be merged into one new bundle;
>
> First round merge job:
> 4. If one bundle's all usesInternal elements are in the other bundle,
> these two bundles should be merged into a new bundle;
>
> Think about how to merge used by only bundle (bundle be used only by
> other bundle, it does not rely on any other bundle):
> Define two variable for used by only bundle:
> sameUB: it means the number of two bundles have same usedBy elements.
> sameUE: it menas the number of two bundles have same usedExternal
> external package rely elements.
>
> boolean condition1 = 4 * sameUB >= one.usedByList.size() +
> two.usedByList.size();
> boolean condition2 = 2 * sameUE >= one.usedExternalList.size() +
> two.usedExternalList.size();
>
> if condition1 or condition2 is true, we should merge these two usedBy
> only bundle.
>
> Merge the other bundles:
> 5.The core problem is how to decide two bundles(bundle one and bundle
> two) can be merged or not.
>
> Define 5 variables:
> uiNumber: the sum of bundle one's usesInternal elements in bundle two
> number and bundle two's usesInternal elements in bundle one number;
>
> ubNumber:the sum of bundle one's usedBy elements in bundle two number
> and bundle two's usedBy elements in bundle one number;
>
> sameUI: the same usesInternal number bundle one and two have
>
> sameUB: Be similar with used by only bundle's this variable
>
> sameUE: Be similar with used by only bundle's this variable
>
> Define these conditions:
> boolean condition1 = 2 * uiNumber >= one.usesInternalList.size() +
> two.usesInternalList.size();
> boolean condition2 = 2 * ubNumber >= one.usedByList.size() +
> two.usedByList.size() ;
> boolean condition3 = 3.5 * sameUI >= one.usesInternalList.size() +
> two.usesIn
Re: iPOJO vs SCR vs Blueprint
I guess you'd rather have someone write your app as well? :-)
The beauty of it all is that you you could actually write your perfect manager
and it would work seamlessly with all the others.
Kind regards,
Peter Kriens
On 10 jun 2011, at 22:27, Andrei Pozolotin wrote:
> in my experience:
> 1) blueprint is a disaster
> 2) ipojo is over-kill
> 3) ds is under-kill :-)
> and yes, I would like to see some features of ipojo in scr
>
> Original Message
> Subject: Re: iPOJO vs SCR vs Blueprint
> From: Richard S. Hall
> To: dev@felix.apache.org
> Date: Wed 08 Jun 2011 08:24:02 AM CDT
>> On 6/8/11 9:13, Peter Kriens wrote:
>>> The summary for me is that DS is limited to simplifying being a
>>> service and depending on other services while iPOJO and Blueprint add
>>> a programming language (XML/Annotations) that support services among
>>> many, many other features.
>>>
>>> In my experience DS is the simplest and least intrusive, especially
>>> with the SCR or bnd annotations. Blueprint is not my favorite because
>>> I consider XML among the worst programming languages one can imagine.
>>> I do not have a lot of experience with iPOJO; it is clearly the most
>>> powerful but it somehow lacks a compelling reason to switch as none
>>> of its additional functions seem worth the effort to switch.
>>
>> Yeah, who needs things like automatic concurrency handling for
>> services or byte-code generated smart service references that
>> eliminate the need to turn everything into a component in order to
>> pass around services throughout your component? It's better to do all
>> that stuff by hand with DS... ;-)
>>
>> -> richard
>>
>> p.s. Sorry, I couldn't resist... :-P
>>
>>> Anyway, who cares. They all interact very nicely and switching from
>>> one to the other is not so hard as long as you could in POJOs.
>>>
>>> Kind regards,
>>>
>>>Peter Kriens
>>>
>>>
>>> On 30 mei 2011, at 13:25, Felix Meschberger wrote:
>>>
>>>> Hi,
>>>>
>>>> Just stating an incompletely informed opinion here ..
>>>>
>>>> If you want something simple, light-weight and easy to use, go for
>>>> Declarative Services.
>>>>
>>>> If you want elaborate functionality or need something Declarative
>>>> Services does not provide, consider iPojo (I understand it is an
>>>> evolution of Declarative Services, right ?)
>>>>
>>>> If you have a Spring background go for blueprint.
>>>>
>>>> Regards
>>>> Felix, whose loves and sticks with Declarative Services ;-)
>>>>
>>>> Am Donnerstag, den 26.05.2011, 02:23 +0100 schrieb jie yan:
>>>>> On Thu, May 26, 2011 at 6:02 AM, Alasdair
>>>>> Nottingham wrote:
>>>>>
>>>>>>
>>>>>> Alasdair Nottingham
>>>>>>
>>>>>> On 25 May 2011, at 22:16, "Richard S. Hall"
>>>>>> wrote:
>>>>>>
>>>>>>> On 5/25/11 16:26, Alasdair Nottingham wrote:
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> This is good I might link to it, or pinch it for the aries
>>>>>>>> webpage too
>>>>>>>> if that is ok. When doing that thought I would put some changes
>>>>>>>> into
>>>>>>>> the blueprint column. The Aries blueprint implementation
>>>>>>>> provides some
>>>>>>>> value add that would change some of the No's into Yes's.
>>>>>>> Sure.
>>>>>>>
>>>>>>>> One thing though in component lifecycle control you have a Partial
>>>>>>>> down for blueprint I was wondering what you meant by this.
>>>>>>> I'd have to review the chapter, I don't really claim to be any
>>>>>>> Blueprint
>>>>>> expert...other than knowing it sucks... ;-)
>>>>>>
>>>>>> Of course if you were an expert you would know how much better it
>>>>>> is than
>>>>>> anything else ;) let the religious flame war begin, or not.
>>>>>>
>>>>> In fact, casual users wish for an almighty expert who knows all
>>>>> solutions
>>>>> in-depth and exposes t
Re: iPOJO vs SCR vs Blueprint
Obviously everybody needs all these goodies you mention. However the choice is
to do this in iPOJO with a new "language" and new semantics attached to it or
do it in Java. I am very familiar with the semantics of Java and the pain of
the redundancy in Java over iPOJO in this area has not been high enough to make
this switch seem desirable.
Kind regards,
Peter Kriens
On 8 jun 2011, at 15:24, Richard S. Hall wrote:
> On 6/8/11 9:13, Peter Kriens wrote:
>> The summary for me is that DS is limited to simplifying being a service and
>> depending on other services while iPOJO and Blueprint add a programming
>> language (XML/Annotations) that support services among many, many other
>> features.
>>
>> In my experience DS is the simplest and least intrusive, especially with the
>> SCR or bnd annotations. Blueprint is not my favorite because I consider XML
>> among the worst programming languages one can imagine. I do not have a lot
>> of experience with iPOJO; it is clearly the most powerful but it somehow
>> lacks a compelling reason to switch as none of its additional functions seem
>> worth the effort to switch.
>
> Yeah, who needs things like automatic concurrency handling for services or
> byte-code generated smart service references that eliminate the need to turn
> everything into a component in order to pass around services throughout your
> component? It's better to do all that stuff by hand with DS... ;-)
>
> -> richard
>
> p.s. Sorry, I couldn't resist... :-P
>
>> Anyway, who cares. They all interact very nicely and switching from one to
>> the other is not so hard as long as you could in POJOs.
>>
>> Kind regards,
>>
>> Peter Kriens
>>
>>
>> On 30 mei 2011, at 13:25, Felix Meschberger wrote:
>>
>>> Hi,
>>>
>>> Just stating an incompletely informed opinion here ..
>>>
>>> If you want something simple, light-weight and easy to use, go for
>>> Declarative Services.
>>>
>>> If you want elaborate functionality or need something Declarative
>>> Services does not provide, consider iPojo (I understand it is an
>>> evolution of Declarative Services, right ?)
>>>
>>> If you have a Spring background go for blueprint.
>>>
>>> Regards
>>> Felix, whose loves and sticks with Declarative Services ;-)
>>>
>>> Am Donnerstag, den 26.05.2011, 02:23 +0100 schrieb jie yan:
>>>> On Thu, May 26, 2011 at 6:02 AM, Alasdair Nottingham
>>>> wrote:
>>>>
>>>>>
>>>>> Alasdair Nottingham
>>>>>
>>>>> On 25 May 2011, at 22:16, "Richard S. Hall" wrote:
>>>>>
>>>>>> On 5/25/11 16:26, Alasdair Nottingham wrote:
>>>>>>> Hi,
>>>>>>>
>>>>>>> This is good I might link to it, or pinch it for the aries webpage too
>>>>>>> if that is ok. When doing that thought I would put some changes into
>>>>>>> the blueprint column. The Aries blueprint implementation provides some
>>>>>>> value add that would change some of the No's into Yes's.
>>>>>> Sure.
>>>>>>
>>>>>>> One thing though in component lifecycle control you have a Partial
>>>>>>> down for blueprint I was wondering what you meant by this.
>>>>>> I'd have to review the chapter, I don't really claim to be any Blueprint
>>>>> expert...other than knowing it sucks... ;-)
>>>>>
>>>>> Of course if you were an expert you would know how much better it is than
>>>>> anything else ;) let the religious flame war begin, or not.
>>>>>
>>>> In fact, casual users wish for an almighty expert who knows all solutions
>>>> in-depth and exposes them to all.
>>>>
>>>> If there's no such expert, the second best method is, experts of different
>>>> solutions advertise themself and compare with each other.
>>>>
>>>> Maybe that can be called religious flame war, but it's valuable. What we
>>>> really need in open community is simple and perfect product in technology,
>>>> but not many repeat manufacturing wheels like some outside companies.
>>>>
>>>> Regards,
>>>> drhades
>>>>
>>>>>> -> richard
>>>>>>
>>>>>>> Thanks
>>>>>>> Alasdair
Re: iPOJO vs SCR vs Blueprint
The summary for me is that DS is limited to simplifying being a service and depending on other services while iPOJO and Blueprint add a programming language (XML/Annotations) that support services among many, many other features. In my experience DS is the simplest and least intrusive, especially with the SCR or bnd annotations. Blueprint is not my favorite because I consider XML among the worst programming languages one can imagine. I do not have a lot of experience with iPOJO; it is clearly the most powerful but it somehow lacks a compelling reason to switch as none of its additional functions seem worth the effort to switch. Anyway, who cares. They all interact very nicely and switching from one to the other is not so hard as long as you could in POJOs. Kind regards, Peter Kriens On 30 mei 2011, at 13:25, Felix Meschberger wrote: > Hi, > > Just stating an incompletely informed opinion here .. > > If you want something simple, light-weight and easy to use, go for > Declarative Services. > > If you want elaborate functionality or need something Declarative > Services does not provide, consider iPojo (I understand it is an > evolution of Declarative Services, right ?) > > If you have a Spring background go for blueprint. > > Regards > Felix, whose loves and sticks with Declarative Services ;-) > > Am Donnerstag, den 26.05.2011, 02:23 +0100 schrieb jie yan: >> On Thu, May 26, 2011 at 6:02 AM, Alasdair Nottingham wrote: >> >>> >>> >>> Alasdair Nottingham >>> >>> On 25 May 2011, at 22:16, "Richard S. Hall" wrote: >>> >>>> On 5/25/11 16:26, Alasdair Nottingham wrote: >>>>> Hi, >>>>> >>>>> This is good I might link to it, or pinch it for the aries webpage too >>>>> if that is ok. When doing that thought I would put some changes into >>>>> the blueprint column. The Aries blueprint implementation provides some >>>>> value add that would change some of the No's into Yes's. >>>> >>>> Sure. >>>> >>>>> One thing though in component lifecycle control you have a Partial >>>>> down for blueprint I was wondering what you meant by this. >>>> >>>> I'd have to review the chapter, I don't really claim to be any Blueprint >>> expert...other than knowing it sucks... ;-) >>> >>> Of course if you were an expert you would know how much better it is than >>> anything else ;) let the religious flame war begin, or not. >>> >> >> In fact, casual users wish for an almighty expert who knows all solutions >> in-depth and exposes them to all. >> >> If there's no such expert, the second best method is, experts of different >> solutions advertise themself and compare with each other. >> >> Maybe that can be called religious flame war, but it's valuable. What we >> really need in open community is simple and perfect product in technology, >> but not many repeat manufacturing wheels like some outside companies. >> >> Regards, >> drhades >> >>> >>>> >>>> -> richard >>>> >>>>> Thanks >>>>> Alasdair >>>>> >>>>> >>>>> On 25 May 2011 15:29, Richard S. Hall wrote: >>>>>> On 5/25/11 9:19, Richard S. Hall wrote: >>>>>>> We actually have a table in our book (OSGi in Action) that tries to >>>>>>> compare the features...perhaps I could re-create that table on a web >>> page... >>>>>> Ok, I added the table to the iPOJO FAQ on wiki: >>>>>> >>>>>> >>>>>> >>> https://cwiki.apache.org/confluence/display/FELIX/iPOJO+FAQ#iPOJOFAQ-HowdoesiPOJOcomparetoDeclarativeServicesorBlueprint%3F >>>>>> >>>>>> It's not perfect, but it is better than nothing. It should eventually >>>>>> propagate to our static pages. >>>>>> >>>>>> Clement, please double check the iPOJO features, since you've added >>> features >>>>>> since the book has been published. >>>>>> >>>>>> -> richard >>>>>> >>>>>>> On 5/25/11 5:26, jie yan wrote: >>>>>>>> +1 >>>>>>>> >>>>>>>> Regards, >>>>>>>> drhades >>>>>>>> >>>>>>>> On Wed, May 25, 201
Re: How to organize OSGi bundles according to source code dependencies analyse report
I think the primary focus is grouping packages with the following rules: 1) Group packages that are strongly connected 2) Start with the largest group and try to merge groups into it that do not cause additional dependencies 3) repeat for all groups I think you need a cost/entropy function to calculate the optimum division. If you group package A and B then the cost is zero if A and B have identical imports. Even if A and B are not cohesive they could be placed in the same bundle because they do not drag in additional dependencies. So the interesting question is what the cost is if B would add one additional import. Is it worth it? Or not? Part of that analysis is then to analyze if you could do more grouping if classes were moved from packages to other (new?) packages. I.e. sometimes you have a package where there is only one class that makes the package not groupable. I think there should be the concept of a "dependency cost". If you import X by 15 packages and 254 classes it is likely that you get your moneys worth for that dependency. However, if you find that a single class drags in dependencies that nobody else uses it is likely that that class is expensive. It is interesting how much automation we can do there but I expect you need people to look at the details. One of the biggest modularity problems are usually when you get bridge classes. I.e. someone has a library doing X but wants to make it available with for example Spring. There is usually then a few classes bridging the library to the Spring world, which can be extremely expensive. For example, bnd is coupled to ant but I made sure that was a separate package. This all seems closely related to the concept of entropy and it might be interesting to take a look at Shannon et al. You have to find a decomposition that has minimum entropy where entropy is somehow defined in terms of imports versus contents. You want to group as much as possible while minimizing the connections between the groups. Again, this normally means you need a cost function and optimize that cost function. However, start with the mechanic grouping and apply that idea to open source projects to see how this would look like. If you could calculate the "entropy" of existing bundles that would also be very interesting. Kind regards, Peter Kriens On 8 jun 2011, at 10:35, Tiger Gui wrote: > Hi Peter, > > I am working about source code dependencies analyse algorithm design > and implement job, i will finish the whole analyse algorithm in the > coming month. This algorithm include two sections: package and class. > > 1. Package section > > a. It can analyse package cycles in project source code > b. Analyse all the necessary packages for each package > c. Tell us who use it about each package > > 2. Class section > > a. This algorithm will tell us all the class cycles in project source > code (for example A -> B -> C -> A) > b. Analyse all the necessary classes for each class (for example, it > can tell us class A use class B, C and D) > c. Tell us who use it about each class (for example, it can tell us > class A was used by class B and C) > > After we get the source code analyse report, we should split the > project into several OSGi bundles, so the problems is how should we > split the project according to the report. > > In my initial option: > > A. classes in a cycle should be in the same bundle > B. classes (or interfaces ) which were used much by other classes, but > does not require any other class, can be in the same bundle. (Usually, > these are basic interface or abstract class). These classes usually > be API define classes. > > I am very clear about these two situations, but there should be many > other situations. So, you advises ? > > -- > Best Regards > > Tiger Gui [tigergui1...@gmail.com]
Re: Where can i find Bnd's source code
All source code is on Github ... https://github.com/bnd/bnd Kind regards, Peter Kriens On 23 mei 2011, at 08:24, Tiger Gui wrote: > Hi Peter, > > Where can i get Bnd's source code or API document ? I want to use > Tarjan's algorithm to analyse project's OSGi bundles, as we know, bnd > supply this algorithm's implementation already, it is in ee > aQute.libg.tarjan. In order to make clear how to use and improve this > algorithm, i want to check Bnd's source code. But i can not find it in > bnd's index page [1]. Where can i get it ? Thank you > > > > [1] http://www.aqute.biz/Bnd/Bnd > > -- > Best Regards > > Tiger Gui [tigergui1...@gmail.com]
Re: Bndtools based OSGi bundle marker project source code hosting address
That was my guess ... but he had the chance to test it. In theory practice and theory are the same, in practice they tend to differ :-) Kind regards, Peter Kriens On 6 mei 2011, at 15:59, Toni Menzel wrote: > Git is as distributed as it can be. If github does not work, any other > reachable ssh server can server as a remote repo even without requiring > extra (server) software. > Also, there are other git (free for oss) hosters. For distributed work with > non free internet connection (like you in China) there is no better thing > than a distributed version control system. is it? > > just my 2cts. > > On Fri, May 6, 2011 at 3:54 PM, Peter Kriens wrote: > >> Google code is fine, weird that Github is bad in china. I would expect git >> to work a lot better than svn with a bad connection ... But I have no >> problem with Google code. >> >> Kind regards, >> >> Peter Kriens >> >> On 4 mei 2011, at 05:20, Tiger Gui wrote: >> >>> Hi Peter, >>> >>> Due to bad internet service in China, i can hardly connected to Github >>> web site, so i decided to host my project source code in Google Code >>> web site first, and finished initial source code commit job, its >>> address is here [1]. I do not know whether Apache can supply some SVN >>> workspace for GSoC 2011 project, but it seems that Google code is the >>> best place for me currently :-) >>> >>> >>> [1] http://code.google.com/p/osgimaker/ >>> >>> -- >>> Best Regards >>> >>> Tiger Gui [tigergui1...@gmail.com] >> >> > > > -- > Toni Menzel Source <http://tonimenzel.com>
Re: Bndtools based OSGi bundle marker project source code hosting address
Google code is fine, weird that Github is bad in china. I would expect git to work a lot better than svn with a bad connection ... But I have no problem with Google code. Kind regards, Peter Kriens On 4 mei 2011, at 05:20, Tiger Gui wrote: > Hi Peter, > > Due to bad internet service in China, i can hardly connected to Github > web site, so i decided to host my project source code in Google Code > web site first, and finished initial source code commit job, its > address is here [1]. I do not know whether Apache can supply some SVN > workspace for GSoC 2011 project, but it seems that Google code is the > best place for me currently :-) > > > [1] http://code.google.com/p/osgimaker/ > > -- > Best Regards > > Tiger Gui [tigergui1...@gmail.com]
Re: Project source code host things for "Bndtools based OSGi bundles maker project"
It will ... Otherwise Richard will surely kill me after having suffered heavy torture :-) Kind regards, Peter Kriens On 20 apr 2011, at 15:08, Tiger Gui wrote: > Ok, we will host it at github first. And hoping it can be merged into > Felxi oneday :-) > > 2011/4/20 Peter Kriens : >> I would rather strongly prefer to use git in this project so I suggest >> github. bnd and bndtools are scheduled to move to Felix later (actually when >> we find some way to keep using git and not have to revert to svn). Github >> will integrate rather nicely with bnd and bntools that are also hosted at >> github. At github you can just fork the bnd and bndtools repositories. I >> think this model will be a whole lot less complex this way. Once we move >> bnd(tools) to Felix we can integrate your code as well. >> >> bnd is at http://www.github.com/bnd >> bndtools is at http://www.github.com/njbartlett >> >> Kind regards, >> >>Peter Kriens >> >> >> >> On 20 apr 2011, at 14:57, Tiger Gui wrote: >> >>> Hi Peter, >>> >>> After these days's research job and coding experiment, i think it is >>> time for me to start some real coding job first. Now the only problem >>> is that where should we host our project ? If our project is accepted >>> by Apache, should we create a SVN workspace in Apache's SVN server or >>> something ? Or we should find some other place to host our project, >>> for example, host it in Google Code platform ? Thank you >>> >>> -- >>> Best Regards >>> >>> Tiger Gui [tigergui1...@gmail.com] >> >> > > > > -- > Best Regards > > Tiger Gui [tigergui1...@gmail.com]
Re: Project source code host things for "Bndtools based OSGi bundles maker project"
I would rather strongly prefer to use git in this project so I suggest github. bnd and bndtools are scheduled to move to Felix later (actually when we find some way to keep using git and not have to revert to svn). Github will integrate rather nicely with bnd and bntools that are also hosted at github. At github you can just fork the bnd and bndtools repositories. I think this model will be a whole lot less complex this way. Once we move bnd(tools) to Felix we can integrate your code as well. bnd is at http://www.github.com/bnd bndtools is at http://www.github.com/njbartlett Kind regards, Peter Kriens On 20 apr 2011, at 14:57, Tiger Gui wrote: > Hi Peter, > > After these days's research job and coding experiment, i think it is > time for me to start some real coding job first. Now the only problem > is that where should we host our project ? If our project is accepted > by Apache, should we create a SVN workspace in Apache's SVN server or > something ? Or we should find some other place to host our project, > for example, host it in Google Code platform ? Thank you > > -- > Best Regards > > Tiger Gui [tigergui1...@gmail.com]
[jira] [Commented] (FELIX-2916) Don't include Embed-Dependency in manifest
[ https://issues.apache.org/jira/browse/FELIX-2916?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13021569#comment-13021569 ] Peter Kriens commented on FELIX-2916: - It does not do any harm and it provides me with a lot of info when there are problems ... > Don't include Embed-Dependency in manifest > -- > > Key: FELIX-2916 > URL: https://issues.apache.org/jira/browse/FELIX-2916 > Project: Felix > Issue Type: Improvement > Components: Maven Bundle Plugin >Affects Versions: maven-bundle-plugin-2.3.4 >Reporter: Carsten Ziegeler >Priority: Minor > > The Embed-Dependency directive is an instruction for the plugin (bnd) - it > should not be included in the final manifest -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (FELIX-2899) [GSoc 2011]Bndtools based OSGi bundles maker project
[ https://issues.apache.org/jira/browse/FELIX-2899?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13021567#comment-13021567 ] Peter Kriens commented on FELIX-2899: - Hey! A bit of ambition has harmed nobody so far! :-) But I agree, it is ambitious. The project should really focus on the low hanging fruit first. > [GSoc 2011]Bndtools based OSGi bundles maker project > > > Key: FELIX-2899 > URL: https://issues.apache.org/jira/browse/FELIX-2899 > Project: Felix > Issue Type: Task > Environment: Eclipse platform, this project add a new tool for Felix > users to improve OSGi bundles development process in Eclipse environment >Reporter: Tiger Gui >Assignee: Peter Kriens > Labels: gsoc, gsoc2011, mentor, mentoring > Original Estimate: 1680h > Remaining Estimate: 1680h > > OSGi(Open Service Gateway Initiative) is a worldwide consortium of technology > innovators that advances a proven and > mature process to create open specifications that enable the modular assembly > of software built with Java technology. > It is becoming more and more popular in Java Desktop or Web application > developmenent especially when we are working on > some huge project, as it is growing more and more complex, OSGi can help > us.Developing with OSGi technology means > developing bundles: the OSGi components. Bundles are modules. > OSGi is a good thing, but coin has two sides. Usually the development process > with OSGi will be more troublesome. Suppose > that we are in this scenario. We use a interface Greeting to say hello to our > customers , but we should say different words to different kind of customers > , so we have two implemention class for Greeting interface, we > name them BasicGreeting and GreatGreeting. > If we develop this application in a traditional OSGi way, we should create at > lease 3 projects (or bundles) in our IDE (Eclipse for example). > one service define bundle, two service supply bundles, it's a long list in > our workspace.Isn't it troublesome? If we just > write these codes in a Jave project and some tool can help us to split this > project in OSGi way and export 3 jar files, isn't it cool? > So i want to build OSGi split tool for Java project, it can also be used to > split and refactor our exist huge project in OSGi way. This > is very important. In some huge application, how to manage components in a > convinent way is an art, so far, OSGi is the best solution > that we can find. But the refactor and split for exist huge project is > complex and painful. This tool will help us to do this job. > We want to build a bnd(tools) based OSGi bunlles maker project, it will help > us analyse java application and split the whole project into several OSGi > bundles. > Suppose that we write code in good style, define service in interface, > implement the service by the implemention class of the interface > and put similar service in a package. This tool can analyse source code, > supply vari-size grained split and refactor suggestions, show > the analyse result in a GUI view and we can change split solution manually, > then it will split the project into several projects. > Function lists: > 1. configuration > Define default split/refactor solution for this tool. For example,assign > default interface split particle or package split partical. Or may be > we can just split the project by function module define, similar with > M(Module)-V(View)-C(control) develop pattern. Or in some other ways. > 2. analyse module > It can analyse project source code, make clear of class dependency > relationship and give us a graphical view analyse result, this is default > split solution, and we can change it as we like. > The trick is to find strongly coupled packages. These are packages that are > in a cycle. A -> B -> C -> A. Normally I find that these packages should be > in the same bundle. In bnd (the current next branch) I already can calculate > those strongly connected packages. In general, I find that many, especially > larger, bundles consist of a number of subsystems. > These subsystems have dependencies on each other, however, by definition > there is no cycle between these subsystem dependencies (otherwise they would > be strongly connected and be part of the same subsystem). > There should be the following types of subsystems: > API - Self contained, no internal dependencies. All exported/imported. Very > few dependencies. The OSGi specification packages are prime examples. Having > import
[jira] [Commented] (FELIX-2918) Missing package in Import-Package causes NoClassDefFoundError at runtime
[
https://issues.apache.org/jira/browse/FELIX-2918?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13020920#comment-13020920
]
Peter Kriens commented on FELIX-2918:
-
I think the problem is caused by improper dynamic loading in Guice and not bnd.
Why do you expect to see package b in the analysis of A? A has no reference to
package b whatsoever, look in the class file.
a.AS -> e.ES -> b.AD. Therefore A should import e but not more.
If you look at the class file for AS you will not find any reference of AD nor
AH because these are referenced by EW and ES. To make it more clear, I
simplified the example a bit:
A: package a;
public class A implements B {}
B: package b;
public interface B extends C {}
C: package c;
public interface C {}
It is clear here that A should not import C. It is likely that the Guice code
tries to load the interfaces through the same class loader but it must follow
the rules and use the loader of interface B to load interface C and not as it
seems to do now, the loader of class A.
If you can verify this, please close the bug otherwise please try to make a
minimal example and send it to me..
> Missing package in Import-Package causes NoClassDefFoundError at runtime
>
>
> Key: FELIX-2918
> URL: https://issues.apache.org/jira/browse/FELIX-2918
> Project: Felix
> Issue Type: Bug
> Components: Maven Bundle Plugin
>Affects Versions: maven-bundle-plugin-2.3.4
> Environment: OSX Snow Leopard, Maven3, Java6, Guice/Peaberry
>Reporter: Yuri
>Priority: Minor
>
> I have an issue where I get a NoClassDefFoundError while starting my
> multi-project bundles. This exception is thrown while Peaberry is creating an
> proxy for a multiple() import. Aside from the Peaberry specifics, the
> multiple() import is loading the service interface, it's implementation and
> dependencies until it hits this error. After taking a closer look and
> comparing the bundle giving me grief to another similar (wrt dependencies)
> one that was working fine, I noticed two differences in the Manifest: a
> missing package in the Import-Package and the same package missing from the
> uses directive in the Export-Package. Basically, maven-bundle-plugin was not
> "seeing" the missing package when auto generating the manifest.
> The scenario, in more detail, is as follows.
> Bundle A (the one with the missing package in the manifest) imports packages
> from bundle E:
> BUNDLE A (package a):
>
> interface a.AS extends e.ES{}
> interface a.AW extends e.EW{}
> BUNDLE E (packages e and b):
>
> interface e.EW, W extends e.EW> extends b.AD, b.AH{}
> interface b.AD{} // THIS IS THE NoClassDefFoundError CLASS
> interface b.AH{}
> I then ran my mvn3 build with maven-bundle-plugin v2.3.4 and attached a
> debugger to it. I then stopped in the aQute.lib.osgi.Analyzer line
> 1684 (t.addAll(clazz.getReferred());) for class a.AS. I was expecting
> to see packages a (for a.AS and the two generic parameters a.AS and
> a.AW, which happens to be in the same package), e (for e.ES interface,
> and the two generic parameters a.ES and e.EW, which happens to be in
> the same package) and b (b.AD and b.AH). However, I didn't see the
> package b there.
> So it seems that BND is not analyzing dependencies of dependencies and the
> reason my other module worked was because there was an unrelated, direct
> dependency to package b somewhere else, forcing the package to be added to
> the Manifest.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Bndtools based OSGi bundles maker project need feedback
I do not think you get any responsibilities as long as you do not sign up as a mentor for a specific project. The process as I understand it is to get the id so you can put your evaluation in the CSV file. Kind regards, Peter Kriens On 14 apr 2011, at 16:31, David Bosschaert wrote: > Sure, but I guess there are other responsibilities attached to being a > mentor, than just leaving a supportive comment. > > Cheers, > > David > > On 14 April 2011 15:24, Peter Kriens wrote: >> The issue is https://issues.apache.org/jira/browse/FELIX-2899 >> Becoming a mentor is easy at http://socghop.appspot.com , this gives you an >> id >> Kind regards, >> Peter Kriens >> >> >> >> >> On 14 apr 2011, at 16:20, David Bosschaert wrote: >> >> That file is for mentors only AFAICS (you need to specify your mentor ID). >> >> Again I'm happy to say that I'd love to see this done but I'm not sure >> what the appropriate place for it is... >> BTW the linked Felix issue >> (https://issues.apache.org/jira/browse/FELIX-2898) contains only >> garbage. >> >> David >> >> On 14 April 2011 15:13, Peter Kriens wrote: >> >> I think you have to register as a mentor first for that site, quite easy. >> However, the most important one is the CSV file in SVN. >> >> >> https://svn.apache.org/repos/private/committers/gsoc/GSoC-2011-scoring.csv >> >> I am happy I am not the only one having problems with the process :-) >> >> Kind regards, >> >>Peter Kriens >> >> >> On 14 apr 2011, at 15:57, David Bosschaert wrote: >> >> Tiger Gui wrote: >> >> or just leave some comments behind my project proposal [5], it will help us >> much >> >> I'm happy to leave some positive comments, but when I click on that link I >> get: >> >> "This proposal is not made public, and you are not the student who >> >> submitted the proposal, nor are you a mentor for the organization it >> >> was submitted to." >> >> Do I need to register as a mentor just to leave some positive >> >> comments? BTW I am an apache committer. >> >> Cheers, >> >> David >> >> On 14 April 2011 14:45, Peter Kriens wrote: >> >> Yeah, well, I also find it not easy to fill in. However, you can look at the >> top for the title and then fill in your comments and valuations. >> >> The only advantage of this process is that it is at least not XML :-) >> >> Kind regards, >> >>Peter Kriens >> >> On 14 apr 2011, at 14:57, Toni Menzel wrote: >> >> um.. after checking out, am i supposed to find the logic in this CSV file >> >> and add values like "i think they comply to the intrinsic" logic ? >> >> Or is this just the data view of some web form i missed ? >> >> Toni >> >> On Thu, Apr 14, 2011 at 2:40 PM, Peter Kriens wrote: >> >> The deadline is today btw so in this case there can be no procrastination >> >> ... :-) >> >> Kind regards, >> >> Peter Kriens >> >> On 14 apr 2011, at 09:29, Tiger Gui wrote: >> >> Hi all, >> >> These days, i was thinking about create a Bndtools based OSGi bundles >> >> maker project, it will help us to split complex Java project into OSGi >> >> bundles (modules), i have submited my project proposal here[1]. I have >> >> finished its demo on line here [2] and finished core analyse algorithm >> >> design job here[3]. >> >> Meanwhile, it is a brand new project, i want to hold it as a Google >> >> Summer of Code (GSoC)4] project, and Peter would like to mentor me( In >> >> fact, he has given me many good advises already), GSoC will select >> >> some *perfect* to support only, so if you guys are interested in this >> >> tool, may be you can give our project some support, apply to be a >> >> mentor member for Apache in GSoC melange system[4], and give my >> >> project some feedback or just leave some comments behind my project >> >> proposal [5], it will help us much :-) >> >> And it seems that there is a committer vote and score process for all >> >> the project proposals, all the support from you guys can help this >> >> tool to win. All Apache committer can register in GSoC system, so if >> >> you are interested, please give us some support, thank you very much >>
Re: Bndtools based OSGi bundles maker project need feedback
The issue is https://issues.apache.org/jira/browse/FELIX-2899 Becoming a mentor is easy at http://socghop.appspot.com , this gives you an id Kind regards, Peter Kriens On 14 apr 2011, at 16:20, David Bosschaert wrote: > That file is for mentors only AFAICS (you need to specify your mentor ID). > > Again I'm happy to say that I'd love to see this done but I'm not sure > what the appropriate place for it is... > BTW the linked Felix issue > (https://issues.apache.org/jira/browse/FELIX-2898) contains only > garbage. > > David > > On 14 April 2011 15:13, Peter Kriens wrote: >> I think you have to register as a mentor first for that site, quite easy. >> However, the most important one is the CSV file in SVN. >> >> >> https://svn.apache.org/repos/private/committers/gsoc/GSoC-2011-scoring.csv >> >> I am happy I am not the only one having problems with the process :-) >> >> Kind regards, >> >>Peter Kriens >> >> >> On 14 apr 2011, at 15:57, David Bosschaert wrote: >> >>> Tiger Gui wrote: >>>> or just leave some comments behind my project proposal [5], it will help >>>> us much >>> >>> I'm happy to leave some positive comments, but when I click on that link I >>> get: >>> "This proposal is not made public, and you are not the student who >>> submitted the proposal, nor are you a mentor for the organization it >>> was submitted to." >>> >>> Do I need to register as a mentor just to leave some positive >>> comments? BTW I am an apache committer. >>> >>> Cheers, >>> >>> David >>> >>> On 14 April 2011 14:45, Peter Kriens wrote: >>>> Yeah, well, I also find it not easy to fill in. However, you can look at >>>> the top for the title and then fill in your comments and valuations. >>>> >>>> The only advantage of this process is that it is at least not XML :-) >>>> >>>> Kind regards, >>>> >>>>Peter Kriens >>>> >>>> On 14 apr 2011, at 14:57, Toni Menzel wrote: >>>> >>>>> um.. after checking out, am i supposed to find the logic in this CSV file >>>>> and add values like "i think they comply to the intrinsic" logic ? >>>>> Or is this just the data view of some web form i missed ? >>>>> >>>>> Toni >>>>> >>>>> On Thu, Apr 14, 2011 at 2:40 PM, Peter Kriens >>>>> wrote: >>>>> >>>>>> The deadline is today btw so in this case there can be no procrastination >>>>>> ... :-) >>>>>> >>>>>> Kind regards, >>>>>> >>>>>> Peter Kriens >>>>>> >>>>>> On 14 apr 2011, at 09:29, Tiger Gui wrote: >>>>>> >>>>>>> Hi all, >>>>>>> >>>>>>> These days, i was thinking about create a Bndtools based OSGi bundles >>>>>>> maker project, it will help us to split complex Java project into OSGi >>>>>>> bundles (modules), i have submited my project proposal here[1]. I have >>>>>>> finished its demo on line here [2] and finished core analyse algorithm >>>>>>> design job here[3]. >>>>>>> >>>>>>> Meanwhile, it is a brand new project, i want to hold it as a Google >>>>>>> Summer of Code (GSoC)4] project, and Peter would like to mentor me( In >>>>>>> fact, he has given me many good advises already), GSoC will select >>>>>>> some *perfect* to support only, so if you guys are interested in this >>>>>>> tool, may be you can give our project some support, apply to be a >>>>>>> mentor member for Apache in GSoC melange system[4], and give my >>>>>>> project some feedback or just leave some comments behind my project >>>>>>> proposal [5], it will help us much :-) >>>>>>> >>>>>>> And it seems that there is a committer vote and score process for all >>>>>>> the project proposals, all the support from you guys can help this >>>>>>> tool to win. All Apache committer can register in GSoC system, so if >>>>>>> you are interested, please give us some support, thank you very much >>>>>>> :-) >&g
Re: Bndtools based OSGi bundles maker project need feedback
I think you have to register as a mentor first for that site, quite easy. However, the most important one is the CSV file in SVN. https://svn.apache.org/repos/private/committers/gsoc/GSoC-2011-scoring.csv I am happy I am not the only one having problems with the process :-) Kind regards, Peter Kriens On 14 apr 2011, at 15:57, David Bosschaert wrote: > Tiger Gui wrote: >> or just leave some comments behind my project proposal [5], it will help us >> much > > I'm happy to leave some positive comments, but when I click on that link I > get: > "This proposal is not made public, and you are not the student who > submitted the proposal, nor are you a mentor for the organization it > was submitted to." > > Do I need to register as a mentor just to leave some positive > comments? BTW I am an apache committer. > > Cheers, > > David > > On 14 April 2011 14:45, Peter Kriens wrote: >> Yeah, well, I also find it not easy to fill in. However, you can look at the >> top for the title and then fill in your comments and valuations. >> >> The only advantage of this process is that it is at least not XML :-) >> >> Kind regards, >> >>Peter Kriens >> >> On 14 apr 2011, at 14:57, Toni Menzel wrote: >> >>> um.. after checking out, am i supposed to find the logic in this CSV file >>> and add values like "i think they comply to the intrinsic" logic ? >>> Or is this just the data view of some web form i missed ? >>> >>> Toni >>> >>> On Thu, Apr 14, 2011 at 2:40 PM, Peter Kriens wrote: >>> >>>> The deadline is today btw so in this case there can be no procrastination >>>> ... :-) >>>> >>>> Kind regards, >>>> >>>> Peter Kriens >>>> >>>> On 14 apr 2011, at 09:29, Tiger Gui wrote: >>>> >>>>> Hi all, >>>>> >>>>> These days, i was thinking about create a Bndtools based OSGi bundles >>>>> maker project, it will help us to split complex Java project into OSGi >>>>> bundles (modules), i have submited my project proposal here[1]. I have >>>>> finished its demo on line here [2] and finished core analyse algorithm >>>>> design job here[3]. >>>>> >>>>> Meanwhile, it is a brand new project, i want to hold it as a Google >>>>> Summer of Code (GSoC)4] project, and Peter would like to mentor me( In >>>>> fact, he has given me many good advises already), GSoC will select >>>>> some *perfect* to support only, so if you guys are interested in this >>>>> tool, may be you can give our project some support, apply to be a >>>>> mentor member for Apache in GSoC melange system[4], and give my >>>>> project some feedback or just leave some comments behind my project >>>>> proposal [5], it will help us much :-) >>>>> >>>>> And it seems that there is a committer vote and score process for all >>>>> the project proposals, all the support from you guys can help this >>>>> tool to win. All Apache committer can register in GSoC system, so if >>>>> you are interested, please give us some support, thank you very much >>>>> :-) >>>>> >>>>> This is the GSoC mentor register steps: >>>>> 1. open url [4], register as a mentor, you should supply a email >>>>> address to register, and then you will get a *link_id*. >>>>> >>>>> 2. add your register email (in google melange system) address and the >>>>> *link_id* in the file [6] >>>>> https://svn.apache.org/repos/private/committers/GsocLinkId.txt, only >>>>> Apache committer guys edit this file, you >>>>> should supply your Apache account and password to export this file, >>>>> edit it and then submit it. >>>>> >>>>> 3. if you do not use your Apache account (such as ***@apache.org) to >>>>> register in Google melange system, you should also add your apache >>>>> email the the email you used to register in Google melange system into >>>>> the file [7] >>>> https://svn.apache.org/repos/private/committers/MailAlias.txt, >>>>> this file also need you supply Apache account and password to edit it. >>>>> >>>>> 4. apply to be a mentor for Apache in GSoC melange system[4], wait for >>>>> Apache admins
Re: Bndtools based OSGi bundles maker project need feedback
Yeah, well, I also find it not easy to fill in. However, you can look at the top for the title and then fill in your comments and valuations. The only advantage of this process is that it is at least not XML :-) Kind regards, Peter Kriens On 14 apr 2011, at 14:57, Toni Menzel wrote: > um.. after checking out, am i supposed to find the logic in this CSV file > and add values like "i think they comply to the intrinsic" logic ? > Or is this just the data view of some web form i missed ? > > Toni > > On Thu, Apr 14, 2011 at 2:40 PM, Peter Kriens wrote: > >> The deadline is today btw so in this case there can be no procrastination >> ... :-) >> >> Kind regards, >> >> Peter Kriens >> >> On 14 apr 2011, at 09:29, Tiger Gui wrote: >> >>> Hi all, >>> >>> These days, i was thinking about create a Bndtools based OSGi bundles >>> maker project, it will help us to split complex Java project into OSGi >>> bundles (modules), i have submited my project proposal here[1]. I have >>> finished its demo on line here [2] and finished core analyse algorithm >>> design job here[3]. >>> >>> Meanwhile, it is a brand new project, i want to hold it as a Google >>> Summer of Code (GSoC)4] project, and Peter would like to mentor me( In >>> fact, he has given me many good advises already), GSoC will select >>> some *perfect* to support only, so if you guys are interested in this >>> tool, may be you can give our project some support, apply to be a >>> mentor member for Apache in GSoC melange system[4], and give my >>> project some feedback or just leave some comments behind my project >>> proposal [5], it will help us much :-) >>> >>> And it seems that there is a committer vote and score process for all >>> the project proposals, all the support from you guys can help this >>> tool to win. All Apache committer can register in GSoC system, so if >>> you are interested, please give us some support, thank you very much >>> :-) >>> >>> This is the GSoC mentor register steps: >>> 1. open url [4], register as a mentor, you should supply a email >>> address to register, and then you will get a *link_id*. >>> >>> 2. add your register email (in google melange system) address and the >>> *link_id* in the file [6] >>> https://svn.apache.org/repos/private/committers/GsocLinkId.txt, only >>> Apache committer guys edit this file, you >>> should supply your Apache account and password to export this file, >>> edit it and then submit it. >>> >>> 3. if you do not use your Apache account (such as ***@apache.org) to >>> register in Google melange system, you should also add your apache >>> email the the email you used to register in Google melange system into >>> the file [7] >> https://svn.apache.org/repos/private/committers/MailAlias.txt, >>> this file also need you supply Apache account and password to edit it. >>> >>> 4. apply to be a mentor for Apache in GSoC melange system[4], wait for >>> Apache admins to approve your apply(i think they will approve your >>> application very soon). Once you are approved, you can find my >>> proposal, leave some comments, particate in the final vote process or >>> view the other interesting project proposal or try to mentor some >>> project. >>> >>> >>> >>> [1] https://issues.apache.org/jira/browse/FELIX-2898 >>> [2] http://code.google.com/p/osgimaker/wiki/Quick_Start >>> [3] >> http://code.google.com/p/osgimaker/wiki/Project_analyse_algorithm_description >>> [4] http://socghop.appspot.com >>> [5] >> http://socghop.appspot.com/gsoc/proposal/review/google/gsoc2011/tigergui/1 >>> [6] https://svn.apache.org/repos/private/committers/GsocLinkId.txt >>> [7] https://svn.apache.org/repos/private/committers/MailAlias.txt >>> -- >>> Best Regards >>> >>> Tiger Gui [tigergui1...@gmail.com] >> >> > > > -- > *Toni Menzel - http://www.okidokiteam.com*
