[jira] [Assigned] (FELIX-3854) Problem running Felix in Android 4.1 ad 4.2 (JB)
[ https://issues.apache.org/jira/browse/FELIX-3854?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl Pauls reassigned FELIX-3854: - Assignee: Karl Pauls > Problem running Felix in Android 4.1 ad 4.2 (JB) > > > Key: FELIX-3854 > URL: https://issues.apache.org/jira/browse/FELIX-3854 > Project: Felix > Issue Type: Bug > Components: Framework >Affects Versions: framework-4.0.3 > Environment: Once Felix is running in the smartphone (Samsung Galaxy > Nexus with Android 4.2), the problem arises when a new bundle is being > installed (considering that the felix cache directory has been placed in the > external sd card by using the property org.osgi.framework.storage). >Reporter: Rafael Bachiller >Assignee: Karl Pauls >Priority: Minor > Labels: Android, Bean, Jelly, patch > > During the installation process, Felix places the .jar in the cache and then > obtains the dex file that is inside the jar file in order to put the dex file > in the cache directory. Then, Felix executes it. > In the new versions of Android, this process fails because the system does > not allow any program to place and execute any dex file in the sd card. The > code line that illustrate the problem is in the file > felix/framework/src/main/java/org/apache/felix/frameworBundleWiringImp.java > (line 2271). > In my modest opinion, there are two possible solutions: > a) For these newer versions of Android, it is not possible to place the cache > in the external sd card. For this solution no changes are needed in Felix, > but it creates a new limitation for running in the Android devices (the cache > can only be placed in the internal memory at runtime). > b) Create a new parameter (e.g. felix.cache.dexfiles) that can be applied to > Android systems that indicates to Felix where to place the dex files. Thus, > Felix is not going to store in the same place the .jar files and the .dex > files (avoiding to waste the internal memory). For this solution, it is > necessary to create the parameter in Felix and to modify the line that has > been indicated before. > Thank you very much in advance. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (FELIX-3854) Problem running Felix in Android 4.1 ad 4.2 (JB)
Rafael Bachiller created FELIX-3854: --- Summary: Problem running Felix in Android 4.1 ad 4.2 (JB) Key: FELIX-3854 URL: https://issues.apache.org/jira/browse/FELIX-3854 Project: Felix Issue Type: Bug Components: Framework Affects Versions: framework-4.0.3 Environment: Once Felix is running in the smartphone (Samsung Galaxy Nexus with Android 4.2), the problem arises when a new bundle is being installed (considering that the felix cache directory has been placed in the external sd card by using the property org.osgi.framework.storage). Reporter: Rafael Bachiller Priority: Minor During the installation process, Felix places the .jar in the cache and then obtains the dex file that is inside the jar file in order to put the dex file in the cache directory. Then, Felix executes it. In the new versions of Android, this process fails because the system does not allow any program to place and execute any dex file in the sd card. The code line that illustrate the problem is in the file felix/framework/src/main/java/org/apache/felix/frameworBundleWiringImp.java (line 2271). In my modest opinion, there are two possible solutions: a) For these newer versions of Android, it is not possible to place the cache in the external sd card. For this solution no changes are needed in Felix, but it creates a new limitation for running in the Android devices (the cache can only be placed in the internal memory at runtime). b) Create a new parameter (e.g. felix.cache.dexfiles) that can be applied to Android systems that indicates to Felix where to place the dex files. Thus, Felix is not going to store in the same place the .jar files and the .dex files (avoiding to waste the internal memory). For this solution, it is necessary to create the parameter in Felix and to modify the line that has been indicated before. Thank you very much in advance. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Releasing the dependency manager...
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 1/18/13 8:59 AM, Marcel Offermans wrote: > Just a quick heads-up to the list that I want to release a new > version of the dependency manager soon. The codebase has been > stable and tested by several committers here for some time now, and > there have been some new and interesting improvements. So, unless > someone has showstopping bugs they have not reported yet, I'm going > to proceed. I do not have any showstoppers for releasing a new version of Felix DM, so, go for it! ;) - -- Met vriendelijke groeten | Kind regards Jan Willem Janssen | Software Architect +31 631 765 814 /My world is:/ Luminis Technologies B.V. IJsselburcht 3 6825 BS Arnhem +31 88 586 46 30 http://www.luminis-technologies.com http://www.luminis.eu KvK (CoC) 09 16 28 93 BTW (VAT) NL8169.78.566.B.01 -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJQ+Qt6AAoJEKF/mP2eHDc4ZoAP/iRoFd7XBlwx3gaIzKEHpYde LTzB8deRvFYc4H82RvePdoJ0L5VCWFvcm04frMgAXd/NrEmBZDpZeoJzp76qCaqb NnGRwEqjEf4zVWeW2JQU9KLV59UEjdQt+BzUV1m1aiSzZ4Hkimp+VW732DQ5ViYJ uOvZWeNYz0MKya2lrphbIRoiOJJOc1F6fDOZ5+1oFIWTeKn91h/gZwrJGkz7Tx0M GeZZsFO1JLVRjPKYld/pdJvFOQgXs7wgRZVFqcE+2Tfea6s1nHZ70j7U9HWP4eC/ D1ijp3bmavJd9zpIaMdPniSgn0V7nMGu54ju6/rN3kk4N8biRNo4YK+oP+PwOjiz l9pP+quCzt6TuCEqGDaqR+lE5Wo3nr2x1B5fU981ZHqdsnkFUCeYzkmvDFJfA7oq NB61Uu6lto54JNukHb3skCnxAOfEK7QvBXsZ5XQOGwjKfj6kXDH10lr8zMNB9y5y TGbrx57IYjmmMqly3JTh4Lpm9eo0tj6Y7XdocA0nMZhuD6wRBx0dGXGnV4Pc03bc MThPpHNQHBgsi92x1k+d8t6sQjQwa7jmnZXzf6IspxwLUMtlQWVy1xeHRQPbRDwS VldX1pn62tz8J3N6iuMwD/A0Or7oG+QMUk5LW21uxmTA+7tPDWppyq/KTyWsdQYE r2a1RpSCb9n5J+rXoUya =YLvg -END PGP SIGNATURE-
AW: Metatype Service - OptionalAttributes - extra XML attributes with namespace support
Hi
Wakeup-Call :-). Has anybody a better idea or substantial arguments against my
last proposal?
Regards,
Alex
-Ursprüngliche Nachricht-
Von: alexander.ber...@finnova.ch [mailto:alexander.ber...@finnova.ch]
Gesendet: Montag, 14. Januar 2013 10:59
An: dev@felix.apache.org
Betreff: AW: Metatype Service - OptionalAttributes - extra XML attributes with
namespace support
Bridging the world of namespace-aware XML and not namespace-aware object models
like Java, where an object can only have one field (attribute) with the same
name, is quite difficult. In other words if we allow for multiple namespaces
for XML attributes (which at the moment is the case according to the spec) then
we must also adopt that concept of namespaces in the Java object model.
And as a note, (namespace) prefixes by them self are meaningless. They only
convey meaning if they are associated with a namespace.
So we need a solution which is namespace-aware and not limited to, but
compatible to XML. In the light of this I suggest the following interface,
where "namespace" is now a generic concept (abstraction) and does not
necessarily stand for XML-namespaces per se.
public interface ExtraAttributes {
/**
* List the names of extra attributes for a given namespace.
*
* @param namespace the namespace for which to retrieve the names of
available attribute.
*
* @return an {@link Iterator} producing the {@link String}s of the
extra attribute names.
* for the given namespace.
*/
public Iterator getExtraAttributeNames(String namespace);
/**
* Retrieve the value of an extra attribute.
*
* @param namespace the namespace from which to retrieve the attribute
value.
* @param name name of the extra attribute, whose value should be
retrieved.
* @return the value of the extra attribute or null if no
attribute with
* that name exists.
*/
public String getExtraAttributeValue(String namespace, String name); }
What do you think.
Regards
Alex
--
finnova AG Bankware
Alexander Berger
Software Architect
Merkurstrasse 6
CH-5600 Lenzburg
Tel: +41 (0)62 886 48 07 (direkt)
Tel: +41 (0)62 886 47 47 (zentrale)
Fax: +41 (0)62 886 48 88
mailto:alexander.ber...@finnova.ch
http://www.finnova.ch
-Ursprüngliche Nachricht-
Von: Felix Meschberger [mailto:fmesc...@adobe.com]
Gesendet: Montag, 14. Januar 2013 10:39
An: dev@felix.apache.org
Betreff: Re: Metatype Service - OptionalAttributes - extra XML attributes with
namespace support
Hi
QNAme is an XML-ism and the API is XML-free (as I said, use of XML is just one
way to back the API). So I am extremely reluctant to using QName (regardless of
whether we use javax.xml.QName or define our own QName class). Always consider
the case where an QbjectClassDefinition might be backed by a MetaTypeProvider
service and not XML.
As for the interface (except QName question), I am fine.
However, I could assume we could have the name, if it comes from XML, to be
something like
{url}localname
or
prefix:localname
And, of course, the {url} or prefix: prefix would be omitted for the default
namespace (empty string) or the namespace of the metatype descriptor.
Regards
Felix
Am 14.01.2013 um 07:43 schrieb
:
> O.K. I see.
>
> Then I would suggest to add something like the following interface to
> AttributeDefinition and ObjectClassDefinition:
>
> public interface ExtraAttributes {
>
> /**
>* List the {@link QName}s of extra XML attributes.
>*
>* @return an {@link Iterator} producing the {@link QName}s of the
> extra attributes.
>*/
> public Iterator getExtraAttributeNames();
>
> /**
>* Retrieve the value of an extra XML attribute.
>*
>* @param name {@link QName} of the extra attribute, whose value should
> be retrieved.
>* @return the value of the extra attribute or null if no
> attribute with
>* that name exists.
>*/
> public String getExtraAttributeValue(QName name); }
>
> However, my initial question about QName and XML API support arises
> again as we are using QName here. Note, using just a String as
> argument to getExtraAttributeValue will not work, as several
> attributes with the same name but different Namespaces (prefixes) might exist
> on the same Element.
>
> Regards
> Alex
>
> --
> finnova AG Bankware
> Alexander Berger
> Software Architect
> Merkurstrasse 6
> CH-5600 Lenzburg
> Tel: +41 (0)62 886 48 07 (direkt)
> Tel: +41 (0)62 886 47 47 (zentrale)
> Fax: +41 (0)62 886 48 88
> mailto:alexander.ber...@finnova.ch
> http://www.finnova.ch
>
> -Ursprüngliche Nachricht-
> Von: Felix Meschberger [mailto:fmesc...@adobe.com]
> Gesendet: Samstag, 12. Januar 2013 22:15
> An: dev@felix.apache.org
> Betreff: Re: Metatype Service - OptionalAttributes - ext
Re: Releasing the dependency manager...
Hello Angelo, Yes, indexing is stable now (Xander did a lot of work in this area, both implementing and testing) so updated documentation is very welcome. This also gives us the opportunity to update the documentation in general on the website, now that it has been moved to the Apache CMS. Greetings, Marcel On Jan 18, 2013, at 9:24 , Angelo van der Sijpt wrote: > No bugs for me, and I am rather excited about the upcoming indexing. > Will this be in as an official feature in this release? If so, I will see to > it that I update the documentation around that (as I promised) as soon as > possible. > > On Jan 18, 2013, at 8:59 AM, Marcel Offermans > wrote: > >> Just a quick heads-up to the list that I want to release a new version of >> the dependency manager soon. The codebase has been stable and tested by >> several committers here for some time now, and there have been some new and >> interesting improvements. So, unless someone has showstopping bugs they have >> not reported yet, I'm going to proceed.
Re: Releasing the dependency manager...
Hi Marcel, No bugs for me, and I am rather excited about the upcoming indexing. Will this be in as an official feature in this release? If so, I will see to it that I update the documentation around that (as I promised) as soon as possible. Angelo On Jan 18, 2013, at 8:59 AM, Marcel Offermans wrote: > Just a quick heads-up to the list that I want to release a new version of the > dependency manager soon. The codebase has been stable and tested by several > committers here for some time now, and there have been some new and > interesting improvements. So, unless someone has showstopping bugs they have > not reported yet, I'm going to proceed. > > Greetings, Marcel > >
Releasing the dependency manager...
Just a quick heads-up to the list that I want to release a new version of the dependency manager soon. The codebase has been stable and tested by several committers here for some time now, and there have been some new and interesting improvements. So, unless someone has showstopping bugs they have not reported yet, I'm going to proceed. Greetings, Marcel
