I've got a Maven jar project in which I use Birt in order to generate some PDF.
In order to use Birt engine, I've just added this dependency to my <dependencies>:
<dependency>
<groupId>org.eclipse.birt.runtime</groupId>
<artifactId>org.eclipse.birt.runtime</artifactId>
<version>4.4.2</version>
</dependency>
I run my main class using mvn exec:java.
My question is: when I was using the Birt runtime without Maven, I could add Birt plugins in the plugins dir and modify plugins/org.eclipse.birt.report.engine.fonts_4.4.2.v201410272105/fontsConfig.xml in order to add specific <font-paths><path ..., how can I do this using this Maven environment?
I'm not sure also which path I must give to org.eclipse.birt.core.framework.PlatformConfig.setBIRTHome(String) or org.eclipse.birt.report.engine.api.EngineConfig.setEngineHome(String) now.
I've tried to follow the guide and used config.setEngineHome("absolute_path_to_a_4.4.2_osgi_birt_runtime") but then I've got that stacktrace (inside a call to factory.createReportEngine(config)):
java.lang.NullPointerException
at org.eclipse.birt.report.engine.api.impl.ReportEngine$EngineExtensionManager.<init>(ReportEngine.java:822)
at org.eclipse.birt.report.engine.api.impl.ReportEngine.<init>(ReportEngine.java:111)
at org.eclipse.birt.report.engine.api.impl.ReportEngineFactory$1.run(ReportEngineFactory.java:18)
at org.eclipse.birt.report.engine.api.impl.ReportEngineFactory$1.run(ReportEngineFactory.java:1)
at java.security.AccessController.doPrivileged(Native Method)
at org.eclipse.birt.report.engine.api.impl.ReportEngineFactory.createReportEngine(ReportEngineFactory.java:14)
It seems that Platform.getExtensionRegistry() returns null...
If I don't call config.setEngineHome nor config.setBIRTHome, then I've got org.eclipse.birt.report.engine.api.impl.ParameterValidationException: Required parameter myParam is not set., error that I didn't have before migrating to Maven (actually, my rptdesign use myParam from a linked library).
I've also posted my question to Birt dev forums.
First of all, you can use Birt 4.4.2 with this Maven configuration (due to the fact that the pom.xml of the runtime is buggy and declares 2 different versions of those dependencies) :
<dependency>
<groupId>org.eclipse.birt.runtime</groupId>
<artifactId>org.eclipse.birt.runtime</artifactId>
<version>4.4.2</version>
<exclusions>
<exclusion>
<groupId>org.eclipse.birt.runtime</groupId>
<artifactId>org.eclipse.osgi.services</artifactId>
</exclusion>
<exclusion>
<groupId>org.eclipse.birt.runtime</groupId>
<artifactId>com.ibm.icu</artifactId>
</exclusion>
</exclusions>
</dependency>
<dependency>
<groupId>org.eclipse.birt.runtime</groupId>
<artifactId>org.eclipse.osgi.services</artifactId>
<version>3.4.0.v20140312-2051</version>
</dependency>
<dependency>
<groupId>org.eclipse.birt.runtime</groupId>
<artifactId>com.ibm.icu</artifactId>
<version>52.1.1.v201501240615</version>
</dependency>
Then, any Birt plugin can be added just like any classic Maven dependency (provided the fact that there is a correct META-INF/MANIFEST.MF defining Bundle-Name & Bundle-Version properties).
Then you have to launch the Birt engine in POJO mode: without calling EngineConfig.setEngineHome(engineHome).
Finally, for the font config, you can use either:
EngineConfig.setFontConfig(pathToFontsConfigXmlAsUrl) (thanks for that answer)
FontFactory.register("path/to/myfont.ttf") (thanks for that answer) if you want to load a specific font from the classpath
FontFactory.registerDirectory("/path/to/external/dir") if you want to declare an external directory of font to use (thanks for that answer)
Here is an example of bootstrap code (based on Birt website directives):
try{
final EngineConfig config = new EngineConfig( );
config.setLogConfig("c:/temp", Level.FINE);
config.setFontConfig("c:/temp/fontsConfig.xml");
Platform.startup( config );
//If using RE API in Eclipse/RCP application this is not needed.
IReportEngineFactory factory = (IReportEngineFactory) Platform
.createFactoryObject( IReportEngineFactory.EXTENSION_REPORT_ENGINE_FACTORY );
IReportEngine engine = factory.createReportEngine( config );
engine.changeLogLevel( Level.WARNING );
}catch( Exception ex){
ex.printStackTrace();
}
// Run reports, etc.
...
// destroy the engine.
try
{
engine.destroy();
Platform.shutdown();
//Bugzilla 351052
RegistryProviderFactory.releaseDefault();
}catch ( EngineException e1 ){
// Ignore
}
Related
I've been having issues with JSP since moving to Java 17 and Spring Boot 3. I know that we need to use jakarta.* instead of javax.*, but is there something I'm missing? I am using Spring Tools 4 and just running a basic web app using JSP. When using the following dependencies
<dependency>
<groupId>jakarta.servlet</groupId>
<artifactId>jakarta.servlet-api</artifactId>
<scope>provided</scope>
</dependency>
<dependency>
<groupId>org.glassfish.web</groupId>
<artifactId>jakarta.servlet.jsp.jstl</artifactId>
</dependency>
The project runs, but I get the following error
The superclass "javax.servlet.http.HttpServlet", determined from the Dynamic Web Module facet version (2.5), was not found on the Java Build Path
I can get rid of it by adding the javax servlet dependency
<dependency>
<groupId>javax.servlet</groupId>
<artifactId>javax.servlet-api</artifactId>
<version>4.0.1</version>
<scope>provided</scope>
</dependency>
But that goes against using javax.* dependencies with Spring Boot 3.
I have read these articles and tried adding the jakarta.servlet.jsp dependency with no luck.
https://debugah.com/solved-tomcat10-error-jakarta-servlet-servletexception-class-com-kuang-servlet-helloservlet-is-not-a-servlet-22749/
https://howtodoinjava.com/java/exception-handling/solved-the-superclass-javax-servlet-http-httpservlet-was-not-found-on-the-java-build-path-in-eclipse/
Solved!
All I had to do was go into Project Properties and under Project Faces, change my Dynamic Web Module from 2.5 to 5.0
The JSTL warning can be suppressed under Properties->Web->JSP Files->Validation->Custom actions->Other problems with TagExtraInfo class (Just change from 'Warning' to 'Ignore')
I am integrating Outlook API and for making HTTP Calls I am using Retrofit version 2.3.0 and okHttp3 version 3.9.1.
However when I'm making an HTTP Call, for example :
// Create a logging interceptor to log request and responses
HttpLoggingInterceptor interceptor = new HttpLoggingInterceptor();
interceptor.setLevel( HttpLoggingInterceptor.Level.BODY );
OkHttpClient client = new OkHttpClient.Builder().addInterceptor( interceptor ).build();
// Create and configure the Retrofit object
Retrofit retrofit = new Retrofit.Builder().baseUrl( authority ).client( client ).addConverterFactory( JacksonConverterFactory.create() ).build();
// Generate the token service
TokenService tokenService = retrofit.create( TokenService.class );
try
{
return tokenService.getAccessTokenFromAuthCode( tenantId, getAppId(), getAppPassword(), "authorization_code", authCode, getRedirectUrl() ).execute().body();
}
catch ( IOException e )
{
TokenResponse error = new TokenResponse();
error.setError( "IOException" );
error.setErrorDescription( e.getMessage() );
return error;
}
I am getting following exception :
org.springframework.web.util.NestedServletException: Handler dispatch failed; nested exception is java.lang.NoSuchMethodError: okio.BufferedSource.rangeEquals(JLokio/ByteString;)Z
Below is my partial pom.xml :
<!-- JACKSON DEPENDENCY FOR JSON PARSING -->
<dependency>
<groupId>com.fasterxml.jackson.core</groupId>
<artifactId>jackson-core</artifactId>
<version>2.9.3</version>
</dependency>
<dependency>
<groupId>com.fasterxml.jackson.core</groupId>
<artifactId>jackson-annotations</artifactId>
<version>2.9.3</version>
</dependency>
<dependency>
<groupId>com.fasterxml.jackson.core</groupId>
<artifactId>jackson-databind</artifactId>
<version>2.9.3</version>
</dependency>
<!-- RETROFIT DEPENDENCY FOR SENDING HTTP REQUESTS -->
<dependency>
<groupId>com.squareup.retrofit2</groupId>
<artifactId>retrofit</artifactId>
<version>2.3.0</version>
</dependency>
<dependency>
<groupId>com.squareup.retrofit2</groupId>
<artifactId>converter-jackson</artifactId>
<version>2.3.0</version>
</dependency>
<dependency>
<groupId>com.squareup.okhttp3</groupId>
<artifactId>logging-interceptor</artifactId>
<version>3.9.1</version>
</dependency>
Can some one help me figure out, what's wrong with this?
BufferedSource
is in okio project version 1.13.0.
Both dependencies com.squareup.retrofit2 and com.squareup.okhttp3 use this version. Also in this version this method is included. Version-wise it looks okay.
Local Environemnt
Now make sure to clear your maven repository. Maybe an old version got hung up somewhere. After that do a maven update project and a clean install.
Tomcat Environment
If this is happening in your tomcat make also sure to delete the work/Catalina/localhost/ folder, because sometimes things could be cached there.
I experienced a similar issue while executing a MapReduce job via YARN. In my case, an existing downgraded okio version was present which was overriding the external libraries of the application. I changed it to okio 1.13.0 and the issue was fixed.
It was this location for me:
/home/vagrant/bigdata/hadoop/share/hadoop/hdfs/lib
This could be because a conflict with an existing Okio version, provided by a dependency.
See Spark and Influx: OKIO conflict, there is a conflict with Apache Spark.
Use Maven / Gradle dep. tree export to see all transitive dep, or (in my case) :
jar tf /usr/hdp/current/spark-client/lib/spark-assembly-1.6.3.2.6.3.0-235-hadoop2.7.3.2.6.3.0-235.jar | grep okio
This will list:
okio/BufferedSource.class
Then extract the okhttp pom.xml:
jar xf /usr/hdp/current/spark-client/lib/spark-assembly-1.6.3.2.6.3.0-235-hadoop2.7.3.2.6.3.0-235.jar META-INF/maven/com.squareup.okhttp/okhttp/pom.xml
cat META-INF/maven/com.squareup.okhttp/okhttp/pom.xml | grep version
Experienced similar issue executing Spark job on EMR via YARN, as Okio/Okhttp dependencies for an external library used in the application were being overridden by those distributed on a system class path for Spark.
Resolution: Shade/relocate the Okio dependency in the external library's build.
I get vaadin-client-compiler artifact (which brings Jetty with it) included with my production project. Am I supposed to ?
To reproduce I'm starting from scratch and letting Maven generate a Vaadin multimodule project for me:
mvn
-DarchetypeGroupId=com.vaadin
-DarchetypeArtifactId=vaadin-archetype-application-multimodule
-DarchetypeVersion=7.6.2
-DarchetypeRepository=http://repo.maven.apache.org/maven2/
-DgroupId=com.acme
-DartifactId=VaadinTest1
-Dversion=1.0.0-SNAPSHOT
-Dpackage=com.acme.vaadintest1
-Dbasedir=D:\\dev\\java
-DthemeName=mytheme
-DwidgetsetName=MyAppWidgetset
-DuiName=MyUI
-Darchetype.interactive=false
--batch-mode archetype:generate
Then in the parent project I execute:
mvn -Pproduction clean install
After this is done I look into the WAR file generated in the "xxx-production" project and notice it contains vaadin-client-compiler, Jetty, and what not.
I've found this ticket and by looking at the last comment it seems I shouldn't have anything like that in my production WAR. I hesitate to change my POMs as they are generated by the archetype and I guess at some level supposed to represent kind of a Vaadin best-practice approach. I wouldn't want to second guess that. Or ?
The problem with these artifacts being part of the classpath is that
it balloons the size of the WAR
it creates some problems wrt Atmosphere which supposedly gets confused because it finds Jetty on the classpath. (Atmosphere is used under the hood by Vaadin)
The result is that you'll get SEVERE error like this in the log when deploying on Tomcat 8:
14-Feb-2016 16:42:30.368 SEVERE [localhost-startStop-1] org.atmosphere.cpr.DefaultAsyncSupportResolver.newCometSupport Failed to create comet support class: class org.
atmosphere.container.JettyServlet30AsyncSupportWithWebSocket, error: null
To sum up:
Is it correct that I'm not supposed to have these artifacts in a
Vaadin 7.6.2 production project ?
How to solve ?
I believe I've found the answer. It seems Vaadin team was/is fully aware of this but it is kind of a left-over from the old days when there was some kind of annoying bug.
In your xxx-widgetset project you'll see something like this in the POM for that project:
<dependencies>
<!-- Versions for these are configured in the parent POM -->
<dependency>
<groupId>com.vaadin</groupId>
<artifactId>vaadin-client</artifactId>
<!-- TODO this should have scope provided once http://dev.vaadin.com/ticket/14788 is resolved -->
<!-- <scope>provided</scope> -->
</dependency>
<dependency>
<groupId>com.vaadin</groupId>
<artifactId>vaadin-client-compiler</artifactId>
<!-- TODO this should have scope provided once http://dev.vaadin.com/ticket/14788 is resolved -->
<!-- <scope>provided</scope> -->
</dependency>
... you'll see more deps here if you've added
... Vaadin add-ons to your project.
</dependencies>
See the TODO comments ??
Well, it just so happens that the bug mentioned in ticket 14788 doesn't happen anymore, at least not on 7.6.2. So you can now safely do what the TODO comment says.
This has reduced my WAR size by 50-70 pct.
It seems to me there's no longer any good reason why this archetype generation doesn't actually do what TODO comment says. Currently you'll have to manually correct it every time you generate a new project skeleton.
If you work with a different webserver (in your case Tomcat 8) you don't need the provided jetty-plugin.
As the archetype has some jetty-dependencies you can exclude them with the
exclusions tag in the Maven POM file.
Example
<groupId>com.vaadin</groupId>
<artifactId>vaadin-client-compiler</artifactId>
<version>${vaadin.version}</version>
<exclusions>
<exclusion>
<groupId>org.eclipse.jetty</groupId>
<artifactId>jetty-servlets</artifactId>
</exclusion>
<exclusion>
<groupId>org.eclipse.jetty</groupId>
<artifactId>jetty-annotations</artifactId>
</exclusion>
<exclusion>
<groupId>org.eclipse.jetty</groupId>
<artifactId>jetty-util</artifactId>
</exclusion>
</exclusions>
Moreover delete/comment out all unnecessary "jetty" dependencies found in the module POM files.
I have a program, developed in a maven project through Eclipse, that provides an ETL service which ingests data, generates turtle format RDF using the Jena API, and loads it into a triple store which requires data sent to it using the Sesame API. As such, I need to convert the statements created by the ETL service from Jena to Sesame.
I want to use the following class from Stardog, as it does precisely what I need to do. I tried to add the following dependencies to my pom.xml to resolve the issue:
<dependency>
<groupId>com.complexible.stardog.protocols.http</groupId>
<artifactId>client</artifactId>
<version>${stardog.version}</version>
<exclusions>
<exclusion>
<!-- Depends on this as if it were a jar artifact, when it is a pom -->
<artifactId>sesame</artifactId>
<groupId>org.openrdf.sesame</groupId>
</exclusion>
</exclusions>
</dependency>
<dependency>
<groupId>com.complexible.stardog.reasoning.http</groupId>
<artifactId>client</artifactId>
<version>${stardog.version}</version>
<exclusions>
<exclusion>
<!-- Depends on this as if it were a jar artifact, when it is a pom -->
<artifactId>sesame</artifactId>
<groupId>org.openrdf.sesame</groupId>
</exclusion>
</exclusions>
</dependency>
<dependency>
<groupId>com.complexible.stardog</groupId>
<artifactId>core</artifactId>
<version>${stardog.version}</version>
<exclusions>
<exclusion>
<!-- Depends on this as if it were a jar artifact, when it is a pom -->
<artifactId>sesame</artifactId>
<groupId>org.openrdf.sesame</groupId>
</exclusion>
<exclusion>
<artifactId>license</artifactId>
<groupId>com.clarkparsia</groupId>
</exclusion>
<exclusion>
<artifactId>erg</artifactId>
<groupId>com.complexible.erg</groupId>
</exclusion>
</exclusions>
</dependency>
but I get the following errors:
Missing artifact com.complexible.stardog:shared:jar 2.2.2
Missing artifact org.openrdf.sesame:sesame:jar:2.7.12
Missing artifact com.complexible.stardog:api:jar.2.2.2
I also get errors on the opening Dependency tag for the above dependencies saying that the dependency contained within it is also missing.
Note: stardog.version = 2.2.2 and sesame.version = 2.7.12.
Any ideas?
I don't really know how to help you with the maven dependency problem - this looks very specific to Stardog. If you don't get an answer here you might try asking about this on their support mailinglist instead.
However, I can offer an alternative solution: instead of using a convertor class, you just serialize the Jena objects back to N-Triples or Turtle, and then parse them using Sesame's Rio parser - which will of course create Sesame API objects.
I'm not too familiar with the Jena API but I'm sure there is a way you can write a model to, say, an OutputStream in Turtle format. Once you have that OutputStream, you can simply do something like this:
// in case of very large files, use something more efficient, like a
// PipedOutputStream, or first write back to disk
ByteArrayInputStream in = new ByteArrayInputStream(out.toByteArray());
// parse the data using Sesame Rio, which provides a Sesame Model
// object. You can of course also immediately write the
// data to the store instead of first creating a Model.
org.openrdf.model.Model model = Rio.parse(in, "", RDFFormat.TURTLE);
I am trying to run my application which contain JAX WS (2.1) Webservice using JDeveloper 11g R2(11.1.2.3.0) in JDK 1.6.0_31-b05. The error is coming from #WebService annotation present on the class.
When I am running the application, I am getting below error,
java.lang.IllegalArgumentException: Argument(s) "type" can't be null.
at com.sun.xml.bind.api.TypeReference.<init>(TypeReference.java:89)
at com.sun.xml.ws.model.RuntimeModeler.processDocWrappedMethod(RuntimeModeler.java:758)
at com.sun.xml.ws.model.RuntimeModeler.processMethod(RuntimeModeler.java:678)
at com.sun.xml.ws.model.RuntimeModeler.processClass(RuntimeModeler.java:428)
at com.sun.xml.ws.model.RuntimeModeler.buildRuntimeModel(RuntimeModeler.java:277)
at com.sun.xml.ws.server.EndpointFactory.createSEIModel(EndpointFactory.java:363)
at com.sun.xml.ws.server.EndpointFactory.createEndpoint(EndpointFactory.java:202)
at com.sun.xml.ws.api.server.WSEndpoint.create(WSEndpoint.java:496)
at com.sun.xml.ws.api.server.WSEndpoint.create(WSEndpoint.java:539)
at weblogic.wsee.jaxws.JAXWSDeployedServlet.getEndpoint(JAXWSDeployedServlet.java:183)
It seems that embedded Web Logic is using the internal libraries instead of provided one from JDK. The classes RuntimeModeler or TypeReference are present in JDK rt.jar starts with package com.sun.xml.ws.internal. Weblogic is picking these classes from glassfish.jaxb_1.0.0.0_2-1-12.jar & glassfish.jaxws.rt_1.2.0.0_2-1-5.jar, but these jars are not part of my application.
I have already used weblogic.xml with below tag,
<prefer-web-inf-classes>true</prefer-web-inf-classes>
I tried adding jaxws-api.jar & jws-api.jar in DefaultDomain/lib directory, but that didn't work
Any clue how to resolve this exception or how to force weblogic to use jdk runtime classes? The same application work properly on stand alone weblogic.
I had the same problem and found the answer here: http://www.intropro.com/resources/blog/66-argument-s-type-can-t-be-null
In short - the problem appears because you have jaxb-impl in you classpath which overrides WebLogics own jaxb, You may not explicitly refer to this dependency from your pom.xml, but some of your other dependencies do.
In my case I had apache-cxf as maven dependency and it had jaxb 2.1.13 as sub-dependency with scope "compile". All I had to do is exclude this apaches jaxb and add my own dependency with scope "provided" to explicitly use WebLogics jaxb.
in pom.xml it looked like this:
<dependency>
<groupId>org.apache.cxf</groupId>
<artifactId>cxf-rt-frontend-jaxws</artifactId>
<version>2.7.2</version>
<exclusions>
<exclusion>
<artifactId>jaxb-impl</artifactId>
<groupId>com.sun.xml.bind</groupId>
</exclusion>
</exclusions>
</dependency>
<dependency>
<groupId>com.sun.xml.bind</groupId>
<artifactId>jaxb-impl</artifactId>
<scope>provided</scope>
<version>2.1.13</version>
</dependency>
You can use eclipses "Dependency Hierarchy" tab in pom.xml view or simply command line "mvn dependency:tree" to find out how jaxb-impl made it to your classpath.
In my case, i had a typo in the arguments of the operation, where two arguments had the same webParam name. Modified that and deployed, issue was resolved.
Have you tried listing the correct jar in the manifest class-path: attribute? You could also put the jdk classes in the app and try using a FilteringClassLoader to specify which classes to use from the app rather than system classloader.
http://docs.oracle.com/cd/E15051_01/wls/docs103/programming/classloading.html#wp1097263