Re: felix-cache

2023-03-25 Thread Chuck Davis
Anybody got an idea what I can do to get rid of all the errors?  All
bundles in the cache produce this error.  The project runs flawlessly on
Linux but when I try to run it on windows (10) I get the following errors.
I'm not a windows user so I have no idea if there some setting that will
make windows work properly with the files.  Thanks for any advice.

ERROR: Error reloading cached bundle, removing it: .\felix-cache\bundle1
java.nio.file.NoSuchFileException:
.\felix-cache\bundle1\version0.0\bundle.jar
at
java.base/sun.nio.fs.WindowsException.translateToIOException(WindowsException.java:85)
at
java.base/sun.nio.fs.WindowsException.rethrowAsIOException(WindowsException.java:103)
at
java.base/sun.nio.fs.WindowsException.rethrowAsIOException(WindowsException.java:108)
at
java.base/sun.nio.fs.WindowsFileAttributeViews$Basic.readAttributes(WindowsFileAttributeViews.java:53)
at
java.base/sun.nio.fs.WindowsFileAttributeViews$Basic.readAttributes(WindowsFileAttributeViews.java:38)
at
java.base/sun.nio.fs.WindowsFileSystemProvider.readAttributes(WindowsFileSystemProvider.java:199)
at java.base/java.nio.file.Files.readAttributes(Files.java:1849)
at java.base/java.util.zip.ZipFile$Source.get(ZipFile.java:1279)
at
java.base/java.util.zip.ZipFile$CleanableResource.(ZipFile.java:710)
at java.base/java.util.zip.ZipFile.(ZipFile.java:243)
at java.base/java.util.zip.ZipFile.(ZipFile.java:172)
at java.base/java.util.zip.ZipFile.(ZipFile.java:186)
at org.apache.felix.framework@7.0.5
/org.apache.felix.framework.util.SecureAction.openZipFile(SecureAction.java:802)
at org.apache.felix.framework@7.0.5
/org.apache.felix.framework.util.WeakZipFileFactory$WeakZipFile.(WeakZipFileFactory.java:169)
at org.apache.felix.framework@7.0.5
/org.apache.felix.framework.util.WeakZipFileFactory$WeakZipFile.(WeakZipFileFactory.java:151)
at org.apache.felix.framework@7.0.5
/org.apache.felix.framework.util.WeakZipFileFactory.create(WeakZipFileFactory.java:78)
at org.apache.felix.framework@7.0.5
/org.apache.felix.framework.cache.JarRevision.(JarRevision.java:83)
at org.apache.felix.framework@7.0.5
/org.apache.felix.framework.cache.BundleArchive.createRevisionFromLocation(BundleArchive.java:819)
at org.apache.felix.framework@7.0.5
/org.apache.felix.framework.cache.BundleArchive.reviseInternal(BundleArchive.java:491)
at org.apache.felix.framework@7.0.5
/org.apache.felix.framework.cache.BundleArchive.(BundleArchive.java:226)
at org.apache.felix.framework@7.0.5
/org.apache.felix.framework.cache.BundleCache.getArchives(BundleCache.java:427)
at org.apache.felix.framework@7.0.5
/org.apache.felix.framework.Felix.init(Felix.java:798)
at org.apache.felix.framework@7.0.5
/org.apache.felix.framework.Felix.init(Felix.java:648)
at YRSDealerAgent@1.0
/com.yrs.dealer.client.agent.YRSDealerAgent.start(YRSDealerAgent.java:56)
at YRSDealerAgent@1.0
/com.yrs.dealer.client.agent.YRSDealerAgent.main(YRSDealerAgent.java:47)


Re: Felix DM - Migrating from version 3 to 4

2020-07-20 Thread Pierre De Rop
Hello Martin,

you can stop your component by removing it from the dependency manager
object.

Here is an example:

public class Activator extends DependencyActivatorBase {
@Override
public void init(BundleContext ctx, DependencyManager dm) throws
Exception {
Component c = createComponent().setImplementation(Example.class);
dm.add(c);
dm.remove(c); // will stop the component
}
}

regards
Pierre

On Wed, Jul 15, 2020 at 9:13 PM Martin Lichtin 
wrote:

> When migrating from DM version 3 to 4, I've code that's using the stop()
> method on the Component interface.
>
>  component.stop();
>
> What would I migrate this to?
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
> For additional commands, e-mail: users-h...@felix.apache.org
>
>


Re: felix-dev examples will not build

2020-07-20 Thread Carsten Ziegeler

Hi,

thanks for your report - the examples haven't been touched for a long 
time; I updated them to use newer maven plugins; at least they should 
compile now


Regards
Carsten

Am 06.07.2020 um 00:46 schrieb user unknown:

- this is the latest felix-dev from github - last commit 321fe9a
- Apache Maven 3.6.3
- Java version: 1.8.0_202
- OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows"

[DEBUG]
F:\apache_felix\felix-dev-master\examples\servicebased.host\src\main\java
[INFO] Compiling 8 source files to
F:\apache_felix\felix-dev-master\examples\servicebased.host\target\classes
[INFO]

[INFO] BUILD FAILURE
[INFO]

[INFO] Total time:  3.174 s
[INFO] Finished at: 2020-07-05T17:39:22-05:00
[INFO]

[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-compiler-plugin:2.0.2:compile
(default-compile) on project servicebased.host: Compilation failure:
Compilation failure:
[ERROR]
F:\apache_felix\felix-dev-master\examples\servicebased.host\src\main\java\org\apache\felix\example\servicebased\host\ShapeTracker.java:[37,48]
error: type ServiceTracker does not take parameters
[ERROR]
[ERROR]
F:\apache_felix\felix-dev-master\examples\servicebased.host\src\main\java\org\apache\felix\example\servicebased\host\ShapeTracker.java:[65,53]
error: type ServiceReference does not take parameters
[ERROR]
[ERROR]
F:\apache_felix\felix-dev-master\examples\servicebased.host\src\main\java\org\apache\felix\example\servicebased\host\ShapeTracker.java:[79,48]
error: type ServiceReference does not take parameters
[ERROR]
[ERROR]
F:\apache_felix\felix-dev-master\examples\servicebased.host\src\main\java\org\apache\felix\example\servicebased\host\ShapeTracker.java:[91,47]
error: type ServiceReference does not take parameters
[ERROR]
[ERROR]
F:\apache_felix\felix-dev-master\examples\servicebased.host\src\main\java\org\apache\felix\example\servicebased\host\ShapeTracker.java:[106,42]
error: type ServiceReference does not take parameters
[ERROR]
[ERROR]
F:\apache_felix\felix-dev-master\examples\servicebased.host\src\main\java\org\apache\felix\example\servicebased\host\ShapeTracker.java:[133,64]
error: type ServiceReference does not take parameters
[ERROR]
[ERROR]
F:\apache_felix\felix-dev-master\examples\servicebased.host\src\main\java\org\apache\felix\example\servicebased\host\ShapeTracker.java:[162,38]
error: type ServiceReference does not take parameters
[ERROR]
[ERROR]
F:\apache_felix\felix-dev-master\examples\servicebased.host\src\main\java\org\apache\felix\example\servicebased\host\ShapeTracker.java:[172,63]
error: type ServiceReference does not take parameters
[ERROR]
[ERROR]
F:\apache_felix\felix-dev-master\examples\servicebased.host\src\main\java\org\apache\felix\example\servicebased\host\DefaultShape.java:[53,28]
error: type ServiceReference does not take parameters
[ERROR]
[ERROR]
F:\apache_felix\felix-dev-master\examples\servicebased.host\src\main\java\org\apache\felix\example\servicebased\host\DefaultShape.java:[70,63]
error: type ServiceReference does not take parameters
[ERROR]
[ERROR]
F:\apache_felix\felix-dev-master\examples\servicebased.host\src\main\java\org\apache\felix\example\servicebased\host\ShapeTracker.java:[64,4]
error: method does not override or implement a method from a supertype
[ERROR]
[ERROR]
F:\apache_felix\felix-dev-master\examples\servicebased.host\src\main\java\org\apache\felix\example\servicebased\host\ShapeTracker.java:[78,4]
error: method does not override or implement a method from a supertype
[ERROR]
[ERROR]
F:\apache_felix\felix-dev-master\examples\servicebased.host\src\main\java\org\apache\felix\example\servicebased\host\ShapeTracker.java:[90,4]
error: method does not override or implement a method from a supertype
[ERROR]
[ERROR]
F:\apache_felix\felix-dev-master\examples\servicebased.host\src\main\java\org\apache\felix\example\servicebased\host\Activator.java:[76,30]
error: cannot find symbol
[ERROR]
[ERROR] could not parse error message:   symbol:   method open()
[ERROR]   location: variable m_shapetracker of type ShapeTracker
[ERROR]
F:\apache_felix\felix-dev-master\examples\servicebased.host\src\main\java\org\apache\felix\example\servicebased\host\Activator.java:93:
error: cannot find symbol
[ERROR] m_shapetracker.close();
[ERROR]   ^
[ERROR] -> [Help 1]
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
goal org.apache.maven.plugins:maven-compiler-plugin:2.0.2:compile
(default-compile) on project servicebased.host: Compilation failure
 at org.apache.maven.lifecycle.internal.MojoExecutor.execute
(MojoExecutor.java:215)
 at org.apache.maven.lifecycle.internal.MojoExecutor.execute
(MojoExecutor.java:156)
 at org.apache.maven.lifecycle.internal.MojoExecutor.execute

Re: Felix OBR releases.xml referencing http://repo1.maven.org

2020-04-12 Thread Carsten Ziegeler
Thanks Wayne for reporting...as you note we didnt update that OBR 
repository for quiet a while...which is a little bit embarrassing...
I've updated releases.xml by replacing http: with https: for most of the 
links, so you should be able to use this as-is from now on.


If there is anything else, don't hesitate to send another mail or 
directly create a Jira issue ticket for it.


Thanks
Carsten

On 10.04.2020 23:26, Wayne Tackabury wrote:

Hi all….first time post, so be kind… :)

I have to believe this has been asked enough to be a FAQ, but couldn’t
find the reference in the users, dev list that I could see nor the
Felix Jira list, StackOverflow, etc.

Using Felix 6.0.3, the default configuration seems to reference
felix.apache.org/obr/releases.xml which, well, hasn’t been updated
since 2017.  The only problem with that is there are a lot of
references to http://repo1.maven.org... which get picked up.  And the
only problem with that is maven.org went https-only since start of
this year; references to the non-secure HTTP link return 501 errors at
deploy/start time.

If this was a code problem in the Felix bundlerepository, or even the
distro config.properties, I’d create an issue in Jira and try to fix
it in code or conf, but that’s not the problem as  this is an online
resource at felix.apache.org.  I’ve worked around by pulling the .xml,
changing the repo1 refs, and changing my obr.repository .url entry in
config.properties to reference that as a file:// URL, but that seems
like a hack.

Is there an alternate releases.xml resource?  Or did I totally miss
the memo (as I expect :)

Thanks!
Wayne

-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org



--
--
Carsten Ziegeler
Adobe Research Switzerland
cziege...@apache.org

-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org



Re: Felix

2019-07-22 Thread Carsten Ziegeler

Hi Chris,


thanks for reporting, I think I fixed this now (together with some other 
links).



Regards

Carsten


Chris Pilsworth wrote

Hi all,

I've noticed recently that some of the felix website content is not being
loaded properly as it's trying to load content over HTTP into a HTTPS
page.  The problematic content is an ad for ApacheCon that is included on
all pages - with the mixed mode problem, the content isn't shown.

The error in the browser console is as follows:
Mixed Content: The page at 'https://felix.apache.org/' was loaded over
HTTPS, but requested an insecure resource '
http://www.apache.org/ads/button.html'. This request has been blocked; the
content must be served over HTTPS.

I had a quick look around to see if this was something that could be easily
fixed in a felix website repo, but couldn't find the original source.

Regards,

Chris Pilsworth


--
Carsten Ziegeler
Adobe Research Switzerland
cziege...@apache.org

-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org



Re: Felix on jdk11

2019-02-18 Thread Neil Bartlett
No. The felix framework is only a single jar. Any other jars that happen to
have felix in their name are just bundles.

I’ll have to let Karl or another felix insider comment on your second
question. It would need to be clarified though since “conform to” could
mean any number of things.

Neil.

On Mon, 18 Feb 2019 at 18:39, Chuck Davis  wrote:

> So ALL the Felix jars go on the classpath not just felix.jar?  I'll
> experiment with that.  Thanks much for the assist.
>
> That begs the question then, when will Felix conform to jdk9+ modules?  I
> have an OpenJDK11/OpenJFX11 application I want to distribute as a
> self-updating application to the end-users.
>
> On Mon, Feb 18, 2019 at 10:31 AM Neil Bartlett 
> wrote:
>
> > It looks like you are still running with Felix on the modulepath rather
> > than the classpath. This is the giveaway from the output you showed:
> >
> > 'module java.base does not "opens java.net" to module
> > org.apache.felix.framework
> > at org.apache.felix.framework@6.0.2'
> >
> > In other words, Java thinks that Felix is a module.
> >
> > Put Felix on the classpath and it should work.
> >
> > Regards,
> > Neil
> >
> >
> > On Mon, Feb 18, 2019 at 6:23 PM Chuck Davis  wrote:
> >
> > > Didn't make any difference.  Still getting the following exception with
> > > felix.jar on the classpath:
> > >
> > > chuck@linux-hk84:~> ./startJFXFelix
> > > The framework class is: org.apache.felix.framework.Felix
> > ><-- my class output
> > > loaded bundle: org.apache.felix.framework which is bundle number: 0
> > ><-- my class output
> > > Exception in thread "main" java.lang.ExceptionInInitializerError
> > > at org.apache.felix.framework@6.0.2
> > >
> > >
> >
> /org.apache.felix.framework.URLHandlers.createURLStreamHandler(URLHandlers.java:513)
> > > at java.base/java.net.URL.getURLStreamHandler(URL.java:1415)
> > > at java.base/java.net.URL.(URL.java:633)
> > > at org.apache.felix.framework@6.0.2
> > >
> > >
> >
> /org.apache.felix.framework.util.SecureAction.createURL(SecureAction.java:256)
> > > at org.apache.felix.framework@6.0.2
> > >
> > >
> >
> /org.apache.felix.framework.cache.JarRevision.initialize(JarRevision.java:148)
> > > at org.apache.felix.framework@6.0.2
> > >
> /org.apache.felix.framework.cache.JarRevision.(JarRevision.java:76)
> > > at org.apache.felix.framework@6.0.2
> > >
> > >
> >
> /org.apache.felix.framework.cache.BundleArchive.createRevisionFromLocation(BundleArchive.java:799)
> > > at org.apache.felix.framework@6.0.2
> > >
> > >
> >
> /org.apache.felix.framework.cache.BundleArchive.reviseInternal(BundleArchive.java:480)
> > > at org.apache.felix.framework@6.0.2
> > >
> > >
> >
> /org.apache.felix.framework.cache.BundleArchive.(BundleArchive.java:148)
> > > at org.apache.felix.framework@6.0.2
> > >
> >
> /org.apache.felix.framework.cache.BundleCache.create(BundleCache.java:462)
> > > at org.apache.felix.framework@6.0.2
> > > /org.apache.felix.framework.Felix.installBundle(Felix.java:3227)
> > > at org.apache.felix.framework@6.0.2
> > >
> > >
> >
> /org.apache.felix.framework.BundleContextImpl.installBundle(BundleContextImpl.java:147)
> > > at org.apache.felix.framework@6.0.2
> > >
> > >
> >
> /org.apache.felix.framework.BundleContextImpl.installBundle(BundleContextImpl.java:120)
> > > at
> > > JFXFelix/com.yakridge.jfxfelix.JFXMain.someNewMethod(JFXMain.java:65)
> > > at JFXFelix/com.yakridge.jfxfelix.JFXMain.main(JFXMain.java:30)
> > > Caused by: java.lang.RuntimeException: Unable to make protected boolean
> > > java.net.URLStreamHandler.equals(java.net.URL,java.net.URL)
> accessible:
> > > module java.base does not "opens java.net" to module
> > > org.apache.felix.framework
> > > at org.apache.felix.framework@6.0.2
> > >
> > >
> >
> /org.apache.felix.framework.URLHandlersStreamHandlerProxy.(URLHandlersStreamHandlerProxy.java:104)
> > > ... 15 more
> > > Caused by: java.lang.reflect.InaccessibleObjectException: Unable to
> make
> > > protected boolean
> > > java.net.URLStreamHandler.equals(java.net.URL,java.net.URL)
> accessible:
> > > module java.base does not "opens java.net" to module
> > > org.apache.felix.framework
> > > at
> > >
> > >
> >
> java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:340)
> > > at
> > >
> > >
> >
> java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:280)
> > > at
> > >
> java.base/java.lang.reflect.Method.checkCanSetAccessible(Method.java:198)
> > > at
> > > java.base/java.lang.reflect.Method.setAccessible(Method.java:192)
> > > at org.apache.felix.framework@6.0.2
> > >
> > >
> >
> /org.apache.felix.framework.util.SecureAction.setAccesssible(SecureAction.java:871)
> > > at org.apache.felix.framework@6.0.2
> > >
> > >
> >
> 

Re: Felix on jdk11

2019-02-18 Thread Chuck Davis
So ALL the Felix jars go on the classpath not just felix.jar?  I'll
experiment with that.  Thanks much for the assist.

That begs the question then, when will Felix conform to jdk9+ modules?  I
have an OpenJDK11/OpenJFX11 application I want to distribute as a
self-updating application to the end-users.

On Mon, Feb 18, 2019 at 10:31 AM Neil Bartlett  wrote:

> It looks like you are still running with Felix on the modulepath rather
> than the classpath. This is the giveaway from the output you showed:
>
> 'module java.base does not "opens java.net" to module
> org.apache.felix.framework
> at org.apache.felix.framework@6.0.2'
>
> In other words, Java thinks that Felix is a module.
>
> Put Felix on the classpath and it should work.
>
> Regards,
> Neil
>
>
> On Mon, Feb 18, 2019 at 6:23 PM Chuck Davis  wrote:
>
> > Didn't make any difference.  Still getting the following exception with
> > felix.jar on the classpath:
> >
> > chuck@linux-hk84:~> ./startJFXFelix
> > The framework class is: org.apache.felix.framework.Felix
> ><-- my class output
> > loaded bundle: org.apache.felix.framework which is bundle number: 0
> ><-- my class output
> > Exception in thread "main" java.lang.ExceptionInInitializerError
> > at org.apache.felix.framework@6.0.2
> >
> >
> /org.apache.felix.framework.URLHandlers.createURLStreamHandler(URLHandlers.java:513)
> > at java.base/java.net.URL.getURLStreamHandler(URL.java:1415)
> > at java.base/java.net.URL.(URL.java:633)
> > at org.apache.felix.framework@6.0.2
> >
> >
> /org.apache.felix.framework.util.SecureAction.createURL(SecureAction.java:256)
> > at org.apache.felix.framework@6.0.2
> >
> >
> /org.apache.felix.framework.cache.JarRevision.initialize(JarRevision.java:148)
> > at org.apache.felix.framework@6.0.2
> > /org.apache.felix.framework.cache.JarRevision.(JarRevision.java:76)
> > at org.apache.felix.framework@6.0.2
> >
> >
> /org.apache.felix.framework.cache.BundleArchive.createRevisionFromLocation(BundleArchive.java:799)
> > at org.apache.felix.framework@6.0.2
> >
> >
> /org.apache.felix.framework.cache.BundleArchive.reviseInternal(BundleArchive.java:480)
> > at org.apache.felix.framework@6.0.2
> >
> >
> /org.apache.felix.framework.cache.BundleArchive.(BundleArchive.java:148)
> > at org.apache.felix.framework@6.0.2
> >
> /org.apache.felix.framework.cache.BundleCache.create(BundleCache.java:462)
> > at org.apache.felix.framework@6.0.2
> > /org.apache.felix.framework.Felix.installBundle(Felix.java:3227)
> > at org.apache.felix.framework@6.0.2
> >
> >
> /org.apache.felix.framework.BundleContextImpl.installBundle(BundleContextImpl.java:147)
> > at org.apache.felix.framework@6.0.2
> >
> >
> /org.apache.felix.framework.BundleContextImpl.installBundle(BundleContextImpl.java:120)
> > at
> > JFXFelix/com.yakridge.jfxfelix.JFXMain.someNewMethod(JFXMain.java:65)
> > at JFXFelix/com.yakridge.jfxfelix.JFXMain.main(JFXMain.java:30)
> > Caused by: java.lang.RuntimeException: Unable to make protected boolean
> > java.net.URLStreamHandler.equals(java.net.URL,java.net.URL) accessible:
> > module java.base does not "opens java.net" to module
> > org.apache.felix.framework
> > at org.apache.felix.framework@6.0.2
> >
> >
> /org.apache.felix.framework.URLHandlersStreamHandlerProxy.(URLHandlersStreamHandlerProxy.java:104)
> > ... 15 more
> > Caused by: java.lang.reflect.InaccessibleObjectException: Unable to make
> > protected boolean
> > java.net.URLStreamHandler.equals(java.net.URL,java.net.URL) accessible:
> > module java.base does not "opens java.net" to module
> > org.apache.felix.framework
> > at
> >
> >
> java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:340)
> > at
> >
> >
> java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:280)
> > at
> > java.base/java.lang.reflect.Method.checkCanSetAccessible(Method.java:198)
> > at
> > java.base/java.lang.reflect.Method.setAccessible(Method.java:192)
> > at org.apache.felix.framework@6.0.2
> >
> >
> /org.apache.felix.framework.util.SecureAction.setAccesssible(SecureAction.java:871)
> > at org.apache.felix.framework@6.0.2
> >
> >
> /org.apache.felix.framework.URLHandlersStreamHandlerProxy.(URLHandlersStreamHandlerProxy.java:79)
> > ... 15 more
> >
> >
> > On Mon, Feb 18, 2019 at 9:39 AM Karl Pauls  wrote:
> >
> > > right, as I said, you need to put the felix jar on the classpath - then
> > it
> > > should work.
> > >
> > > regards,
> > >
> > > Karl
> > >
> > > On Monday, February 18, 2019, Chuck Davis  wrote:
> > >
> > > > I start my main class with the following bash script:
> > > >
> > > > java --module-path
> > > > /sata2/modules:/sata2/modules/felix:/sata2/Downloads/javafx/
> > > > javafx-sdk-11.0.1/lib
> > > > --add-modules=ALL-MODULE-PATH 

Re: Felix on jdk11

2019-02-18 Thread Neil Bartlett
It looks like you are still running with Felix on the modulepath rather
than the classpath. This is the giveaway from the output you showed:

'module java.base does not "opens java.net" to module
org.apache.felix.framework
at org.apache.felix.framework@6.0.2'

In other words, Java thinks that Felix is a module.

Put Felix on the classpath and it should work.

Regards,
Neil


On Mon, Feb 18, 2019 at 6:23 PM Chuck Davis  wrote:

> Didn't make any difference.  Still getting the following exception with
> felix.jar on the classpath:
>
> chuck@linux-hk84:~> ./startJFXFelix
> The framework class is: org.apache.felix.framework.Felix
><-- my class output
> loaded bundle: org.apache.felix.framework which is bundle number: 0
><-- my class output
> Exception in thread "main" java.lang.ExceptionInInitializerError
> at org.apache.felix.framework@6.0.2
>
> /org.apache.felix.framework.URLHandlers.createURLStreamHandler(URLHandlers.java:513)
> at java.base/java.net.URL.getURLStreamHandler(URL.java:1415)
> at java.base/java.net.URL.(URL.java:633)
> at org.apache.felix.framework@6.0.2
>
> /org.apache.felix.framework.util.SecureAction.createURL(SecureAction.java:256)
> at org.apache.felix.framework@6.0.2
>
> /org.apache.felix.framework.cache.JarRevision.initialize(JarRevision.java:148)
> at org.apache.felix.framework@6.0.2
> /org.apache.felix.framework.cache.JarRevision.(JarRevision.java:76)
> at org.apache.felix.framework@6.0.2
>
> /org.apache.felix.framework.cache.BundleArchive.createRevisionFromLocation(BundleArchive.java:799)
> at org.apache.felix.framework@6.0.2
>
> /org.apache.felix.framework.cache.BundleArchive.reviseInternal(BundleArchive.java:480)
> at org.apache.felix.framework@6.0.2
>
> /org.apache.felix.framework.cache.BundleArchive.(BundleArchive.java:148)
> at org.apache.felix.framework@6.0.2
> /org.apache.felix.framework.cache.BundleCache.create(BundleCache.java:462)
> at org.apache.felix.framework@6.0.2
> /org.apache.felix.framework.Felix.installBundle(Felix.java:3227)
> at org.apache.felix.framework@6.0.2
>
> /org.apache.felix.framework.BundleContextImpl.installBundle(BundleContextImpl.java:147)
> at org.apache.felix.framework@6.0.2
>
> /org.apache.felix.framework.BundleContextImpl.installBundle(BundleContextImpl.java:120)
> at
> JFXFelix/com.yakridge.jfxfelix.JFXMain.someNewMethod(JFXMain.java:65)
> at JFXFelix/com.yakridge.jfxfelix.JFXMain.main(JFXMain.java:30)
> Caused by: java.lang.RuntimeException: Unable to make protected boolean
> java.net.URLStreamHandler.equals(java.net.URL,java.net.URL) accessible:
> module java.base does not "opens java.net" to module
> org.apache.felix.framework
> at org.apache.felix.framework@6.0.2
>
> /org.apache.felix.framework.URLHandlersStreamHandlerProxy.(URLHandlersStreamHandlerProxy.java:104)
> ... 15 more
> Caused by: java.lang.reflect.InaccessibleObjectException: Unable to make
> protected boolean
> java.net.URLStreamHandler.equals(java.net.URL,java.net.URL) accessible:
> module java.base does not "opens java.net" to module
> org.apache.felix.framework
> at
>
> java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:340)
> at
>
> java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:280)
> at
> java.base/java.lang.reflect.Method.checkCanSetAccessible(Method.java:198)
> at
> java.base/java.lang.reflect.Method.setAccessible(Method.java:192)
> at org.apache.felix.framework@6.0.2
>
> /org.apache.felix.framework.util.SecureAction.setAccesssible(SecureAction.java:871)
> at org.apache.felix.framework@6.0.2
>
> /org.apache.felix.framework.URLHandlersStreamHandlerProxy.(URLHandlersStreamHandlerProxy.java:79)
> ... 15 more
>
>
> On Mon, Feb 18, 2019 at 9:39 AM Karl Pauls  wrote:
>
> > right, as I said, you need to put the felix jar on the classpath - then
> it
> > should work.
> >
> > regards,
> >
> > Karl
> >
> > On Monday, February 18, 2019, Chuck Davis  wrote:
> >
> > > I start my main class with the following bash script:
> > >
> > > java --module-path
> > > /sata2/modules:/sata2/modules/felix:/sata2/Downloads/javafx/
> > > javafx-sdk-11.0.1/lib
> > > --add-modules=ALL-MODULE-PATH com.yakridge.jfxfelix.JFXMain
> > > If I comment out all the Felix stuff the program runs fine.  My main
> > class
> > > is on the classpath.  The felix bundles are in /sata2/modules
> directory.
> > >
> > >
> > > On Mon, Feb 18, 2019 at 8:00 AM Karl Pauls 
> wrote:
> > >
> > > > How do you start this main class (and/or, are you embedding felix in
> a
> > > > module)?
> > > >
> > > > You need to be on the classpath and not on the module path to work.
> > > >
> > > > regards,
> > > >
> > > > Karl
> > > >
> > > >
> > >
> >
> >
> > --
> > Karl Pauls
> > karlpa...@gmail.com
> >
>


Re: Felix on jdk11

2019-02-18 Thread Chuck Davis
Didn't make any difference.  Still getting the following exception with
felix.jar on the classpath:

chuck@linux-hk84:~> ./startJFXFelix
The framework class is: org.apache.felix.framework.Felix
   <-- my class output
loaded bundle: org.apache.felix.framework which is bundle number: 0
   <-- my class output
Exception in thread "main" java.lang.ExceptionInInitializerError
at org.apache.felix.framework@6.0.2
/org.apache.felix.framework.URLHandlers.createURLStreamHandler(URLHandlers.java:513)
at java.base/java.net.URL.getURLStreamHandler(URL.java:1415)
at java.base/java.net.URL.(URL.java:633)
at org.apache.felix.framework@6.0.2
/org.apache.felix.framework.util.SecureAction.createURL(SecureAction.java:256)
at org.apache.felix.framework@6.0.2
/org.apache.felix.framework.cache.JarRevision.initialize(JarRevision.java:148)
at org.apache.felix.framework@6.0.2
/org.apache.felix.framework.cache.JarRevision.(JarRevision.java:76)
at org.apache.felix.framework@6.0.2
/org.apache.felix.framework.cache.BundleArchive.createRevisionFromLocation(BundleArchive.java:799)
at org.apache.felix.framework@6.0.2
/org.apache.felix.framework.cache.BundleArchive.reviseInternal(BundleArchive.java:480)
at org.apache.felix.framework@6.0.2
/org.apache.felix.framework.cache.BundleArchive.(BundleArchive.java:148)
at org.apache.felix.framework@6.0.2
/org.apache.felix.framework.cache.BundleCache.create(BundleCache.java:462)
at org.apache.felix.framework@6.0.2
/org.apache.felix.framework.Felix.installBundle(Felix.java:3227)
at org.apache.felix.framework@6.0.2
/org.apache.felix.framework.BundleContextImpl.installBundle(BundleContextImpl.java:147)
at org.apache.felix.framework@6.0.2
/org.apache.felix.framework.BundleContextImpl.installBundle(BundleContextImpl.java:120)
at
JFXFelix/com.yakridge.jfxfelix.JFXMain.someNewMethod(JFXMain.java:65)
at JFXFelix/com.yakridge.jfxfelix.JFXMain.main(JFXMain.java:30)
Caused by: java.lang.RuntimeException: Unable to make protected boolean
java.net.URLStreamHandler.equals(java.net.URL,java.net.URL) accessible:
module java.base does not "opens java.net" to module
org.apache.felix.framework
at org.apache.felix.framework@6.0.2
/org.apache.felix.framework.URLHandlersStreamHandlerProxy.(URLHandlersStreamHandlerProxy.java:104)
... 15 more
Caused by: java.lang.reflect.InaccessibleObjectException: Unable to make
protected boolean
java.net.URLStreamHandler.equals(java.net.URL,java.net.URL) accessible:
module java.base does not "opens java.net" to module
org.apache.felix.framework
at
java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:340)
at
java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:280)
at
java.base/java.lang.reflect.Method.checkCanSetAccessible(Method.java:198)
at java.base/java.lang.reflect.Method.setAccessible(Method.java:192)
at org.apache.felix.framework@6.0.2
/org.apache.felix.framework.util.SecureAction.setAccesssible(SecureAction.java:871)
at org.apache.felix.framework@6.0.2
/org.apache.felix.framework.URLHandlersStreamHandlerProxy.(URLHandlersStreamHandlerProxy.java:79)
... 15 more


On Mon, Feb 18, 2019 at 9:39 AM Karl Pauls  wrote:

> right, as I said, you need to put the felix jar on the classpath - then it
> should work.
>
> regards,
>
> Karl
>
> On Monday, February 18, 2019, Chuck Davis  wrote:
>
> > I start my main class with the following bash script:
> >
> > java --module-path
> > /sata2/modules:/sata2/modules/felix:/sata2/Downloads/javafx/
> > javafx-sdk-11.0.1/lib
> > --add-modules=ALL-MODULE-PATH com.yakridge.jfxfelix.JFXMain
> > If I comment out all the Felix stuff the program runs fine.  My main
> class
> > is on the classpath.  The felix bundles are in /sata2/modules directory.
> >
> >
> > On Mon, Feb 18, 2019 at 8:00 AM Karl Pauls  wrote:
> >
> > > How do you start this main class (and/or, are you embedding felix in a
> > > module)?
> > >
> > > You need to be on the classpath and not on the module path to work.
> > >
> > > regards,
> > >
> > > Karl
> > >
> > >
> >
>
>
> --
> Karl Pauls
> karlpa...@gmail.com
>


Re: Felix on jdk11

2019-02-18 Thread Karl Pauls
right, as I said, you need to put the felix jar on the classpath - then it
should work.

regards,

Karl

On Monday, February 18, 2019, Chuck Davis  wrote:

> I start my main class with the following bash script:
>
> java --module-path
> /sata2/modules:/sata2/modules/felix:/sata2/Downloads/javafx/
> javafx-sdk-11.0.1/lib
> --add-modules=ALL-MODULE-PATH com.yakridge.jfxfelix.JFXMain
> If I comment out all the Felix stuff the program runs fine.  My main class
> is on the classpath.  The felix bundles are in /sata2/modules directory.
>
>
> On Mon, Feb 18, 2019 at 8:00 AM Karl Pauls  wrote:
>
> > How do you start this main class (and/or, are you embedding felix in a
> > module)?
> >
> > You need to be on the classpath and not on the module path to work.
> >
> > regards,
> >
> > Karl
> >
> >
>


-- 
Karl Pauls
karlpa...@gmail.com


Re: Felix on jdk11

2019-02-18 Thread Chuck Davis
I start my main class with the following bash script:

java --module-path
/sata2/modules:/sata2/modules/felix:/sata2/Downloads/javafx/javafx-sdk-11.0.1/lib
--add-modules=ALL-MODULE-PATH com.yakridge.jfxfelix.JFXMain
If I comment out all the Felix stuff the program runs fine.  My main class
is on the classpath.  The felix bundles are in /sata2/modules directory.


On Mon, Feb 18, 2019 at 8:00 AM Karl Pauls  wrote:

> How do you start this main class (and/or, are you embedding felix in a
> module)?
>
> You need to be on the classpath and not on the module path to work.
>
> regards,
>
> Karl
>
>


Re: Felix on jdk11

2019-02-18 Thread James Carman
What particular APIs are you trying to use that we’re removed?  The JAX-B,
JAF, and JAX-WS stuff are the big ones we have had to manually include
after upgrading to java 11.

On Mon, Feb 18, 2019 at 10:49 AM Rob Walker  wrote:

> The issue we found was not so much Felix - that does indeed run fine on
> Java 11.
>
> But depending on what packages you really on, some of those that were
> system packages in Java 8 but have since move either to separate J9+
> modules, or in some cases dropped completely from J9+ and now need
> additional bundles. You can't rely on the system classloader wiring for
> those in Felix, you have to make sure the requisite bundles and modules are
> present.
>
> -Rob
>
> -Original Message-
> From: Neil Bartlett 
> Sent: 18 February 2019 17:25
> To: users 
> Subject: Re: Felix on jdk11
>
> Wait a minute... if Chuck is having problems running Felix on Java 11
> because of dependencies on the platform, then how is adding MORE bundles by
> using Karaf going to help?
>
> Since Felix has been tested on Java 11 and is expected to work, it would
> be really good to try to help out with the original problem, as Karl is
> trying to do.
>
> Neil
>
> On Mon, Feb 18, 2019 at 3:16 PM James Carman 
> wrote:
>
> > People run karaf on Raspberry Pi devices.  It can be quite small.
> > What are your requirements on resources?
> >
> > On Mon, Feb 18, 2019 at 10:10 AM Chuck Davis  wrote:
> >
> > > Hi James:
> > >
> > > My understanding is that Karaf is quite heavy.  I want to keep my
> > > client
> > as
> > > light as possible.  This is for a Java client application that I
> > > want to update automatically on a periodic basis.
> > >
> > > On Mon, Feb 18, 2019 at 5:41 AM James Carman
> > >  > >
> > > wrote:
> > >
> > > > Unless you really need to be “down and dirty” with OSGi, lots of
> > > > folks
> > > opt
> > > > for using Apache Karaf, which is based on Felix (by default).  It
> > > > takes care of a lot of the heavy lifting for you automatically.
> > > > If you
> > really
> > > > want to learn the insides and outs, though, stick with Felix, but
> > you’ll
> > > > want something like karaf when you deploy for real, most likely.
> > > >
> > > > On Mon, Feb 18, 2019 at 7:43 AM Chuck Davis 
> > wrote:
> > > >
> > > > > Thanks for responding, Rob.  I'm very new to OSGi and that
> > > > > sounds
> > like
> > > a
> > > > > LOT of tinkering to me (overwhelming in fact at this point !!).
> > > > >
> > > > > But the more I study it the more it makes sense to me and the
> > > exceptions
> > > > > I'm seeing.
> > > > >
> > > > > Thanks for your response.
> > > > >
> > > > > On Sun, Feb 17, 2019 at 8:44 PM Rob Walker 
> wrote:
> > > > >
> > > > > > We have worked our Felix based app so that it runs on JDK11 -
> > > > > > took
> > a
> > > > bit
> > > > > > of tinkering, but there wasn't anything in core code we had to
> > > change.
> > > > > >
> > > > > >
> > > > > >
> > > > > > We did need to load the following bundles separately to
> > > > > > replace
> > > missing
> > > > > > classes:
> > > > > >
> > > > > >
> > > > > >
> > > > > > jre-1.8_extra_bundles=
> > > > > >
> > > > > > jre-9_extra_bundles=${j9_replacement_packages}
> > > > > >
> > > > > > jre-10_extra_bundles=${j9_replacement_packages}
> > > > > >
> > > > > > jre-11_extra_bundles=${j9_replacement_packages}
> > > > > >
> > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>


Re: Felix on jdk11

2019-02-18 Thread Karl Pauls
How do you start this main class (and/or, are you embedding felix in a module)?

You need to be on the classpath and not on the module path to work.

regards,

Karl

On Mon, Feb 18, 2019 at 4:58 PM Chuck Davis  wrote:
>
> I'm running openSUSE tumbleweed with OpenJDK11.0.2.
>
> My main class loads the framework with this code: (which worked on jdk8)
>
> ServiceLoader factoryLoader =
> ServiceLoader.load(FrameworkFactory.class);
> Iterator it = factoryLoader.iterator();
> frameworkFactory = it.next();
> framework = frameworkFactory.newFramework(null);
>
>
> if (framework == null) {
> System.out.println("The framework is null");
> } else {
> System.out.println("The framework class is: " +
> framework.getClass().getName());
> }
>
>
>
> try {
> framework.start();
> context = framework.getBundleContext();
> } catch (BundleException ex) {
> //Logger.getLogger(JFXMain.class.getName()).log(Level.SEVERE,
> null, ex);
> }
>
> On Mon, Feb 18, 2019 at 7:12 AM Karl Pauls  wrote:
>
> > Hm, that would be new - are you sure that happens on java11 and how
> > did you start-up the framework?
> >
> > regards,
> >
> > Karl
> >
> > On Mon, Feb 18, 2019 at 4:08 PM Chuck Davis  wrote:
> > >
> > > Hi Karl:
> > >
> > > This seems to be the root cause of the other exceptions I'm dealing with.
> > > Obviously, there is no longer a java.net to open.  I don't know if the
> > > highlighting will transmit but the problems is: "Caused by:..
> > >
> > > Caused by: java.lang.RuntimeException: Unable to make protected boolean
> > > java.net.URLStreamHandler.equals(java.net.URL,java.net.URL) accessible:
> > > module java.base does not "opens java.net" to module
> > > org.apache.felix.framework
> > > at org.apache.felix.framework@6.0.2
> > >
> > /org.apache.felix.framework.URLHandlersStreamHandlerProxy.(URLHandlersStreamHandlerProxy.java:104)
> > > ... 15 more
> > > Caused by: java.lang.reflect.InaccessibleObjectException: Unable to make
> > > protected boolean
> > > java.net.URLStreamHandler.equals(java.net.URL,java.net.URL) accessible:
> > > module java.base does not "opens java.net" to module
> > > org.apache.felix.framework
> > > at
> > >
> > java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:340)
> > > at
> > >
> > java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:280)
> > > at
> > > java.base/java.lang.reflect.Method.checkCanSetAccessible(Method.java:198)
> > > at
> > java.base/java.lang.reflect.Method.setAccessible(Method.java:192)
> > > at org.apache.felix.framework@6.0.2
> > >
> > /org.apache.felix.framework.util.SecureAction.setAccesssible(SecureAction.java:871)
> > > at org.apache.felix.framework@6.0.2
> > >
> > /org.apache.felix.framework.URLHandlersStreamHandlerProxy.(URLHandlersStreamHandlerProxy.java:79)
> > > ... 15 more
> > >
> > >
> > > On Mon, Feb 18, 2019 at 4:53 AM Karl Pauls  wrote:
> > >
> > > > The framework itself should work ootb on java11 just fine. Likewise, I
> > > > think the default distribution should work on java11 too (i.e., the
> > > > shell).
> > > >
> > > > Not sure about other bundles - feel free to follow-up with your set-up
> > > > and the exceptions you see.
> > > >
> > > > regards,
> > > >
> > > > Karl
> > > >
> > > > On Mon, Feb 18, 2019 at 1:43 PM Chuck Davis 
> > wrote:
> > > > >
> > > > > Thanks for responding, Rob.  I'm very new to OSGi and that sounds
> > like a
> > > > > LOT of tinkering to me (overwhelming in fact at this point !!).
> > > > >
> > > > > But the more I study it the more it makes sense to me and the
> > exceptions
> > > > > I'm seeing.
> > > > >
> > > > > Thanks for your response.
> > > > >
> > > > > On Sun, Feb 17, 2019 at 8:44 PM Rob Walker  wrote:
> > > > >
> > > > > > We have worked our Felix based app so that it runs on JDK11 - took
> > a
> > > > bit
> > > > > > of tinkering, but there wasn't anything in core code we had to
> > change.
> > > > > >
> > > > > >
> > > > > >
> > > > > > We did need to load the following bundles separately to replace
> > missing
> > > > > > classes:
> > > > > >
> > > > > >
> > > > > >
> > > > > > jre-1.8_extra_bundles=
> > > > > >
> > > > > > jre-9_extra_bundles=${j9_replacement_packages}
> > > > > >
> > > > > > jre-10_extra_bundles=${j9_replacement_packages}
> > > > > >
> > > > > > jre-11_extra_bundles=${j9_replacement_packages}
> > > > > >
> > > > > >
> > > > > >
> > > >
> > > >
> > > >
> > > > --
> > > > Karl Pauls
> > > > karlpa...@gmail.com
> > > >
> > > > -
> > > > To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
> > > > For additional commands, e-mail: users-h...@felix.apache.org
> > > >
> > > >
> >
> >
> >
> > --
> > Karl Pauls
> > karlpa...@gmail.com
> >
> > 

Re: Felix on jdk11

2019-02-18 Thread Chuck Davis
I'm running openSUSE tumbleweed with OpenJDK11.0.2.

My main class loads the framework with this code: (which worked on jdk8)

ServiceLoader factoryLoader =
ServiceLoader.load(FrameworkFactory.class);
Iterator it = factoryLoader.iterator();
frameworkFactory = it.next();
framework = frameworkFactory.newFramework(null);


if (framework == null) {
System.out.println("The framework is null");
} else {
System.out.println("The framework class is: " +
framework.getClass().getName());
}



try {
framework.start();
context = framework.getBundleContext();
} catch (BundleException ex) {
//Logger.getLogger(JFXMain.class.getName()).log(Level.SEVERE,
null, ex);
}

On Mon, Feb 18, 2019 at 7:12 AM Karl Pauls  wrote:

> Hm, that would be new - are you sure that happens on java11 and how
> did you start-up the framework?
>
> regards,
>
> Karl
>
> On Mon, Feb 18, 2019 at 4:08 PM Chuck Davis  wrote:
> >
> > Hi Karl:
> >
> > This seems to be the root cause of the other exceptions I'm dealing with.
> > Obviously, there is no longer a java.net to open.  I don't know if the
> > highlighting will transmit but the problems is: "Caused by:..
> >
> > Caused by: java.lang.RuntimeException: Unable to make protected boolean
> > java.net.URLStreamHandler.equals(java.net.URL,java.net.URL) accessible:
> > module java.base does not "opens java.net" to module
> > org.apache.felix.framework
> > at org.apache.felix.framework@6.0.2
> >
> /org.apache.felix.framework.URLHandlersStreamHandlerProxy.(URLHandlersStreamHandlerProxy.java:104)
> > ... 15 more
> > Caused by: java.lang.reflect.InaccessibleObjectException: Unable to make
> > protected boolean
> > java.net.URLStreamHandler.equals(java.net.URL,java.net.URL) accessible:
> > module java.base does not "opens java.net" to module
> > org.apache.felix.framework
> > at
> >
> java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:340)
> > at
> >
> java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:280)
> > at
> > java.base/java.lang.reflect.Method.checkCanSetAccessible(Method.java:198)
> > at
> java.base/java.lang.reflect.Method.setAccessible(Method.java:192)
> > at org.apache.felix.framework@6.0.2
> >
> /org.apache.felix.framework.util.SecureAction.setAccesssible(SecureAction.java:871)
> > at org.apache.felix.framework@6.0.2
> >
> /org.apache.felix.framework.URLHandlersStreamHandlerProxy.(URLHandlersStreamHandlerProxy.java:79)
> > ... 15 more
> >
> >
> > On Mon, Feb 18, 2019 at 4:53 AM Karl Pauls  wrote:
> >
> > > The framework itself should work ootb on java11 just fine. Likewise, I
> > > think the default distribution should work on java11 too (i.e., the
> > > shell).
> > >
> > > Not sure about other bundles - feel free to follow-up with your set-up
> > > and the exceptions you see.
> > >
> > > regards,
> > >
> > > Karl
> > >
> > > On Mon, Feb 18, 2019 at 1:43 PM Chuck Davis 
> wrote:
> > > >
> > > > Thanks for responding, Rob.  I'm very new to OSGi and that sounds
> like a
> > > > LOT of tinkering to me (overwhelming in fact at this point !!).
> > > >
> > > > But the more I study it the more it makes sense to me and the
> exceptions
> > > > I'm seeing.
> > > >
> > > > Thanks for your response.
> > > >
> > > > On Sun, Feb 17, 2019 at 8:44 PM Rob Walker  wrote:
> > > >
> > > > > We have worked our Felix based app so that it runs on JDK11 - took
> a
> > > bit
> > > > > of tinkering, but there wasn't anything in core code we had to
> change.
> > > > >
> > > > >
> > > > >
> > > > > We did need to load the following bundles separately to replace
> missing
> > > > > classes:
> > > > >
> > > > >
> > > > >
> > > > > jre-1.8_extra_bundles=
> > > > >
> > > > > jre-9_extra_bundles=${j9_replacement_packages}
> > > > >
> > > > > jre-10_extra_bundles=${j9_replacement_packages}
> > > > >
> > > > > jre-11_extra_bundles=${j9_replacement_packages}
> > > > >
> > > > >
> > > > >
> > >
> > >
> > >
> > > --
> > > Karl Pauls
> > > karlpa...@gmail.com
> > >
> > > -
> > > To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
> > > For additional commands, e-mail: users-h...@felix.apache.org
> > >
> > >
>
>
>
> --
> Karl Pauls
> karlpa...@gmail.com
>
> -
> To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
> For additional commands, e-mail: users-h...@felix.apache.org
>
>


RE: Felix on jdk11

2019-02-18 Thread Rob Walker
The issue we found was not so much Felix - that does indeed run fine on Java 11.

But depending on what packages you really on, some of those that were system 
packages in Java 8 but have since move either to separate J9+ modules, or in 
some cases dropped completely from J9+ and now need additional bundles. You 
can't rely on the system classloader wiring for those in Felix, you have to 
make sure the requisite bundles and modules are present.

-Rob
 
-Original Message-
From: Neil Bartlett  
Sent: 18 February 2019 17:25
To: users 
Subject: Re: Felix on jdk11

Wait a minute... if Chuck is having problems running Felix on Java 11 because 
of dependencies on the platform, then how is adding MORE bundles by using Karaf 
going to help?

Since Felix has been tested on Java 11 and is expected to work, it would be 
really good to try to help out with the original problem, as Karl is trying to 
do.

Neil

On Mon, Feb 18, 2019 at 3:16 PM James Carman 
wrote:

> People run karaf on Raspberry Pi devices.  It can be quite small.  
> What are your requirements on resources?
>
> On Mon, Feb 18, 2019 at 10:10 AM Chuck Davis  wrote:
>
> > Hi James:
> >
> > My understanding is that Karaf is quite heavy.  I want to keep my 
> > client
> as
> > light as possible.  This is for a Java client application that I 
> > want to update automatically on a periodic basis.
> >
> > On Mon, Feb 18, 2019 at 5:41 AM James Carman 
> >  >
> > wrote:
> >
> > > Unless you really need to be “down and dirty” with OSGi, lots of 
> > > folks
> > opt
> > > for using Apache Karaf, which is based on Felix (by default).  It 
> > > takes care of a lot of the heavy lifting for you automatically.  
> > > If you
> really
> > > want to learn the insides and outs, though, stick with Felix, but
> you’ll
> > > want something like karaf when you deploy for real, most likely.
> > >
> > > On Mon, Feb 18, 2019 at 7:43 AM Chuck Davis 
> wrote:
> > >
> > > > Thanks for responding, Rob.  I'm very new to OSGi and that 
> > > > sounds
> like
> > a
> > > > LOT of tinkering to me (overwhelming in fact at this point !!).
> > > >
> > > > But the more I study it the more it makes sense to me and the
> > exceptions
> > > > I'm seeing.
> > > >
> > > > Thanks for your response.
> > > >
> > > > On Sun, Feb 17, 2019 at 8:44 PM Rob Walker  wrote:
> > > >
> > > > > We have worked our Felix based app so that it runs on JDK11 - 
> > > > > took
> a
> > > bit
> > > > > of tinkering, but there wasn't anything in core code we had to
> > change.
> > > > >
> > > > >
> > > > >
> > > > > We did need to load the following bundles separately to 
> > > > > replace
> > missing
> > > > > classes:
> > > > >
> > > > >
> > > > >
> > > > > jre-1.8_extra_bundles=
> > > > >
> > > > > jre-9_extra_bundles=${j9_replacement_packages}
> > > > >
> > > > > jre-10_extra_bundles=${j9_replacement_packages}
> > > > >
> > > > > jre-11_extra_bundles=${j9_replacement_packages}
> > > > >
> > > > >
> > > > >
> > > >
> > >
> >
>


Re: Felix on jdk11

2019-02-18 Thread Neil Bartlett
Wait a minute... if Chuck is having problems running Felix on Java 11
because of dependencies on the platform, then how is adding MORE bundles by
using Karaf going to help?

Since Felix has been tested on Java 11 and is expected to work, it would be
really good to try to help out with the original problem, as Karl is trying
to do.

Neil

On Mon, Feb 18, 2019 at 3:16 PM James Carman 
wrote:

> People run karaf on Raspberry Pi devices.  It can be quite small.  What are
> your requirements on resources?
>
> On Mon, Feb 18, 2019 at 10:10 AM Chuck Davis  wrote:
>
> > Hi James:
> >
> > My understanding is that Karaf is quite heavy.  I want to keep my client
> as
> > light as possible.  This is for a Java client application that I want to
> > update automatically on a periodic basis.
> >
> > On Mon, Feb 18, 2019 at 5:41 AM James Carman  >
> > wrote:
> >
> > > Unless you really need to be “down and dirty” with OSGi, lots of folks
> > opt
> > > for using Apache Karaf, which is based on Felix (by default).  It takes
> > > care of a lot of the heavy lifting for you automatically.  If you
> really
> > > want to learn the insides and outs, though, stick with Felix, but
> you’ll
> > > want something like karaf when you deploy for real, most likely.
> > >
> > > On Mon, Feb 18, 2019 at 7:43 AM Chuck Davis 
> wrote:
> > >
> > > > Thanks for responding, Rob.  I'm very new to OSGi and that sounds
> like
> > a
> > > > LOT of tinkering to me (overwhelming in fact at this point !!).
> > > >
> > > > But the more I study it the more it makes sense to me and the
> > exceptions
> > > > I'm seeing.
> > > >
> > > > Thanks for your response.
> > > >
> > > > On Sun, Feb 17, 2019 at 8:44 PM Rob Walker  wrote:
> > > >
> > > > > We have worked our Felix based app so that it runs on JDK11 - took
> a
> > > bit
> > > > > of tinkering, but there wasn't anything in core code we had to
> > change.
> > > > >
> > > > >
> > > > >
> > > > > We did need to load the following bundles separately to replace
> > missing
> > > > > classes:
> > > > >
> > > > >
> > > > >
> > > > > jre-1.8_extra_bundles=
> > > > >
> > > > > jre-9_extra_bundles=${j9_replacement_packages}
> > > > >
> > > > > jre-10_extra_bundles=${j9_replacement_packages}
> > > > >
> > > > > jre-11_extra_bundles=${j9_replacement_packages}
> > > > >
> > > > >
> > > > >
> > > >
> > >
> >
>


Re: Felix on jdk11

2019-02-18 Thread Karl Pauls
Are you maybe trying to add the framework as an automatic module? That
wouldn't work, it needs to be on the classpath (i.e., in the unnamed
module)...

regards,

Karl

On Mon, Feb 18, 2019 at 4:11 PM Karl Pauls  wrote:
>
> Hm, that would be new - are you sure that happens on java11 and how
> did you start-up the framework?
>
> regards,
>
> Karl
>
> On Mon, Feb 18, 2019 at 4:08 PM Chuck Davis  wrote:
> >
> > Hi Karl:
> >
> > This seems to be the root cause of the other exceptions I'm dealing with.
> > Obviously, there is no longer a java.net to open.  I don't know if the
> > highlighting will transmit but the problems is: "Caused by:..
> >
> > Caused by: java.lang.RuntimeException: Unable to make protected boolean
> > java.net.URLStreamHandler.equals(java.net.URL,java.net.URL) accessible:
> > module java.base does not "opens java.net" to module
> > org.apache.felix.framework
> > at org.apache.felix.framework@6.0.2
> > /org.apache.felix.framework.URLHandlersStreamHandlerProxy.(URLHandlersStreamHandlerProxy.java:104)
> > ... 15 more
> > Caused by: java.lang.reflect.InaccessibleObjectException: Unable to make
> > protected boolean
> > java.net.URLStreamHandler.equals(java.net.URL,java.net.URL) accessible:
> > module java.base does not "opens java.net" to module
> > org.apache.felix.framework
> > at
> > java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:340)
> > at
> > java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:280)
> > at
> > java.base/java.lang.reflect.Method.checkCanSetAccessible(Method.java:198)
> > at java.base/java.lang.reflect.Method.setAccessible(Method.java:192)
> > at org.apache.felix.framework@6.0.2
> > /org.apache.felix.framework.util.SecureAction.setAccesssible(SecureAction.java:871)
> > at org.apache.felix.framework@6.0.2
> > /org.apache.felix.framework.URLHandlersStreamHandlerProxy.(URLHandlersStreamHandlerProxy.java:79)
> > ... 15 more
> >
> >
> > On Mon, Feb 18, 2019 at 4:53 AM Karl Pauls  wrote:
> >
> > > The framework itself should work ootb on java11 just fine. Likewise, I
> > > think the default distribution should work on java11 too (i.e., the
> > > shell).
> > >
> > > Not sure about other bundles - feel free to follow-up with your set-up
> > > and the exceptions you see.
> > >
> > > regards,
> > >
> > > Karl
> > >
> > > On Mon, Feb 18, 2019 at 1:43 PM Chuck Davis  wrote:
> > > >
> > > > Thanks for responding, Rob.  I'm very new to OSGi and that sounds like a
> > > > LOT of tinkering to me (overwhelming in fact at this point !!).
> > > >
> > > > But the more I study it the more it makes sense to me and the exceptions
> > > > I'm seeing.
> > > >
> > > > Thanks for your response.
> > > >
> > > > On Sun, Feb 17, 2019 at 8:44 PM Rob Walker  wrote:
> > > >
> > > > > We have worked our Felix based app so that it runs on JDK11 - took a
> > > bit
> > > > > of tinkering, but there wasn't anything in core code we had to change.
> > > > >
> > > > >
> > > > >
> > > > > We did need to load the following bundles separately to replace 
> > > > > missing
> > > > > classes:
> > > > >
> > > > >
> > > > >
> > > > > jre-1.8_extra_bundles=
> > > > >
> > > > > jre-9_extra_bundles=${j9_replacement_packages}
> > > > >
> > > > > jre-10_extra_bundles=${j9_replacement_packages}
> > > > >
> > > > > jre-11_extra_bundles=${j9_replacement_packages}
> > > > >
> > > > >
> > > > >
> > >
> > >
> > >
> > > --
> > > Karl Pauls
> > > karlpa...@gmail.com
> > >
> > > -
> > > To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
> > > For additional commands, e-mail: users-h...@felix.apache.org
> > >
> > >
>
>
>
> --
> Karl Pauls
> karlpa...@gmail.com



-- 
Karl Pauls
karlpa...@gmail.com

-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org



Re: Felix on jdk11

2019-02-18 Thread James Carman
People run karaf on Raspberry Pi devices.  It can be quite small.  What are
your requirements on resources?

On Mon, Feb 18, 2019 at 10:10 AM Chuck Davis  wrote:

> Hi James:
>
> My understanding is that Karaf is quite heavy.  I want to keep my client as
> light as possible.  This is for a Java client application that I want to
> update automatically on a periodic basis.
>
> On Mon, Feb 18, 2019 at 5:41 AM James Carman 
> wrote:
>
> > Unless you really need to be “down and dirty” with OSGi, lots of folks
> opt
> > for using Apache Karaf, which is based on Felix (by default).  It takes
> > care of a lot of the heavy lifting for you automatically.  If you really
> > want to learn the insides and outs, though, stick with Felix, but you’ll
> > want something like karaf when you deploy for real, most likely.
> >
> > On Mon, Feb 18, 2019 at 7:43 AM Chuck Davis  wrote:
> >
> > > Thanks for responding, Rob.  I'm very new to OSGi and that sounds like
> a
> > > LOT of tinkering to me (overwhelming in fact at this point !!).
> > >
> > > But the more I study it the more it makes sense to me and the
> exceptions
> > > I'm seeing.
> > >
> > > Thanks for your response.
> > >
> > > On Sun, Feb 17, 2019 at 8:44 PM Rob Walker  wrote:
> > >
> > > > We have worked our Felix based app so that it runs on JDK11 - took a
> > bit
> > > > of tinkering, but there wasn't anything in core code we had to
> change.
> > > >
> > > >
> > > >
> > > > We did need to load the following bundles separately to replace
> missing
> > > > classes:
> > > >
> > > >
> > > >
> > > > jre-1.8_extra_bundles=
> > > >
> > > > jre-9_extra_bundles=${j9_replacement_packages}
> > > >
> > > > jre-10_extra_bundles=${j9_replacement_packages}
> > > >
> > > > jre-11_extra_bundles=${j9_replacement_packages}
> > > >
> > > >
> > > >
> > >
> >
>


Re: Felix on jdk11

2019-02-18 Thread Chuck Davis
Hi James:

My understanding is that Karaf is quite heavy.  I want to keep my client as
light as possible.  This is for a Java client application that I want to
update automatically on a periodic basis.

On Mon, Feb 18, 2019 at 5:41 AM James Carman 
wrote:

> Unless you really need to be “down and dirty” with OSGi, lots of folks opt
> for using Apache Karaf, which is based on Felix (by default).  It takes
> care of a lot of the heavy lifting for you automatically.  If you really
> want to learn the insides and outs, though, stick with Felix, but you’ll
> want something like karaf when you deploy for real, most likely.
>
> On Mon, Feb 18, 2019 at 7:43 AM Chuck Davis  wrote:
>
> > Thanks for responding, Rob.  I'm very new to OSGi and that sounds like a
> > LOT of tinkering to me (overwhelming in fact at this point !!).
> >
> > But the more I study it the more it makes sense to me and the exceptions
> > I'm seeing.
> >
> > Thanks for your response.
> >
> > On Sun, Feb 17, 2019 at 8:44 PM Rob Walker  wrote:
> >
> > > We have worked our Felix based app so that it runs on JDK11 - took a
> bit
> > > of tinkering, but there wasn't anything in core code we had to change.
> > >
> > >
> > >
> > > We did need to load the following bundles separately to replace missing
> > > classes:
> > >
> > >
> > >
> > > jre-1.8_extra_bundles=
> > >
> > > jre-9_extra_bundles=${j9_replacement_packages}
> > >
> > > jre-10_extra_bundles=${j9_replacement_packages}
> > >
> > > jre-11_extra_bundles=${j9_replacement_packages}
> > >
> > >
> > >
> >
>


Re: Felix on jdk11

2019-02-18 Thread Chuck Davis
Hi Karl:

This seems to be the root cause of the other exceptions I'm dealing with.
Obviously, there is no longer a java.net to open.  I don't know if the
highlighting will transmit but the problems is: "Caused by:..

Caused by: java.lang.RuntimeException: Unable to make protected boolean
java.net.URLStreamHandler.equals(java.net.URL,java.net.URL) accessible:
module java.base does not "opens java.net" to module
org.apache.felix.framework
at org.apache.felix.framework@6.0.2
/org.apache.felix.framework.URLHandlersStreamHandlerProxy.(URLHandlersStreamHandlerProxy.java:104)
... 15 more
Caused by: java.lang.reflect.InaccessibleObjectException: Unable to make
protected boolean
java.net.URLStreamHandler.equals(java.net.URL,java.net.URL) accessible:
module java.base does not "opens java.net" to module
org.apache.felix.framework
at
java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:340)
at
java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:280)
at
java.base/java.lang.reflect.Method.checkCanSetAccessible(Method.java:198)
at java.base/java.lang.reflect.Method.setAccessible(Method.java:192)
at org.apache.felix.framework@6.0.2
/org.apache.felix.framework.util.SecureAction.setAccesssible(SecureAction.java:871)
at org.apache.felix.framework@6.0.2
/org.apache.felix.framework.URLHandlersStreamHandlerProxy.(URLHandlersStreamHandlerProxy.java:79)
... 15 more


On Mon, Feb 18, 2019 at 4:53 AM Karl Pauls  wrote:

> The framework itself should work ootb on java11 just fine. Likewise, I
> think the default distribution should work on java11 too (i.e., the
> shell).
>
> Not sure about other bundles - feel free to follow-up with your set-up
> and the exceptions you see.
>
> regards,
>
> Karl
>
> On Mon, Feb 18, 2019 at 1:43 PM Chuck Davis  wrote:
> >
> > Thanks for responding, Rob.  I'm very new to OSGi and that sounds like a
> > LOT of tinkering to me (overwhelming in fact at this point !!).
> >
> > But the more I study it the more it makes sense to me and the exceptions
> > I'm seeing.
> >
> > Thanks for your response.
> >
> > On Sun, Feb 17, 2019 at 8:44 PM Rob Walker  wrote:
> >
> > > We have worked our Felix based app so that it runs on JDK11 - took a
> bit
> > > of tinkering, but there wasn't anything in core code we had to change.
> > >
> > >
> > >
> > > We did need to load the following bundles separately to replace missing
> > > classes:
> > >
> > >
> > >
> > > jre-1.8_extra_bundles=
> > >
> > > jre-9_extra_bundles=${j9_replacement_packages}
> > >
> > > jre-10_extra_bundles=${j9_replacement_packages}
> > >
> > > jre-11_extra_bundles=${j9_replacement_packages}
> > >
> > >
> > >
>
>
>
> --
> Karl Pauls
> karlpa...@gmail.com
>
> -
> To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
> For additional commands, e-mail: users-h...@felix.apache.org
>
>


Re: Felix on jdk11

2019-02-18 Thread James Carman
Unless you really need to be “down and dirty” with OSGi, lots of folks opt
for using Apache Karaf, which is based on Felix (by default).  It takes
care of a lot of the heavy lifting for you automatically.  If you really
want to learn the insides and outs, though, stick with Felix, but you’ll
want something like karaf when you deploy for real, most likely.

On Mon, Feb 18, 2019 at 7:43 AM Chuck Davis  wrote:

> Thanks for responding, Rob.  I'm very new to OSGi and that sounds like a
> LOT of tinkering to me (overwhelming in fact at this point !!).
>
> But the more I study it the more it makes sense to me and the exceptions
> I'm seeing.
>
> Thanks for your response.
>
> On Sun, Feb 17, 2019 at 8:44 PM Rob Walker  wrote:
>
> > We have worked our Felix based app so that it runs on JDK11 - took a bit
> > of tinkering, but there wasn't anything in core code we had to change.
> >
> >
> >
> > We did need to load the following bundles separately to replace missing
> > classes:
> >
> >
> >
> > jre-1.8_extra_bundles=
> >
> > jre-9_extra_bundles=${j9_replacement_packages}
> >
> > jre-10_extra_bundles=${j9_replacement_packages}
> >
> > jre-11_extra_bundles=${j9_replacement_packages}
> >
> >
> >
>


Re: Felix on jdk11

2019-02-18 Thread Karl Pauls
The framework itself should work ootb on java11 just fine. Likewise, I
think the default distribution should work on java11 too (i.e., the
shell).

Not sure about other bundles - feel free to follow-up with your set-up
and the exceptions you see.

regards,

Karl

On Mon, Feb 18, 2019 at 1:43 PM Chuck Davis  wrote:
>
> Thanks for responding, Rob.  I'm very new to OSGi and that sounds like a
> LOT of tinkering to me (overwhelming in fact at this point !!).
>
> But the more I study it the more it makes sense to me and the exceptions
> I'm seeing.
>
> Thanks for your response.
>
> On Sun, Feb 17, 2019 at 8:44 PM Rob Walker  wrote:
>
> > We have worked our Felix based app so that it runs on JDK11 - took a bit
> > of tinkering, but there wasn't anything in core code we had to change.
> >
> >
> >
> > We did need to load the following bundles separately to replace missing
> > classes:
> >
> >
> >
> > jre-1.8_extra_bundles=
> >
> > jre-9_extra_bundles=${j9_replacement_packages}
> >
> > jre-10_extra_bundles=${j9_replacement_packages}
> >
> > jre-11_extra_bundles=${j9_replacement_packages}
> >
> >
> >



-- 
Karl Pauls
karlpa...@gmail.com

-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org



Re: Felix on jdk11

2019-02-18 Thread Chuck Davis
Thanks for responding, Rob.  I'm very new to OSGi and that sounds like a
LOT of tinkering to me (overwhelming in fact at this point !!).

But the more I study it the more it makes sense to me and the exceptions
I'm seeing.

Thanks for your response.

On Sun, Feb 17, 2019 at 8:44 PM Rob Walker  wrote:

> We have worked our Felix based app so that it runs on JDK11 - took a bit
> of tinkering, but there wasn't anything in core code we had to change.
>
>
>
> We did need to load the following bundles separately to replace missing
> classes:
>
>
>
> jre-1.8_extra_bundles=
>
> jre-9_extra_bundles=${j9_replacement_packages}
>
> jre-10_extra_bundles=${j9_replacement_packages}
>
> jre-11_extra_bundles=${j9_replacement_packages}
>
>
>


RE: Felix on jdk11

2019-02-17 Thread Rob Walker
We have worked our Felix based app so that it runs on JDK11 - took a bit of 
tinkering, but there wasn't anything in core code we had to change.



We did need to load the following bundles separately to replace missing classes:



jre-1.8_extra_bundles=

jre-9_extra_bundles=${j9_replacement_packages}

jre-10_extra_bundles=${j9_replacement_packages}

jre-11_extra_bundles=${j9_replacement_packages}



j9_replacement_packages =  \

"${vtmp.bundle.root}/lib/ext/javax.activation.jar" \

"${vtmp.bundle.root}/lib/ext/jaxb-api.jar" \

"${vtmp.bundle.root}/lib/ext/javax.annotation-api.jar"



You also need to remove the relevant references from the JRE classpath 
(javax.activation etc) for J9+ since these will now be resolved by the extra 
bundles. As can be seen, on jre1.8 there are no extra bundles needed.



You also then need to be sure to load these bundles as part of your 
initialisation



felix.auto.install.1=\

  ...

${jre_extra_bundles}

  ...



And finally, you need to make sure you have you java modules set right for 
program launch e.g.



set J9_OPTIONS=--add-opens java.base/java.lang=ALL-UNNAMED --add-opens 
java.base/java.net=ALL-UNNAMED --add-opens java.base/java.security=ALL-UNNAMED 
--add-opens java.base/java.util=ALL-UNNAMED



"%JAVA_HOME%\bin\java" % JVM_OPTS% %J9_OPTIONS% -D



(we have conditional code which only sets J9_OPTIONS for J9+)





-Rob





-Original Message-
From: Chuck Davis 
Sent: 17 February 2019 23:39
To: users@felix.apache.org
Subject: Re: Felix on jdk11



Has there been any discussion among developers regarding referenced subject?  
I'm only subscribed to the users list.



I tried to run 6.0.2 on Linux (which has only jdk11 installed) and it's asking 
for classes no longer existing in jdk11.



Thanks if anybody knows the time-frame for when Felix is targeted to run on 
jdk11.


Re: Felix on jdk11

2019-02-17 Thread Chuck Davis
Has there been any discussion among developers regarding referenced
subject?  I'm only subscribed to the users list.

I tried to run 6.0.2 on Linux (which has only jdk11 installed) and it's
asking for classes no longer existing in jdk11.

Thanks if anybody knows the time-frame for when Felix is targeted to run on
jdk11.


Re: Felix-Resolver: Fragment was not selected for attachment

2018-08-07 Thread Richard S. Hall




On 7/24/18 07:35 , patrick.pus...@telekom.de wrote:

Hi all,

during resolving of several bundles with the felixResolver I get a 
ResolutionException: org.apache.felix.resolver.reason.ReasonException: Fragment 
was not selected for attachment: com.xx.yy version=1.7.0.201806111251

But the unresolvedRequirments are 0 in the exception. This confuses me, why an 
exception is thrown but no unresolved Req. are there?

I found the origin of the error in that class: 
https://github.com/eclipse/rt.equinox.framework/blob/eb0f2a037d2e03d66f0eca857b16838745bbb2a2/bundles/org.eclipse.osgi/felix/src/org/apache/felix/resolver/Candidates.java
but it's hard for me to understand the comment:
  // For any fragment that wasn't selected, remove the
  // current host as a potential host for it and remove it
  // as a dependent on the host. If there are no more
// potential hosts for the fragment, then mark it as
// unselected for later removal.

Could someone explain me what happens during resolving here or even explain the 
code comment to me?


I'm not sure what's going on, but the only time the "else" should get 
triggered is if you are installing multiple versions of a given 
fragment. In that case, only the highest version of that fragment is 
"selected" and every other lower version hits the "else" and is removed 
as the comment above describes. So, first of all, are you installing 
multiple versions of the same fragment (i.e., same symbolic name)?


What it sounds like is happening, is that some module you are trying to 
resolve has a dependency (directly or indirectly) on something provided 
by an older version of the fragment, but that fragment isn't selected 
for merging into a host because there is a newer version of the fragment.


Whether or not that makes sense with respect to your use case, I have no 
idea, but that appears to be the only plausible explanation with the 
info provided.


-> richard



I tested with bndtools 3.5.0, 4.0.0 and 4.1.0-SNAPSHOT. All are producing the 
same ResolutionException.

Thanks and best regards,
Patrick





-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org



Re: Felix Log Service version 1.2.0 cannot be referenced

2018-08-02 Thread Carsten Ziegeler
I just started the release process for SCR 2.1.2 which contains the fix.

If everything goes well, it will be available on Monday

Regards

Carsten


Philipp Höfler wrote
> Hallo Ray,
> 
> thanks for pointing this out. 
> 
> Best,
> Philipp
> 
> -Ursprüngliche Nachricht-
> Von: Raymond Auge  
> Gesendet: Mittwoch, 1. August 2018 22:51
> An: felix users 
> Betreff: Re: Felix Log Service version 1.2.0 cannot be referenced
> 
> There's a bug in Felix SCR which solves this but it is not yet released.
> 
> I won't be able to do it at least 'till next week.
> 
> Sincerely,
> - Ray
> 
> On Wed, Aug 1, 2018, 04:59 Philipp Höfler, 
> wrote:
> 
>> Hi,
>>
>> I am trying to utilize the new Felix Log Service (1.2.0) with DS.
>> But no matter what I am trying, the reference is always null.
>>
>> I added a field with the annotation in my class.
>>
>> @Reference(service = org.osgi.service.log.LoggerFactory.class)
>> private org.osgi.service.log.Logger _logger;
>>
>> In addition, I've added the following two bundles to the -runbundles 
>> property of my bndrun file:
>>
>> org.apache.felix.log;version='[1.2.0,1.2.1)',\
>> org.apache.felix.log.extension;version='[1.0.0,1.0.1)',\
>>
>> I am not sure, if this is really necessary.
>> Even if no logger implementation (logback, log4j) is available, I 
>> would have expected that the reference could be resolved?
>>
>> But also, when I add logback to the -runbundles, the logger cannot be 
>> resolved and is always null
>>
>> ch.qos.logback.classic;version='[1.2.3,1.2.4)',\
>> ch.qos.logback.core;version='[1.2.3,1.2.4)',\
>>
>> You can inspect the whole project on GitHub:
>>
>> https://github.com/phhoef/osgi-test/blob/master/rest-service/src/main/
>> java/com/my/app/rest/rest/ServerInfoControllerImpl.java
>>
>> Thanks
>>
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
> For additional commands, e-mail: users-h...@felix.apache.org
> 
-- 
Carsten Ziegeler
Adobe Research Switzerland
cziege...@apache.org

-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org



Re: Felix Log Service version 1.2.0 cannot be referenced

2018-08-01 Thread Raymond Auge
There's a bug in Felix SCR which solves this but it is not yet released.

I won't be able to do it at least 'till next week.

Sincerely,
- Ray

On Wed, Aug 1, 2018, 04:59 Philipp Höfler, 
wrote:

> Hi,
>
> I am trying to utilize the new Felix Log Service (1.2.0) with DS.
> But no matter what I am trying, the reference is always null.
>
> I added a field with the annotation in my class.
>
> @Reference(service = org.osgi.service.log.LoggerFactory.class)
> private org.osgi.service.log.Logger _logger;
>
> In addition, I've added the following two bundles to the -runbundles
> property of my bndrun file:
>
> org.apache.felix.log;version='[1.2.0,1.2.1)',\
> org.apache.felix.log.extension;version='[1.0.0,1.0.1)',\
>
> I am not sure, if this is really necessary.
> Even if no logger implementation (logback, log4j) is available, I would
> have expected that the reference could be resolved?
>
> But also, when I add logback to the -runbundles, the logger cannot be
> resolved and is always null
>
> ch.qos.logback.classic;version='[1.2.3,1.2.4)',\
> ch.qos.logback.core;version='[1.2.3,1.2.4)',\
>
> You can inspect the whole project on GitHub:
>
> https://github.com/phhoef/osgi-test/blob/master/rest-service/src/main/java/com/my/app/rest/rest/ServerInfoControllerImpl.java
>
> Thanks
>


Re: Felix Http Jetty packaging as uber bundle?

2018-07-16 Thread Eric Norman
Hi Karl,

I understand how ServiceLoader works.  But in OSGi the proper way to do
ServiceLoader is what is described in the Service Loader Mediator
specification (see [1]).  Playing with the TCCL is just a workaround and
error prone.   Also, it seems to me that setting the TCCL to a specific
bundle makes the assumption that all the ServiceLoader providers are within
that same bundle which isn't always (or typically) the case.

RE: the alpn-impl bundles

Only the JDK8 impl requires adding the alpn-boot-*.jar to the
bootclasspath.  In java 9 or later the ALPN support is baked into the JRE
so doing the same is not needed or appropriate anymore.

So my point was basically that there is a choice to be made about which
jetty ALPN bundles to include.  There is one set of bundles if you are
running with java 8, another set of bundles if you are running java 9 or
later, and yet another set of bundles if you wish to use the conscript impl
of the same for better performance as described at [2].

If we don't use an uber bundle for felix.http.jetty then that choice is
easy as you can just provision whichever set of bundles is appropriate for
your environment and just ignore the others.  However if we continue to use
an uber bundle, then we would likely need a new unique
felix.http.jetty artifact for
each combination of bundles?

So I guess my point remains that the uber felix.http.jetty bundle is not
really a good idea, but perhaps I haven't convinced everyone yet.

   1. https://osgi.org/specification/osgi.cmpn/7.0.0/service.loader.html
   2. https://webtide.com/conscrypting-native-ssl-for-jetty/


I hope that makes sense.

Regards,
-Eric


On Mon, Jul 16, 2018 at 12:58 AM, Karl Pauls  wrote:

> Hi Eric,
>
> sorry, I was a bit brief in my last mail (was on my phone). The point is:
>
> the TCCL is the mechanism intended for configuring a ServiceLoader.
> That is how this is supposed to work. The problem typically is that in
> OSGi it is either not set or its set to the wrong classloader.
> However, it sounds like in case of our jetty bundle we know what
> classloader we want namely, the classloader of the bundle.
>
> Granted, I might be missing something but it sounds like if set the
> TCCL to the the bundle classloader we don't need the ServiceLoader
> mediator involved in our jetty bundle at all (which would be nice as
> it should be as self-contained a possible). Am I missing some other
> service case that would require it?
>
> Furthermore, I'm not sure I understand you comment about the need to
> "provide the appropriate alpn-impl bundles that corresponds to your
> JRE". Don't these jars have to be added to the bootclasspath (in which
> case, they can't be provided as bundles, no)?
>
> regards,
>
> Karl
>
>
> On Sun, Jul 15, 2018 at 11:59 PM Eric Norman 
> wrote:
> >
> > Hi Karl,
> >
> > Perhaps juggling the TCCL around the jetty startup code would workaround
> > the specific startup error from PreEncodedHttpField, but I don't really
> > like doing that around such a broad block of someone else's code.   It
> > wouldn't be clear to me that it doesn't have any unintended side effects
> > now or in the future.
> >
> > I guess I can take a closer look at patching the jetty code.  A solution
> > that replaces their usages of ServiceLoader with a ServiceTracker when
> > running inside of an osgi container would be better in the long run.
> Plus
> > that would remove the need for the additional ServiceLoader mediator
> > bundles which would make the distribution a bit smaller.
> >
> > Regards,
> > Eric
> >
> > On Sun, Jul 15, 2018 at 10:28 AM, Karl Pauls 
> wrote:
> >
> > > I think you can just set the thread context classloader to the
> classloader
> > > of the bundle in the activator and then you don’t need the spifly
> thingy at
> > > all anymore...
> > >
> > >
> > > regards,
> > >
> > > Karl
> > >
> > > On Sunday, July 15, 2018, Eric Norman  wrote:
> > >
> > > > Hi Carsten,
> > > >
> > > > I tried to make it work with an uber bundle by merging in the
> important
> > > > stuff.  In this case the o.a.felix.http.jetty is both a consumer and
> a
> > > > producer of a few ServiceLoader services.
> > > >
> > > > Unfortunately, it looks like there is a problem with using the
> service
> > > > loader mediator stuff in the uber bundle.  The problem is that the
> spifly
> > > > osgi.extender listens for new bundles being installed (when the
> bundle
> > > > reaches the ACTIVE state) and registers the service providers it
> > > discovers
> > > > at that point.
> > > >
> > > > However, one of the ServiceLoader.load consumer calls is invoked in
> the
> > > > JettyActivator before the o.a.felix.http.jetty has reached the ACTIVE
> > > > state (see
> > > > the stack trace below).  So in this use case, the producer hasn't
> > > declared
> > > > the services yet when the consumer tries to use them.
> > > >
> > > > PreEncodedHttpField.() line: 49
> > > > MimeTypes$Type.(String) line: 103
> > > > MimeTypes$Type.() line: 58
> > > > 

Re: Felix Http Jetty packaging as uber bundle?

2018-07-16 Thread Karl Pauls
Hi Eric,

sorry, I was a bit brief in my last mail (was on my phone). The point is:

the TCCL is the mechanism intended for configuring a ServiceLoader.
That is how this is supposed to work. The problem typically is that in
OSGi it is either not set or its set to the wrong classloader.
However, it sounds like in case of our jetty bundle we know what
classloader we want namely, the classloader of the bundle.

Granted, I might be missing something but it sounds like if set the
TCCL to the the bundle classloader we don't need the ServiceLoader
mediator involved in our jetty bundle at all (which would be nice as
it should be as self-contained a possible). Am I missing some other
service case that would require it?

Furthermore, I'm not sure I understand you comment about the need to
"provide the appropriate alpn-impl bundles that corresponds to your
JRE". Don't these jars have to be added to the bootclasspath (in which
case, they can't be provided as bundles, no)?

regards,

Karl


On Sun, Jul 15, 2018 at 11:59 PM Eric Norman  wrote:
>
> Hi Karl,
>
> Perhaps juggling the TCCL around the jetty startup code would workaround
> the specific startup error from PreEncodedHttpField, but I don't really
> like doing that around such a broad block of someone else's code.   It
> wouldn't be clear to me that it doesn't have any unintended side effects
> now or in the future.
>
> I guess I can take a closer look at patching the jetty code.  A solution
> that replaces their usages of ServiceLoader with a ServiceTracker when
> running inside of an osgi container would be better in the long run.  Plus
> that would remove the need for the additional ServiceLoader mediator
> bundles which would make the distribution a bit smaller.
>
> Regards,
> Eric
>
> On Sun, Jul 15, 2018 at 10:28 AM, Karl Pauls  wrote:
>
> > I think you can just set the thread context classloader to the classloader
> > of the bundle in the activator and then you don’t need the spifly thingy at
> > all anymore...
> >
> >
> > regards,
> >
> > Karl
> >
> > On Sunday, July 15, 2018, Eric Norman  wrote:
> >
> > > Hi Carsten,
> > >
> > > I tried to make it work with an uber bundle by merging in the important
> > > stuff.  In this case the o.a.felix.http.jetty is both a consumer and a
> > > producer of a few ServiceLoader services.
> > >
> > > Unfortunately, it looks like there is a problem with using the service
> > > loader mediator stuff in the uber bundle.  The problem is that the spifly
> > > osgi.extender listens for new bundles being installed (when the bundle
> > > reaches the ACTIVE state) and registers the service providers it
> > discovers
> > > at that point.
> > >
> > > However, one of the ServiceLoader.load consumer calls is invoked in the
> > > JettyActivator before the o.a.felix.http.jetty has reached the ACTIVE
> > > state (see
> > > the stack trace below).  So in this use case, the producer hasn't
> > declared
> > > the services yet when the consumer tries to use them.
> > >
> > > PreEncodedHttpField.() line: 49
> > > MimeTypes$Type.(String) line: 103
> > > MimeTypes$Type.() line: 58
> > > MimeTypes.() line: 191
> > > ServletContextHandler(ContextHandler).doStart() line: 832
> > > ServletContextHandler.doStart() line: 287
> > > ServletContextHandler(AbstractLifeCycle).start() line: 68
> > > ContextHandlerCollection(ContainerLifeCycle).start(LifeCycle) line: 138
> > > ContextHandlerCollection(ContainerLifeCycle).doStart() line: 117
> > > ContextHandlerCollection(AbstractHandler).doStart() line: 113
> > > ContextHandlerCollection.doStart() line: 167
> > > ContextHandlerCollection(AbstractLifeCycle).start() line: 68
> > > Server(ContainerLifeCycle).start(LifeCycle) line: 138
> > > Server.start(LifeCycle) line: 419
> > > Server(ContainerLifeCycle).doStart() line: 108
> > > Server(AbstractHandler).doStart() line: 113
> > > Server.doStart() line: 386
> > > Server(AbstractLifeCycle).start() line: 68
> > > JettyService.initializeJetty() line: 426
> > > JettyService.startJetty() line: 306
> > > JettyService.start() line: 149
> > > JettyActivator.doStart() line: 63
> > > JettyActivator(AbstractActivator).start(BundleContext) line: 39
> > > SecureAction.startActivator(BundleActivator, BundleContext) line: 697
> > > SlingFelix(Felix).activateBundle(BundleImpl, boolean) line: 2240
> > > SlingFelix(Felix).startBundle(BundleImpl, int) line: 2146
> > > SlingFelix(Felix).setActiveStartLevel(int, FrameworkListener[]) line:
> > 1373
> > > FrameworkStartLevelImpl.run() line: 308
> > > Thread.run() line: 748
> > >
> > >
> > > It seems that some other changes would be required to get around that.
> > > Either changes to jetty code or changing the felix code to not start
> > > synchronously in the bundle activator.
> > >
> > > The uber bundle seems to complicate the scenario and additional bundles
> > are
> > > still required anyways to enable OSGi ServiceLoader mediator support and
> > > provide the appropriate alpn-impl bundles that corresponds to your JRE.
> > >
> 

Re: Felix Http Jetty packaging as uber bundle?

2018-07-15 Thread Eric Norman
Hi Karl,

Perhaps juggling the TCCL around the jetty startup code would workaround
the specific startup error from PreEncodedHttpField, but I don't really
like doing that around such a broad block of someone else's code.   It
wouldn't be clear to me that it doesn't have any unintended side effects
now or in the future.

I guess I can take a closer look at patching the jetty code.  A solution
that replaces their usages of ServiceLoader with a ServiceTracker when
running inside of an osgi container would be better in the long run.  Plus
that would remove the need for the additional ServiceLoader mediator
bundles which would make the distribution a bit smaller.

Regards,
Eric

On Sun, Jul 15, 2018 at 10:28 AM, Karl Pauls  wrote:

> I think you can just set the thread context classloader to the classloader
> of the bundle in the activator and then you don’t need the spifly thingy at
> all anymore...
>
>
> regards,
>
> Karl
>
> On Sunday, July 15, 2018, Eric Norman  wrote:
>
> > Hi Carsten,
> >
> > I tried to make it work with an uber bundle by merging in the important
> > stuff.  In this case the o.a.felix.http.jetty is both a consumer and a
> > producer of a few ServiceLoader services.
> >
> > Unfortunately, it looks like there is a problem with using the service
> > loader mediator stuff in the uber bundle.  The problem is that the spifly
> > osgi.extender listens for new bundles being installed (when the bundle
> > reaches the ACTIVE state) and registers the service providers it
> discovers
> > at that point.
> >
> > However, one of the ServiceLoader.load consumer calls is invoked in the
> > JettyActivator before the o.a.felix.http.jetty has reached the ACTIVE
> > state (see
> > the stack trace below).  So in this use case, the producer hasn't
> declared
> > the services yet when the consumer tries to use them.
> >
> > PreEncodedHttpField.() line: 49
> > MimeTypes$Type.(String) line: 103
> > MimeTypes$Type.() line: 58
> > MimeTypes.() line: 191
> > ServletContextHandler(ContextHandler).doStart() line: 832
> > ServletContextHandler.doStart() line: 287
> > ServletContextHandler(AbstractLifeCycle).start() line: 68
> > ContextHandlerCollection(ContainerLifeCycle).start(LifeCycle) line: 138
> > ContextHandlerCollection(ContainerLifeCycle).doStart() line: 117
> > ContextHandlerCollection(AbstractHandler).doStart() line: 113
> > ContextHandlerCollection.doStart() line: 167
> > ContextHandlerCollection(AbstractLifeCycle).start() line: 68
> > Server(ContainerLifeCycle).start(LifeCycle) line: 138
> > Server.start(LifeCycle) line: 419
> > Server(ContainerLifeCycle).doStart() line: 108
> > Server(AbstractHandler).doStart() line: 113
> > Server.doStart() line: 386
> > Server(AbstractLifeCycle).start() line: 68
> > JettyService.initializeJetty() line: 426
> > JettyService.startJetty() line: 306
> > JettyService.start() line: 149
> > JettyActivator.doStart() line: 63
> > JettyActivator(AbstractActivator).start(BundleContext) line: 39
> > SecureAction.startActivator(BundleActivator, BundleContext) line: 697
> > SlingFelix(Felix).activateBundle(BundleImpl, boolean) line: 2240
> > SlingFelix(Felix).startBundle(BundleImpl, int) line: 2146
> > SlingFelix(Felix).setActiveStartLevel(int, FrameworkListener[]) line:
> 1373
> > FrameworkStartLevelImpl.run() line: 308
> > Thread.run() line: 748
> >
> >
> > It seems that some other changes would be required to get around that.
> > Either changes to jetty code or changing the felix code to not start
> > synchronously in the bundle activator.
> >
> > The uber bundle seems to complicate the scenario and additional bundles
> are
> > still required anyways to enable OSGi ServiceLoader mediator support and
> > provide the appropriate alpn-impl bundles that corresponds to your JRE.
> >
> > Does that make sense?
> >
> > Regards,
> > Eric
> >
> > On Sat, Jul 14, 2018 at 1:04 AM, Carsten Ziegeler 
> > wrote:
> >
> > > Hi Eric,
> > >
> > > that sounds interesting. As far as I remember we started to embed Jetty
> > > as by that time Jetty was not available as OSGi bundles out of the box.
> > > The other reason is ease of use, you just need to install a single
> > > bundle - which is sufficient for most users - instead of a set of
> > bundles.
> > >
> > > Would it be possible to create the uber bundle with the correct set of
> > > files like the service loader stuff?
> > >
> > > How about we provide two artifacts, the uber and the thin one? I really
> > > would like to keep the uber one as this makes using it easier and is
> > > easier for upgrading existing systems.
> > >
> > > Regards
> > >
> > > Carsten
> > >
> > >
> > > Eric Norman wrote
> > > > I've been doing some work to enable the HTTP/2 support in jetty for
> > usage
> > > > within the Felix Http Jetty 4.x bundle for an apache sling based
> > project.
> > > >
> > > > I'm not sure about the history of the felix.http.jetty bundle, but
> can
> > I
> > > > ask why it was decided to make copies of the jetty classes inside the
> > > felix
> > 

Re: Felix Http Jetty packaging as uber bundle?

2018-07-15 Thread Karl Pauls
I think you can just set the thread context classloader to the classloader
of the bundle in the activator and then you don’t need the spifly thingy at
all anymore...


regards,

Karl

On Sunday, July 15, 2018, Eric Norman  wrote:

> Hi Carsten,
>
> I tried to make it work with an uber bundle by merging in the important
> stuff.  In this case the o.a.felix.http.jetty is both a consumer and a
> producer of a few ServiceLoader services.
>
> Unfortunately, it looks like there is a problem with using the service
> loader mediator stuff in the uber bundle.  The problem is that the spifly
> osgi.extender listens for new bundles being installed (when the bundle
> reaches the ACTIVE state) and registers the service providers it discovers
> at that point.
>
> However, one of the ServiceLoader.load consumer calls is invoked in the
> JettyActivator before the o.a.felix.http.jetty has reached the ACTIVE
> state (see
> the stack trace below).  So in this use case, the producer hasn't declared
> the services yet when the consumer tries to use them.
>
> PreEncodedHttpField.() line: 49
> MimeTypes$Type.(String) line: 103
> MimeTypes$Type.() line: 58
> MimeTypes.() line: 191
> ServletContextHandler(ContextHandler).doStart() line: 832
> ServletContextHandler.doStart() line: 287
> ServletContextHandler(AbstractLifeCycle).start() line: 68
> ContextHandlerCollection(ContainerLifeCycle).start(LifeCycle) line: 138
> ContextHandlerCollection(ContainerLifeCycle).doStart() line: 117
> ContextHandlerCollection(AbstractHandler).doStart() line: 113
> ContextHandlerCollection.doStart() line: 167
> ContextHandlerCollection(AbstractLifeCycle).start() line: 68
> Server(ContainerLifeCycle).start(LifeCycle) line: 138
> Server.start(LifeCycle) line: 419
> Server(ContainerLifeCycle).doStart() line: 108
> Server(AbstractHandler).doStart() line: 113
> Server.doStart() line: 386
> Server(AbstractLifeCycle).start() line: 68
> JettyService.initializeJetty() line: 426
> JettyService.startJetty() line: 306
> JettyService.start() line: 149
> JettyActivator.doStart() line: 63
> JettyActivator(AbstractActivator).start(BundleContext) line: 39
> SecureAction.startActivator(BundleActivator, BundleContext) line: 697
> SlingFelix(Felix).activateBundle(BundleImpl, boolean) line: 2240
> SlingFelix(Felix).startBundle(BundleImpl, int) line: 2146
> SlingFelix(Felix).setActiveStartLevel(int, FrameworkListener[]) line: 1373
> FrameworkStartLevelImpl.run() line: 308
> Thread.run() line: 748
>
>
> It seems that some other changes would be required to get around that.
> Either changes to jetty code or changing the felix code to not start
> synchronously in the bundle activator.
>
> The uber bundle seems to complicate the scenario and additional bundles are
> still required anyways to enable OSGi ServiceLoader mediator support and
> provide the appropriate alpn-impl bundles that corresponds to your JRE.
>
> Does that make sense?
>
> Regards,
> Eric
>
> On Sat, Jul 14, 2018 at 1:04 AM, Carsten Ziegeler 
> wrote:
>
> > Hi Eric,
> >
> > that sounds interesting. As far as I remember we started to embed Jetty
> > as by that time Jetty was not available as OSGi bundles out of the box.
> > The other reason is ease of use, you just need to install a single
> > bundle - which is sufficient for most users - instead of a set of
> bundles.
> >
> > Would it be possible to create the uber bundle with the correct set of
> > files like the service loader stuff?
> >
> > How about we provide two artifacts, the uber and the thin one? I really
> > would like to keep the uber one as this makes using it easier and is
> > easier for upgrading existing systems.
> >
> > Regards
> >
> > Carsten
> >
> >
> > Eric Norman wrote
> > > I've been doing some work to enable the HTTP/2 support in jetty for
> usage
> > > within the Felix Http Jetty 4.x bundle for an apache sling based
> project.
> > >
> > > I'm not sure about the history of the felix.http.jetty bundle, but can
> I
> > > ask why it was decided to make copies of the jetty classes inside the
> > felix
> > > bundle rather than just depending on the already existing jetty bundles
> > and
> > > then provisioning the jetty-* bundles to the OSGi profile to provide
> > those
> > > classes?
> > >
> > > The reason I ask is that the jetty implementation is still utilizing
> the
> > > java.util.ServiceLoader mechanism in a few places and the packaging of
> > the
> > > felix.http.jetty bundle is not copying the META-INF/services/* files or
> > > merging the related "osgi.serviceloader" Require-Capability and
> > > Provide-Capability attributes from the manifest of the embedded jetty-*
> > > bundles when it is repackaged.  This makes it so the ServiceLoader code
> > is
> > > unable to discover the services provided by the jetty-http and the
> > > jetty-alpn-* bundles and the jetty HTTP/2 related code fails.
> > >
> > > In other words, using the jetty-* bundles has everything packaged and
> > > declared correctly to utilize the OSGi ServiceLoader 

Re: Felix Http Jetty packaging as uber bundle?

2018-07-14 Thread Eric Norman
Hi Carsten,

I tried to make it work with an uber bundle by merging in the important
stuff.  In this case the o.a.felix.http.jetty is both a consumer and a
producer of a few ServiceLoader services.

Unfortunately, it looks like there is a problem with using the service
loader mediator stuff in the uber bundle.  The problem is that the spifly
osgi.extender listens for new bundles being installed (when the bundle
reaches the ACTIVE state) and registers the service providers it discovers
at that point.

However, one of the ServiceLoader.load consumer calls is invoked in the
JettyActivator before the o.a.felix.http.jetty has reached the ACTIVE
state (see
the stack trace below).  So in this use case, the producer hasn't declared
the services yet when the consumer tries to use them.

PreEncodedHttpField.() line: 49
MimeTypes$Type.(String) line: 103
MimeTypes$Type.() line: 58
MimeTypes.() line: 191
ServletContextHandler(ContextHandler).doStart() line: 832
ServletContextHandler.doStart() line: 287
ServletContextHandler(AbstractLifeCycle).start() line: 68
ContextHandlerCollection(ContainerLifeCycle).start(LifeCycle) line: 138
ContextHandlerCollection(ContainerLifeCycle).doStart() line: 117
ContextHandlerCollection(AbstractHandler).doStart() line: 113
ContextHandlerCollection.doStart() line: 167
ContextHandlerCollection(AbstractLifeCycle).start() line: 68
Server(ContainerLifeCycle).start(LifeCycle) line: 138
Server.start(LifeCycle) line: 419
Server(ContainerLifeCycle).doStart() line: 108
Server(AbstractHandler).doStart() line: 113
Server.doStart() line: 386
Server(AbstractLifeCycle).start() line: 68
JettyService.initializeJetty() line: 426
JettyService.startJetty() line: 306
JettyService.start() line: 149
JettyActivator.doStart() line: 63
JettyActivator(AbstractActivator).start(BundleContext) line: 39
SecureAction.startActivator(BundleActivator, BundleContext) line: 697
SlingFelix(Felix).activateBundle(BundleImpl, boolean) line: 2240
SlingFelix(Felix).startBundle(BundleImpl, int) line: 2146
SlingFelix(Felix).setActiveStartLevel(int, FrameworkListener[]) line: 1373
FrameworkStartLevelImpl.run() line: 308
Thread.run() line: 748


It seems that some other changes would be required to get around that.
Either changes to jetty code or changing the felix code to not start
synchronously in the bundle activator.

The uber bundle seems to complicate the scenario and additional bundles are
still required anyways to enable OSGi ServiceLoader mediator support and
provide the appropriate alpn-impl bundles that corresponds to your JRE.

Does that make sense?

Regards,
Eric

On Sat, Jul 14, 2018 at 1:04 AM, Carsten Ziegeler 
wrote:

> Hi Eric,
>
> that sounds interesting. As far as I remember we started to embed Jetty
> as by that time Jetty was not available as OSGi bundles out of the box.
> The other reason is ease of use, you just need to install a single
> bundle - which is sufficient for most users - instead of a set of bundles.
>
> Would it be possible to create the uber bundle with the correct set of
> files like the service loader stuff?
>
> How about we provide two artifacts, the uber and the thin one? I really
> would like to keep the uber one as this makes using it easier and is
> easier for upgrading existing systems.
>
> Regards
>
> Carsten
>
>
> Eric Norman wrote
> > I've been doing some work to enable the HTTP/2 support in jetty for usage
> > within the Felix Http Jetty 4.x bundle for an apache sling based project.
> >
> > I'm not sure about the history of the felix.http.jetty bundle, but can I
> > ask why it was decided to make copies of the jetty classes inside the
> felix
> > bundle rather than just depending on the already existing jetty bundles
> and
> > then provisioning the jetty-* bundles to the OSGi profile to provide
> those
> > classes?
> >
> > The reason I ask is that the jetty implementation is still utilizing the
> > java.util.ServiceLoader mechanism in a few places and the packaging of
> the
> > felix.http.jetty bundle is not copying the META-INF/services/* files or
> > merging the related "osgi.serviceloader" Require-Capability and
> > Provide-Capability attributes from the manifest of the embedded jetty-*
> > bundles when it is repackaged.  This makes it so the ServiceLoader code
> is
> > unable to discover the services provided by the jetty-http and the
> > jetty-alpn-* bundles and the jetty HTTP/2 related code fails.
> >
> > In other words, using the jetty-* bundles has everything packaged and
> > declared correctly to utilize the OSGi ServiceLoader mediator patterns,
> but
> > the felix.http.jetty bundle is missing some of the critical details.
> Also,
> > by using the jetty bundles directly, the jetty and felix bundles could
> > evolve at their own pace and felix would not have to re-release a new
> > version of the felix.http.jetty bundle every time a new jetty version
> gets
> > released.
> >
> > I have proven locally that the above scenario works and have gotten the
> > jetty HTTP/2 support 

Re: Felix Http Jetty packaging as uber bundle?

2018-07-14 Thread Raymond Auge
Let's not forget the fact that jetty is not semantically versioned, which
can cause ugly problems. The Uber jetty bundle hides this concern.

I'm not saying this couldn't be solved somehow but it can't be ignored.

And also don't get me wrong, I love jetty!

The thing is that Felix modules are cornerstone OSGi technologies and it
takes things like semantic versioning seriously and I would be opposed to
having a key part of the system suddenly become a burden by binding itself
to something that isn't semantically versioned.

Sincerely,
- Ray

On Sat, Jul 14, 2018, 04:04 Carsten Ziegeler,  wrote:

> Hi Eric,
>
> that sounds interesting. As far as I remember we started to embed Jetty
> as by that time Jetty was not available as OSGi bundles out of the box.
> The other reason is ease of use, you just need to install a single
> bundle - which is sufficient for most users - instead of a set of bundles.
>
> Would it be possible to create the uber bundle with the correct set of
> files like the service loader stuff?
>
> How about we provide two artifacts, the uber and the thin one? I really
> would like to keep the uber one as this makes using it easier and is
> easier for upgrading existing systems.
>
> Regards
>
> Carsten
>
>
> Eric Norman wrote
> > I've been doing some work to enable the HTTP/2 support in jetty for usage
> > within the Felix Http Jetty 4.x bundle for an apache sling based project.
> >
> > I'm not sure about the history of the felix.http.jetty bundle, but can I
> > ask why it was decided to make copies of the jetty classes inside the
> felix
> > bundle rather than just depending on the already existing jetty bundles
> and
> > then provisioning the jetty-* bundles to the OSGi profile to provide
> those
> > classes?
> >
> > The reason I ask is that the jetty implementation is still utilizing the
> > java.util.ServiceLoader mechanism in a few places and the packaging of
> the
> > felix.http.jetty bundle is not copying the META-INF/services/* files or
> > merging the related "osgi.serviceloader" Require-Capability and
> > Provide-Capability attributes from the manifest of the embedded jetty-*
> > bundles when it is repackaged.  This makes it so the ServiceLoader code
> is
> > unable to discover the services provided by the jetty-http and the
> > jetty-alpn-* bundles and the jetty HTTP/2 related code fails.
> >
> > In other words, using the jetty-* bundles has everything packaged and
> > declared correctly to utilize the OSGi ServiceLoader mediator patterns,
> but
> > the felix.http.jetty bundle is missing some of the critical details.
> Also,
> > by using the jetty bundles directly, the jetty and felix bundles could
> > evolve at their own pace and felix would not have to re-release a new
> > version of the felix.http.jetty bundle every time a new jetty version
> gets
> > released.
> >
> > I have proven locally that the above scenario works and have gotten the
> > jetty HTTP/2 support to work locally by refactoring to make a "thin"
> > version of the felix.http.jetty bundle that doesn't have a copy of the
> > jetty classes inside of it and then provision the following bundles to
> the
> > OSGi profile:
> >
> > # "thin" felix http jetty without the jetty classes embedded
> > org.apache.felix/org.apache.felix.http.jetty/4.0.3-SNAPSHOT
> >
> > # additional bundles to enable OSGi ServiceLoader mediator support
> > org.ow2.asm/asm-all/5.2
> > org.apache.aries/org.apache.aries.util/1.1.3
> > org.apache.aries.spifly/org.apache.aries.spifly.dynamic.bundle/1.0.12
> >
> > # Jetty bundles
> > org.eclipse.jetty/jetty-servlet/9.4.11.v20180605
> > org.eclipse.jetty/jetty-server/9.4.11.v20180605
> > org.eclipse.jetty/jetty-http/9.4.11.v20180605
> > org.eclipse.jetty/jetty-io/9.4.11.v20180605
> > org.eclipse.jetty/jetty-util/9.4.11.v20180605
> > org.eclipse.jetty/jetty-jmx/9.4.11.v20180605
> > org.eclipse.jetty/jetty-security/9.4.11.v20180605
> > org.eclipse.jetty/jetty-webapp/9.4.11.v20180605
> > org.eclipse.jetty/jetty-xml/9.4.11.v20180605
> > org.eclipse.jetty.websocket/websocket-servlet/9.4.11.v20180605
> > org.eclipse.jetty.websocket/websocket-api/9.4.11.v20180605
> > org.eclipse.jetty.websocket/websocket-server/9.4.11.v20180605
> > org.eclipse.jetty.websocket/websocket-common/9.4.11.v20180605
> > org.eclipse.jetty.websocket/websocket-client/9.4.11.v20180605
> > org.eclipse.jetty/jetty-client/9.4.11.v20180605
> > org.eclipse.jetty.http2/http2-server/9.4.11.v20180605
> > org.eclipse.jetty.http2/http2-common/9.4.11.v20180605
> > org.eclipse.jetty.http2/http2-hpack/9.4.11.v20180605
> > org.eclipse.jetty/jetty-alpn-server/9.4.11.v20180605
> >
> > # Provide ALPN support for JDK8 (doesn't work for JDK 9+).  Also requires
> > an additional alpn-boot-*.jar to be declared as a "-Xbootclasspath/p"
> > argument to java.
> > org.eclipse.jetty.osgi/jetty-osgi-alpn/9.4.11.v20180605
> > org.eclipse.jetty/jetty-alpn-openjdk8-server/9.4.11.v20180605
> >
> > # Alternatively, exclude the JDK8 bundles and provide support for 

Re: Felix Http Jetty packaging as uber bundle?

2018-07-14 Thread Carsten Ziegeler
Hi Eric,

that sounds interesting. As far as I remember we started to embed Jetty
as by that time Jetty was not available as OSGi bundles out of the box.
The other reason is ease of use, you just need to install a single
bundle - which is sufficient for most users - instead of a set of bundles.

Would it be possible to create the uber bundle with the correct set of
files like the service loader stuff?

How about we provide two artifacts, the uber and the thin one? I really
would like to keep the uber one as this makes using it easier and is
easier for upgrading existing systems.

Regards

Carsten


Eric Norman wrote
> I've been doing some work to enable the HTTP/2 support in jetty for usage
> within the Felix Http Jetty 4.x bundle for an apache sling based project.
> 
> I'm not sure about the history of the felix.http.jetty bundle, but can I
> ask why it was decided to make copies of the jetty classes inside the felix
> bundle rather than just depending on the already existing jetty bundles and
> then provisioning the jetty-* bundles to the OSGi profile to provide those
> classes?
> 
> The reason I ask is that the jetty implementation is still utilizing the
> java.util.ServiceLoader mechanism in a few places and the packaging of the
> felix.http.jetty bundle is not copying the META-INF/services/* files or
> merging the related "osgi.serviceloader" Require-Capability and
> Provide-Capability attributes from the manifest of the embedded jetty-*
> bundles when it is repackaged.  This makes it so the ServiceLoader code is
> unable to discover the services provided by the jetty-http and the
> jetty-alpn-* bundles and the jetty HTTP/2 related code fails.
> 
> In other words, using the jetty-* bundles has everything packaged and
> declared correctly to utilize the OSGi ServiceLoader mediator patterns, but
> the felix.http.jetty bundle is missing some of the critical details.  Also,
> by using the jetty bundles directly, the jetty and felix bundles could
> evolve at their own pace and felix would not have to re-release a new
> version of the felix.http.jetty bundle every time a new jetty version gets
> released.
> 
> I have proven locally that the above scenario works and have gotten the
> jetty HTTP/2 support to work locally by refactoring to make a "thin"
> version of the felix.http.jetty bundle that doesn't have a copy of the
> jetty classes inside of it and then provision the following bundles to the
> OSGi profile:
> 
> # "thin" felix http jetty without the jetty classes embedded
> org.apache.felix/org.apache.felix.http.jetty/4.0.3-SNAPSHOT
> 
> # additional bundles to enable OSGi ServiceLoader mediator support
> org.ow2.asm/asm-all/5.2
> org.apache.aries/org.apache.aries.util/1.1.3
> org.apache.aries.spifly/org.apache.aries.spifly.dynamic.bundle/1.0.12
> 
> # Jetty bundles
> org.eclipse.jetty/jetty-servlet/9.4.11.v20180605
> org.eclipse.jetty/jetty-server/9.4.11.v20180605
> org.eclipse.jetty/jetty-http/9.4.11.v20180605
> org.eclipse.jetty/jetty-io/9.4.11.v20180605
> org.eclipse.jetty/jetty-util/9.4.11.v20180605
> org.eclipse.jetty/jetty-jmx/9.4.11.v20180605
> org.eclipse.jetty/jetty-security/9.4.11.v20180605
> org.eclipse.jetty/jetty-webapp/9.4.11.v20180605
> org.eclipse.jetty/jetty-xml/9.4.11.v20180605
> org.eclipse.jetty.websocket/websocket-servlet/9.4.11.v20180605
> org.eclipse.jetty.websocket/websocket-api/9.4.11.v20180605
> org.eclipse.jetty.websocket/websocket-server/9.4.11.v20180605
> org.eclipse.jetty.websocket/websocket-common/9.4.11.v20180605
> org.eclipse.jetty.websocket/websocket-client/9.4.11.v20180605
> org.eclipse.jetty/jetty-client/9.4.11.v20180605
> org.eclipse.jetty.http2/http2-server/9.4.11.v20180605
> org.eclipse.jetty.http2/http2-common/9.4.11.v20180605
> org.eclipse.jetty.http2/http2-hpack/9.4.11.v20180605
> org.eclipse.jetty/jetty-alpn-server/9.4.11.v20180605
> 
> # Provide ALPN support for JDK8 (doesn't work for JDK 9+).  Also requires
> an additional alpn-boot-*.jar to be declared as a "-Xbootclasspath/p"
> argument to java.
> org.eclipse.jetty.osgi/jetty-osgi-alpn/9.4.11.v20180605
> org.eclipse.jetty/jetty-alpn-openjdk8-server/9.4.11.v20180605
> 
> # Alternatively, exclude the JDK8 bundles and provide support for ALPN
> based on support baked into the runtime for JDK9+ (doesn't work for JDK
> 8).  No alpn-boot-*.jar is required.
> #org.eclipse.jetty.alpn/alpn-api/1.1.3.v20160715
> #org.eclipse.jetty/jetty-alpn-java-server/9.4.11.v20180605
> 
> # Alternatively, exclude the JDK8/JDK9 ALPN impl bundles and provide
> support for ALPN based on the conscrypt impl (NOTE: I haven't gotten this
> one to work yet).
> #
> org.apache.servicemix.bundles/org.apache.servicemix.bundles.conscrypt-openjdk/1.0.1_1
> #org.eclipse.jetty/jetty-alpn-conscrypt-server/9.4.11.v20180605
> 
> 
> FYI: I've stashed the changes to the felix.http.jetty code at [1] if you
> wish to review.
> 
>1.
>
> https://github.com/enapps-enorman/felix/commit/76adf9d3a445cb620d2baa9fd1155f5e25aa3ca5
> 
> 
> 

Re: Felix Fileinstall 3.6.0 overwriting custom .json configuration files

2018-04-19 Thread Chris Drake
Guillaume,

Thanks for the confirmation.  I've filed FELIX-5832
<https://issues.apache.org/jira/browse/FELIX-5832> and submitted a PR to
resolve the issue.

Regards,
Chris

On Thu, Apr 19, 2018 at 2:53 PM, Guillaume Nodet <gno...@apache.org> wrote:

> Ok, I understand now.
> Please raise an issue, as the ConfigInstaller should not handle events for
> files it does not manage.
>
> 2018-04-19 15:45 GMT+02:00 Chris Drake <cgdr...@infodrake.com>:
>
> > Guillaume,
> >
> > Thanks for the feedback, however I'm not sure I understand how setting
> the
> > felix.fileinstall.filter will resolve the issue.  Maybe I'm
> > misunderstanding how things are intended to work?
> >
> > We currently use the following fileinstall configuration:
> >
> > PID = org.apache.felix.fileinstall.c84c4846-d3a3-4a8d-8228-223d52613459
> >   Factory PID = org.apache.felix.fileinstall
> >   BundleLocation = file:/app/bundle/org.apache.
> felix.fileinstall-3.5.4.jar
> >   felix.fileinstall.bundles.new.start = false
> >   felix.fileinstall.dir = /app/conf
> >   felix.fileinstall.filter = .*\.cfg|.*\.json
> >   felix.fileinstall.noInitialDelay = true
> >   felix.fileinstall.poll = 2000
> >   service.factoryPid = org.apache.felix.fileinstall
> >   service.pid =
> > org.apache.felix.fileinstall.c84c4846-d3a3-4a8d-8228-223d52613459
> >
> >
> > Our ArtifactInstaller only handles .json config files, similarly our
> > ConfigurationListener will only handle events for configuration objects
> > bound to our .json config files.
> >
> > The Felix ConfigInstaller's ArtifactInstaller implementation only handles
> > .cfg and .config files, therefore ignoring our custom .json configuration
> > files. This is the expected behaviour.  However, for the
> > ConfigurationListener implementation all configuration events are handled
> > regardless of the bound configuration objects file type. As a result
> > Felix's ConfigInstaller overwrites our .json config files immediately
> after
> > our ConfigurationListener writes them out to disk.
> >
> > Regards,
> > Chris
> >
> > From: Guillaume Nodet <gno...@apache.org>
> > > To: users@felix.apache.org
> > > Cc:
> > > Bcc:
> > > Date: Thu, 19 Apr 2018 07:52:00 +0200
> > > Subject: Re: Felix Fileinstall 3.6.0 overwriting custom .json
> > > configuration files
> > > That's definitely a change in the behavior.
> > > A simple workaround is to define the following property:
> > >
> > > felix.fileinstall.filter = .*\\.(cfg|config)
> > >
> > >
> > > 2018-04-18 22:40 GMT+02:00 Chris Drake <cgdr...@infodrake.com>:
> > >
> > > > Hello,
> > > >
> > > > We have a OSGi service registered via a Bundle activator and which
> > > > implements the ArtifactInstaller and ConfigurationListener
> interfaces.
> > > The
> > > > purpose of this service is to support loading custom .json
> > configuration
> > > > files from disk, creating and updating the corresponding config via
> the
> > > > ConfigurationAdmin and writing configuration changes back out to
> disk.
> > > >
> > > > This service has worked well for a long time across multiple upgrades
> > of
> > > > the Felix's FileInstall bundle.  Unfortunately recent changes as a
> > result
> > > > of FELIX-5609 <https://issues.apache.org/jira/browse/FELIX-5609>
> have
> > > > broken this service.  Prior to FELIX-5609
> > > > <https://issues.apache.org/jira/browse/FELIX-5609> FileInstall was
> > > > restricted to handling .cfg and .config files and would ignore our
> > > > customized .json config files, never attempting to write them out to
> > > disk.
> > > > When we moved to FileInstall 3.6.0 we observed our .json config files
> > > being
> > > > overwritten by FileInstall's ConfigInstaller.
> > > >
> > > > I believe the above is a bug and the changes introduced by FELIX-5609
> > > > <https://issues.apache.org/jira/browse/FELIX-5609> should have
> > retained
> > > > the
> > > > check restricting configuration handling to only .cfg and .confg
> files.
> > > >
> > > > What do you think?
> > > >
> > > > Regards,
> > > > Chris
> > > >
> > >
> > >
> > >
> > > --
> > > 
> > > Guillaume Nodet
> > >
> > >
> >
>
>
>
> --
> 
> Guillaume Nodet
>


Re: Felix Fileinstall 3.6.0 overwriting custom .json configuration files

2018-04-19 Thread Guillaume Nodet
Ok, I understand now.
Please raise an issue, as the ConfigInstaller should not handle events for
files it does not manage.

2018-04-19 15:45 GMT+02:00 Chris Drake <cgdr...@infodrake.com>:

> Guillaume,
>
> Thanks for the feedback, however I'm not sure I understand how setting the
> felix.fileinstall.filter will resolve the issue.  Maybe I'm
> misunderstanding how things are intended to work?
>
> We currently use the following fileinstall configuration:
>
> PID = org.apache.felix.fileinstall.c84c4846-d3a3-4a8d-8228-223d52613459
>   Factory PID = org.apache.felix.fileinstall
>   BundleLocation = file:/app/bundle/org.apache.felix.fileinstall-3.5.4.jar
>   felix.fileinstall.bundles.new.start = false
>   felix.fileinstall.dir = /app/conf
>   felix.fileinstall.filter = .*\.cfg|.*\.json
>   felix.fileinstall.noInitialDelay = true
>   felix.fileinstall.poll = 2000
>   service.factoryPid = org.apache.felix.fileinstall
>   service.pid =
> org.apache.felix.fileinstall.c84c4846-d3a3-4a8d-8228-223d52613459
>
>
> Our ArtifactInstaller only handles .json config files, similarly our
> ConfigurationListener will only handle events for configuration objects
> bound to our .json config files.
>
> The Felix ConfigInstaller's ArtifactInstaller implementation only handles
> .cfg and .config files, therefore ignoring our custom .json configuration
> files. This is the expected behaviour.  However, for the
> ConfigurationListener implementation all configuration events are handled
> regardless of the bound configuration objects file type. As a result
> Felix's ConfigInstaller overwrites our .json config files immediately after
> our ConfigurationListener writes them out to disk.
>
> Regards,
> Chris
>
> From: Guillaume Nodet <gno...@apache.org>
> > To: users@felix.apache.org
> > Cc:
> > Bcc:
> > Date: Thu, 19 Apr 2018 07:52:00 +0200
> > Subject: Re: Felix Fileinstall 3.6.0 overwriting custom .json
> > configuration files
> > That's definitely a change in the behavior.
> > A simple workaround is to define the following property:
> >
> > felix.fileinstall.filter = .*\\.(cfg|config)
> >
> >
> > 2018-04-18 22:40 GMT+02:00 Chris Drake <cgdr...@infodrake.com>:
> >
> > > Hello,
> > >
> > > We have a OSGi service registered via a Bundle activator and which
> > > implements the ArtifactInstaller and ConfigurationListener interfaces.
> > The
> > > purpose of this service is to support loading custom .json
> configuration
> > > files from disk, creating and updating the corresponding config via the
> > > ConfigurationAdmin and writing configuration changes back out to disk.
> > >
> > > This service has worked well for a long time across multiple upgrades
> of
> > > the Felix's FileInstall bundle.  Unfortunately recent changes as a
> result
> > > of FELIX-5609 <https://issues.apache.org/jira/browse/FELIX-5609> have
> > > broken this service.  Prior to FELIX-5609
> > > <https://issues.apache.org/jira/browse/FELIX-5609> FileInstall was
> > > restricted to handling .cfg and .config files and would ignore our
> > > customized .json config files, never attempting to write them out to
> > disk.
> > > When we moved to FileInstall 3.6.0 we observed our .json config files
> > being
> > > overwritten by FileInstall's ConfigInstaller.
> > >
> > > I believe the above is a bug and the changes introduced by FELIX-5609
> > > <https://issues.apache.org/jira/browse/FELIX-5609> should have
> retained
> > > the
> > > check restricting configuration handling to only .cfg and .confg files.
> > >
> > > What do you think?
> > >
> > > Regards,
> > > Chris
> > >
> >
> >
> >
> > --
> > 
> > Guillaume Nodet
> >
> >
>



-- 

Guillaume Nodet


Re: Felix Fileinstall 3.6.0 overwriting custom .json configuration files

2018-04-19 Thread Chris Drake
Guillaume,

Thanks for the feedback, however I'm not sure I understand how setting the
felix.fileinstall.filter will resolve the issue.  Maybe I'm
misunderstanding how things are intended to work?

We currently use the following fileinstall configuration:

PID = org.apache.felix.fileinstall.c84c4846-d3a3-4a8d-8228-223d52613459
  Factory PID = org.apache.felix.fileinstall
  BundleLocation = file:/app/bundle/org.apache.felix.fileinstall-3.5.4.jar
  felix.fileinstall.bundles.new.start = false
  felix.fileinstall.dir = /app/conf
  felix.fileinstall.filter = .*\.cfg|.*\.json
  felix.fileinstall.noInitialDelay = true
  felix.fileinstall.poll = 2000
  service.factoryPid = org.apache.felix.fileinstall
  service.pid =
org.apache.felix.fileinstall.c84c4846-d3a3-4a8d-8228-223d52613459


Our ArtifactInstaller only handles .json config files, similarly our
ConfigurationListener will only handle events for configuration objects
bound to our .json config files.

The Felix ConfigInstaller's ArtifactInstaller implementation only handles
.cfg and .config files, therefore ignoring our custom .json configuration
files. This is the expected behaviour.  However, for the
ConfigurationListener implementation all configuration events are handled
regardless of the bound configuration objects file type. As a result
Felix's ConfigInstaller overwrites our .json config files immediately after
our ConfigurationListener writes them out to disk.

Regards,
Chris

From: Guillaume Nodet <gno...@apache.org>
> To: users@felix.apache.org
> Cc:
> Bcc:
> Date: Thu, 19 Apr 2018 07:52:00 +0200
> Subject: Re: Felix Fileinstall 3.6.0 overwriting custom .json
> configuration files
> That's definitely a change in the behavior.
> A simple workaround is to define the following property:
>
> felix.fileinstall.filter = .*\\.(cfg|config)
>
>
> 2018-04-18 22:40 GMT+02:00 Chris Drake <cgdr...@infodrake.com>:
>
> > Hello,
> >
> > We have a OSGi service registered via a Bundle activator and which
> > implements the ArtifactInstaller and ConfigurationListener interfaces.
> The
> > purpose of this service is to support loading custom .json configuration
> > files from disk, creating and updating the corresponding config via the
> > ConfigurationAdmin and writing configuration changes back out to disk.
> >
> > This service has worked well for a long time across multiple upgrades of
> > the Felix's FileInstall bundle.  Unfortunately recent changes as a result
> > of FELIX-5609 <https://issues.apache.org/jira/browse/FELIX-5609> have
> > broken this service.  Prior to FELIX-5609
> > <https://issues.apache.org/jira/browse/FELIX-5609> FileInstall was
> > restricted to handling .cfg and .config files and would ignore our
> > customized .json config files, never attempting to write them out to
> disk.
> > When we moved to FileInstall 3.6.0 we observed our .json config files
> being
> > overwritten by FileInstall's ConfigInstaller.
> >
> > I believe the above is a bug and the changes introduced by FELIX-5609
> > <https://issues.apache.org/jira/browse/FELIX-5609> should have retained
> > the
> > check restricting configuration handling to only .cfg and .confg files.
> >
> > What do you think?
> >
> > Regards,
> > Chris
> >
>
>
>
> --
> 
> Guillaume Nodet
>
>


Re: Felix Fileinstall 3.6.0 overwriting custom .json configuration files

2018-04-18 Thread Guillaume Nodet
That's definitely a change in the behavior.
A simple workaround is to define the following property:

felix.fileinstall.filter = .*\\.(cfg|config)


2018-04-18 22:40 GMT+02:00 Chris Drake :

> Hello,
>
> We have a OSGi service registered via a Bundle activator and which
> implements the ArtifactInstaller and ConfigurationListener interfaces. The
> purpose of this service is to support loading custom .json configuration
> files from disk, creating and updating the corresponding config via the
> ConfigurationAdmin and writing configuration changes back out to disk.
>
> This service has worked well for a long time across multiple upgrades of
> the Felix's FileInstall bundle.  Unfortunately recent changes as a result
> of FELIX-5609  have
> broken this service.  Prior to FELIX-5609
>  FileInstall was
> restricted to handling .cfg and .config files and would ignore our
> customized .json config files, never attempting to write them out to disk.
> When we moved to FileInstall 3.6.0 we observed our .json config files being
> overwritten by FileInstall's ConfigInstaller.
>
> I believe the above is a bug and the changes introduced by FELIX-5609
>  should have retained
> the
> check restricting configuration handling to only .cfg and .confg files.
>
> What do you think?
>
> Regards,
> Chris
>



-- 

Guillaume Nodet


Re: Felix startup performance on Windows due to secure random and network card MAC access

2018-03-22 Thread Brad Wood
Thanks for the responses guys!

*>  Could you open a jira issue for this?*

Sure thing!
https://issues.apache.org/jira/browse/FELIX-5816


*>  You can also seed the SecureRandom yourself*

Interesting.  A friend suggested some options from a StackOverflow post
<https://stackoverflow.com/questions/49322948/slow-securerandom-initialization/49322949#49322949>
to avoid SecureRandom as the default security provider on Windows.  I was
able to implement this snippet of code as a temp workaround prior to
loading up Felix which has now shaved 1.5 seconds off of my startup time!

Optional.ofNullable( Security.getProvider( "SunMSCAPI" ) ).ifPresent( p->{
Security.removeProvider( p.getName() );
Security.insertProviderAt( p, 1 );
} );



Thanks!

~Brad

*Developer Advocate*
*Ortus Solutions, Corp *

E-mail: b...@coldbox.org
ColdBox Platform: http://www.coldbox.org
Blog: http://www.codersrevolution.com


On Thu, Mar 22, 2018 at 10:35 PM, Bernd Eckenfels <e...@zusammenkunft.net>
wrote:

> You can also seed the SecureRandom yourself (with current time and
> hostname and similar) but I think that’s a very specific driver/Hardware
> problem)
>
> Gruss
> Bernd
> --
> http://bernd.eckenfels.net
> 
> From: Karl Pauls <karlpa...@gmail.com>
> Sent: Friday, March 23, 2018 12:07:24 AM
> To: users@felix.apache.org
> Subject: Re: Felix startup performance on Windows due to secure random and
> network card MAC access
>
> I think we could probably just switch to using java.util.Random
> instead of SecureRandom. Could you open a jira issue for this?
>
> regards,
>
> Karl
>
> On Thu, Mar 22, 2018 at 11:45 PM, Brad Wood <bdw4...@gmail.com> wrote:
> > Hi all, first time poster here.  I'm working on a CLI project called
> > CommandBox ( https://www.ortussolutions.com/products/commandbox ) which
> is
> > based on a JSR-223 implementation of the JVM language Lucee Server (
> > http://lucee.org/ ).  Lucee uses Apache Felix internally when it starts
> up
> > and on my Windows machines I'm seeing a significant slowdown in startup
> > time due to accessing my Windows network adapter in order to read the Mac
> > address as part of SecureRandom which is used to generate a UUID for each
> > Felix instance.
> >
> > By significant slowdown, I'm talking about 1.5 seconds, which may go
> > unnoticed in a server startup, but is a week in CLI-startup years. :)
> Java
> > libs that want to access my network adapter's Mac address are a common
> > nemesis of my startup times, mostly due to Windows sucking from what I
> can
> > tell.
> >
> > This line here is where things start to go south:
> > https://github.com/apache/felix/blob/trunk/framework/src/
> main/java/org/apache/felix/framework/Felix.java#L675
> >
> > And the stack traces usually look similar to this right here:
> >
> > java.lang.Thread.State: RUNNABLE
> >   at java.net.NetworkInterface.getMacAddr0(Native Method)
> >   at java.net.NetworkInterface.getHardwareAddress(NetworkInterfac
> e.java:460)
> >   at sun.security.provider.SeedGenerator.addNetworkAdapterInfo(Se
> edGenerator.java:238)
> >   at sun.security.provider.SeedGenerator.access$000(SeedGenerator
> .java:80)
> >   at sun.security.provider.SeedGenerator$1.run(SeedGenerator.java:183)
> >   at sun.security.provider.SeedGenerator$1.run(SeedGenerator.java:168)
> >   at java.security.AccessController.doPrivileged(Native Method)
> >   at sun.security.provider.SeedGenerator.getSystemEntropy(SeedGen
> erator.java:168)
> >   at sun.security.provider.SecureRandom$SeederHolder.(
> SecureRandom.java:201)
> >   at sun.security.provider.SecureRandom.engineNextBytes(SecureRan
> dom.java:221)
> >   - locked <0x0007415f5f40> (a sun.security.provider.SecureRandom)
> >   at java.security.SecureRandom.nextBytes(SecureRandom.java:468)
> >   at org.apache.felix.framework.util.Util.randomUUID(Util.java:795)
> >   at org.apache.felix.framework.Felix.init(Felix.java:675)
> >   at org.apache.felix.framework.Felix.init(Felix.java:626)
> >   at org.apache.felix.framework.Felix.start(Felix.java:964)
> >   ... unrelated bootstrapping code...
> >
> > Based on the comments and a quick review of the code, I'm guessing the
> > generation of a UUID of some sort is unavoidable.  What are the
> > chances of switching to some other, much faster library for UUID
> > generation that doesn't need to drop down the rabbit hole of asking my
> > Windows networking stack for a Mac address?  This will make a huge
> > difference in my CLI startup times for sure.
> >
> > Perhaps a library like this could be used:
&g

Re: Felix startup performance on Windows due to secure random and network card MAC access

2018-03-22 Thread Bernd Eckenfels
You can also seed the SecureRandom yourself (with current time and hostname and 
similar) but I think that’s a very specific driver/Hardware problem)

Gruss
Bernd
--
http://bernd.eckenfels.net

From: Karl Pauls <karlpa...@gmail.com>
Sent: Friday, March 23, 2018 12:07:24 AM
To: users@felix.apache.org
Subject: Re: Felix startup performance on Windows due to secure random and 
network card MAC access

I think we could probably just switch to using java.util.Random
instead of SecureRandom. Could you open a jira issue for this?

regards,

Karl

On Thu, Mar 22, 2018 at 11:45 PM, Brad Wood <bdw4...@gmail.com> wrote:
> Hi all, first time poster here.  I'm working on a CLI project called
> CommandBox ( https://www.ortussolutions.com/products/commandbox ) which is
> based on a JSR-223 implementation of the JVM language Lucee Server (
> http://lucee.org/ ).  Lucee uses Apache Felix internally when it starts up
> and on my Windows machines I'm seeing a significant slowdown in startup
> time due to accessing my Windows network adapter in order to read the Mac
> address as part of SecureRandom which is used to generate a UUID for each
> Felix instance.
>
> By significant slowdown, I'm talking about 1.5 seconds, which may go
> unnoticed in a server startup, but is a week in CLI-startup years. :)  Java
> libs that want to access my network adapter's Mac address are a common
> nemesis of my startup times, mostly due to Windows sucking from what I can
> tell.
>
> This line here is where things start to go south:
> https://github.com/apache/felix/blob/trunk/framework/src/main/java/org/apache/felix/framework/Felix.java#L675
>
> And the stack traces usually look similar to this right here:
>
> java.lang.Thread.State: RUNNABLE
>   at java.net.NetworkInterface.getMacAddr0(Native Method)
>   at java.net.NetworkInterface.getHardwareAddress(NetworkInterface.java:460)
>   at 
> sun.security.provider.SeedGenerator.addNetworkAdapterInfo(SeedGenerator.java:238)
>   at sun.security.provider.SeedGenerator.access$000(SeedGenerator.java:80)
>   at sun.security.provider.SeedGenerator$1.run(SeedGenerator.java:183)
>   at sun.security.provider.SeedGenerator$1.run(SeedGenerator.java:168)
>   at java.security.AccessController.doPrivileged(Native Method)
>   at 
> sun.security.provider.SeedGenerator.getSystemEntropy(SeedGenerator.java:168)
>   at 
> sun.security.provider.SecureRandom$SeederHolder.(SecureRandom.java:201)
>   at sun.security.provider.SecureRandom.engineNextBytes(SecureRandom.java:221)
>   - locked <0x0007415f5f40> (a sun.security.provider.SecureRandom)
>   at java.security.SecureRandom.nextBytes(SecureRandom.java:468)
>   at org.apache.felix.framework.util.Util.randomUUID(Util.java:795)
>   at org.apache.felix.framework.Felix.init(Felix.java:675)
>   at org.apache.felix.framework.Felix.init(Felix.java:626)
>   at org.apache.felix.framework.Felix.start(Felix.java:964)
>   ... unrelated bootstrapping code...
>
> Based on the comments and a quick review of the code, I'm guessing the
> generation of a UUID of some sort is unavoidable.  What are the
> chances of switching to some other, much faster library for UUID
> generation that doesn't need to drop down the rabbit hole of asking my
> Windows networking stack for a Mac address?  This will make a huge
> difference in my CLI startup times for sure.
>
> Perhaps a library like this could be used:
>
> https://github.com/jchambers/fast-uuid
>
> Thanks!
>
> ~Brad
>
> *Developer Advocate*
> *Ortus Solutions, Corp *
>
> E-mail: b...@coldbox.org
> ColdBox Platform: http://www.coldbox.org
> Blog: http://www.codersrevolution.com



--
Karl Pauls
karlpa...@gmail.com

-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org



Re: Felix startup performance on Windows due to secure random and network card MAC access

2018-03-22 Thread Karl Pauls
I think we could probably just switch to using java.util.Random
instead of SecureRandom. Could you open a jira issue for this?

regards,

Karl

On Thu, Mar 22, 2018 at 11:45 PM, Brad Wood  wrote:
> Hi all, first time poster here.  I'm working on a CLI project called
> CommandBox ( https://www.ortussolutions.com/products/commandbox ) which is
> based on a JSR-223 implementation of the JVM language Lucee Server (
> http://lucee.org/ ).  Lucee uses Apache Felix internally when it starts up
> and on my Windows machines I'm seeing a significant slowdown in startup
> time due to accessing my Windows network adapter in order to read the Mac
> address as part of SecureRandom which is used to generate a UUID for each
> Felix instance.
>
> By significant slowdown, I'm talking about 1.5 seconds, which may go
> unnoticed in a server startup, but is a week in CLI-startup years. :)  Java
> libs that want to access my network adapter's Mac address are a common
> nemesis of my startup times, mostly due to Windows sucking from what I can
> tell.
>
> This line here is where things start to go south:
> https://github.com/apache/felix/blob/trunk/framework/src/main/java/org/apache/felix/framework/Felix.java#L675
>
> And the stack traces usually look similar to this right here:
>
> java.lang.Thread.State: RUNNABLE
>   at java.net.NetworkInterface.getMacAddr0(Native Method)
>   at java.net.NetworkInterface.getHardwareAddress(NetworkInterface.java:460)
>   at 
> sun.security.provider.SeedGenerator.addNetworkAdapterInfo(SeedGenerator.java:238)
>   at sun.security.provider.SeedGenerator.access$000(SeedGenerator.java:80)
>   at sun.security.provider.SeedGenerator$1.run(SeedGenerator.java:183)
>   at sun.security.provider.SeedGenerator$1.run(SeedGenerator.java:168)
>   at java.security.AccessController.doPrivileged(Native Method)
>   at 
> sun.security.provider.SeedGenerator.getSystemEntropy(SeedGenerator.java:168)
>   at 
> sun.security.provider.SecureRandom$SeederHolder.(SecureRandom.java:201)
>   at sun.security.provider.SecureRandom.engineNextBytes(SecureRandom.java:221)
>   - locked <0x0007415f5f40> (a sun.security.provider.SecureRandom)
>   at java.security.SecureRandom.nextBytes(SecureRandom.java:468)
>   at org.apache.felix.framework.util.Util.randomUUID(Util.java:795)
>   at org.apache.felix.framework.Felix.init(Felix.java:675)
>   at org.apache.felix.framework.Felix.init(Felix.java:626)
>   at org.apache.felix.framework.Felix.start(Felix.java:964)
>   ... unrelated bootstrapping code...
>
> Based on the comments and a quick review of the code, I'm guessing the
> generation of a UUID of some sort is unavoidable.  What are the
> chances of switching to some other, much faster library for UUID
> generation that doesn't need to drop down the rabbit hole of asking my
> Windows networking stack for a Mac address?  This will make a huge
> difference in my CLI startup times for sure.
>
> Perhaps a library like this could be used:
>
> https://github.com/jchambers/fast-uuid
>
> Thanks!
>
> ~Brad
>
> *Developer Advocate*
> *Ortus Solutions, Corp *
>
> E-mail: b...@coldbox.org
> ColdBox Platform: http://www.coldbox.org
> Blog: http://www.codersrevolution.com



-- 
Karl Pauls
karlpa...@gmail.com

-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org



Re: Felix Useradmin as service factory

2018-03-11 Thread David Leangen

Thanks, Neil,

I think the subsystem approach is a bit too heavy, as you pointed out.

Is there a means (which I could eventually submit via a pull request) that 
would allow the Useradmin to be configured as either a factory or a singleton?

Or is it one or the other, period.

The start() method of the Activator code looks like this:

public void start(BundleContext context) throws Exception {
m_context = createServiceContext(context);

// The actual service itself...
UserAdminImpl service = new UserAdminImpl(m_context.m_roleRepository, 
m_context.m_eventDispatcher);

// Register the actual service...
context.registerService(UserAdmin.class.getName(), service, null);

// Start/open all helper classes...
m_context.start();
}

Perhaps packaging as a separate bundle is the answer? So a singleton Useradmin 
bundle, and a factory Useradmin bundle?


Cheers,
=David



> On Feb 13, 2018, at 20:29, Neil Bartlett  wrote:
> 
> I can't think of a way. If a bundle does not provide a service as a
> bundle-scope or prototype-scope service, you cannot force it to provide
> multiple implementations.
> 
> You could go down the subsystems route in order to get multiple copies of
> the UserAdmin bundle installed into the framework. Maybe you should
> consider that as a high-level solution for what sounds like a multi-tenant
> application... but it's very heavyweight if all you want is multiple copies
> of a single service.
> 
> Neil
> 
> On Tue, Feb 13, 2018 at 11:13 AM, David Leangen  wrote:
> 
>> 
>> Hi!
>> 
>> Although my question is probably a more general OSGi question, I thought I
>> would try here first, as it is related to the Felix Useradmin…
>> 
>> I intend to use multiple instances of the Useradmin. The reason is because
>> I want to host multiple (small) enterprise customers in one installation,
>> but I want to ensure safe segregation of user data. The spec seems to imply
>> that there is only one Useradmin, yet I do not see anything in the spec
>> that prohibits multiple instances of the service.
>> 
>> In the Felix implementation, it is provided as a service singleton. In
>> order to do what I want, I ended up embedding the felix implementation in
>> my own bundle and wrapped it with a DS service factory component.
>> 
>> 
>> I don’t like depending on the implementation code.
>> 
>> 
>> Is there a better way?
>> 
>> 
>> Cheers,
>> =David
>> 
>> 
>> -
>> To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
>> For additional commands, e-mail: users-h...@felix.apache.org
>> 
>> 



Re: Felix Useradmin as service factory

2018-02-13 Thread Neil Bartlett
I can't think of a way. If a bundle does not provide a service as a
bundle-scope or prototype-scope service, you cannot force it to provide
multiple implementations.

You could go down the subsystems route in order to get multiple copies of
the UserAdmin bundle installed into the framework. Maybe you should
consider that as a high-level solution for what sounds like a multi-tenant
application... but it's very heavyweight if all you want is multiple copies
of a single service.

Neil

On Tue, Feb 13, 2018 at 11:13 AM, David Leangen  wrote:

>
> Hi!
>
> Although my question is probably a more general OSGi question, I thought I
> would try here first, as it is related to the Felix Useradmin…
>
> I intend to use multiple instances of the Useradmin. The reason is because
> I want to host multiple (small) enterprise customers in one installation,
> but I want to ensure safe segregation of user data. The spec seems to imply
> that there is only one Useradmin, yet I do not see anything in the spec
> that prohibits multiple instances of the service.
>
> In the Felix implementation, it is provided as a service singleton. In
> order to do what I want, I ended up embedding the felix implementation in
> my own bundle and wrapped it with a DS service factory component.
>
>
> I don’t like depending on the implementation code.
>
>
> Is there a better way?
>
>
> Cheers,
> =David
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
> For additional commands, e-mail: users-h...@felix.apache.org
>
>


Re: Felix and JavaFX

2017-12-12 Thread Kerry

Hi Chuck,

No problem, I wasn't aware of the issues you were having i.e. felix not 
exporting the javafx packages by default. In Karaf they are exported by default 
but obviously not everyone wants all the functionality provided by Karaf. 
You've given me the idea to include some integration tests with 'stand-alone' 
Felix and suitable documentation.

If you ever do get the chance to re-visit JavaFX in OSGi your comments would be 
much appreciated (as would from anyone else reading this and is interested.)

Regards
Kerry

On 12/12/17 14:56, Chuck Davis wrote:

Hi Kerry:

Thanks for the note.  Old indeed.  I don't remember anything I learned from 
that project (though I did keep the modules).  I did get it to work by 
including the module somebody mentioned.  It seems so easy, looking at that 
module, I can't understand why Felix doesn't do the export for JavaFX so that 
it's not even an issue -- at least an option that can be turned on or off, 
installed or uninstalled or some such and stop the necessity of all the 
work-arounds on which developers are having to waste their time.

If I revisit OSGi I'll take a look at your project if Felix hasn't fixed the 
issue yet at the time.

Thanks.

CD

On 12/12/2017 05:19 AM, Kerry wrote:

Hi Chuck,

I realise that this is a response to an old message of yours but I have a 
GitHub project that may be of interest to you that brings OSGi to JavaFx.

https://github.com/jtkb/osgifx

It aims to be simpler than Drombler and is agnostic to the OSGi implementation. 
It is still a work in progress but check the examples and integration-test 
modules to see how to use it. I have currently tested it with Apache karaf 
which obviously used Apache Felix but plan to add tests for other 
implementations too.

If you try it out any comments you have or improvements are welcome. Any issues 
also just ask. I'm in the process of improving the documentation at the moment.

Kerry

⁣Sent from BlueMail ​



-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org





-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org



Re: Felix and JavaFX

2017-12-12 Thread Chuck Davis

Karl, thanks for that information.


On 12/12/2017 08:31 AM, Karl Pauls wrote:

Additionally, the JavaFX exports should now be available on java9 ootb
  (assuming the modules are on the module path). As Neil correctly
points out, the reason they are not on older version is exactly that -
we don't know if they are there or not. With java9, we can detect that
(and we do starting with Felix Framework 5.6.10).

regards,

Karl





-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org



Re: Felix and JavaFX

2017-12-12 Thread Karl Pauls
Additionally, the JavaFX exports should now be available on java9 ootb
 (assuming the modules are on the module path). As Neil correctly
points out, the reason they are not on older version is exactly that -
we don't know if they are there or not. With java9, we can detect that
(and we do starting with Felix Framework 5.6.10).

regards,

Karl

On Tue, Dec 12, 2017 at 4:03 PM, Neil Bartlett  wrote:
> That's pretty easy to answer.
>
> Felix by default exports all standard Java SE packages. JavaFX is not part
> of Java SE, it is an extension that is only available on a subset of Java
> implementations.
>
> Neil
>
> On 12 Dec 2017 2:56 pm, "Chuck Davis"  wrote:
>
>> Hi Kerry:
>>
>> Thanks for the note.  Old indeed.  I don't remember anything I learned
>> from that project (though I did keep the modules).  I did get it to work by
>> including the module somebody mentioned.  It seems so easy, looking at that
>> module, I can't understand why Felix doesn't do the export for JavaFX so
>> that it's not even an issue -- at least an option that can be turned on or
>> off, installed or uninstalled or some such and stop the necessity of all
>> the work-arounds on which developers are having to waste their time.
>>
>> If I revisit OSGi I'll take a look at your project if Felix hasn't fixed
>> the issue yet at the time.
>>
>> Thanks.
>>
>> CD
>>
>> On 12/12/2017 05:19 AM, Kerry wrote:
>>
>>> Hi Chuck,
>>>
>>> I realise that this is a response to an old message of yours but I have a
>>> GitHub project that may be of interest to you that brings OSGi to JavaFx.
>>>
>>> https://github.com/jtkb/osgifx
>>>
>>> It aims to be simpler than Drombler and is agnostic to the OSGi
>>> implementation. It is still a work in progress but check the examples and
>>> integration-test modules to see how to use it. I have currently tested it
>>> with Apache karaf which obviously used Apache Felix but plan to add tests
>>> for other implementations too.
>>>
>>> If you try it out any comments you have or improvements are welcome. Any
>>> issues also just ask. I'm in the process of improving the documentation at
>>> the moment.
>>>
>>> Kerry
>>>
>>> ⁣Sent from BlueMail
>>>
>>
>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
>> For additional commands, e-mail: users-h...@felix.apache.org
>>
>>



-- 
Karl Pauls
karlpa...@gmail.com

-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org



Re: Felix and JavaFX

2017-12-12 Thread Neil Bartlett
That's pretty easy to answer.

Felix by default exports all standard Java SE packages. JavaFX is not part
of Java SE, it is an extension that is only available on a subset of Java
implementations.

Neil

On 12 Dec 2017 2:56 pm, "Chuck Davis"  wrote:

> Hi Kerry:
>
> Thanks for the note.  Old indeed.  I don't remember anything I learned
> from that project (though I did keep the modules).  I did get it to work by
> including the module somebody mentioned.  It seems so easy, looking at that
> module, I can't understand why Felix doesn't do the export for JavaFX so
> that it's not even an issue -- at least an option that can be turned on or
> off, installed or uninstalled or some such and stop the necessity of all
> the work-arounds on which developers are having to waste their time.
>
> If I revisit OSGi I'll take a look at your project if Felix hasn't fixed
> the issue yet at the time.
>
> Thanks.
>
> CD
>
> On 12/12/2017 05:19 AM, Kerry wrote:
>
>> Hi Chuck,
>>
>> I realise that this is a response to an old message of yours but I have a
>> GitHub project that may be of interest to you that brings OSGi to JavaFx.
>>
>> https://github.com/jtkb/osgifx
>>
>> It aims to be simpler than Drombler and is agnostic to the OSGi
>> implementation. It is still a work in progress but check the examples and
>> integration-test modules to see how to use it. I have currently tested it
>> with Apache karaf which obviously used Apache Felix but plan to add tests
>> for other implementations too.
>>
>> If you try it out any comments you have or improvements are welcome. Any
>> issues also just ask. I'm in the process of improving the documentation at
>> the moment.
>>
>> Kerry
>>
>> ⁣Sent from BlueMail ​
>>
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
> For additional commands, e-mail: users-h...@felix.apache.org
>
>


Re: Felix and JavaFX

2017-12-12 Thread Chuck Davis

Hi Kerry:

Thanks for the note.  Old indeed.  I don't remember anything I learned 
from that project (though I did keep the modules).  I did get it to work 
by including the module somebody mentioned.  It seems so easy, looking 
at that module, I can't understand why Felix doesn't do the export for 
JavaFX so that it's not even an issue -- at least an option that can be 
turned on or off, installed or uninstalled or some such and stop the 
necessity of all the work-arounds on which developers are having to 
waste their time.


If I revisit OSGi I'll take a look at your project if Felix hasn't fixed 
the issue yet at the time.


Thanks.

CD

On 12/12/2017 05:19 AM, Kerry wrote:

Hi Chuck,

I realise that this is a response to an old message of yours but I have a 
GitHub project that may be of interest to you that brings OSGi to JavaFx.

https://github.com/jtkb/osgifx

It aims to be simpler than Drombler and is agnostic to the OSGi implementation. 
It is still a work in progress but check the examples and integration-test 
modules to see how to use it. I have currently tested it with Apache karaf 
which obviously used Apache Felix but plan to add tests for other 
implementations too.

If you try it out any comments you have or improvements are welcome. Any issues 
also just ask. I'm in the process of improving the documentation at the moment.

Kerry

⁣Sent from BlueMail ​



-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org



Re: Felix and JavaFX

2017-12-12 Thread Kerry
Hi Chuck,

I realise that this is a response to an old message of yours but I have a 
GitHub project that may be of interest to you that brings OSGi to JavaFx.

https://github.com/jtkb/osgifx

It aims to be simpler than Drombler and is agnostic to the OSGi implementation. 
It is still a work in progress but check the examples and integration-test 
modules to see how to use it. I have currently tested it with Apache karaf 
which obviously used Apache Felix but plan to add tests for other 
implementations too.

If you try it out any comments you have or improvements are welcome. Any issues 
also just ask. I'm in the process of improving the documentation at the moment.

Kerry

⁣Sent from BlueMail ​

Re: Re: Felix and Pax Logging

2017-11-30 Thread Milen Dyankov
Have you seen
http://karaf.922171.n3.nabble.com/Using-Log4j-mail-appender-in-Karaf-with-pax-logging-td3180892.html
It's about Karaf but I think the concept should apply to OSGi in general.

On Thu, Nov 30, 2017 at 1:19 PM, daniel stieger <daniel.stie...@gmx.at>
wrote:

>
>
> Hi Milen, hi Erwin,
>
> thanks for your comments. Indeed, i could get pax up and running with the
> config in the file-install dir, the pax itself in the bundles dir.
> Nevertheless, getting the smtp append up and running is realy tricky. I
> read a lot of stuff regarding the javax.activiation and javax.mail
> packages, which are not "out of the box" suitable for osgi..
>
> My struggle wil go on... i will try a couple of things.
>
> Thanks for your help,
> Daniel
>
>
> Gesendet: Mittwoch, 29. November 2017 um 19:49 Uhr
> Von: "Milen Dyankov" <milendyan...@gmail.com>
> An: users@felix.apache.org
> Betreff: Re: Felix and Pax Logging
> I think in order to do that you need FileInstall (
> http://felix.apache.org/documentation/subprojects/
> apache-felix-file-install.html).
> You need to configure it to watch the folder(s) you want via system
> property `felix.fileinstall.dir`.
> Then you can place a file `org.ops4j.pax.logging.cfg` in that folder and it
> should (re)configure Pax Logging.
>
> On Wed, Nov 29, 2017 at 5:42 PM, daniel stieger <daniel.stie...@gmx.at>
> wrote:
>
> >
> > Gentlemen,
> >
> > i feel realy bad to ask such a beginner s question, but after 4 hours i m
> > giving up.
> >
> > I just use a plain felix installation and added the config admin and the
> > pax logging framework (api + service). However, i have not found out how
> to
> > configure pax logging to use a file...
> >
> > * placed org.ops4j.pax.logging.properties file to ./confg
> > * placed org.ops4j.pax.logging.cfg file to ./bundle
> >
> > and to almost all other dirs .. .. i was able to
> > set org.ops4j.pax.logging.DefaultServiceLog.level=ERROR
> > int ./config/config.propeties That did work! also tried to adjust with
> > "org.ops4j.pax.logging.log4j.rootLogger =  " in this very file ..
> > doesn't work either.
> >
> > How could i adjust the pax settings? Is there also a way to check those
> > settings via gogo shell?
> >
> >
> > Any hint apreciated ..
> > Daniel
> >
> >
> > -
> > To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
> > For additional commands, e-mail: users-h...@felix.apache.org
> >
> >
>
>
> --
> http://about.me/milen[http://about.me/milen]
>
> -
> To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
> For additional commands, e-mail: users-h...@felix.apache.org
>
>


-- 
http://about.me/milen


Aw: Re: Felix and Pax Logging

2017-11-30 Thread daniel stieger


Hi Milen, hi Erwin,
 
thanks for your comments. Indeed, i could get pax up and running with the 
config in the file-install dir, the pax itself in the bundles dir. 
Nevertheless, getting the smtp append up and running is realy tricky. I read a 
lot of stuff regarding the javax.activiation and javax.mail packages, which are 
not "out of the box" suitable for osgi.. 
 
My struggle wil go on... i will try a couple of things.
 
Thanks for your help,
Daniel 
 

Gesendet: Mittwoch, 29. November 2017 um 19:49 Uhr
Von: "Milen Dyankov" <milendyan...@gmail.com>
An: users@felix.apache.org
Betreff: Re: Felix and Pax Logging
I think in order to do that you need FileInstall (
http://felix.apache.org/documentation/subprojects/apache-felix-file-install.html).
You need to configure it to watch the folder(s) you want via system
property `felix.fileinstall.dir`.
Then you can place a file `org.ops4j.pax.logging.cfg` in that folder and it
should (re)configure Pax Logging.

On Wed, Nov 29, 2017 at 5:42 PM, daniel stieger <daniel.stie...@gmx.at>
wrote:

>
> Gentlemen,
>
> i feel realy bad to ask such a beginner s question, but after 4 hours i m
> giving up.
>
> I just use a plain felix installation and added the config admin and the
> pax logging framework (api + service). However, i have not found out how to
> configure pax logging to use a file...
>
> * placed org.ops4j.pax.logging.properties file to ./confg
> * placed org.ops4j.pax.logging.cfg file to ./bundle
>
> and to almost all other dirs .. .. i was able to
> set org.ops4j.pax.logging.DefaultServiceLog.level=ERROR
> int ./config/config.propeties That did work! also tried to adjust with
> "org.ops4j.pax.logging.log4j.rootLogger =  " in this very file ..
> doesn't work either.
>
> How could i adjust the pax settings? Is there also a way to check those
> settings via gogo shell?
>
>
> Any hint apreciated ..
> Daniel
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
> For additional commands, e-mail: users-h...@felix.apache.org
>
>


--
http://about.me/milen[http://about.me/milen]

-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org



Re: Felix and Pax Logging

2017-11-29 Thread Milen Dyankov
I think in order to do that you need FileInstall (
http://felix.apache.org/documentation/subprojects/apache-felix-file-install.html).
You need to configure it to watch the folder(s) you want via system
property `felix.fileinstall.dir`.
Then you can place a file `org.ops4j.pax.logging.cfg` in that folder and it
should (re)configure Pax Logging.

On Wed, Nov 29, 2017 at 5:42 PM, daniel stieger 
wrote:

>
> Gentlemen,
>
> i feel realy bad to ask such a beginner s question, but after 4 hours i m
> giving up.
>
> I just use a plain felix installation and added the config admin and the
> pax logging framework (api + service). However, i have not found out how to
> configure pax logging to use a file...
>
> * placed org.ops4j.pax.logging.properties   file to ./confg
> * placed org.ops4j.pax.logging.cfgfile to ./bundle
>
> and to almost all other dirs ..  .. i was able to
> set org.ops4j.pax.logging.DefaultServiceLog.level=ERROR
> int ./config/config.propeties That did work! also tried to adjust with
> "org.ops4j.pax.logging.log4j.rootLogger = " in this very file ..
> doesn't work either.
>
> How could i adjust the pax settings? Is there also a way to check those
> settings via gogo shell?
>
>
> Any hint apreciated ..
> Daniel
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
> For additional commands, e-mail: users-h...@felix.apache.org
>
>


-- 
http://about.me/milen


Re: Felix and Pax Logging

2017-11-29 Thread Erwin Hogeweg
Daniel,

We have these in our startup script:
-Dfelix.fileinstall.dir=../../conf \
-Dlog4j.configuration=file:../../conf/org.ops4j.pax.logging.cfg \

Not even sure anymore if we need them both, but it works perfectly.

Hope this helps,

Erwin

On Nov 29, 2017, at 11:42, daniel stieger 
> wrote:


Gentlemen,

i feel realy bad to ask such a beginner s question, but after 4 hours i m 
giving up.

I just use a plain felix installation and added the config admin and the pax 
logging framework (api + service). However, i have not found out how to 
configure pax logging to use a file...

* placed org.ops4j.pax.logging.properties   file to ./confg
* placed org.ops4j.pax.logging.cfgfile to ./bundle

and to almost all other dirs ..  .. i was able to set 
org.ops4j.pax.logging.DefaultServiceLog.level=ERROR
int ./config/config.propeties That did work! also tried to adjust with
"org.ops4j.pax.logging.log4j.rootLogger = " in this very file .. 
doesn't work either.

How could i adjust the pax settings? Is there also a way to check those 
settings via gogo shell?


Any hint apreciated ..
Daniel


-
To unsubscribe, e-mail: 
users-unsubscr...@felix.apache.org
For additional commands, e-mail: 
users-h...@felix.apache.org


Erwin Hogeweg
CTO
3690 Airport Road
Boca Raton, FL 33431
P. +1 (954) 556-6565
M. +1 (561) 306-7395
F. +1 (561) 948-2730
[Seecago]


Re: Antwort: RE: Felix and JavaFX

2017-07-21 Thread Neil Bartlett
In fact you ARE doing the things explained in Paul Bakker’s article. Or rather, 
Karaf does them for you: it sets up the system bundle exports using the 
contents of jre.properties.

By default Felix (and all other OSGi frameworks that I’m aware of) exports only 
the JavaSE standard packages. JavaFX is not part of JavaSE standard, therefore 
it is not exported by default. Somebody has to add its packages to the system 
bundle exports — you can do this yourself with a single line of code, or you 
can drag in all the dependencies of Karaf. I know which I would choose.

Regards,
Neil

> On 20 Jul 2017, at 13:25, CLEMENT Jean-Philippe 
> <jean-philippe.clem...@fr.thalesgroup.com> wrote:
> 
> Ok, thanks.
> 
> At least with Karaf, there is no such "ClassNotFoundException"  (JavaFX 
> packages must declared in the jre.properties file). I don't use things 
> explained in Paul's article.
> 
> I just need the initialize() of the class below to be called within a 
> singleton bundle. That bundle should be started before any other which uses 
> JavaFX. Then there is no more "primary window" and any bundle can show 
> whatever things it needs.
> 
> public final class FXInitializer extends Application {
>private static BlockingQueue sync;
> 
>/**
> * Initializes the FX windowing system.
> *
> * @throws InterruptedException
> * If initialization was cancelled due to program exit
> */
>public static FXInitializer initialize() throws InterruptedException {
>return initialize(new String[0]);
>}
> 
>/**
> * Initializes the FX windowing system.
> *
> * @param a
> *Arguments as gave to the "main" application
> * @throws InterruptedException
> * If initialization was cancelled due to program exit
> */
>public static FXInitializer initialize(final String... a) throws 
> InterruptedException {
>try {
>Platform.setImplicitExit(false);
>sync = new SynchronousQueue<>();
>new Thread(() -> FXInitializer.launch(FXInitializer.class, 
> a)).start();
>return sync.take();
>} finally {
>sync = null;
>}
>}
> 
>@Override
>public void start(final Stage stage) throws InterruptedException {
>stage.hide();
>sync.put(this);
>    }
> }
> 
> JP
> 
> 
> -Message d'origine-
> De : marc.schle...@sdv-it.de [mailto:marc.schle...@sdv-it.de] 
> Envoyé : jeudi 20 juillet 2017 13:50
> À : users@felix.apache.org
> Objet : Antwort: RE: Felix and JavaFX
> 
> I think you are refering to this one
> 
> http://paulonjava.blogspot.de/2014/11/making-javafx-better-with-osgi.html
> 
> regards
> Marc
> 
> 
> Von:CLEMENT Jean-Philippe <jean-philippe.clem...@fr.thalesgroup.com>
> An: "users@felix.apache.org" <users@felix.apache.org>, 
> Datum:  20.07.2017 10:26
> Betreff:RE: Felix and JavaFX
> 
> 
> 
> Sorry, I didn't find Paul's article. From my point of view there is no issue 
> with JavaFX 8 (also succeeded with Java 9). Just the tiny workaround in order 
> to start the JavaFX engine - which is a bundle containing a single class 
> class with few lines of code.
> 
> Could you please remind me the link to Paul's article?
> 
> Regards,
> JP
> 
> -Message d'origine-
> De : Chuck Davis [mailto:cjgun...@gmail.com] Envoyé : jeudi 20 juillet 2017 
> 05:32 À : users@felix.apache.org Objet : Re: Felix and JavaFX
> 
> All the ones Paul's article delineates.
> 
> On Tue, Jul 18, 2017 at 8:12 AM, CLEMENT Jean-Philippe < 
> jean-philippe.clem...@fr.thalesgroup.com> wrote:
> 
>> Paul?
>> 
>> I just replied to your initial question "I spent most of the day 
>> yesterday googling to find out if there is a way to build a JavaFX 
>> desktop application based upon Felix..."
>> 
>> Well, which problem are you experiencing with JavaFX?
>> 
>> JP
>> 
>> -Message d'origine-
>> De : Chuck Davis [mailto:cjgun...@gmail.com] Envoyé : lundi 17 juillet
>> 2017 18:41 À : users@felix.apache.org Objet : Re: Felix and JavaFX
>> 
>> JP, are you doing the same thing Paul outlines in his article?  If 
>> you've taken a different approach can you share it for the benefit of 
>> all of us following this thread?
>> 
>> Thanks.
>> 
>> On Mon, Jul 17, 2017 at 12:55 AM, CLEMENT Jean-Philippe < 
>> jean-philippe.clem...@fr.thalesgroup.com> wrote:
>> 
>>> Hi,
>>> 
>>> We are making OSGi deskt

Re: Antwort: RE: Felix and JavaFX

2017-07-21 Thread Chuck Davis
JP:

Thanks for the additional information.  I've seen some indication that the
Felix team are considering how to handle the JavaFX issues as well.
Perhaps it is time to investigate Karaf further -- but it adds a lot of
additional capabilities that a client doesn't actually need if I understand
correctly.   When I get back to programming I'll have to investigate
further the options offered by Karaf.  Right now I'm concentrating on
getting my knee replacement to respond to therapy.  Narcotics make me feel
and act loopy so best I absent myself for a while.  But I suspect I'm not
the only one interested in this subject and I suppose others will chime in
as time passes.

On Thu, Jul 20, 2017 at 5:25 AM, CLEMENT Jean-Philippe <
jean-philippe.clem...@fr.thalesgroup.com> wrote:

> Ok, thanks.
>
> At least with Karaf, there is no such "ClassNotFoundException"  (JavaFX
> packages must declared in the jre.properties file). I don't use things
> explained in Paul's article.
>
> I just need the initialize() of the class below to be called within a
> singleton bundle. That bundle should be started before any other which uses
> JavaFX. Then there is no more "primary window" and any bundle can show
> whatever things it needs.
>
> public final class FXInitializer extends Application {
> private static BlockingQueue sync;
>
> /**
>  * Initializes the FX windowing system.
>  *
>  * @throws InterruptedException
>  * If initialization was cancelled due to program exit
>  */
> public static FXInitializer initialize() throws InterruptedException {
> return initialize(new String[0]);
> }
>
> /**
>  * Initializes the FX windowing system.
>  *
>  * @param a
>  *Arguments as gave to the "main" application
>  * @throws InterruptedException
>  * If initialization was cancelled due to program exit
>  */
> public static FXInitializer initialize(final String... a) throws
> InterruptedException {
> try {
> Platform.setImplicitExit(false);
> sync = new SynchronousQueue<>();
> new Thread(() -> FXInitializer.launch(FXInitializer.class,
> a)).start();
> return sync.take();
> } finally {
> sync = null;
> }
> }
>
> @Override
> public void start(final Stage stage) throws InterruptedException {
> stage.hide();
> sync.put(this);
> }
> }
>
> JP
>
>
>
>


RE: Antwort: RE: Felix and JavaFX

2017-07-20 Thread CLEMENT Jean-Philippe
Ok, thanks.

At least with Karaf, there is no such "ClassNotFoundException"  (JavaFX 
packages must declared in the jre.properties file). I don't use things 
explained in Paul's article.

I just need the initialize() of the class below to be called within a singleton 
bundle. That bundle should be started before any other which uses JavaFX. Then 
there is no more "primary window" and any bundle can show whatever things it 
needs.

public final class FXInitializer extends Application {
private static BlockingQueue sync;

/**
 * Initializes the FX windowing system.
 *
 * @throws InterruptedException
 * If initialization was cancelled due to program exit
 */
public static FXInitializer initialize() throws InterruptedException {
return initialize(new String[0]);
}

/**
 * Initializes the FX windowing system.
 *
 * @param a
 *Arguments as gave to the "main" application
 * @throws InterruptedException
 * If initialization was cancelled due to program exit
 */
public static FXInitializer initialize(final String... a) throws 
InterruptedException {
try {
Platform.setImplicitExit(false);
sync = new SynchronousQueue<>();
new Thread(() -> FXInitializer.launch(FXInitializer.class, 
a)).start();
return sync.take();
} finally {
sync = null;
}
}

@Override
public void start(final Stage stage) throws InterruptedException {
stage.hide();
sync.put(this);
}
}

JP


-Message d'origine-
De : marc.schle...@sdv-it.de [mailto:marc.schle...@sdv-it.de] 
Envoyé : jeudi 20 juillet 2017 13:50
À : users@felix.apache.org
Objet : Antwort: RE: Felix and JavaFX

I think you are refering to this one

http://paulonjava.blogspot.de/2014/11/making-javafx-better-with-osgi.html

regards
Marc


Von:CLEMENT Jean-Philippe <jean-philippe.clem...@fr.thalesgroup.com>
An: "users@felix.apache.org" <users@felix.apache.org>, 
Datum:  20.07.2017 10:26
Betreff:RE: Felix and JavaFX



Sorry, I didn't find Paul's article. From my point of view there is no issue 
with JavaFX 8 (also succeeded with Java 9). Just the tiny workaround in order 
to start the JavaFX engine - which is a bundle containing a single class class 
with few lines of code.

Could you please remind me the link to Paul's article?

Regards,
JP

-Message d'origine-
De : Chuck Davis [mailto:cjgun...@gmail.com] Envoyé : jeudi 20 juillet 2017 
05:32 À : users@felix.apache.org Objet : Re: Felix and JavaFX

All the ones Paul's article delineates.

On Tue, Jul 18, 2017 at 8:12 AM, CLEMENT Jean-Philippe < 
jean-philippe.clem...@fr.thalesgroup.com> wrote:

> Paul?
>
> I just replied to your initial question "I spent most of the day 
> yesterday googling to find out if there is a way to build a JavaFX 
> desktop application based upon Felix..."
>
> Well, which problem are you experiencing with JavaFX?
>
> JP
>
> -Message d'origine-
> De : Chuck Davis [mailto:cjgun...@gmail.com] Envoyé : lundi 17 juillet
> 2017 18:41 À : users@felix.apache.org Objet : Re: Felix and JavaFX
>
> JP, are you doing the same thing Paul outlines in his article?  If 
> you've taken a different approach can you share it for the benefit of 
> all of us following this thread?
>
> Thanks.
>
> On Mon, Jul 17, 2017 at 12:55 AM, CLEMENT Jean-Philippe < 
> jean-philippe.clem...@fr.thalesgroup.com> wrote:
>
> > Hi,
> >
> > We are making OSGi desktop applications with JavaFX without any issue.
> > We do not rely on Eclipse or Equinox. We are using Karaf and 
> > maven-bundle-plugin.
> >
> > There is only a small workaround for startup with a special bundle 
> > which is a fake "Application" in order to start JavaFX engine.
> >
> > JP
> >
> > -Message d'origine-
> > De : Chuck Davis [mailto:cjgun...@gmail.com] Envoyé : dimanche 9 
> > juillet 2017 18:17 À : users@felix.apache.org Objet : Re: Felix and 
> > JavaFX
> >
> > I spent most of the day yesterday googling to find out if there is a 
> > way to build a JavaFX desktop application based upon Felix.  So far 
> > I've not found anything that advises how to do this or if it is even 
> > possible at this stage of development.
> >
> > Can anybody point me to an article that explains how, if this can be
> done?
> >
> > TIA.
> >
> > 
> > - To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
> > For additional commands, e-mail: users-h...@felix.apache.org
> >
>

-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org


-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org



Antwort: RE: Felix and JavaFX

2017-07-20 Thread marc . schlegel
I think you are refering to this one

http://paulonjava.blogspot.de/2014/11/making-javafx-better-with-osgi.html

regards
Marc


Von:CLEMENT Jean-Philippe <jean-philippe.clem...@fr.thalesgroup.com>
An: "users@felix.apache.org" <users@felix.apache.org>, 
Datum:  20.07.2017 10:26
Betreff:RE: Felix and JavaFX



Sorry, I didn't find Paul's article. From my point of view there is no 
issue with JavaFX 8 (also succeeded with Java 9). Just the tiny workaround 
in order to start the JavaFX engine - which is a bundle containing a 
single class class with few lines of code.

Could you please remind me the link to Paul's article?

Regards,
JP

-Message d'origine-
De : Chuck Davis [mailto:cjgun...@gmail.com] 
Envoyé : jeudi 20 juillet 2017 05:32
À : users@felix.apache.org
Objet : Re: Felix and JavaFX

All the ones Paul's article delineates.

On Tue, Jul 18, 2017 at 8:12 AM, CLEMENT Jean-Philippe < 
jean-philippe.clem...@fr.thalesgroup.com> wrote:

> Paul?
>
> I just replied to your initial question "I spent most of the day 
> yesterday googling to find out if there is a way to build a JavaFX 
> desktop application based upon Felix..."
>
> Well, which problem are you experiencing with JavaFX?
>
> JP
>
> -Message d'origine-
> De : Chuck Davis [mailto:cjgun...@gmail.com] Envoyé : lundi 17 juillet 
> 2017 18:41 À : users@felix.apache.org Objet : Re: Felix and JavaFX
>
> JP, are you doing the same thing Paul outlines in his article?  If 
> you've taken a different approach can you share it for the benefit of 
> all of us following this thread?
>
> Thanks.
>
> On Mon, Jul 17, 2017 at 12:55 AM, CLEMENT Jean-Philippe < 
> jean-philippe.clem...@fr.thalesgroup.com> wrote:
>
> > Hi,
> >
> > We are making OSGi desktop applications with JavaFX without any issue.
> > We do not rely on Eclipse or Equinox. We are using Karaf and 
> > maven-bundle-plugin.
> >
> > There is only a small workaround for startup with a special bundle 
> > which is a fake "Application" in order to start JavaFX engine.
> >
> > JP
> >
> > -Message d'origine-
> > De : Chuck Davis [mailto:cjgun...@gmail.com] Envoyé : dimanche 9 
> > juillet 2017 18:17 À : users@felix.apache.org Objet : Re: Felix and 
> > JavaFX
> >
> > I spent most of the day yesterday googling to find out if there is a 
> > way to build a JavaFX desktop application based upon Felix.  So far 
> > I've not found anything that advises how to do this or if it is even 
> > possible at this stage of development.
> >
> > Can anybody point me to an article that explains how, if this can be
> done?
> >
> > TIA.
> >
> > 
> > - To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
> > For additional commands, e-mail: users-h...@felix.apache.org
> >
>

-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org



RE: Felix and JavaFX

2017-07-20 Thread CLEMENT Jean-Philippe
Sorry, I didn't find Paul's article. From my point of view there is no issue 
with JavaFX 8 (also succeeded with Java 9). Just the tiny workaround in order 
to start the JavaFX engine - which is a bundle containing a single class class 
with few lines of code.

Could you please remind me the link to Paul's article?

Regards,
JP

-Message d'origine-
De : Chuck Davis [mailto:cjgun...@gmail.com] 
Envoyé : jeudi 20 juillet 2017 05:32
À : users@felix.apache.org
Objet : Re: Felix and JavaFX

All the ones Paul's article delineates.

On Tue, Jul 18, 2017 at 8:12 AM, CLEMENT Jean-Philippe < 
jean-philippe.clem...@fr.thalesgroup.com> wrote:

> Paul?
>
> I just replied to your initial question "I spent most of the day 
> yesterday googling to find out if there is a way to build a JavaFX 
> desktop application based upon Felix..."
>
> Well, which problem are you experiencing with JavaFX?
>
> JP
>
> -Message d'origine-
> De : Chuck Davis [mailto:cjgun...@gmail.com] Envoyé : lundi 17 juillet 
> 2017 18:41 À : users@felix.apache.org Objet : Re: Felix and JavaFX
>
> JP, are you doing the same thing Paul outlines in his article?  If 
> you've taken a different approach can you share it for the benefit of 
> all of us following this thread?
>
> Thanks.
>
> On Mon, Jul 17, 2017 at 12:55 AM, CLEMENT Jean-Philippe < 
> jean-philippe.clem...@fr.thalesgroup.com> wrote:
>
> > Hi,
> >
> > We are making OSGi desktop applications with JavaFX without any issue.
> > We do not rely on Eclipse or Equinox. We are using Karaf and 
> > maven-bundle-plugin.
> >
> > There is only a small workaround for startup with a special bundle 
> > which is a fake "Application" in order to start JavaFX engine.
> >
> > JP
> >
> > -Message d'origine-
> > De : Chuck Davis [mailto:cjgun...@gmail.com] Envoyé : dimanche 9 
> > juillet 2017 18:17 À : users@felix.apache.org Objet : Re: Felix and 
> > JavaFX
> >
> > I spent most of the day yesterday googling to find out if there is a 
> > way to build a JavaFX desktop application based upon Felix.  So far 
> > I've not found anything that advises how to do this or if it is even 
> > possible at this stage of development.
> >
> > Can anybody point me to an article that explains how, if this can be
> done?
> >
> > TIA.
> >
> > 
> > - To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
> > For additional commands, e-mail: users-h...@felix.apache.org
> >
>

-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org


Re: Felix and JavaFX

2017-07-19 Thread Chuck Davis
All the ones Paul's article delineates.

On Tue, Jul 18, 2017 at 8:12 AM, CLEMENT Jean-Philippe <
jean-philippe.clem...@fr.thalesgroup.com> wrote:

> Paul?
>
> I just replied to your initial question "I spent most of the day yesterday
> googling to find out if there is a way to build a JavaFX desktop
> application based upon Felix..."
>
> Well, which problem are you experiencing with JavaFX?
>
> JP
>
> -Message d'origine-
> De : Chuck Davis [mailto:cjgun...@gmail.com]
> Envoyé : lundi 17 juillet 2017 18:41
> À : users@felix.apache.org
> Objet : Re: Felix and JavaFX
>
> JP, are you doing the same thing Paul outlines in his article?  If you've
> taken a different approach can you share it for the benefit of all of us
> following this thread?
>
> Thanks.
>
> On Mon, Jul 17, 2017 at 12:55 AM, CLEMENT Jean-Philippe <
> jean-philippe.clem...@fr.thalesgroup.com> wrote:
>
> > Hi,
> >
> > We are making OSGi desktop applications with JavaFX without any issue.
> > We do not rely on Eclipse or Equinox. We are using Karaf and
> > maven-bundle-plugin.
> >
> > There is only a small workaround for startup with a special bundle
> > which is a fake "Application" in order to start JavaFX engine.
> >
> > JP
> >
> > -Message d'origine-
> > De : Chuck Davis [mailto:cjgun...@gmail.com] Envoyé : dimanche 9
> > juillet 2017 18:17 À : users@felix.apache.org Objet : Re: Felix and
> > JavaFX
> >
> > I spent most of the day yesterday googling to find out if there is a
> > way to build a JavaFX desktop application based upon Felix.  So far
> > I've not found anything that advises how to do this or if it is even
> > possible at this stage of development.
> >
> > Can anybody point me to an article that explains how, if this can be
> done?
> >
> > TIA.
> >
> > -
> > To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
> > For additional commands, e-mail: users-h...@felix.apache.org
> >
>


RE: Felix and JavaFX

2017-07-18 Thread CLEMENT Jean-Philippe
Paul?

I just replied to your initial question "I spent most of the day yesterday 
googling to find out if there is a way to build a JavaFX desktop application 
based upon Felix..."

Well, which problem are you experiencing with JavaFX?

JP

-Message d'origine-
De : Chuck Davis [mailto:cjgun...@gmail.com] 
Envoyé : lundi 17 juillet 2017 18:41
À : users@felix.apache.org
Objet : Re: Felix and JavaFX

JP, are you doing the same thing Paul outlines in his article?  If you've taken 
a different approach can you share it for the benefit of all of us following 
this thread?

Thanks.

On Mon, Jul 17, 2017 at 12:55 AM, CLEMENT Jean-Philippe < 
jean-philippe.clem...@fr.thalesgroup.com> wrote:

> Hi,
>
> We are making OSGi desktop applications with JavaFX without any issue. 
> We do not rely on Eclipse or Equinox. We are using Karaf and 
> maven-bundle-plugin.
>
> There is only a small workaround for startup with a special bundle 
> which is a fake "Application" in order to start JavaFX engine.
>
> JP
>
> -Message d'origine-
> De : Chuck Davis [mailto:cjgun...@gmail.com] Envoyé : dimanche 9 
> juillet 2017 18:17 À : users@felix.apache.org Objet : Re: Felix and 
> JavaFX
>
> I spent most of the day yesterday googling to find out if there is a 
> way to build a JavaFX desktop application based upon Felix.  So far 
> I've not found anything that advises how to do this or if it is even 
> possible at this stage of development.
>
> Can anybody point me to an article that explains how, if this can be done?
>
> TIA.
>
> -
> To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
> For additional commands, e-mail: users-h...@felix.apache.org
>


Re: Felix and JavaFX

2017-07-17 Thread Chuck Davis
JP, are you doing the same thing Paul outlines in his article?  If you've
taken a different approach can you share it for the benefit of all of us
following this thread?

Thanks.

On Mon, Jul 17, 2017 at 12:55 AM, CLEMENT Jean-Philippe <
jean-philippe.clem...@fr.thalesgroup.com> wrote:

> Hi,
>
> We are making OSGi desktop applications with JavaFX without any issue. We
> do not rely on Eclipse or Equinox. We are using Karaf and
> maven-bundle-plugin.
>
> There is only a small workaround for startup with a special bundle which
> is a fake "Application" in order to start JavaFX engine.
>
> JP
>
> -Message d'origine-
> De : Chuck Davis [mailto:cjgun...@gmail.com]
> Envoyé : dimanche 9 juillet 2017 18:17
> À : users@felix.apache.org
> Objet : Re: Felix and JavaFX
>
> I spent most of the day yesterday googling to find out if there is a way
> to build a JavaFX desktop application based upon Felix.  So far I've not
> found anything that advises how to do this or if it is even possible at
> this stage of development.
>
> Can anybody point me to an article that explains how, if this can be done?
>
> TIA.
>
> -
> To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
> For additional commands, e-mail: users-h...@felix.apache.org
>


RE: Felix and JavaFX

2017-07-17 Thread CLEMENT Jean-Philippe
Hi,

We are making OSGi desktop applications with JavaFX without any issue. We do 
not rely on Eclipse or Equinox. We are using Karaf and maven-bundle-plugin.

There is only a small workaround for startup with a special bundle which is a 
fake "Application" in order to start JavaFX engine.

JP

-Message d'origine-
De : Chuck Davis [mailto:cjgun...@gmail.com] 
Envoyé : dimanche 9 juillet 2017 18:17
À : users@felix.apache.org
Objet : Re: Felix and JavaFX

I spent most of the day yesterday googling to find out if there is a way to 
build a JavaFX desktop application based upon Felix.  So far I've not found 
anything that advises how to do this or if it is even possible at this stage of 
development.

Can anybody point me to an article that explains how, if this can be done?

TIA.

-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org


Re: Felix and JavaFX

2017-07-11 Thread Oliver Lietz
On Sunday 09 July 2017 15:50:51 Chuck Davis wrote:
> Hi Neil:

Hi Chuck,

> I'm just beginning my investigation of OSGi because I want to do things
> that it sounds like OSGi was designed to do and I'm too lazy to reinvent
> the wheel if it already exists.  I develop desktop business applications
> and my development style is already quite modular in concept but I want to
> get to the next level of modularity.
> 
> Paul's article hits the nail on the head with what I am hung up on in the
> "Importing JavaFX Packages" subsection.  That is the first problem and Paul
> lays out that there are more ahead before/if I achieve victory.

see https://issues.apache.org/jira/browse/FELIX-5558

You basically setup the OSGi framework in your main method, register screen 
and primary stage as services in (Application) start method and shutdown the 
framework in (Application) stop method. The hardest part is to get all third-
party dependencies playing nice.

I'm using maven-bundle-plugin and javafx-maven-plugin.

> I've done a bit more reading and it sounds like the Bndtools he endorses
> from Eclipse is just a more user-friendly version of Bnd so maybe I can
> find a way to use the Bnd tool directly.many challenges lie ahead it
> sound like.
> 
> Thanks for your interest.

Regards,
O.

> On Sun, Jul 9, 2017 at 10:24 AM, Neil Bartlett  wrote:
> > Hi Chuck,
> > 
> > Using Eclipse as an IDE does not tie you into using Equinox for your
> > runtime.
> > 
> > I don’t know much about JavaFX but what is the actual problem you are
> > experiencing with it? Isn’t it just a library like any other?
> > 
> > Neil
> > 
> > 
> > 
> > -
> > To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
> > For additional commands, e-mail: users-h...@felix.apache.org


-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org



Re: Felix and JavaFX

2017-07-09 Thread Neil Bartlett
Hi Chuck,

I read through Paul’s article and it still looks very relevant and well written.

You don’t really want to use bnd directly. It’s a low-level tool… it would be 
like using javac and the jar tool directly from the command line, rather than 
via a build system. Does anybody still do that?? Fortunately the Maven 
integration for bnd has improved markedly since Paul’s article was written, you 
can read about the suite of plugins available here: 
https://github.com/bndtools/bnd/tree/master/maven 


Regards,
Neil


> On 9 Jul 2017, at 23:50, Chuck Davis  wrote:
> 
> Hi Neil:
> 
> I'm just beginning my investigation of OSGi because I want to do things
> that it sounds like OSGi was designed to do and I'm too lazy to reinvent
> the wheel if it already exists.  I develop desktop business applications
> and my development style is already quite modular in concept but I want to
> get to the next level of modularity.
> 
> Paul's article hits the nail on the head with what I am hung up on in the
> "Importing JavaFX Packages" subsection.  That is the first problem and Paul
> lays out that there are more ahead before/if I achieve victory.
> 
> I've done a bit more reading and it sounds like the Bndtools he endorses
> from Eclipse is just a more user-friendly version of Bnd so maybe I can
> find a way to use the Bnd tool directly.many challenges lie ahead it
> sound like.
> 
> Thanks for your interest.
> 
> 
> 
> On Sun, Jul 9, 2017 at 10:24 AM, Neil Bartlett  wrote:
> 
>> Hi Chuck,
>> 
>> Using Eclipse as an IDE does not tie you into using Equinox for your
>> runtime.
>> 
>> I don’t know much about JavaFX but what is the actual problem you are
>> experiencing with it? Isn’t it just a library like any other?
>> 
>> Neil
>> 
>> 
>> 
>> -
>> To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
>> For additional commands, e-mail: users-h...@felix.apache.org
>> 
>> 



Re: Felix and JavaFX

2017-07-09 Thread Chuck Davis
Thanks Renato.  I'll investigate that project...sounds like a real time
saver.  At least get me to the next problem that Paul's article lays out...

On Sun, Jul 9, 2017 at 3:00 PM, Paulo Renato de Athaydes <
renatoathay...@hotmail.com> wrote:

> It's hard because Felix does not (or did not used to at least) export the
> javafx classes to bundles.
>
>
> This project fixes that:
>
>
> https://github.com/edvin/javafx-osgi
>
> [https://avatars0.githubusercontent.com/u/977035?v=3=400]<https://
> github.com/edvin/javafx-osgi>
>
> edvin/javafx-osgi<https://github.com/edvin/javafx-osgi>
> github.com
> javafx-osgi - JavaFX 8.0 OSGi bundle to support JavaFX in an OSGi container
>
>
>
>
>
> Hope it helps,
>
>
> Renato
>
>
> 
> De: Neil Bartlett <njbartl...@gmail.com>
> Enviado: segunda-feira, 10 de julho de 2017 03:24
> Para: users@felix.apache.org
> Assunto: Re: Felix and JavaFX
>
> Hi Chuck,
>
> Using Eclipse as an IDE does not tie you into using Equinox for your
> runtime.
>
> I don’t know much about JavaFX but what is the actual problem you are
> experiencing with it? Isn’t it just a library like any other?
>
> Neil
>
> > On 9 Jul 2017, at 18:18, Chuck Davis <cjgun...@gmail.com> wrote:
> >
> > Thanks Bram.  I actually read that yesterday but unfortunately it's
> Eclipse
> > related and that ties me to Equinox.  So far I haven't found anything to
> > like about Eclipse and I want true OSGi compatibility -- not tied to a
> > specific IDE or OSGi implementation.  At least the Eclipse people are
> > wrestling with the issue and that is a good sign.  I've done some of the
> > e(fx)clipse tutorials as well but, again, it makes me dependent on
> specific
> > implementations.
> >
> > I'm going to re-read the article and see if I've missed something
> > though.
> >
> > Again, thanks for your interest.
> >
> >
> > On Sun, Jul 9, 2017 at 10:10 AM, Bram Pouwelse <b...@pouwelse.com>
> wrote:
> >
> >> Hi Chuck,
> >>
> >> It's an old post but could be what you're looking for
> >>
> >> http://paulonjava.blogspot.nl/2014/11/making-javafx-better-
> Java, OSGi, Amdatu and a bit of JavaScript<http://paulonjava.
> blogspot.nl/2014/11/making-javafx-better->
> paulonjava.blogspot.nl
> Blog about creating modular Java applications with OSGi, Amdatu and a bit
> of JavaScript.
>
>
>
> >> with-osgi.html?m=1
> >>
> >> Regards,
> >> Bram
> >>
> >> Op 9 jul. 2017 19:05 schreef "Chuck Davis" <cjgun...@gmail.com>:
> >>
> >>> Thanks Thomas.  I guess there must be a way.  I wish he would have just
> >>> explained how to use JavaFX with Felix rather than develop a whole
> third
> >>> party development environment.
> >>>
> >>> On Sun, Jul 9, 2017 at 9:19 AM, Thomas Driessen <
> >>> thomas.dries...@ds-lab.org>
> >>> wrote:
> >>>
> >>>> Hi Chuck,
> >>>>
> >>>> maybe this Project is an interesting starting Point for you:
> >>>> http://www.drombler.org
> Drombler<http://www.drombler.org/>
> www.drombler.org
> This is the home of the Open Source projects maintained by Drombler.
> Drombler FX. Drombler FX - the modular application framework for JavaFX.
> Drombler ACP
>
>
>
> >>>>
> >>>> Kind regards,
> >>>> Thomas
> >>>>
> >>>> Am 09.07.2017 18:17 schrieb "Chuck Davis" <cjgun...@gmail.com>:
> >>>>
> >>>>> I spent most of the day yesterday googling to find out if there is a
> >>> way
> >>>> to
> >>>>> build a JavaFX desktop application based upon Felix.  So far I've not
> >>>> found
> >>>>> anything that advises how to do this or if it is even possible at
> >> this
> >>>>> stage of development.
> >>>>>
> >>>>> Can anybody point me to an article that explains how, if this can be
> >>>> done?
> >>>>>
> >>>>> TIA.
> >>>>>
> >>>>
> >>>
> >>
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
> For additional commands, e-mail: users-h...@felix.apache.org
>
>


Re: Felix and JavaFX

2017-07-09 Thread Paulo Renato de Athaydes
It's hard because Felix does not (or did not used to at least) export the 
javafx classes to bundles.


This project fixes that:


https://github.com/edvin/javafx-osgi

[https://avatars0.githubusercontent.com/u/977035?v=3=400]<https://github.com/edvin/javafx-osgi>

edvin/javafx-osgi<https://github.com/edvin/javafx-osgi>
github.com
javafx-osgi - JavaFX 8.0 OSGi bundle to support JavaFX in an OSGi container





Hope it helps,


Renato



De: Neil Bartlett <njbartl...@gmail.com>
Enviado: segunda-feira, 10 de julho de 2017 03:24
Para: users@felix.apache.org
Assunto: Re: Felix and JavaFX

Hi Chuck,

Using Eclipse as an IDE does not tie you into using Equinox for your runtime.

I don’t know much about JavaFX but what is the actual problem you are 
experiencing with it? Isn’t it just a library like any other?

Neil

> On 9 Jul 2017, at 18:18, Chuck Davis <cjgun...@gmail.com> wrote:
>
> Thanks Bram.  I actually read that yesterday but unfortunately it's Eclipse
> related and that ties me to Equinox.  So far I haven't found anything to
> like about Eclipse and I want true OSGi compatibility -- not tied to a
> specific IDE or OSGi implementation.  At least the Eclipse people are
> wrestling with the issue and that is a good sign.  I've done some of the
> e(fx)clipse tutorials as well but, again, it makes me dependent on specific
> implementations.
>
> I'm going to re-read the article and see if I've missed something
> though.
>
> Again, thanks for your interest.
>
>
> On Sun, Jul 9, 2017 at 10:10 AM, Bram Pouwelse <b...@pouwelse.com> wrote:
>
>> Hi Chuck,
>>
>> It's an old post but could be what you're looking for
>>
>> http://paulonjava.blogspot.nl/2014/11/making-javafx-better-
Java, OSGi, Amdatu and a bit of 
JavaScript<http://paulonjava.blogspot.nl/2014/11/making-javafx-better->
paulonjava.blogspot.nl
Blog about creating modular Java applications with OSGi, Amdatu and a bit of 
JavaScript.



>> with-osgi.html?m=1
>>
>> Regards,
>> Bram
>>
>> Op 9 jul. 2017 19:05 schreef "Chuck Davis" <cjgun...@gmail.com>:
>>
>>> Thanks Thomas.  I guess there must be a way.  I wish he would have just
>>> explained how to use JavaFX with Felix rather than develop a whole third
>>> party development environment.
>>>
>>> On Sun, Jul 9, 2017 at 9:19 AM, Thomas Driessen <
>>> thomas.dries...@ds-lab.org>
>>> wrote:
>>>
>>>> Hi Chuck,
>>>>
>>>> maybe this Project is an interesting starting Point for you:
>>>> http://www.drombler.org
Drombler<http://www.drombler.org/>
www.drombler.org
This is the home of the Open Source projects maintained by Drombler. Drombler 
FX. Drombler FX - the modular application framework for JavaFX. Drombler ACP



>>>>
>>>> Kind regards,
>>>> Thomas
>>>>
>>>> Am 09.07.2017 18:17 schrieb "Chuck Davis" <cjgun...@gmail.com>:
>>>>
>>>>> I spent most of the day yesterday googling to find out if there is a
>>> way
>>>> to
>>>>> build a JavaFX desktop application based upon Felix.  So far I've not
>>>> found
>>>>> anything that advises how to do this or if it is even possible at
>> this
>>>>> stage of development.
>>>>>
>>>>> Can anybody point me to an article that explains how, if this can be
>>>> done?
>>>>>
>>>>> TIA.
>>>>>
>>>>
>>>
>>


-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org



Re: Felix and JavaFX

2017-07-09 Thread Bram Pouwelse
Hi Chuck,

Had another look as I would've been supirised if Paul was using Equinox ;)
but I don't see anything related to that, and the sample on that's on
GitHub runs on Felix [1]

So Eclipse (with Bndtools) is only used as IDE  and as Niel already
mentioned that doesn't force you to use Equinox

Regards,
Bram

1:
https://github.com/paulbakker/javafx-osgi-example/blob/master/run/demo.bndrun

On Sun, Jul 9, 2017 at 7:24 PM Neil Bartlett  wrote:

> Hi Chuck,
>
> Using Eclipse as an IDE does not tie you into using Equinox for your
> runtime.
>
> I don’t know much about JavaFX but what is the actual problem you are
> experiencing with it? Isn’t it just a library like any other?
>
> Neil
>
> > On 9 Jul 2017, at 18:18, Chuck Davis  wrote:
> >
> > Thanks Bram.  I actually read that yesterday but unfortunately it's
> Eclipse
> > related and that ties me to Equinox.  So far I haven't found anything to
> > like about Eclipse and I want true OSGi compatibility -- not tied to a
> > specific IDE or OSGi implementation.  At least the Eclipse people are
> > wrestling with the issue and that is a good sign.  I've done some of the
> > e(fx)clipse tutorials as well but, again, it makes me dependent on
> specific
> > implementations.
> >
> > I'm going to re-read the article and see if I've missed something
> > though.
> >
> > Again, thanks for your interest.
> >
> >
> > On Sun, Jul 9, 2017 at 10:10 AM, Bram Pouwelse 
> wrote:
> >
> >> Hi Chuck,
> >>
> >> It's an old post but could be what you're looking for
> >>
> >> http://paulonjava.blogspot.nl/2014/11/making-javafx-better-
> >> with-osgi.html?m=1
> >>
> >> Regards,
> >> Bram
> >>
> >> Op 9 jul. 2017 19:05 schreef "Chuck Davis" :
> >>
> >>> Thanks Thomas.  I guess there must be a way.  I wish he would have just
> >>> explained how to use JavaFX with Felix rather than develop a whole
> third
> >>> party development environment.
> >>>
> >>> On Sun, Jul 9, 2017 at 9:19 AM, Thomas Driessen <
> >>> thomas.dries...@ds-lab.org>
> >>> wrote:
> >>>
>  Hi Chuck,
> 
>  maybe this Project is an interesting starting Point for you:
>  http://www.drombler.org
> 
>  Kind regards,
>  Thomas
> 
>  Am 09.07.2017 18:17 schrieb "Chuck Davis" :
> 
> > I spent most of the day yesterday googling to find out if there is a
> >>> way
>  to
> > build a JavaFX desktop application based upon Felix.  So far I've not
>  found
> > anything that advises how to do this or if it is even possible at
> >> this
> > stage of development.
> >
> > Can anybody point me to an article that explains how, if this can be
>  done?
> >
> > TIA.
> >
> 
> >>>
> >>
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
> For additional commands, e-mail: users-h...@felix.apache.org
>
>


Re: Felix and JavaFX

2017-07-09 Thread Neil Bartlett
Hi Chuck,

Using Eclipse as an IDE does not tie you into using Equinox for your runtime.

I don’t know much about JavaFX but what is the actual problem you are 
experiencing with it? Isn’t it just a library like any other?

Neil

> On 9 Jul 2017, at 18:18, Chuck Davis  wrote:
> 
> Thanks Bram.  I actually read that yesterday but unfortunately it's Eclipse
> related and that ties me to Equinox.  So far I haven't found anything to
> like about Eclipse and I want true OSGi compatibility -- not tied to a
> specific IDE or OSGi implementation.  At least the Eclipse people are
> wrestling with the issue and that is a good sign.  I've done some of the
> e(fx)clipse tutorials as well but, again, it makes me dependent on specific
> implementations.
> 
> I'm going to re-read the article and see if I've missed something
> though.
> 
> Again, thanks for your interest.
> 
> 
> On Sun, Jul 9, 2017 at 10:10 AM, Bram Pouwelse  wrote:
> 
>> Hi Chuck,
>> 
>> It's an old post but could be what you're looking for
>> 
>> http://paulonjava.blogspot.nl/2014/11/making-javafx-better-
>> with-osgi.html?m=1
>> 
>> Regards,
>> Bram
>> 
>> Op 9 jul. 2017 19:05 schreef "Chuck Davis" :
>> 
>>> Thanks Thomas.  I guess there must be a way.  I wish he would have just
>>> explained how to use JavaFX with Felix rather than develop a whole third
>>> party development environment.
>>> 
>>> On Sun, Jul 9, 2017 at 9:19 AM, Thomas Driessen <
>>> thomas.dries...@ds-lab.org>
>>> wrote:
>>> 
 Hi Chuck,
 
 maybe this Project is an interesting starting Point for you:
 http://www.drombler.org
 
 Kind regards,
 Thomas
 
 Am 09.07.2017 18:17 schrieb "Chuck Davis" :
 
> I spent most of the day yesterday googling to find out if there is a
>>> way
 to
> build a JavaFX desktop application based upon Felix.  So far I've not
 found
> anything that advises how to do this or if it is even possible at
>> this
> stage of development.
> 
> Can anybody point me to an article that explains how, if this can be
 done?
> 
> TIA.
> 
 
>>> 
>> 


-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org



Re: Felix and JavaFX

2017-07-09 Thread Chuck Davis
Thanks Bram.  I actually read that yesterday but unfortunately it's Eclipse
related and that ties me to Equinox.  So far I haven't found anything to
like about Eclipse and I want true OSGi compatibility -- not tied to a
specific IDE or OSGi implementation.  At least the Eclipse people are
wrestling with the issue and that is a good sign.  I've done some of the
e(fx)clipse tutorials as well but, again, it makes me dependent on specific
implementations.

I'm going to re-read the article and see if I've missed something
though.

Again, thanks for your interest.


On Sun, Jul 9, 2017 at 10:10 AM, Bram Pouwelse  wrote:

> Hi Chuck,
>
> It's an old post but could be what you're looking for
>
> http://paulonjava.blogspot.nl/2014/11/making-javafx-better-
> with-osgi.html?m=1
>
> Regards,
> Bram
>
> Op 9 jul. 2017 19:05 schreef "Chuck Davis" :
>
> > Thanks Thomas.  I guess there must be a way.  I wish he would have just
> > explained how to use JavaFX with Felix rather than develop a whole third
> > party development environment.
> >
> > On Sun, Jul 9, 2017 at 9:19 AM, Thomas Driessen <
> > thomas.dries...@ds-lab.org>
> > wrote:
> >
> > > Hi Chuck,
> > >
> > > maybe this Project is an interesting starting Point for you:
> > > http://www.drombler.org
> > >
> > > Kind regards,
> > > Thomas
> > >
> > > Am 09.07.2017 18:17 schrieb "Chuck Davis" :
> > >
> > > > I spent most of the day yesterday googling to find out if there is a
> > way
> > > to
> > > > build a JavaFX desktop application based upon Felix.  So far I've not
> > > found
> > > > anything that advises how to do this or if it is even possible at
> this
> > > > stage of development.
> > > >
> > > > Can anybody point me to an article that explains how, if this can be
> > > done?
> > > >
> > > > TIA.
> > > >
> > >
> >
>


Re: Felix and JavaFX

2017-07-09 Thread Bram Pouwelse
Hi Chuck,

It's an old post but could be what you're looking for

http://paulonjava.blogspot.nl/2014/11/making-javafx-better-with-osgi.html?m=1

Regards,
Bram

Op 9 jul. 2017 19:05 schreef "Chuck Davis" :

> Thanks Thomas.  I guess there must be a way.  I wish he would have just
> explained how to use JavaFX with Felix rather than develop a whole third
> party development environment.
>
> On Sun, Jul 9, 2017 at 9:19 AM, Thomas Driessen <
> thomas.dries...@ds-lab.org>
> wrote:
>
> > Hi Chuck,
> >
> > maybe this Project is an interesting starting Point for you:
> > http://www.drombler.org
> >
> > Kind regards,
> > Thomas
> >
> > Am 09.07.2017 18:17 schrieb "Chuck Davis" :
> >
> > > I spent most of the day yesterday googling to find out if there is a
> way
> > to
> > > build a JavaFX desktop application based upon Felix.  So far I've not
> > found
> > > anything that advises how to do this or if it is even possible at this
> > > stage of development.
> > >
> > > Can anybody point me to an article that explains how, if this can be
> > done?
> > >
> > > TIA.
> > >
> >
>


Re: Felix and JavaFX

2017-07-09 Thread Chuck Davis
Thanks Thomas.  I guess there must be a way.  I wish he would have just
explained how to use JavaFX with Felix rather than develop a whole third
party development environment.

On Sun, Jul 9, 2017 at 9:19 AM, Thomas Driessen 
wrote:

> Hi Chuck,
>
> maybe this Project is an interesting starting Point for you:
> http://www.drombler.org
>
> Kind regards,
> Thomas
>
> Am 09.07.2017 18:17 schrieb "Chuck Davis" :
>
> > I spent most of the day yesterday googling to find out if there is a way
> to
> > build a JavaFX desktop application based upon Felix.  So far I've not
> found
> > anything that advises how to do this or if it is even possible at this
> > stage of development.
> >
> > Can anybody point me to an article that explains how, if this can be
> done?
> >
> > TIA.
> >
>


Re: Felix and JavaFX

2017-07-09 Thread Thomas Driessen
Hi Chuck,

maybe this Project is an interesting starting Point for you:
http://www.drombler.org

Kind regards,
Thomas

Am 09.07.2017 18:17 schrieb "Chuck Davis" :

> I spent most of the day yesterday googling to find out if there is a way to
> build a JavaFX desktop application based upon Felix.  So far I've not found
> anything that advises how to do this or if it is even possible at this
> stage of development.
>
> Can anybody point me to an article that explains how, if this can be done?
>
> TIA.
>


Re: Felix and JavaFX

2017-07-09 Thread Chuck Davis
I spent most of the day yesterday googling to find out if there is a way to
build a JavaFX desktop application based upon Felix.  So far I've not found
anything that advises how to do this or if it is even possible at this
stage of development.

Can anybody point me to an article that explains how, if this can be done?

TIA.


Re: Felix: bundle double update with osgi refresh

2017-05-13 Thread Karl Pauls
On Saturday, May 13, 2017, Alex Sviridov 
wrote:

>
> Hi Karl
>
> Thank you for your answer. I've tested your solution. I did the following
> steps:
> -stopped bundleA
> -updated bundleA
> -started bundleA
> However, BundleB is still using old classes from bundleA after all steps.
>
> How can I make BundleB use new classes (automatically) and not to restart
> bundleA twice?


As Rick mentioned, you have to explicitly refresh inbetween- sorry for not
being clear about that. The sequence must be: stop, update, refresh, start.

You can read more about the why here:

http://felix.apache.org/documentation/tutorials-examples-and-presentations/apache-felix-osgi-faq.html#when-i-update-my-bundle-why-are-my-bundles-old-classes-still-being-used

regards,

Karl


> >Пятница, 12 мая 2017, 14:38 +03:00 от Karl Pauls  >:
> >
> >> For example I have a running osgi framework with two bundles: bundleA
> and bundleB
> >> which jars are in JARS folder. BundleB depends on BundleA. Now I
> replace bundleA jar
> >> in JARS folder.
> >>
> >> Is there any way to refresh framework (there is new version of bundleA
> in JARS folder)
> >> and not to start/stop bundleA twice?
> >
> >Yes, you basically don't just update() but call stop() then update()
> >and finally start() on bundleA again.
> >
> >regards,
> >
> >Karl
> >
> >> Best regards, Alex
> >>
> >>
> >>>Среда, 10 мая 2017, 16:55 +03:00 от "Richard S. Hall" <
> he...@ungoverned.org  >:
> >>>
> >>>On 5/10/17 08:16 , Alex Sviridov wrote:
>  Hi all
> 
>  I use Apache Felix 5.4.0 and I have two bundles: bundleA and bundleB.
> BundleB depends on bundleA.
> 
>  I update bundleA and after that run the following code to do osgi
> refresh:
> 
>  Bundle systemBundle  = bcx . getBundle ( 0 );
>  FrameworkWiring frameworkWiring  = systemBundle . adapt (
> FrameworkWiring . class );
>  frameworkWiring . refreshBundles ( null );
>  (from here  http://stackoverflow.com/a/23361835/5057736 )
> 
>  This code does the following: it stops and starts bundleA and stops
> and starts bundleB.
> 
>  But why bundleA? I am asking because in result bundleA is two times
> updated. Is this a bug or what?
> >>>
> >>>The first stop/start is when you do the update, the second is when you
> >>>do the refresh. The former is historical, since that is the way update()
> >>>was defined in the first version of the spec (I believe). Later versions
> >>>of the spec where refreshing was introduced didn't change this behavior
> >>>for backward compatibility reasons.
> >>>
> >>>If refresh were there from the beginning, then it would have likely been
> >>>better to have update() simply prepare the updated version and refresh
> >>>enact it.
> >>>
> >>>-> richard
> >>>
> 
>  Best regards, Alex
> >>>
> >>>
> >>>-
> >>>To unsubscribe, e-mail:  users-unsubscr...@felix.apache.org
> 
> >>>For additional commands, e-mail:  users-h...@felix.apache.org
> 
> >>>
> >>
> >>
> >> --
> >> Alex Sviridov
> >
> >
> >
> >--
> >Karl Pauls
> >karlpa...@gmail.com 
>
>
> --
> Alex Sviridov
>


-- 
Karl Pauls
karlpa...@gmail.com


Re: Felix: bundle double update with osgi refresh

2017-05-12 Thread Richard S. Hall

On 5/12/17 07:38 , Karl Pauls wrote:

For example I have a running osgi framework with two bundles: bundleA and 
bundleB
which jars are in JARS folder. BundleB depends on BundleA. Now I replace 
bundleA jar
in JARS folder.

Is there any way to refresh framework (there is new version of bundleA in JARS 
folder)
and not to start/stop bundleA twice?

Yes, you basically don't just update() but call stop() then update()
and finally start() on bundleA again.


Yes, that's what I was going to say, but what Karl really meant was 
stop, update, refresh, then start on bundle A.


It's the only way.

-> richard


regards,

Karl


Best regards, Alex



Среда, 10 мая 2017, 16:55 +03:00 от "Richard S. Hall" :

On 5/10/17 08:16 , Alex Sviridov wrote:

Hi all

I use Apache Felix 5.4.0 and I have two bundles: bundleA and bundleB. BundleB 
depends on bundleA.

I update bundleA and after that run the following code to do osgi refresh:

Bundle systemBundle  = bcx . getBundle ( 0 );
FrameworkWiring frameworkWiring  = systemBundle . adapt ( FrameworkWiring . 
class );
frameworkWiring . refreshBundles ( null );
(from here  http://stackoverflow.com/a/23361835/5057736 )

This code does the following: it stops and starts bundleA and stops and starts 
bundleB.

But why bundleA? I am asking because in result bundleA is two times updated. Is 
this a bug or what?

The first stop/start is when you do the update, the second is when you
do the refresh. The former is historical, since that is the way update()
was defined in the first version of the spec (I believe). Later versions
of the spec where refreshing was introduced didn't change this behavior
for backward compatibility reasons.

If refresh were there from the beginning, then it would have likely been
better to have update() simply prepare the updated version and refresh
enact it.

-> richard


Best regards, Alex


-
To unsubscribe, e-mail:  users-unsubscr...@felix.apache.org
For additional commands, e-mail:  users-h...@felix.apache.org



--
Alex Sviridov






-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org



Re: Felix: bundle double update with osgi refresh

2017-05-10 Thread Richard S. Hall

On 5/10/17 08:16 , Alex Sviridov wrote:

Hi all

I use Apache Felix 5.4.0 and I have two bundles: bundleA and bundleB. BundleB 
depends on bundleA.

I update bundleA and after that run the following code to do osgi refresh:

Bundle systemBundle  = bcx . getBundle ( 0 );
FrameworkWiring frameworkWiring  = systemBundle . adapt ( FrameworkWiring . 
class );
frameworkWiring . refreshBundles ( null );
(from here http://stackoverflow.com/a/23361835/5057736 )

This code does the following: it stops and starts bundleA and stops and starts 
bundleB.

But why bundleA? I am asking because in result bundleA is two times updated. Is 
this a bug or what?


The first stop/start is when you do the update, the second is when you 
do the refresh. The former is historical, since that is the way update() 
was defined in the first version of the spec (I believe). Later versions 
of the spec where refreshing was introduced didn't change this behavior 
for backward compatibility reasons.


If refresh were there from the beginning, then it would have likely been 
better to have update() simply prepare the updated version and refresh 
enact it.


-> richard



Best regards, Alex



-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org



Re: Felix not behaving as per tutorial

2017-05-04 Thread Richard S. Hall

On 5/3/17 15:23 , Dan Hartman wrote:

Hi there,

I followed the tutorial here:

http://felix.apache.org/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-gettingstarted/ipojo-hello-word-maven-based-tutorial.html 



I can't find any felix-1.0.3 directory (nor one appropriately named 
like that, according to the version current to the tutorial page).


When I search the tutorial folder, there are quite a number of 
"bin/felix.jar" occurrences scattered around, but none of them behave 
like the tutorial.  A prompt does start, but instead of having a "->" 
sigil, it's "g!".  The "hello iPOJO" message starts emitting every so 
often.


After typing "java -jar bin/felix.java", I didn't have to do anything 
to start the hello example emitting a message.  There's no ps command, 
and when I type help, I get a LOT of choices, and there are three 
categories of them, felix, ipojo, and obr.


See the attached screenshot.

What am I doing wrong?  It seems like the tutorial is not up to date 
with the tutorial archive zip.


You aren't doing anything wrong, I would guess. It just sounds like the 
tutorial is woefully out of date.


Felix now has a new command shell, called Gogo, which is why you see so 
much of a difference between the prompts and commands. You should use 
"lb" to list the bundles. Commands for starting/stopping are the same, 
although it is doubtful the "arch" command would be working with the 
newer shell, since that is provided by iPOJO for the old shell.


I think in the original tutorial the bundles also auto-started, so that 
part works the same.


-> richard



Thanks in advance!

Dan




-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org




Re: Felix/CM/DS mystery

2016-10-19 Thread Benson Margulies
I said I'd be quiet unless I found an explanation -- and I did.
Removing this, which was a leftover from a bigger bad idea, did the
job.


   org.osgi
   osgi.cmpn
   test


-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org



Re: Felix container and Java SecurityManager -- does the container always implement security

2016-09-21 Thread Benson Margulies
Thanks, that does answer my question.


On Wed, Sep 21, 2016 at 5:17 PM, Karl Pauls  wrote:
> I guess I'm not 100% sure I understand what you are asking exactly. Let me
> first try to explain what the different options are and then try to answer
> what I think you are asking.
>
> If there is a security manager installed the framework will do permission
> checks where the spec mandates it. However, assuming you didn't install the
> framework.security provider, all bundles will have AllPermission by default
> -- except, if you have set  felix.security.defaultpolicy=true. In that
> case, your security policy will be consulted for bundles as well.
>
> Hence, if you want behavior just as some ordinary library in an application
> with a security manager you probably want to _not_ install the
> framework.security provider and set felix.security.defaultpolicy=true
> (either as a -D property or as one passed to the felix constructor). That
> in turn will make it so that you _do_ get permission checks triggered from
> Felix as well as potentially from bundles which you can grant (or deny by
> omission, respectively) via your security policy.
>
> Otherwise, if you just don't want failing permission checks then, don't
> install the framework.security provider and _don't_ set
> felix.security.defaultpolicy.
> That will make it so that you _do_ get permission checks triggered from
> Felix as well as potentially from bundles but at least bundles will have
> AllPermission by default (hence, all you need to do in your policy is to
> give felix.jar and your external code that calls into Felix permissions).
>
> If, on the other hand, you don't want _any_ permission checks triggered by
> felix despite a security manage being around the answer is: no - thats not
> possible.
>
> regards,
>
> Karl
>
> On Wed, Sep 21, 2016 at 10:48 PM, Benson Margulies 
> wrote:
>
>> I'd like to run a Felix container as if it was just some ordinary
>> piece of an application inside of a security manager; I don't want any
>> security manager checks or behaviors from the container. Can I do
>> this, or does the container always interact with the SecurityManager
>> if there is one?
>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
>> For additional commands, e-mail: users-h...@felix.apache.org
>>
>>
>
>
> --
> Karl Pauls
> karlpa...@gmail.com

-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org



Re: Felix container and Java SecurityManager -- does the container always implement security

2016-09-21 Thread Karl Pauls
I guess I'm not 100% sure I understand what you are asking exactly. Let me
first try to explain what the different options are and then try to answer
what I think you are asking.

If there is a security manager installed the framework will do permission
checks where the spec mandates it. However, assuming you didn't install the
framework.security provider, all bundles will have AllPermission by default
-- except, if you have set  felix.security.defaultpolicy=true. In that
case, your security policy will be consulted for bundles as well.

Hence, if you want behavior just as some ordinary library in an application
with a security manager you probably want to _not_ install the
framework.security provider and set felix.security.defaultpolicy=true
(either as a -D property or as one passed to the felix constructor). That
in turn will make it so that you _do_ get permission checks triggered from
Felix as well as potentially from bundles which you can grant (or deny by
omission, respectively) via your security policy.

Otherwise, if you just don't want failing permission checks then, don't
install the framework.security provider and _don't_ set
felix.security.defaultpolicy.
That will make it so that you _do_ get permission checks triggered from
Felix as well as potentially from bundles but at least bundles will have
AllPermission by default (hence, all you need to do in your policy is to
give felix.jar and your external code that calls into Felix permissions).

If, on the other hand, you don't want _any_ permission checks triggered by
felix despite a security manage being around the answer is: no - thats not
possible.

regards,

Karl

On Wed, Sep 21, 2016 at 10:48 PM, Benson Margulies 
wrote:

> I'd like to run a Felix container as if it was just some ordinary
> piece of an application inside of a security manager; I don't want any
> security manager checks or behaviors from the container. Can I do
> this, or does the container always interact with the SecurityManager
> if there is one?
>
> -
> To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
> For additional commands, e-mail: users-h...@felix.apache.org
>
>


-- 
Karl Pauls
karlpa...@gmail.com


Re: felix bundle security

2016-05-18 Thread Stephen Higgs
Thanks!

- Original Message -
From: "Karl Pauls" <karlpa...@gmail.com>
To: users@felix.apache.org
Sent: Wednesday, May 18, 2016 10:45:48 AM
Subject: Re: felix bundle security

Yes, that should be possible. If you create a custom condition it will get
passed in the Bundle object in question for evaluation. That is when you
could inspect the bundle. Next, all you need to do is to basically start
with a security policy that only grant permissions to bundles that pass
your custom condition.

You can have a look at this example for a custom condition and how to use
it:
https://github.com/mcculls/osgi-in-action/tree/master/chapter14/combined-example

regards,

Karl

On Wed, May 18, 2016 at 4:37 PM, Stephen Higgs <shi...@redhat.com> wrote:

> So I could write my own logic that checks the bundle via a "custom
> condition"?  That would be perfect - is there a resource that you would
> recommend that shows how to implement a custom condition?
>
> Thanks!
>
> --Stephen
>
> - Original Message -
> From: "Karl Pauls" <karlpa...@gmail.com>
> To: users@felix.apache.org
> Sent: Wednesday, May 18, 2016 9:34:28 AM
> Subject: Re: felix bundle security
>
> Hm, I guess you could do that, yes. However, are you sure you want to
> implement your own provider? If you are running with security enabled, why
> not just use the existing provider and write your own custom condition that
> checks the bundle?
>
> regards,
>
> Karl
>
> On Wed, May 18, 2016 at 2:54 PM, Stephen Higgs <shi...@redhat.com> wrote:
>
> > [Note - Originally Sent to Karaf users list, but may be more appropriate
> > for the felix users list]
> >
> > Hi all,
> >
> > If I wanted to implement custom logic to examine bundles that are
> > installed for security purposes, would the following be appropriate?
> >
> > 1) set org.osgi.framework.security=osgi
> > 2) create an implementation of
> > org.apache.felix.framework.ext.SecurityProvider
> > 3) add the new security provider to startup.properties
> >
> > Would this achieve the desired ability to checkBundle() for all bundles
> > during startup and thereafter?
> >
> > Thank you,
> >
> > Stephen Higgs
> >
> > -
> > To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
> > For additional commands, e-mail: users-h...@felix.apache.org
> >
> >
>
>
> --
> Karl Pauls
> karlpa...@gmail.com
> http://twitter.com/karlpauls
> http://www.linkedin.com/in/karlpauls
> https://profiles.google.com/karlpauls
>
> -
> To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
> For additional commands, e-mail: users-h...@felix.apache.org
>
>


-- 
Karl Pauls
karlpa...@gmail.com
http://twitter.com/karlpauls
http://www.linkedin.com/in/karlpauls
https://profiles.google.com/karlpauls

-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org



Re: felix bundle security

2016-05-18 Thread Karl Pauls
Yes, that should be possible. If you create a custom condition it will get
passed in the Bundle object in question for evaluation. That is when you
could inspect the bundle. Next, all you need to do is to basically start
with a security policy that only grant permissions to bundles that pass
your custom condition.

You can have a look at this example for a custom condition and how to use
it:
https://github.com/mcculls/osgi-in-action/tree/master/chapter14/combined-example

regards,

Karl

On Wed, May 18, 2016 at 4:37 PM, Stephen Higgs <shi...@redhat.com> wrote:

> So I could write my own logic that checks the bundle via a "custom
> condition"?  That would be perfect - is there a resource that you would
> recommend that shows how to implement a custom condition?
>
> Thanks!
>
> --Stephen
>
> - Original Message -
> From: "Karl Pauls" <karlpa...@gmail.com>
> To: users@felix.apache.org
> Sent: Wednesday, May 18, 2016 9:34:28 AM
> Subject: Re: felix bundle security
>
> Hm, I guess you could do that, yes. However, are you sure you want to
> implement your own provider? If you are running with security enabled, why
> not just use the existing provider and write your own custom condition that
> checks the bundle?
>
> regards,
>
> Karl
>
> On Wed, May 18, 2016 at 2:54 PM, Stephen Higgs <shi...@redhat.com> wrote:
>
> > [Note - Originally Sent to Karaf users list, but may be more appropriate
> > for the felix users list]
> >
> > Hi all,
> >
> > If I wanted to implement custom logic to examine bundles that are
> > installed for security purposes, would the following be appropriate?
> >
> > 1) set org.osgi.framework.security=osgi
> > 2) create an implementation of
> > org.apache.felix.framework.ext.SecurityProvider
> > 3) add the new security provider to startup.properties
> >
> > Would this achieve the desired ability to checkBundle() for all bundles
> > during startup and thereafter?
> >
> > Thank you,
> >
> > Stephen Higgs
> >
> > -
> > To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
> > For additional commands, e-mail: users-h...@felix.apache.org
> >
> >
>
>
> --
> Karl Pauls
> karlpa...@gmail.com
> http://twitter.com/karlpauls
> http://www.linkedin.com/in/karlpauls
> https://profiles.google.com/karlpauls
>
> -
> To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
> For additional commands, e-mail: users-h...@felix.apache.org
>
>


-- 
Karl Pauls
karlpa...@gmail.com
http://twitter.com/karlpauls
http://www.linkedin.com/in/karlpauls
https://profiles.google.com/karlpauls


Re: felix bundle security

2016-05-18 Thread Stephen Higgs
So I could write my own logic that checks the bundle via a "custom condition"?  
That would be perfect - is there a resource that you would recommend that shows 
how to implement a custom condition?

Thanks!

--Stephen

- Original Message -
From: "Karl Pauls" <karlpa...@gmail.com>
To: users@felix.apache.org
Sent: Wednesday, May 18, 2016 9:34:28 AM
Subject: Re: felix bundle security

Hm, I guess you could do that, yes. However, are you sure you want to
implement your own provider? If you are running with security enabled, why
not just use the existing provider and write your own custom condition that
checks the bundle?

regards,

Karl

On Wed, May 18, 2016 at 2:54 PM, Stephen Higgs <shi...@redhat.com> wrote:

> [Note - Originally Sent to Karaf users list, but may be more appropriate
> for the felix users list]
>
> Hi all,
>
> If I wanted to implement custom logic to examine bundles that are
> installed for security purposes, would the following be appropriate?
>
> 1) set org.osgi.framework.security=osgi
> 2) create an implementation of
> org.apache.felix.framework.ext.SecurityProvider
> 3) add the new security provider to startup.properties
>
> Would this achieve the desired ability to checkBundle() for all bundles
> during startup and thereafter?
>
> Thank you,
>
> Stephen Higgs
>
> -
> To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
> For additional commands, e-mail: users-h...@felix.apache.org
>
>


-- 
Karl Pauls
karlpa...@gmail.com
http://twitter.com/karlpauls
http://www.linkedin.com/in/karlpauls
https://profiles.google.com/karlpauls

-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org



Re: felix bundle security

2016-05-18 Thread Karl Pauls
Hm, I guess you could do that, yes. However, are you sure you want to
implement your own provider? If you are running with security enabled, why
not just use the existing provider and write your own custom condition that
checks the bundle?

regards,

Karl

On Wed, May 18, 2016 at 2:54 PM, Stephen Higgs  wrote:

> [Note - Originally Sent to Karaf users list, but may be more appropriate
> for the felix users list]
>
> Hi all,
>
> If I wanted to implement custom logic to examine bundles that are
> installed for security purposes, would the following be appropriate?
>
> 1) set org.osgi.framework.security=osgi
> 2) create an implementation of
> org.apache.felix.framework.ext.SecurityProvider
> 3) add the new security provider to startup.properties
>
> Would this achieve the desired ability to checkBundle() for all bundles
> during startup and thereafter?
>
> Thank you,
>
> Stephen Higgs
>
> -
> To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
> For additional commands, e-mail: users-h...@felix.apache.org
>
>


-- 
Karl Pauls
karlpa...@gmail.com
http://twitter.com/karlpauls
http://www.linkedin.com/in/karlpauls
https://profiles.google.com/karlpauls


RE: Felix+Bkuetooth: Missing requirement?

2016-03-10 Thread CLEMENT Jean-Philippe
You have two solutions, either embed them in your bundle or transform them into 
bundles. You may start by embedding them.

Just have to put them in the jar file and change the Bundle-ClassPath, for 
instance Bundle-ClassPath: 
.,lib/net.sf.bluecove.bluecove.jar,net.sf.bluecove.bluecove-gpl.jar

I don't know how you may do that within NetBeans. I use Maven with the 
maven-bundle-plugin which makes things easy.

JP

-Message d'origine-
De : imo [mailto:imoveisnacion...@gmail.com] 
Envoyé : jeudi 10 mars 2016 14:26
À : users@felix.apache.org
Objet : RE: Felix+Bkuetooth: Missing requirement?

But blueCove jars are not bundles, arent they? Should I install or make tham 
available to be used in runtime?





--
View this message in context: 
http://apache-felix.18485.x6.nabble.com/Felix-Bluetooth-Missing-requirement-tp5016686p5016725.html
Sent from the Apache Felix - Users mailing list archive at Nabble.com.

-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org


-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org



RE: Felix+Bkuetooth: Missing requirement?

2016-03-10 Thread imo
But blueCove jars are not bundles, arent they? Should I install or make tham
available to be used in runtime?





--
View this message in context: 
http://apache-felix.18485.x6.nabble.com/Felix-Bluetooth-Missing-requirement-tp5016686p5016725.html
Sent from the Apache Felix - Users mailing list archive at Nabble.com.

-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org



RE: Felix+Bkuetooth: Missing requirement?

2016-03-10 Thread CLEMENT Jean-Philippe
Now it just means that you have to install both BlueCove bundles ;)

I would suggest you not to use "raw" Felix, but rather use Karaf which makes 
use of Felix and adds some nice features around it. Also it is very easy to 
package a full product with Karaf.

JP

-Message d'origine-
De : imo [mailto:imoveisnacion...@gmail.com] 
Envoyé : jeudi 10 mars 2016 11:07
À : users@felix.apache.org
Objet : RE: Felix+Bkuetooth: Missing requirement?

I have restart all the process but again without success I created a new bundle 
project from the ground up (netbeans, ubuntu)


File , new maven osgi bundle, name=Bundle1

Added some printlns to activator…

public class Activator implements BundleActivator {

public void start(BundleContext context) throws Exception {
System.out.println("Starting bundle");
}

public void stop(BundleContext context) throws Exception {
System.out.println("Stopping bundle");
}

}

and build...

Then, i openned gogo console:

sudo java -jar bin/felix.jar

and:

g! install
file:/home/user1/NetBeansProjects/bundle1/target/bundle1-1.0-SNAPSHOT.jar
Bundle ID: 30
g! start 30
Starting bundle
g! 

OK!

Now, I have just added BlueCove support:
In the pom.xml I added:


net.sf.bluecove
bluecove
2.1.0



net.sf.bluecove
bluecove-gpl
2.1.0


then build and:

g! uninstall 30
Stopping bundle
g! install
file:/home/user1/NetBeansProjects/bundle1/target/bundle1-1.0-SNAPSHOT.jar
Bundle ID: 31
g! start 31
Starting bundle
g! 

OK!

Then, in the activator class (to turn this more simple) i added:

import javax.bluetooth.*;
import javax.microedition.io.*;

then build and:

g! uninstall 31
Stopping bundle
g! install
file:/home/user1/NetBeansProjects/bundle1/target/bundle1-1.0-SNAPSHOT.jar
Bundle ID: 32
g! start 32
Starting bundle
g! 

OK!


Then, in the activator, (just to make this simpler) next to println:

public void start(BundleContext context) throws Exception {
System.out.println("Starting bundle");

try
{
LocalDevice localDevice = LocalDevice.getLocalDevice();
}
catch(Exception ex)
{
}
  
}

build and

g! uninstall 32
Stopping bundle
g! install
file:/home/user1/NetBeansProjects/bundle1/target/bundle1-1.0-SNAPSHOT.jar
Bundle ID: 33
g! start 33
org.osgi.framework.BundleException: Unable to resolve com.mycompany.bundle1 
[33](R 33.0): missing requirement [com.mycompany.bundle1 [33](R 33.0)] 
osgi.wiring.package; (osgi.wiring.package=javax.bluetooth) Unresolved
requirements: [[com.mycompany.bundle1 [33](R 33.0)] osgi.wiring.package; 
(osgi.wiring.package=javax.bluetooth)]
g! 

Why?
In simple words, what does “Unresolved requirements: [[com.mycompany.bundle1 
[33](R 33.0)] osgi.wiring.package; (osgi.wiring.package=javax.bluetooth)]”
means?

Thanks again




--
View this message in context: 
http://apache-felix.18485.x6.nabble.com/Felix-Bluetooth-Missing-requirement-tp5016686p5016721.html
Sent from the Apache Felix - Users mailing list archive at Nabble.com.

-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org


-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org


RE: Felix+Bkuetooth: Missing requirement?

2016-03-10 Thread imo
I have restart all the process but again without success
I created a new bundle project from the ground up (netbeans, ubuntu)


File , new maven osgi bundle, name=Bundle1

Added some printlns to activator…

public class Activator implements BundleActivator {

public void start(BundleContext context) throws Exception {
System.out.println("Starting bundle");
}

public void stop(BundleContext context) throws Exception {
System.out.println("Stopping bundle");
}

}

and build...

Then, i openned gogo console:

sudo java -jar bin/felix.jar

and:

g! install
file:/home/user1/NetBeansProjects/bundle1/target/bundle1-1.0-SNAPSHOT.jar
Bundle ID: 30
g! start 30
Starting bundle
g! 

OK!

Now, I have just added BlueCove support:
In the pom.xml I added:


net.sf.bluecove
bluecove
2.1.0



net.sf.bluecove
bluecove-gpl
2.1.0


then build and:

g! uninstall 30
Stopping bundle
g! install
file:/home/user1/NetBeansProjects/bundle1/target/bundle1-1.0-SNAPSHOT.jar
Bundle ID: 31
g! start 31
Starting bundle
g! 

OK!

Then, in the activator class (to turn this more simple) i added:

import javax.bluetooth.*;
import javax.microedition.io.*;

then build and:

g! uninstall 31
Stopping bundle
g! install
file:/home/user1/NetBeansProjects/bundle1/target/bundle1-1.0-SNAPSHOT.jar
Bundle ID: 32
g! start 32
Starting bundle
g! 

OK!


Then, in the activator, (just to make this simpler) next to println:

public void start(BundleContext context) throws Exception {
System.out.println("Starting bundle");

try
{
LocalDevice localDevice = LocalDevice.getLocalDevice();
}
catch(Exception ex)
{
}
  
}

build and

g! uninstall 32
Stopping bundle
g! install
file:/home/user1/NetBeansProjects/bundle1/target/bundle1-1.0-SNAPSHOT.jar
Bundle ID: 33
g! start 33
org.osgi.framework.BundleException: Unable to resolve com.mycompany.bundle1
[33](R 33.0): missing requirement [com.mycompany.bundle1 [33](R 33.0)]
osgi.wiring.package; (osgi.wiring.package=javax.bluetooth) Unresolved
requirements: [[com.mycompany.bundle1 [33](R 33.0)] osgi.wiring.package;
(osgi.wiring.package=javax.bluetooth)]
g! 

Why?
In simple words, what does “Unresolved requirements: [[com.mycompany.bundle1
[33](R 33.0)] osgi.wiring.package; (osgi.wiring.package=javax.bluetooth)]”
means?

Thanks again




--
View this message in context: 
http://apache-felix.18485.x6.nabble.com/Felix-Bluetooth-Missing-requirement-tp5016686p5016721.html
Sent from the Apache Felix - Users mailing list archive at Nabble.com.

-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org



RE: Felix+Bkuetooth: Missing requirement?

2016-03-09 Thread CLEMENT Jean-Philippe
Ah ok, if you have everything in the same bundle then you should not have any 
import package for the com.mycompany one.

So you have to remove it - you may also check within the MANIFEST.MF that it is 
not present.

JP

-Message d'origine-
De : imo [mailto:imoveisnacion...@gmail.com] 
Envoyé : mercredi 9 mars 2016 16:46
À : users@felix.apache.org
Objet : RE: Felix+Bkuetooth: Missing requirement?

Well, as i am starting the project, the bundle project has just one package 
with one bundle class, service interface and service implementation all in the 
same package com.mycompany.BTBundle;

It seems that the package needs to export the package for its own consumption 
(during service instantiation)?

Anyway, I have right clicked netbeans dependencies (where there is already the 
bluecove, bluecove-gpl and osgi core) and added the dependency for the artifact 
representing the app bundle. Now the BT bundle is also listed in the 
dependencies node and the project compiles without errors.

However, after uninstall, install and start I see the same error:

org.osgi.framework.BundleException: Unable to resolve com.mycompany.BTBundle 
[21](R 21.0): missing requirement [com.mycompany.BTBundle [21](R 21.0)] 
osgi.wiring.package; (osgi.wiring.package=com.ibm.oti.connection) Unresolved
requirements: [[com.mycompany.BTBundle [21](R 21.0)] osgi.wiring.package; 
(osgi.wiring.package=com.ibm.oti.connection)]





--
View this message in context: 
http://apache-felix.18485.x6.nabble.com/Felix-Bluetooth-Missing-requirement-tp5016686p5016701.html
Sent from the Apache Felix - Users mailing list archive at Nabble.com.

-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org


-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org



RE: Felix+Bkuetooth: Missing requirement?

2016-03-09 Thread imo
Well, as i am starting the project, the bundle project has just one package
with one bundle class, service interface and service implementation all in
the same package com.mycompany.BTBundle;

It seems that the package needs to export the package for its own
consumption (during service instantiation)?

Anyway, I have right clicked netbeans dependencies (where there is already
the bluecove, bluecove-gpl and osgi core) and added the dependency for the
artifact representing the app bundle. Now the BT bundle is also listed in
the dependencies node and the project compiles without errors.

However, after uninstall, install and start I see the same error:

org.osgi.framework.BundleException: Unable to resolve com.mycompany.BTBundle
[21](R 21.0): missing requirement [com.mycompany.BTBundle [21](R 21.0)]
osgi.wiring.package; (osgi.wiring.package=com.ibm.oti.connection) Unresolved
requirements: [[com.mycompany.BTBundle [21](R 21.0)] osgi.wiring.package;
(osgi.wiring.package=com.ibm.oti.connection)]





--
View this message in context: 
http://apache-felix.18485.x6.nabble.com/Felix-Bluetooth-Missing-requirement-tp5016686p5016701.html
Sent from the Apache Felix - Users mailing list archive at Nabble.com.

-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org



RE: Felix+Bkuetooth: Missing requirement?

2016-03-09 Thread CLEMENT Jean-Philippe
You need two things, the package to be exported from the bundle which contains 
the BTBundle class, and the package to be imported from the bundle which show 
you this issue.

I advise you to check what has been put in these two bundles. Check both 
MANAFEST.MF files (also pay attention to the versions if specified).

JP


-Message d'origine-
De : imo [mailto:imoveisnacion...@gmail.com] 
Envoyé : mercredi 9 mars 2016 10:40
À : users@felix.apache.org
Objet : RE: Felix+Bkuetooth: Missing requirement?

Thanks JP...

I have done this since i read your replay:

In netbeans: RClick project | properties | Export packages | and checked 
com.mycompany.BTBundle  (Explicit selected packages)

Then:

g! uninstall 19
g! install file:/home/ ...  ..  /BTBundle-1.0-SNAPSHOT.jar Bundle ID: 20 g! 
start 20

org.osgi.framework.BundleException: Unable to resolve com.mycompany.BTBundle 
[20](R 20.0): missing requirement [com.mycompany.BTBundle [20](R 20.0)] 
osgi.wiring.package; (osgi.wiring.package=com.ibm.oti.connection) Unresolved
requirements: [[com.mycompany.BTBundle [20](R 20.0)] osgi.wiring.package; 
(osgi.wiring.package=com.ibm.oti.connection)]
g! 

Any further help? 

Thank you



--
View this message in context: 
http://apache-felix.18485.x6.nabble.com/Felix-Bluetooth-Missing-requirement-tp5016686p5016688.html
Sent from the Apache Felix - Users mailing list archive at Nabble.com.

-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org


-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org



RE: Felix+Bkuetooth: Missing requirement?

2016-03-09 Thread imo
Thanks JP...

I have done this since i read your replay:

In netbeans: RClick project | properties | Export packages | and checked
com.mycompany.BTBundle  (Explicit selected packages)

Then:

g! uninstall 19
g! install file:/home/ ...  ..  /BTBundle-1.0-SNAPSHOT.jar
Bundle ID: 20
g! start 20

org.osgi.framework.BundleException: Unable to resolve com.mycompany.BTBundle
[20](R 20.0): missing requirement [com.mycompany.BTBundle [20](R 20.0)]
osgi.wiring.package; (osgi.wiring.package=com.ibm.oti.connection) Unresolved
requirements: [[com.mycompany.BTBundle [20](R 20.0)] osgi.wiring.package;
(osgi.wiring.package=com.ibm.oti.connection)]
g! 

Any further help? 

Thank you



--
View this message in context: 
http://apache-felix.18485.x6.nabble.com/Felix-Bluetooth-Missing-requirement-tp5016686p5016688.html
Sent from the Apache Felix - Users mailing list archive at Nabble.com.

-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org



RE: Felix+Bkuetooth: Missing requirement?

2016-03-09 Thread CLEMENT Jean-Philippe
Hi,

It just says "com.mycompany.BTBundle" has to be found somewhere, so the related 
bundle should export the com.mycompany package.

JP

-Message d'origine-
De : imo [mailto:imoveisnacion...@gmail.com] 
Envoyé : mardi 8 mars 2016 16:52
À : users@felix.apache.org
Objet : Felix+Bkuetooth: Missing requirement?

I am trying to develop a bundle with bluetooth support (listening + publish) 
using netbeans (ubuntu) I have created a Maven | OSGi bundle and then i added 
this to pom.xml:


net.sf.bluecove
bluecove
2.1.0



net.sf.bluecove
bluecove-gpl
2.1.0


to the dependencies element.

I also created a service to be registered and launched during bundle start in 
order to be listening bluetooth channel.
In the service I have just (for now) did this:


import javax.bluetooth.*;
import javax.microedition.io.*;


and

try
{
LocalDevice localDevice = LocalDevice.getLocalDevice(); } catch(Exception 
ex) { }

When i register and start the bundle (and service) I see this:

g! start 15
org.osgi.framework.BundleException: Unable to resolve com.mycompany.BTBundle 
[15](R 15.0): missing requirement [com.mycompany.BTBundle [15](R 15.0)] 
osgi.wiring.package; (osgi.wiring.package=com.ibm.oti.connection) Unresolved
requirements: [[com.mycompany.BTBundle [15](R 15.0)] osgi.wiring.package; 
(osgi.wiring.package=com.ibm.oti.connection)]
g! 


If I comment the line:

LocalDevice localDevice = LocalDevice.getLocalDevice();

Everything works fine...

Any help, please?

Imo



--
View this message in context: 
http://apache-felix.18485.x6.nabble.com/Felix-Bkuetooth-Missing-requirement-tp5016686.html
Sent from the Apache Felix - Users mailing list archive at Nabble.com.

-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org


-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org



Re: Felix and JavaMail

2016-03-07 Thread Mark Derricutt
On 7 Mar 2016, at 20:56, Paul Bakker wrote:

> Hi Mark,
>
> Do you explicitly need JavaMail, or do you just want to send mail from Java?
> If you don't need JavaMail, there's a component in Amdatu that offers this. 
> It supports both smtp and AWS SES.
> http://amdatu.org/components/email.html 
> 

Not explicitly - we wrap javamail access in our own higher-level service which 
abstracts away the majority of things. Amdatu looks good, tho I see it uses 
commons-email which in turn is a wrapper for JavaMail.

Looks like one of the root causes of our problems is this OLD system (this 
layer dates back almost 8-9 years now ) was depending on javamail 1.4 - from 
before it was in Maven Central, and I believe before it had any OSGi metadata 
on it so it looks like it was just dropped into the ./lib directory of the 
karaf ( and felix instance before it ).

Things seem to all startup under 4.0.4 (so nice to see the full app running on 
a new container ) now altho now just hitting activation framework issues with 
class loaders - it's been soo long since I've even THOUGHT about the evil 
Activation Framework :)

mark



-- 
Mark Derricutt
http://www.theoryinpractice.net
http://www.chaliceofblood.net
http://plus.google.com/+MarkDerricutt
http://twitter.com/talios
http://facebook.com/mderricutt


signature.asc
Description: OpenPGP digital signature


Re: Felix and JavaMail

2016-03-06 Thread Paul Bakker
Hi Mark,

Do you explicitly need JavaMail, or do you just want to send mail from Java? 
If you don't need JavaMail, there's a component in Amdatu that offers this. It 
supports both smtp and AWS SES.
http://amdatu.org/components/email.html 
<http://amdatu.org/components/email.html>

Cheers,

Paul

> On 07 Mar 2016, at 08:16, Frank Langel <fr...@frankjlangel.com> wrote:
> 
> Neil,
> 
> I shouldn’t have misquoted you. The statements from you book where 
> incorrectly summarized by me. I realized that when pressing send button.
> 
> Sorry
> Frank
> 
> 
> 
> 
> On 3/7/16, 8:14 AM, "Neil Bartlett" <njbartl...@gmail.com> wrote:
> 
>> Hi Frank,
>> 
>> I don't say Karaf is bloated as such. It's much better than the old JavaEE
>> app servers.
>> 
>> It's just that I have never seen a good reason to use it instead of plain
>> OSGi.
>> 
>> Regards, Neil.
>> On 7 Mar 2016 08:02, "Frank Langel" <fr...@frankjlangel.com> wrote:
>> 
>>> Well,
>>> 
>>> Karaf is a strange journey. Some people like it, some don’t.
>>> I am more in the Neil Bartlett kind of Apache Felix camp who thinks Karaf
>>> too bloated.
>>> 
>>> I discovered Hana is using Eclipse Equinox, so I need to get familiar with
>>> that.
>>> 
>>> Let me know if you need help with the javamail, should be easy sailing
>>> though.
>>> Frank
>>> 
>>> 
>>> From:  Mark Derricutt
>>> Reply-To:  <users@felix.apache.org>
>>> Date:  Monday, March 7, 2016 at 1:26 AM
>>> To:  <users@felix.apache.org>
>>> Subject:  Re: Felix and JavaMail
>>> 
>>> On 7 Mar 2016, at 10:32, Frank Langel wrote:
>>> 
>>> I never had any issues sending mail. What exactly is your issue?
>>> 
>>> Looks like Karaf already ships with javamail so it looks like it was more
>>> an issue with using the kar lifecycle and some extra
>>> strict checking of dependencies.
>>> 
>>> I'm working thru migrating a project deployed via a rather ancient version
>>> of karaf so I think it's more just a matter of working out the build
>>> process to package things up.  Sending email from the application in
>>> question is already working fine.
>>> 
>>> Mark
>>> 
>>> --
>>> Mark Derricutt
>>> http://www.theoryinpractice.net
>>> http://www.chaliceofblood.net
>>> http://plus.google.com/+MarkDerricutt
>>> http://twitter.com/talios
>>> http://facebook.com/mderricutt
>>> 
>>> 
> 
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
> For additional commands, e-mail: users-h...@felix.apache.org
> 



Re: Felix and JavaMail

2016-03-06 Thread Frank Langel
Neil,

I shouldn’t have misquoted you. The statements from you book where incorrectly 
summarized by me. I realized that when pressing send button.

Sorry
Frank




On 3/7/16, 8:14 AM, "Neil Bartlett" <njbartl...@gmail.com> wrote:

>Hi Frank,
>
>I don't say Karaf is bloated as such. It's much better than the old JavaEE
>app servers.
>
>It's just that I have never seen a good reason to use it instead of plain
>OSGi.
>
>Regards, Neil.
>On 7 Mar 2016 08:02, "Frank Langel" <fr...@frankjlangel.com> wrote:
>
>> Well,
>>
>> Karaf is a strange journey. Some people like it, some don’t.
>> I am more in the Neil Bartlett kind of Apache Felix camp who thinks Karaf
>> too bloated.
>>
>> I discovered Hana is using Eclipse Equinox, so I need to get familiar with
>> that.
>>
>> Let me know if you need help with the javamail, should be easy sailing
>> though.
>> Frank
>>
>>
>> From:  Mark Derricutt
>> Reply-To:  <users@felix.apache.org>
>> Date:  Monday, March 7, 2016 at 1:26 AM
>> To:  <users@felix.apache.org>
>> Subject:  Re: Felix and JavaMail
>>
>> On 7 Mar 2016, at 10:32, Frank Langel wrote:
>>
>> I never had any issues sending mail. What exactly is your issue?
>>
>> Looks like Karaf already ships with javamail so it looks like it was more
>> an issue with using the kar lifecycle and some extra
>> strict checking of dependencies.
>>
>> I'm working thru migrating a project deployed via a rather ancient version
>> of karaf so I think it's more just a matter of working out the build
>> process to package things up.  Sending email from the application in
>> question is already working fine.
>>
>> Mark
>>
>> --
>> Mark Derricutt
>> http://www.theoryinpractice.net
>> http://www.chaliceofblood.net
>> http://plus.google.com/+MarkDerricutt
>> http://twitter.com/talios
>> http://facebook.com/mderricutt
>>
>>


-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org



Re: Felix and JavaMail

2016-03-06 Thread Neil Bartlett
Hi Frank,

I don't say Karaf is bloated as such. It's much better than the old JavaEE
app servers.

It's just that I have never seen a good reason to use it instead of plain
OSGi.

Regards, Neil.
On 7 Mar 2016 08:02, "Frank Langel" <fr...@frankjlangel.com> wrote:

> Well,
>
> Karaf is a strange journey. Some people like it, some don’t.
> I am more in the Neil Bartlett kind of Apache Felix camp who thinks Karaf
> too bloated.
>
> I discovered Hana is using Eclipse Equinox, so I need to get familiar with
> that.
>
> Let me know if you need help with the javamail, should be easy sailing
> though.
> Frank
>
>
> From:  Mark Derricutt
> Reply-To:  <users@felix.apache.org>
> Date:  Monday, March 7, 2016 at 1:26 AM
> To:  <users@felix.apache.org>
> Subject:  Re: Felix and JavaMail
>
> On 7 Mar 2016, at 10:32, Frank Langel wrote:
>
> I never had any issues sending mail. What exactly is your issue?
>
> Looks like Karaf already ships with javamail so it looks like it was more
> an issue with using the kar lifecycle and some extra
> strict checking of dependencies.
>
> I'm working thru migrating a project deployed via a rather ancient version
> of karaf so I think it's more just a matter of working out the build
> process to package things up.  Sending email from the application in
> question is already working fine.
>
> Mark
>
> --
> Mark Derricutt
> http://www.theoryinpractice.net
> http://www.chaliceofblood.net
> http://plus.google.com/+MarkDerricutt
> http://twitter.com/talios
> http://facebook.com/mderricutt
>
>


Re: Felix and JavaMail

2016-03-06 Thread Jean-Baptiste Onofré

Hi guys,

Karaf Minimal is really minimal and ship the minimal needed for Karaf 
itself and applications. Karaf 4.1.x standard distribution will be 
already lighter as we will remove blueprint for instance.


Javamail is not included in Karaf standard distribution: it comes with 
the pax-web feature (and just the API from SMX).


Of course, you can start from Equinox or Felix framework and build your 
stuff, but lot of time, you will end with kind of Karaf (minimal at 
least) ;)


Regards
JB

On 03/07/2016 08:02 AM, Frank Langel wrote:

Well,

Karaf is a strange journey. Some people like it, some don’t.
I am more in the Neil Bartlett kind of Apache Felix camp who thinks Karaf too 
bloated.

I discovered Hana is using Eclipse Equinox, so I need to get familiar with that.

Let me know if you need help with the javamail, should be easy sailing though.
Frank


From:  Mark Derricutt
Reply-To:  <users@felix.apache.org>
Date:  Monday, March 7, 2016 at 1:26 AM
To:  <users@felix.apache.org>
Subject:  Re: Felix and JavaMail

On 7 Mar 2016, at 10:32, Frank Langel wrote:

I never had any issues sending mail. What exactly is your issue?

Looks like Karaf already ships with javamail so it looks like it was more an issue with 
using the kar lifecycle and some extra strict checking 
of dependencies.

I'm working thru migrating a project deployed via a rather ancient version of 
karaf so I think it's more just a matter of working out the build process to 
package things up.  Sending email from the application in question is already 
working fine.

Mark



--
Jean-Baptiste Onofré
jbono...@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com

-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org



Re: Felix and JavaMail

2016-03-06 Thread Balázs Zsoldos
Hi Mark,

we have used the following artifact with no issue:

http://search.maven.org/#artifactdetails%7Ccom.sun.mail%7Cjavax.mail%7C1.5.5%7Cjar

Additional notes:

We created a wrapper project that makes it much easier to send emails
(MimeMessage class is not so easy to work with):
http://www.everit.org/email-javamail/
It is based on email-api: http://www.everit.org/email-api/

Also, there are some other projects that you might be interested in:

   - email-javamail-dkim :
   Possibility to attach DKIM signature to your mail if you use our
   email-javamail. DKIM is useful not to get your e-mail lost in the spam
   folder
   - email-store-ri : Stores
   email defined in email-api within persistent database
   - email-queue : Persists
   email in a queue before sending them out by using email-store. We had the
   experience that sending out one email takes 2-3 seconds, but sending out 10
   takes the same amount of time. Building up the connection with the SMTP
   server is the slow part. Not to have a hang on the user interface, it is
   better to put the emails into the queue and send them together frequently
   with a scheduler. This module will be released to maven central within 24
   hours, and documentation comes soon, too.

All of them are available on maven-central
.

If you are interested in these but having problems using them, please let
me know.

Kind regards,
*Balázs **Zsoldos*

On Sun, Mar 6, 2016 at 10:28 PM, Mark Derricutt  wrote:

> Hey all,
>
> I was wondering what the current status of JavaMail was with Felix and
> OSGi ( and Karaf )?  Is it possible to just install some bundles and use
> Javamail or do we need to update felix configuration with boot class loader
> overrides still?
>
> All my google searches just come up with all the old and ancient "you need
> to make your own bundle" camp and still mess with class loaders.
>
> Makr
>
>
> --
> Mark Derricutt
> http://www.theoryinpractice.net
> http://www.chaliceofblood.net
> http://plus.google.com/+MarkDerricutt
> http://twitter.com/talios
> http://facebook.com/mderricutt
>


  1   2   3   4   5   6   >