Oracle Service Bus XPath Implementation - xquery

I'm using Oracle Service Bus 11g Release 1 (11.1.1.3) and have a problem with it's XPath Implementation.
A XQuery-Resource contains a simple XPath Axes Location Path:
preceding::SomeElement
Oracle says it should work: http://docs.oracle.com/cd/E14571_01/doc.1111/e15867/xquery.htm#i1106823
The Oracle Service Bus XQuery engine fully supports all of the language features that are described in the World Wide Web (W3C) specification for XQuery with one exception: modules. For more information about the XQuery 1.0 and XPath 2.0 functions and operators >(W3C Working Draft 23 July 2004), see the following URL: http://www.w3.org/TR/2004/WD-xpath-functions-20040723/
.. but it doesn't:
Error occurred while executing XQuery: {bea-err}SYS001: This functionality has not been implemented (sorry)

OSB 12c supports XQuery 1.0 including library modules and the preceding axis.
http://www.w3.org/TR/xquery/
http://docs.oracle.com/middleware/1213/osb/develop/osb-xquery.htm

Related

Tomcat 9 and Servlet API 2.5

My spring web application is using servlet api 2.5 along with spring framework 4. Its deployed in tomcat 9. Its working fine. I am not sure why tomcat is not complaining about it as it needs servlet api 4 as per documentation. Is it backward compatible or spring is doing some magic? Just for clarity We are using interfaces from servlet api 2.5 in our code which should not compile with servlet api 4. It is compiling because we are compiling with 2.5 but we are expecting it to fail at runtime in tomcat. Thanks
Are you using methods/classes that no longer exist in servlet spec 4? There isn't magic - it's downward compatible. If you tried to run, for example, AsyncEvent code in Tomcat 5.5 (servlet spec 2.4) then yes, you'd have a problem. But running old code on a new server - without using things that have totally changed or disappeared - is rarely a problem.
EDIT
You said that the "old" code has:
Map parameterMap = request.getParameterMap();
This is still valid if not best practice. With newer compilers you may get a warning from the compiler that you are not using generics but it is still valid. And since the Javadocs from that time say:
Returns: an immutable java.util.Map containing parameter names as keys and parameter values as map values. The keys in the parameter map are of type String. The values in the parameter map are of type String array.
So your old code must be casting the keys as a String and the values as a String[] - just like the newer code that would be:
Map<String, String[]> parameterMap = request.getParameterMap();
Both versions will compile in recent versions of the compiler though, again, you may get warnings with the code that doesn't take advantage of generics.
The key is the use of generics - the <String, String[]> part. It's clearer code when using generics and the compiler can help with issues. With the non-generics version you could have tried to cast the key in the map to any object. It would compile but at runtime you'd likely get a ClassCastException.
From the perspective of Tomcat it's still returning the same thing.
Is that clearer?

JDO support for "like" operator

I am learning JDO. I am using it with an sql database. I see no example talking about the common sql "like" operator.
It seems there is no "like operator for compatibility with non sql databases.
I need it. How can I do with JDO?
I add that I am using Datanucleus version 4 as JDO implementation because I am using Apache Isis. It seems that "matches" is implemented only in version 5.
JDOQL supports methods on objects, and follows Java syntax. Consequently it supports String.matches, providing regular expression matching. See the JDO spec and this link in the DataNucleus docs
With datanucleus resolved by Isis 1.15 (core 4.1.1, jdo-query 4.0.5, and so on) I can use "matches" inside a query defined as a string. But I cannot use it in a TypesafeQuery, the StringExpression has no method called "matches".

Gemini Blueprint - PackageAdmin service reference is returning null with spring mvc in IBM Liberty

I am trying to deploy the spring osgi application in IBM Websphere liberty server using gemini blueprint virgo DM. While deploying the application, I am facing the below error, says " ....PackageAdmin service is required . Can anyone has an idea on this?
java.lang.IllegalStateException:
org.osgi.service.packageadmin.PackageAdmin service is required at
org.eclipse.gemini.blueprint.io.internal.resolver.PackageAdminResolver$1.run(PackageAdminResolver.java:179)
at
org.eclipse.gemini.blueprint.io.internal.resolver.PackageAdminResolver$1.run(PackageAdminResolver.java:174)
at java.security.AccessController.doPrivileged(Native Method) at
org.eclipse.gemini.blueprint.io.internal.resolver.PackageAdminResolver.getPackageAdmin(PackageAdminResolver.java:174)
at
org.eclipse.gemini.blueprint.io.internal.resolver.PackageAdminResolver.getImportedBundles(PackageAdminResolver.java:67)
at
org.eclipse.gemini.blueprint.io.OsgiBundleResourcePatternResolver.findClassPathMatchingResources(OsgiBundleResourcePatternResolver.java:217)
at
org.eclipse.gemini.blueprint.io.OsgiBundleResourcePatternResolver.findResources(OsgiBundleResourcePatternResolver.java:154)
at
org.eclipse.gemini.blueprint.io.OsgiBundleResourcePatternResolver.getResources(OsgiBundleResourcePatternResolver.java:186)
at
org.eclipse.gemini.blueprint.context.support.AbstractOsgiBundleApplicationContext.getResources(AbstractOsgiBundleApplicationContext.java:439)
at
org.eclipse.virgo.web.dm.ServerOsgiBundleXmlWebApplicationContext.getResources(ServerOsgiBundleXmlWebApplicationContext.java:346)
at
org.springframework.context.annotation.ClassPathScanningCandidateComponentProvider.findCandidateComponents(ClassPathScanningCandidateComponentProvider.java:270)
at
org.springframework.context.annotation.ClassPathBeanDefinitionScanner.doScan(ClassPathBeanDefinitionScanner.java:248)
at
org.springframework.context.annotation.ComponentScanBeanDefinitionParser.parse(ComponentScanBeanDefinitionParser.java:87)
at
org.springframework.beans.factory.xml.NamespaceHandlerSupport.parse(NamespaceHandlerSupport.java:74)
at
org.springframework.beans.factory.xml.BeanDefinitionParserDelegate.parseCustomElement(BeanDefinitionParserDelegate.java:1411)
at
org.springframework.beans.factory.xml.BeanDefinitionParserDelegate.parseCustomElement(BeanDefinitionParserDelegate.java:1401)
at
org.springframework.beans.factory.xml.DefaultBeanDefinitionDocumentReader.parseBeanDefinitions(DefaultBeanDefinitionDocumentReader.java:172)
at
org.springframework.beans.factory.xml.DefaultBeanDefinitionDocumentReader.doRegisterBeanDefinitions(DefaultBeanDefinitionDocumentReader.java:142)
at
org.springframework.beans.factory.xml.DefaultBeanDefinitionDocumentReader.registerBeanDefinitions(DefaultBeanDefinitionDocumentReader.java:94)
at
org.springframework.beans.factory.xml.XmlBeanDefinitionReader.registerBeanDefinitions(XmlBeanDefinitionReader.java:508)
at
org.springframework.beans.factory.xml.XmlBeanDefinitionReader.doLoadBeanDefinitions(XmlBeanDefinitionReader.java:392)
... 25 more
Starting from fixpack 8.5.5.9 of Liberty, PackageAdmin will not be available to the application region unless you create a custom Liberty feature that exports the package admin service using the IBM-API-Service header.
Create a Liberty feature as explained in this article
Make sure that the feature exports PackageAdmin as in the example below
Declare your custom feature to server.xml using usr:myfeature
Subsystem-ManifestVersion: 1.0
IBM-Feature-Version: 2
IBM-ShortName: myfeature
Subsystem-SymbolicName: myfeature;visibility:=public
Subsystem-Version: 1.0.0
Subsystem-Type: osgi.subsystem.feature
Manifest-Version: 1.0
IBM-API-Service: javax.xml.parsers.SAXParserFactory,
org.osgi.service.packageadmin.PackageAdmin,
org.osgi.service.cm.ConfigurationAdmin
According to the description of a defect fix in 8.5.5.9 fixpack, IBM made this change because Liberty was leaking its own services to the application, so now the OSGi services registered by Liberty are not visible to the application unless you create a feature like the one below to export explicitly those that you need.

Oracle BPEL 12c The prefix "fn-bea" used in the qualified name "fn-bea:serialize" can not be resolved

I'm trying to use fn-bea:serialize($iter) to get xml node content as string in Oracle BPEL 12c XQuery functions but I'm recieving
The prefix "fn-bea" used in the qualified name "fn-bea:serialize" can
not be resolved
In Oracle OSB 12c I don't have any problems using the same XQuery function, but I need to use it in Oracle BPEL.
I'll apreciate any help.
Thanks in advance!!
You should use fn:serialize which should be available in both OSB and BPEL 12. OSB and BPEL use the same XQuery processor internally. When you invoke XQuery from BPEL, just make sure you are using the 1.0 XQuery processor/function.

How to keep implementation and documentation in sync when using swagger 2.0 to document the REST API?

I want to use Swagger 2.0 to document REST API as this seems to be widely used to document RET APIs.
However, I am not sure how can I keep the documentation and implementation in Sync ? e.g. When I add a new API then I have to make sure that the model (to represent the Response) used in the API documentation should be same as the model created in the REST implementation. Similarly, the resource name given in the documentation should match the resource name in the implementation.
Is there a way to generate just the resource interface and model classes from the documentation produced using swagger 2.0 spec ?
You can generate server source with these tools (they can also generate client source) :
http://studio.restlet.com: online editor, generate server skeleton code for java (Jax-RS and Restlet) and Node.js
http://editor.swagger.io: online editor, generate server skeleton code for java (Jax-RS), Node.js, Scalatra and Java Spring MVC
https://github.com/swagger-api/swagger-codegen: swagger code generator, you can try to implement your own generator module (personally, I'm currently trying to use this one)

Resources