I am using the procedure-compiler in my pom file. Adding it and building gives the error in the title.
I learned here: neo4j: user defined procedure exception "Write operations are not allowed for `READ` transactions" that the #Procedure annotation is the old way before 3.1. However i am on 3.2.2.
Disabling the compiler and building seems to work fine so i am sure it is a false positive error. How do i silence it so i can use the compiler again?
Here is one example:
#Procedure(value = "WL.CreateArgumentGroup", mode = Mode.WRITE)
#Description("Takes node id's and create a new arg group with those nodes as premises")
public Stream<LongResult> CreateArgumentGroup(#Name("nodeIds") List<Long> nodeIds)
Pom code:
<properties>
<neo4j.version>3.2.2</neo4j.version>
</properties>
<dependencies>
<dependency>
<groupId>org.neo4j</groupId>
<artifactId>procedure-compiler</artifactId>
<version>${neo4j.version}</version>
<scope>compile</scope>
<optional>true</optional>
</dependency>
Related
At compile time, I am getting the error
the attribute path is undefined for the annotation type
RequestMapping
I have imported org.springframework.web.bind.annotation.PathVariable, but I am still facing same issue.
In pom.xml check dependency version of spring-web. I solved it by changing the version dependency. Previously it was 4.1.4.RELEASE.
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-web</artifactId>
<version>4.2.7.RELEASE</version>
</dependency>
We're running a modular application plattform using Apache ServiceMix 5.3.0. I need to extend our system with a persistence service - so I want to build an OSGi bundle containing Neo4J 2.1.6.
In my pom.xml (Maven) I'm using maven-bundle-plugin (org.apache.felix) to build the bundle. I've added nearly every package from neo4j-kernel and neo4j-lucene-index libs to the <Export-Package> section.
When deployed my bundle shows up in "resolved" state. But when beeing started it throws this:
org.osgi.framework.BundleException: Activator start error ...
...
Caused by: java.lang.ArrayIndexOutOfBoundsException: 0
at org.neo4j.graphdb.factory.GraphDatabaseSettings.<clinit (GraphDatabaseSettings.java:69)
My activator code looks like this (the exception occurs at the last command):
GraphDatabaseFactory factory = new GraphDatabaseFactory();
/*
ArrayList<CacheProvider> caches = new ArrayList();
caches.add(new SoftCacheProvider());
factory.setCacheProviders(caches);
*/
GraphDatabaseBuilder builder = factory.newEmbeddedDatabaseBuilder("neo4j-db");
graphDb = builder.newGraphDatabase();
(It doesn't make a difference if the commented part is active or not.)
The error pattern looks similar like the one in this question.
I suspect the devil sitting in the following method from org.neo4j.graphdb.factory.GraphDatabaseSettings (line 259f) unable to find any CacheProvider instances, although they are packed and referenced in my bundle (org.neo4j.kernel.impl.cache...):
private static String[] availableCaches()
{
List<String> available = new ArrayList<>();
for ( CacheProvider cacheProvider : Service.load( CacheProvider.class ) )
{
available.add( cacheProvider.getName() );
}
...
return available.toArray( new String[available.size()] );
}
I believe this is very much an OSGi classloader issue rather than a Neo4J issue. Any ideas how to proceed here?
I managed to solve my problem meanwhile. As Neil already supposed, it was neither an OSGi-issue nor a Neo4J-bug. Instead I had to learn some more lessons about how Neo4J binds its extensions and how to shape OSGi dependencies accordingly in order to get ahead.
These are the results of my yesterday's research:
(1) Collect all packages
My mistake was to rely on maven-bundle-plugin's capability to parse the project and automatically break down all internal dependencies to package level (which is neccessary for OSGi). This works perfectly for class relations that are declared by import statements, but, of course, will fail where reflection methods are used to bind external stuff.
As the application worked perfectly in my JUnit environment the reasons for my problem had to include missing resources in the OSGi envirmonment.
The solution was to religiously list each single package of every library in the plugins Export-Package, Private-Package and Import-Package section accordingly (the list got quite lengthly) instead of trusting to wildcards.
(2) Neo4J kernel extensions
Heeding the above topics I got rid of the mentioned ArrayIndexOutOfBoundsException but I right ran into other (similar) exceptions. I got ahead after I learned about Neo4J's "kernel extension" concept.
Neo4J (I have version 2.1.6) has introduced "kernel extensions" to couple exchangeable modules for caching and indexing purpose at runtime. In order to apply a certain extension one just needs to add the according jar to the classpath. Each library carries one or more descriptor files under META-INF/services telling about the available implementations. These files are looked up and processed by the kernel in order to find and bind its extensions (extension for indexing and caching are mandatory).
After I securely had all neccessary java packages included in my bundly only the descriptor files in META-INF/services were missing. This code showed me a way how to add those resources to the bundle (search for the <Embed-Dependency> section in the maven-bundle-plugin.
Neo4J libs also contain a blueprint descriptor to automatically publish major classes as service (e.g. GraphDatabaseFactory). These resources are placed under OSGI-INF/blueprint/, which should also be included in the bundle.
The final pom.xml for my Neo4J OSGi bundle looks like this:
<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
<modelVersion>4.0.0</modelVersion>
<groupId>my.group</groupId>
<artifactId>neo4jBundle</artifactId>
<version>0.1.0</version>
<packaging>bundle</packaging>
<properties>
<neo4j-version>2.1.6</neo4j-version>
<lucene-version>3.6.2</lucene-version>
</properties>
<dependencies>
<dependency>
<groupId>org.neo4j</groupId>
<artifactId>neo4j-kernel</artifactId>
<version>${neo4j-version}</version>
</dependency>
<dependency>
<groupId>org.neo4j</groupId>
<artifactId>neo4j-lucene-index</artifactId>
<version>${neo4j-version}</version>
</dependency>
<dependency>
<groupId>org.slf4j</groupId>
<artifactId>slf4j-nop</artifactId>
</dependency>
<dependency>
<groupId>ch.qos.logback</groupId>
<artifactId>logback-classic</artifactId>
<version>1.1.2</version>
</dependency>
</dependencies>
<build>
<plugins>
<plugin>
<groupId>org.apache.felix</groupId>
<artifactId>maven-bundle-plugin</artifactId>
<extensions>true</extensions>
<configuration>
<instructions>
<Bundle-Name>org.neo4j.kernel</Bundle-Name>
<Export-Package>org.neo4j.graphdb.*;version=${neo4j-version},
... {all neo4j packages} ...
org.apache.lucene;version=${lucene-version},
... {all lucene packages} ...
org.slf4j.impl
</Export-Package>
<Private-Package>
javax.transaction,
javax.transaction.xa,
ch.qos.logback.classic,
... {all logback.classic packages} ...
ch.qos.logback.core,
... {all logback.core packages} ...
org.slf4j.*
</Private-Package>
<Import-Package>
javax.lang.model,
... {some javax packages to be imported from the runtime} ...
!sun.misc,
... {exclude uneccessary packages to limit dependency} ...
*
</Import-Package>
<Embed-Dependency>
*;groupId=org.neo4j;artifactId=neo4j-kernel;inline=META-INF/services/*,
*;groupId=org.neo4j;artifactId=neo4j-kernel;inline=OSGI-INF/blueprint/*,
*;groupId=org.neo4j;artifactId=neo4j-lucene-index;inline=META-INF/services/*,
*;groupId=org.neo4j;artifactId=neo4j-lucene-index;inline=OSGI-INF/blueprint/*
</Embed-Dependency>
</instructions>
</configuration>
</plugin>
</plugins>
</build>
</project>
Remarks: This is a pure library bundle without any additional code. My application with the Activator resides in a seperate bundle.
This example only shows my aproach in solving my problems. My example doesn't claim to produce a general-purpose Neo4J bundle. Depending on the features you want and the society of already deployed stuff in the runtime you might need to add or leave out certain packages to get everything to work.
I am a client to a SOAP service I do not control (implemented in .NET). The service provides a WSDL. I use Apache CXF to generate the java client from the WSDL (specifically, I am using the cxf-codegen-plugin for Maven, which uses wsdl2java under the hood).
However, when I instantiate the generated service class, the following warnings are logged:
Sep 04, 2014 5:18:00 PM [com.sun.xml.internal.ws.policy.EffectiveAlternativeSelector] selectAlternatives
WARNING: WSP0075: Policy assertion "{http://schemas.xmlsoap.org/ws/2005/07/securitypolicy}TransportBinding" was evaluated as "UNKNOWN".
Sep 04, 2014 5:18:00 PM [com.sun.xml.internal.ws.policy.EffectiveAlternativeSelector] selectAlternatives
WARNING: WSP0019: Suboptimal policy alternative selected on the client side with fitness "UNKNOWN".
However the client works correctly--I don't have any problem using the service. However, I am puzzled by these errors.
The error is about this security policy in the WSDL, which I think it says it cannot understand:
<wsp:Policy wsu:Id="soap11_policy" xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd" xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy">
<wsp:ExactlyOne>
<wsp:All>
<sp:TransportBinding xmlns:sp="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy">
<wsp:Policy>
<sp:TransportToken>
<wsp:Policy>
<sp:HttpsToken RequireClientCertificate="false"/>
</wsp:Policy>
</sp:TransportToken>
<sp:AlgorithmSuite>
<wsp:Policy>
<sp:Basic256/>
</wsp:Policy>
</sp:AlgorithmSuite>
<sp:Layout>
<wsp:Policy>
<sp:Strict/>
</wsp:Policy>
</sp:Layout>
</wsp:Policy>
</sp:TransportBinding>
</wsp:All>
</wsp:ExactlyOne>
</wsp:Policy>
However as far as I can tell this is a perfectly ordinary policy with nothing unusual about it. Surely it should be understood? How can I fix this warning?
For the record, here is how wsdl2java is being invoked (excerpt from pom.xml).
The -exsh true arg and cxf-rt-bindings-soap dependency are because the WSDL uses some implicit soap headers in its arguments, and I need this so they are included properly in the generated service class methods.
I added the cxf-rt-ws-security and cxf-rt-ws-policy dependencies to try and fix this warning, thinking that maybe the security and policy information were not included. However, this did not fix anything (didn't break anything either, though).
<plugin>
<groupId>org.apache.cxf</groupId>
<artifactId>cxf-codegen-plugin</artifactId>
<version>3.0.1</version>
<executions>
<execution>
<id>rh-soap-client-ssi</id>
<phase>generate-sources</phase>
<configuration>
<sourceRoot>${project.build.directory}/generated/cxf</sourceRoot>
<wsdlOptions>
<wsdlOption>
<wsdl>https://example.org/ssi?wsdl</wsdl>
<extraargs>
<extraarg>-verbose</extraarg>
<extraarg>-client</extraarg>
<extraarg>-mark-generated</extraarg>
<extraarg>-exsh</extraarg>
<extraarg>true</extraarg>
<extraarg>-autoNameResolution</extraarg>
</extraargs>
</wsdlOption>
</wsdlOptions>
</configuration>
<goals>
<goal>wsdl2java</goal>
</goals>
</execution>
</executions>
<dependencies>
<dependency>
<groupId>org.apache.cxf</groupId>
<artifactId>cxf-rt-bindings-soap</artifactId>
<version>3.0.1</version>
</dependency>
<dependency>
<groupId>org.apache.cxf</groupId>
<artifactId>cxf-rt-ws-security</artifactId>
<version>3.0.1</version>
</dependency>
<dependency>
<groupId>org.apache.cxf</groupId>
<artifactId>cxf-rt-ws-policy</artifactId>
<version>3.0.1</version>
</dependency>
</dependencies>
</plugin>
Through guesswork and looking at artifacts in maven central, I was able to hit upon a solution.
It turns out that in order to actually understand and evaluate the policy in this wsdl, a missing runtime dependency must be provided. For me it was org.apache.cxf/cxf-rt-frontend-jaxws. I could not find this documented anywhere. This pulls in a number of other cxf dependencies and I don't know if a more minimal set of them is ok.
Once I include this dependency, I no longer get a warning when I instantiate the client object. (Also, instantiation takes much longer!)
However, when I try to use the service I get an exception:
javax.xml.ws.soap.SOAPFaultException: None of the policy alternatives can be satisfied.
at org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:159)
...
This is most likely for the reason that Willie Wheeler's answer pointed out: the policy requires 256 bit encryption on the transport, but this service's SSL is using 128 bit encryption. However, using a wsdl with Base128 instead does not resolve this exception and I did not investigate further.
So it's quite possible that everyone who uses this service probably gets this warning or something like it, and it's impossible to use this service if the security policy is actually checked. I guess I will be living with the warning instead.
I can reproduce this issue with the Express-1 label service:
2014-09-10 22:15:29.601 WARN 6564 --- [ main] c.s.x.i.w.w.EffectiveAlternativeSelector : WSP0075: Policy assertion "{http://schemas.xmlsoap.org/ws/2005/07/securitypolicy}TransportBinding" was evaluated as "UNKNOWN".
2014-09-10 22:15:29.602 WARN 6564 --- [ main] c.s.x.i.w.w.EffectiveAlternativeSelector : WSP0019: Suboptimal policy alternative selected on the client side with fitness "UNKNOWN".
I believe the problem is that the policy you inline above requires Basic256 message encryption, but the service's SSL encryption is weaker.
For example, check out this WSDL:
https://service.express1.com/Services/EwsLabelService.svc?wsdl
At the very top you will see a policy identical to the one you give. But then if you look at the site's SSL cert, it is using AES_128_CBC, which is only 128-bit encryption.
See http://specs.xmlsoap.org/ws/2005/07/securitypolicy/ws-securitypolicy.pdf, sections 7.1, 8.1 and 8.3 for information about TransportBinding policies and algorithm suites. I believe that the warning is saying is that the policy requires 256-bit encryption, but because the service doesn't support it, the client is choosing a weaker encryption algorithm in its place.
As this is a problem on the service side, probably the best way to fix it is to notify the party responsible for the service of the issue.
Finally found the correct solution:
You're missing a dependency that provides an implementation of PolicyAssertionValidator to validate a policy of the name {http://schemas.xmlsoap.org/ws/2005/07/securitypolicy}TransportBinding.
The correct dependency to use is org.glassfish.metro:wssx-impl. This library provides a class called SecurityPolicyValidator that can validate said policy. The library will work automatically just by putting it on your classpath.
This solution should work with both the JAX-WS stack and Apache CXF.
I found that these errors are being logged BEFORE the SOAP request is even sent.
The warnings did not appear in Java 6. They do appear in Java 7 and Java 8. My hunch is that these warnings are related to the legacy jaxrpc.jar in my source code.
My "hack" work-around was to download a copy of the WSDL file and modify the policy section. Then point the main class in my web-service to this modified WSDL file.
//Modified tags in my main class. Change the wsdlLocation to point to a file in my source code (instead of a URL)
#WebServiceClient(name = "Service1", targetNamespace = "https://example.org/", wsdlLocation = "WebService.wsdl")
public class Service1
...
Modified WebService.wsdl file:
<wsp:Policy wsu:Id="BasicHttpBinding_IService1_policy">
<wsp:ExactlyOne/>
</wsp:Policy>
Im using Primefaces Push (the new thing in 3.4) together with jsf2 and ejb3. Seperate .war and ejb.jar
Now I need to trigger a prime-push event from the ejb tier. What is a clean way to do this? Some options I can think of:
ManagedBean pass down a callback interface when invoking the ejb method
A JMS messagelistener in the web-tier and ejb to send messages.
Managed bean to analyze returned data from ejb method invocation and do push if conditions are met.
Basicly the question is where to put below code?
PushContext pushContext = PushContextFactory.getDefault().getPushContext();
pushContext.push("/notifications", new FacesMessage(summary, detail));
What i've got working, I didnt go with any of my ideas above, just added dependencies needed to access atmosphere APIs from EJB-tier.
MANIFEST.MF for ejb.jar:
Manifest-Version: 1.0
Class-Path:
atmosphere-runtime-1.0.1.jar
atmosphere-compat-jbossweb-1.0.1.jar
atmosphere-compat-tomcat7-1.0.1.jar
atmosphere-compat-tomcat-1.0.1.jar
in pom.xml for ejb.jar and application.ear
<dependency>
<groupId>org.atmosphere</groupId>
<artifactId>atmosphere-runtime</artifactId>
<version>1.0.1</version>
<scope>provided</scope>
</dependency>
Then simply copied two packages from primefaces sources into ejb.jar
org.primefaces.push
org.primefaces.json
because adding primefaces in pom.xml for ejb.jar caused
Missing artifact org.primefaces:primefaces
I'm getting the following exception on startup with Dropwizard
Exception in thread "main" javax.validation.ValidationException: Call to TraversableResolver.isReachable() threw an exception
at org.hibernate.validator.engine.ValidatorImpl.isValidationRequired(ValidatorImpl.java:1251)
at org.hibernate.validator.engine.ValidatorImpl.validateConstraint(ValidatorImpl.java:448)
at org.hibernate.validator.engine.ValidatorImpl.validateConstraintsForDefaultGroup(ValidatorImpl.java:397)
at org.hibernate.validator.engine.ValidatorImpl.validateConstraintsForCurrentGroup(ValidatorImpl.java:361)
at org.hibernate.validator.engine.ValidatorImpl.validateInContext(ValidatorImpl.java:313)
at org.hibernate.validator.engine.ValidatorImpl.validate(ValidatorImpl.java:139)
at com.yammer.dropwizard.validation.Validator.validate(Validator.java:32)
at com.yammer.dropwizard.config.ConfigurationFactory.validate(ConfigurationFactory.java:88)
at com.yammer.dropwizard.config.ConfigurationFactory.build(ConfigurationFactory.java:53)
at com.yammer.dropwizard.cli.ConfiguredCommand.run(ConfiguredCommand.java:69)
at com.yammer.dropwizard.cli.Command.run(Command.java:113)
at com.yammer.dropwizard.AbstractService.run(AbstractService.java:178)
I'm using Dropwizard with Hibernate for JPA rather than JDBI since I have complex persistence requirements.
And the answer was all to do with my own muppetry. I was introducing an older version of the Hibernate Entity Manager as part of my other dependencies in the pom.xml.
For Dropwizard 0.4.0 you'll need to force use of Hibernate Entity Manager 3.6.0.Final. Hopefully this will help others.
<dependency>
<groupId>org.hibernate</groupId>
<artifactId>hibernate-entitymanager</artifactId>
<version>3.6.0.Final</version>
</dependency>