Is there a standard way of reading MANIFEST.MF key-value pairs from a fragment in OSGi?
Each fragment is represented in the OSGi framework with a Bundle object. If you call BundleContext.getBundles() the returned list will include both fragment, and non fragment bundle. If you search through the array to find the fragment you are interested in you can call the Bundle.getHeaders() method which will return a Hashtable containing the name value paris.
Related
In my use case I have a RAML 1.0 library created by our R&D department that contains definition of multiple data types. Those data types are defined in a generic, parametrized manner so when I reference them in my RAML I do so using following syntax:
type: { resourceTypes.collectionWithCriteria: {itemName: reward, itemCriteria: types.RewardCriteria, itemType : types.RewardList} }
This generates proper GET request with query string defined by types.RewardCriteria and response defined by types.RewardList. It also generates the description for the GET resource defined as: Retrieves the list of <<itemName | !pluralize>>, which ends up being Retrieves the list of rewards.
In my RAML I would like to append additional description to my GET resource, however I 'd rather avoid overwriting library-generated one. Is that possible? I've already tried inline description and using overlay file, both of which simply replace description from the library.
You cannot append for a single value simple property.
The merging rules for traits / resource types state that the description will be replaced:
Every explicit node wins over the ones that are declared in a resource
type or trait. The rest are simply merged.
Also, the merging rules of overlays and extensions states that:.
If the property is a Simple Property
If the property is a Single-value Simple Property,
The property value in the identically named Current Target Tree Object property is replaced with its value from Current Extension Tree Object property.
I have some misunderstanding of OSGI fragment,
Suppose I have deployed a bundle "B" with two classes "com.company.C1" and "com.company.C2" where C1 use C2.
And then, I deployed a fragment "F" for the host bundle "B" where F contains only one class "com.company.C2" (with a little change in the code of the first class)
Now, if the class "com.company.C1" is being executed, which class (file) "com.company.C2" will be used, from "B" or from "F" ?
Can the presence of the same class C2 twice in the same class-loader cause runtime errors (same version & differents versions)?
Read chapter "3.9.4 Overall Search Order" of OSGi Core specification and everything will be clear.
In short: The classes in the bundle are checked first and than the fragment bundle. If you have a class in the bundle and in the fragment bundle, the one in the fragment bundle will never be used.
I've retrieved TypedDependency from tree annotation. Now I want to get the graph structure of the dependencies instead of the original list structure. The SemanticGraphEdge class contains four IndexedWord variables which are source, target, gov and dep, also there is a weight variable. How should I determine these variables from a TypedDependency class? Thank you.
TypedDependency tp;
SemanticGraph semgraph = new SemanticGraph(td);
i have this xpath defined for moxy in a jaxb class
#XmlPath("child::*/REG")
public List entries;
but it won't unmarshal the xml document correctly. the List variable called entries is empty.
i've also tried
#XmlPath("*/REG")
public List entries;
i've also tried
#XmlPath("//REG")
public List entries;
without joy
but if i do
#XmlPath("BANKGIRO/REG")
public List entries;
it's fine and the list is populated.
I haven't looked through the source yet but I'm guessing this type of xpath is not supported yet. I checked all my xpath in an xpath verifier for sanity and all the xpath above is fine (all the xpath is valid for the context node i'm positioned at).
EclipseLink JAXB (MOXy) does currently not support an XPath like: #XmlPath("child::*/REG"). Our focus has been on supporting XPath statements that provide enough information for marshalling as well as unmarshalling. For example it is clear what #XmlPath("child::*/REG") means on a read, but is ambiguous in terms when writing that object back to XML or JSON. If you are interested in this kind of support please enter an enhancement request:
https://bugs.eclipse.org/bugs/enter_bug.cgi?product=EclipseLink
MOXy does support XPath like:
#XmlPath(".") // Map to self node, useful when mapping two objects to same element
#XmlPath("#foo") // Map to attribute
#XmlPath("foo") // Map to element
#XmlPath("foo[2]") // Map to 2nd occurence of
#XmlPath("foo[#bar='Hello World']") // Map to foo element with bar attribute with value "Hello World"
#XmlPath("ns1:foo/ns2:#bar") // Map to namespace qualified nodes
For More Information
http://blog.bdoughan.com/2010/07/xpath-based-mapping.html
http://blog.bdoughan.com/2010/09/xpath-based-mapping-geocode-example.html
http://blog.bdoughan.com/2011/03/map-to-element-based-on-attribute-value.html
Assume that I have an Ecore-model containing a package and some classes that make reference to each other. If i create a "Dynamic Instance", Eclipse produces an XMI-file and I can instantiate some classes. Containment-relations are directly serialized to an XML-tree in the XMI (the children elements in the example). But if I instantiate references to elements that are already contained somewhere in the tree, the Editor writes Path-Expressions like in the following, for the currentChild attribute:
<parent currentChild="//#parent/#children.1">
<children/>
<children/>
</parent>
As far as I know this is not XPath, because:
The "childrens" are elements not attributes and have not to be referenced via "#"
XPath uses the e.g., elem[1] and not elem.1 to get e.g., the second elem of a list
What is it and where can I find a information on it? I already tried to browse the EMF pages/specs but could not find it.
It's an EMF Fragment Path. The Javadoc describes it like this:
String org.eclipse.emf.ecore.InternalEObject.eURIFragmentSegment(EStructuralFeature eFeature, EObject eObject)
Returns the fragment segment that, when passed to eObjectForURIFragmentSegment, will resolve to the given object in this object's given feature.
The feature argument may be null in which case it will be deduced, if possible. The default result will be of the form:
"#feature-name[.index]"
The index is used only for many-valued features; it represents the position within the list.
Parameters:
eFeature the feature relating the given object to this object, or null.
eObject the object to be identified.
Returns:
the fragment segment that resolves to the given object in this object's given feature.