I need to implement a firmware upgrade mechanism where Apache ACE will be used for provisioning and Apache Felix will be used at the Target side. Does Felix has the capability to upgrade Firmware on devices?
As mentioned in the documentation of Apache ACE, firmware upgrade provisioning is possible. But, how to create a bundle for firmware?
Any help would be highly appreciated.
Thanks
The Apache ACE architecture page indeed refers to updating not only OSGi bundles, but also "related artifacts such as configuration data, native code and device firmware." To handle this, ACE relies on Demloyment Admin (section 114 of the OSGi Compendium Specification), which allows plugging in resource processors.
Using Deployment Admin, you have a way to distribute the artifacts you need to your devices, and process them in a way you see fit: put files in some location, install application packages (e.g. rpm or Android apps), or even use the payload to update firmware. You can thus tie into a standardized deployment mechanism, and use its lifecycle.
Note that it is still your responsibility to do something sensible with the data. In other words, if you don't have a bootloader for updating your firmware, ACE cannot help you in that, but if you do, you can ride along on the distribution mechanism.
Disclosure: I am an Apache ACE committer.
Related
I am quite confused as to the proper way of distributing Bonjour as a part of a Windows application that would publish a service for a client iOS app.
No matter how much I google around, I cannot find a clear how-to guide. It would be great if someone could provide guidelines.
The main reasons of my confusion are:
Is it mandatory to distribute the entire bonjour Win SDK as a part of my Win application?
Since Apple provides source code to build mDNSResponder.exe, is it sufficient to only distribute such file along with dns-sd.dll?
What is the intended purpose of providing sources for mDNSResponder.exe otherwise?
What is the recommended way to handle the possibility of having Bonjour already installed on the system?
Also, where can I find the latest Bonjour SDK (3.x I guess?), I can only find 2.0.4. Is it only accessible if I am enrolled in the OSX developer program? (I am enrolled in iOS developer program for now.)
Many thanks.
This is information I gathered from various sources, including communications with official Apple support. I report it in the way I believe to be accurate, I hope it can be useful (no liability assumed!).
For Bonjour-enabled Windows application you have basically two main options:
Bundle the Bonjour Installer with your application (which is not the Bonjour SDK, the SDK if for your own developer use only).
If you choose to do so, the Bonjour installer must be called from your own installer during the installation process. The possibility of Bonjour being already installed in the system is totally handled by the Bonjour installer.
And here come some bad news: you must include de Bonjour Logo on your physical distribution medium (like a DVD cover sleeve) according to the Apple guidelines specified in the Windows Bundling Agreement, and you need Apple approval before distributing your product.
Do not bundle. I.e., do not distribute Bonjour with your application but simply use it if already present in the system. If you do not distribute Bonjour in any form the whole Windows Bundling Agreement simply does not apply. You application should search for the dnssd.dll and load it dynamically if found.
Consider that most of Windows users would have Bonjour already installed due to the fact that some popular apps use it (for example iTunes and Skype).
While the source code of Bonjour is released under an open-source library (Apache License, Version 2.0) this does not require Apple to do anything. In particular, they do not need to document how you'd use this license.
The license allows you to use and adapt Apple's source code, including its copyright, but not including its trademark "Bonjour(TM)". Since this is the standard Apache license, you don't have the requirement either to show the trademark.
So, to answer your questions:
No, you can build your own version of Bonjour from source and use that under the Apache license. You can't call it Bonjour, but why do you need a name in the first place? "mDNS" would be a reasonable choice, possibly prefixed with your trademark.
It seems sufficient to distribute the DLL and EXE. Arranging how they find each other might benefit from some tailoring, so your own build of Bonjour doesn't clash with Apple's.
(I won't speculate on Apple's motives)
The design problem here is that Bonjour acts as a system service, and services are inherently singletons. If you install it unmodified, Apple wouldn't be able to install its own build. That's not a legal problem, probably, but it is a bad customer experience. Installing your own build as a distinct service would avoid the clash, allowing both versions to co-exist.
(Resource request, off-topic)
Apache Ace documentation refers that it can do software provisioning to other types of targets "non-OSGi containers, or something completely different target". But no documentation is available regarding non-OSGi target.
Can I have some examples of non-OSGi targets to which Apache Ace can do software provisioning. Also, what are the minimum requirement for a target to work with Apache ACE.
Thanks
Some examples of non-OSGi targets that I have seen people create are:
Android applications to a mobile device, using a resource processor that could programmatically install .APK files.
Windows desktop applications that, again using a resource processor, were installed on a users' desktop computer.
Kernel modules, configuration and other files, database schema, etc.
All of these can be implemented by creating the appropriate resource processor. In short, a resource processor is just an OSGi bundle that gets shipped alongside the resources that are provisioned. Both arrive at the target, where the processor is used to somehow install the resource. The mechanism allows you to extend the provisioning system with new file types.
Another non-OSGi target you can use is PojoSR. This works a bit differently. With a special post processor bundle, ACE can, instead of delivering deployment packages, create an executable JAR file that contains the PojoSR framework and the bundles you configured. You can fetch and run this jar anywhere. Mainly interesting in environments where normally you could not run OSGi.
Yet another thing I've seen being done is deploying to Apache Celix, which is an OSGi implementation in C. They have actually implemented a proof of concept management agent that can talk to ACE and they can provision bundles with C code that way.
About the minimum requirements:
We try to keep the management agent compatible to the basic OSGi execution environment, meaning we refrain from using any Java 5+ features. It does need an R4 compatible OSGi implementation though, R3 is too old as it does not support DeploymentAdmin (which is the basis for the provisioning mechanism we use).
Have a look at remote interfaces, but HTTP is the default I think, see this link - so as a minimum requirement, anything that can check the metadata and stream a socket can hit the relevant (restful looking) URLs and discover/provision from Ace.
I don't have much experience with Apache ACE, but if you are looking for a remote provisioning system which mainly targets OSGi clients but can also handle other targets, you can take a look at ProSyst mPower Remote Manager - the supported targets are OSGi-based devices, OMA DM devices and TR-069 devices.
Can anyone advise on the main benefits of installing the Tomcat native library?
I am running a standard installation of Tomcat to serve a moderately complex intranet based web app using Ext Js on the front end so lots of javascript and AJAX over the network and VPN from various locations.
Is it even worth installing this library for the comparatively small amount of requests it will be getting.
The app can be very slow at times and I'm looking to boost performance. I am already refactoring Java code based on profile data but as the problem seems to be more generalised I am also looking at the app server configuration and I can't seem to find any detail on whether this library would actually benefit me in this scenario.
Thank you
I assume you are speaking about Tomcat APR. I personally don't believe that by simply switching the connector from non-native to native will automagically solve your performance problems.
Unless you have exercised all code inefficiencies (it seems that you are doing this already with the help of profiler) and solved them, it is probably not worth it.
I would envisage that APR helps in cases where most of requests are static and delivering static content becomes a bottleneck. To achieve this, you probably need to be delivering millions pages per day and having thread pool going through the roof (which I assume is not likely for your intranet).
Some of tomcat apr is not found in ubuntu repositories as they are no longer supported.
Please make sure these configurations are correct:
In eclipse under windows->preferences->servers-> runtime environment,
choose the server where your project is deployed. Select the option installed jre and choose the java version you have installed or one you prefer.
Under project properties -> runtime environment select the server and press apply.
Under build path double click on jre library and choose the java version you have installed.
Native libraries are required when there is a mismatch between the code in the project in the jre version or the tomacat version.
Make sure that in your build and code, both are for the latest version of servlet that tomcat supports and jre is at its latest version that tomcat supports.
For example, if tomcat v8.5 supports java version 7 or above, you should have java version latest above 7 and tomcat v8.5 supports servlet version 3.1 so in your build set up. Make sure to use a container that uses servlet 3.1.
Does Mac App Store accept application written in Python/Java/Ruby?
The Good News
Yes, you can submit a Java app to the Mac App Store. Not true in the past, but it is true at least as of now in 2013.
One example is the successful MoneyDance personal finance app currently available for sale in the Mac App Store.
The Bad News
Preparing and submitting your app is neither simple nor easy. You have to jump through some hoops.
Your app cannot depend on Java being installed on the Mac. You must include a JRE (Java Runtime Environment) within your Mac app.
You must write a thin Objective-C wrapper around your Java app. The source code and examples/tutorials are available on the web.
Like any other app, you must go through all hassle of the complicated build and deployment rigmarole with security restrictions Apple requires of any Mac App Store app.
More Info
Two articles, Take your Java application to the Mac App Store and Forking the OpenJDK for fun and profit, by Marco Dinacci. These articles may provide other useful information, but fortunately their discussion of forking the JDK is now outmoded. He and others have provided the needed patches now incorporated in the official releases.
How to Create a Mac OS X Installer for a Java Application (Updated for Mac OS X 10.8 — Mountain Lion) by Dem Pilafian of Center Key Software.
Packaging a Java App for Distribution on a Mac (Oracle)
Submitting to the Mac App Store (Apple)
By the way, you can use both Swing and JavaFX in your app. JavaFX is now bundled with Java, at least as of Java 7 Update 40 according to these Release Notes.
Java 9
The newly released Java 9 should make this process of wrapping an app with a runtime even easier and better.
Modules
Java 9 brings “modularization”, Java Platform Module System (JPMS), where the approximately 5,000 classes bundled with a JVM are grouped into about a hundred chunks known as modules. You can include only the modules containing classes actually used by your particular app rather hauling along every library. If you don't use JSON or CORBA, then you need not include the JSON or CORBA related modules.
The new jlink tool does this work for you, to assemble and optimize a set of modules and their dependencies into a custom run-time image. As a bonus, some link-time optimization work is performed to make your app launch faster.
These features are supported on 64-bit macOS systems, along with other platforms.
Native compiling
Java 9 also brings new support for native compiling, to build an app optimized for specific hardware. But this ability is experimental, and not yet ready for production use.
Update, as of 2018
Oracle has announced the end of web deployment technology, including Java Web Start, the previously recommended avenue for desktop apps. So now, Oracle expects all Java apps to be delivered bundled with a JVM such as is done with the jlink tool mentioned above.
So, the process of wrapping an app with a Java runtime that was something of a rarity just for the Apple App Store is now mainstream. Oracle expects any Java-based desktop app to be installed this way.
Yes and no. Apple doesn't care what language your App is written in, but it cannot depend on or install anything outside of the binary you submit to Apple. The relevant guidelines are below:
2.14
Apps must be packaged and submitted using Apple's packaging technologies included in Xcode - no third party installers allowed
2.15
Apps must be self-contained, single application installation bundles, and cannot install code or resources in shared locations
2.16
Apps that download or install additional code or resources to add functionality or change their primary purpose will be rejected
So, while this means you can't depend on Ruby or Python, you could use a framework like MacRuby to build your app in Ruby and embed the Ruby interpreter. Speaking for MacRuby, apps have been successfully submitted to the Mac App Store this way.
Ruby ? Yes !
Apple already accepted one of my apps written in MacRuby.
AFAIK, Cocoa will allow you include code written in different languages (including Ruby and Python, but not Java I don't think).
Check the Apple SDK's for more info, but I believe (thanks to Cocoa) it's not a problem.
For Python apps, I wrote a comprehensive article explaining how to build and submit such apps to the Mac App Store. It includes source code and build scripts for a barebones example app that I have successfully submitted.
Submitting a Python App to the Mac App Store
Possibly Java, if you bundle the Java application into a mac application.
Before designing my own Linux OTA stack, I'd better probe if anybody knows of an existing Linux OTA stack/framework that I could make use of/contribute to.
What I mean by Linux OTA stack/framework is a service capable of updating the Linux kernel on my device from a remote repository. Basically something like the OTA update feature found on most Linux smartphones today. It must be 99.99% fail-safe such that my devices (which will be mounted in 500 cars for 6-12 months) will not turn into useless bricks that require on-site service to become working again.
An open source solution is not a must - commercial solutions that do the job has equal interest.
Thanks in Advance.
Christian
Could you just use the APT, combined with suitable kernel packages?
Doing the actual update is pretty trivial, you can use any of the existing package management frameworks to provide a new kernel package that the system upgrades to when available.
The hard part is when your device reboots into the new kernel you need some way to detect if it doesn't boot, and boot it back into the old kernel. To do that without human intervention you'll need some sort of watchdog facility in your hardware.