I am using jack rabbit OAK implementation for CMS, where I am versioning some file nodes using below code:
session.getWorkspace().getVersionManager().checkout(file.getPath());
// operation for saving file content and setting file node properties
session.getWorkspace().getVersionManager().checkin(file.getPath());
By using above, I have created 3 version of particular file with setting their custom properties, i.e; 1.0, 1.1, 1.2.
Now I want to update some property values from version 1.1
How to update versionable node property value using jack rabbit OAK implementation?
Related
I have created few custom objects within the range of (26241-32768). As per OMA registry spec, we need not have to register the custom objects which are in the range of 26241-32768. I have used lwm2m Leshan 1.0 server and lwm2m IOWA 1.0 client. When these custom objects get displayed in the Leshan server UI, the name of an object and the instance is not displayed properly. As shown in the attached image, Object name and Instance name is not getting displayed properly. Is it possible to display the name of the Object and Object Instance in server UI without registering the custom objects with OMA? Is there any other possibilities of displaying the name in the server?
Since the Servers have no way to know the representation of an object not registered, they have to be provisioned with the XML to parse their contents and in return to display the information properly on their Web Interface.
For Leshan Server:
• You need to run your own instance of the Server. When you launch the Server, you have the possibility to provide a folder where your XML are located such as:
o java -jar ./leshan-server-demo.jar --modelsfolder XML_PATH
For Connecticut:
• You need to send your XML files to Ioterop, and they will provision their Server with them. Today, there is no public API for it.
In the GlassFish 4 glassfish-acc.xml file, what is the purpose of the name attribute of the target-server element?
It seems that this file has something to do with IIOP.
Different installs of GlassFish 4 have different values for that attribute, but the rest of the files are exactly the same. Some example values of this attribute are:
sc11152542.us.oracle.com
sc11152550.us.oracle.com
I am trying to standardize the configs of some inherited GlassFish 4 servers. They are not clustered. Would it be OK for me to use the same value for all my servers? If so, does it matter which value I choose?
I read the documentation from the following link, but it was too tautological to be useful.
https://glassfish.java.net/docs/4.0/application-deployment-guide.pdf
The documentation also appears to be out of date, since it refers to sun-acc.xml instead of glassfish-acc.xml, and because it uses version 1.2 of the DTD while the glassfish-acc.xml files that I've seen use version 1.3.
I want to post a message to a SOAP webservice with MULE Enterprise edition.
For creating the Request object i am using a data mapper with the
input a POJO and for
the output i selected XML , and from example XML schema i added my own XSD.
Because there are a lot of elements in the xsd, i selected the root element from the list provided.
Then i am dragging the fields from input to the corresponding values i want in the output.
(i also tried to map just one field, to be sure that i keep the minimum the probability for error).
And now the problem:
when the flow is accessed, the following WARN is shown and the data-mapper fails
*[XML WRITER:EXT_XML_WRITER0] - Invalid mapping (With port binded to root element, result might contain multiple root elements. Such XML is not well-formed. To avoid that, set 'Records per file' or 'Max number of records' component attribute to '1'.)*
Where can i set this kind of options in the data mapper ?
And also i want the root element to be only one, i don't need a foreach for the root element, i just need to fill the contents of it. Can i specify this anywhere in the data mapper ?
Thanks.
Mule EE DataMapper uses CloverETL for data transformations, and this annoying warning concerns CloverETL settings. I don't know if you can advise CloverETL to use a specific configuration file in the context of Mule DataMapper, but you can always edit the mapping file generated by Mule with a text editor. Just find your root Node entry in the mapping file and add recordsPerFile="1" attribute.
The problem with this is that Mule may overwrite your manual edits if you use the graphical editor, though.
Check out the Anypoint Studio May 2014. Mule now includes a new Web Service Connector for posting messages to a SOAP web service using just a WSDL. Studio will read the XML Schema from the WSDL and automatically create the metadata for DataMapper for you. See http://www.mulesoft.org/documentation/display/current/Web+Service+Consumer for more details.
I am trying to create an MSI using the WiX toolset. I have a couple questions:
In the WebAppPool documentry there are two Properties: ManagedRuntimeVersion and ManagedPipelineMode. What are the expected values for them?
The documentation mentions that they can be set using formatted Property. What are these Properties?
I'll highly appreciate a sample.
ManagedRuntimeVersion refers to the version of .NET the app pool should use (e.g. v4.0)
ManagedPipelineMode refers to the pipeline mode the app pool should run in (e.g. integrated)
Formatted properties just means you can set the values using the name of a Property (wix docs) instead of specifying the value inline
It seems that once an Ocean Workstep derivative class has been released to production (and is used by clients), its name, namespace and assembly name are effectively locked for future updates (in order to ensure backwards compatibility).
When a Petrel project is saved, workstep references are saved as a full type name (namespace, class, strong assembly name) inside the binary file Classes.ptd. During loading, if the exact type name (assembly version seems to be ignored) can't be resolved, the workstep appears as "workstep not available" in the workflow editor.
In other instances of binary serialization we've encountered, Petrel makes use of the SerializationBinder registered with PetrelSystem.ProjectSerializationService - not so for Workstep instances.
Is there any other way to facilitate Workstep class/namespace/assembly renames?
Why is this behaviour so poorly documented (if at all)? Have we misunderstood something?
This issue will actually be fixed with the Ocean 2012.1 API. The workstep reference will not include the version number anymore: Both workstep and process serialization is cleaned up. Version number is not serialized (and not used on deserialization) and a UniqueId can be used instead of the type name.
Here is an extract of the 2012.1 Ocean release notes on the subject.
Process and Workstep Unique Id
Namespace: Slb.Ocean.Petrel.Workflow
Processes and worksteps created through Ocean did not have a proper identifier until now. They were identified by their full type name including the version number which means that their identifier could change, for instance, if:
- The version number of the plug-in assembly was increased (e.g. new plug-in install).
- The process/workstep class was moved to a new assembly.
- The namespace of the process/workstep class was changed.
This could cause issues in Petrel such as the display of a “broken link” instead of the process name in the Favorites tree or a workstep appearing as "workstep not available" in the workflow editor.
To solve this, Ocean has removed the version number from the process and workstep identifier and is delivering a new API to support a user defined identifier for custom processes and worksteps which will be unique across the Petrel application. Any process/workstep created through Ocean should now implement a unique identifier.
Please refer to:
- Process.UniqueId to define unique identifier for processes
- Workstep.UniqueId to define unique identifier for worksteps.
The new API also offers backward compatibility support for already serialized processes/worksteps and a few changes in the serialization logic. When a legacy project is being opened the old-style ids are automatically replaced by new ids during deserialization.
Best Regards,
Gaelle