Can't get Apache POI to work in SSJS - apache-poi

I'm trying to import an excel sheet of any kind (xls/xslx) into my database via an Xpage and the following code returns with an error:
importPackage(org.apache.poi.ss.usermodel);
var tempFile:java.io.File = fileData.getServerFile();
var wb:WorkBook = WorkbookFactory.create(tempFile);
var sheet:Sheet = wb.getSheetAt(0);
var rows = sheet.getPhysicalNumberOfRows();
"WorkbookFactory not found"
I have put the API in buld path: /tradesec(9).nsf/WebContent/WEB-INF/lib/poi-3.9-20121203.jar
I have tried this without the importPackage but without luck. 'org' not found
Please advice!
/M
update:
I have now copied all jars from POI to jvm/lib/ext, added a grant for everything in java.policy, created a java class as a bean.
Still getting exceptions:
sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:56)
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:39)
java.lang.reflect.Constructor.newInstance(Constructor.java:527)
com.ibm.jscript.types.JavaAccessObject.construct(JavaAccessObject.java:260)
com.ibm.jscript.types.JavaWrapperObject.construct(JavaWrapperObject.java:1)
com.ibm.jscript.ASTTree.ASTNew.interpret(ASTNew.java:109)
com.ibm.jscript.ASTTree.ASTMember.interpret(ASTMember.java:106)
com.ibm.jscript.ASTTree.ASTCall.interpret(ASTCall.java:88)
com.ibm.jscript.ASTTree.ASTVariableDecl.interpret(ASTVariableDecl.java:82)
com.ibm.jscript.ASTTree.ASTBlock.interpret(ASTBlock.java:100)
com.ibm.jscript.ASTTree.ASTTry.interpret(ASTTry.java:109)
com.ibm.jscript.ASTTree.ASTBlock.interpret(ASTBlock.java:100)
com.ibm.jscript.ASTTree.ASTTry.interpret(ASTTry.java:109)
com.ibm.jscript.ASTTree.ASTIf.interpret(ASTIf.java:85)
com.ibm.jscript.ASTTree.ASTBlock.interpret(ASTBlock.java:100)
com.ibm.jscript.ASTTree.ASTTry.interpret(ASTTry.java:109)
com.ibm.jscript.ASTTree.ASTProgram.interpret(ASTProgram.java:119)
com.ibm.jscript.ASTTree.ASTProgram.interpretEx(ASTProgram.java:139)
com.ibm.jscript.JSExpression._interpretExpression(JSExpression.java:435)
com.ibm.jscript.JSExpression.access$1(JSExpression.java:424)
com.ibm.jscript.JSExpression$2.run(JSExpression.java:414)
java.security.AccessController.doPrivileged(AccessController.java:310)
com.ibm.jscript.JSExpression.interpretExpression(JSExpression.java:410)
com.ibm.jscript.JSExpression.evaluateValue(JSExpression.java:251)
com.ibm.jscript.JSExpression.evaluateValue(JSExpression.java:234)
com.ibm.xsp.javascript.JavaScriptInterpreter.interpret(JavaScriptInterpreter.java:221)
com.ibm.xsp.binding.javascript.JavaScriptMethodBinding.invoke(JavaScriptMethodBinding.java:111)
com.ibm.xsp.actions.ActionGroup.invoke(ActionGroup.java:135)
com.ibm.xsp.component.UIViewRootEx.invokePhaseMethodBinding(UIViewRootEx.java:1735)
com.ibm.xsp.controller.FacesControllerImpl.invokePhaseMethodBinding(FacesControllerImpl.java:444)
com.ibm.xsp.controller.FacesControllerImpl.access$0(FacesControllerImpl.java:438)
com.ibm.xsp.controller.FacesControllerImpl$ViewPhaseListener.beforePhase(FacesControllerImpl.java:527)
com.sun.faces.lifecycle.LifecycleImpl.phase(LifecycleImpl.java:197)
com.sun.faces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:120)
com.ibm.xsp.controller.FacesControllerImpl.render(FacesControllerImpl.java:264)
com.ibm.xsp.webapp.FacesServlet.serviceView(FacesServlet.java:248)
com.ibm.xsp.webapp.FacesServletEx.serviceView(FacesServletEx.java:204)
com.ibm.xsp.webapp.FacesServlet.service(FacesServlet.java:160)
com.ibm.xsp.webapp.FacesServletEx.service(FacesServletEx.java:138)
com.ibm.xsp.webapp.DesignerFacesServlet.service(DesignerFacesServlet.java:103)
com.ibm.designer.runtime.domino.adapter.ComponentModule.invokeServlet(ComponentModule.java:583)
com.ibm.domino.xsp.module.nsf.NSFComponentModule.invokeServlet(NSFComponentModule.java:1281)
com.ibm.designer.runtime.domino.adapter.ComponentModule$AdapterInvoker.invokeServlet(ComponentModule.java:860)
com.ibm.designer.runtime.domino.adapter.ComponentModule$ServletInvoker.doService(ComponentModule.java:803)
com.ibm.designer.runtime.domino.adapter.ComponentModule.doService(ComponentModule.java:572)
com.ibm.domino.xsp.module.nsf.NSFComponentModule.doService(NSFComponentModule.java:1265)
com.ibm.domino.xsp.module.nsf.NSFService.doServiceInternal(NSFService.java:658)
com.ibm.domino.xsp.module.nsf.NSFService.doService(NSFService.java:481)
com.ibm.designer.runtime.domino.adapter.LCDEnvironment.doService(LCDEnvironment.java:341)
com.ibm.designer.runtime.domino.adapter.LCDEnvironment.service(LCDEnvironment.java:297)
com.ibm.domino.xsp.bridge.http.engine.XspCmdManager.service(XspCmdManager.java:272)
My knowledge in this section is quite limited I must say.
Currently I'm considering moving away from this and start implementing a plain old text file instead. Too much overhead and dependencies for my tight project schedule to handle, I'm afraid.
If someone out there finds a solution I'm happy to explore it

Make sure that You added poi-ooxml-3.9-20121203.jar to the build path also. The poi-3.9-20121203.jar jar does not contain WorkbookFactory class.

There are class loader related problems with dom4j (used by the POI XLSX parser) when loading from the Domino database. Try adding the needed jars to the filesystem in the jvm/lib/ext directory (both Domino and Notes) and opening up the java.security a bit (see http://www.wissel.net/blog/d6plinks/SHWL-8JYAT5).
I'm having success with the unrestricted grant { permission java.security.AllPermission; };. It would be better to be a bit more restricted, but I have not yet found the time to investigate the issue any further.
You can also try loading the jars by loading the POI 4 XPages OSGi library: http://www.openntf.org/internal/home.nsf/project.xsp?action=openDocument&name=POI%204%20XPages

Try adding the full path to the WorkbookFactory that is what I have done before when referencing classes within jars.

Related

Scala + SBT - How to configure reference.conf for a shaded Akka library

TL;DR
I am trying to shade a version of the akka library and bundle it with my application (to be able to run a spray-can server on the CDH 5.7 version of Spark 1.6). The shading process messes up akka's default configuration, and after manually providing a separate version of akka's reference.conf for the shaded akka, it still looks like the 2 versions get mixed up somehow.
Is shading akka versions known to cause problems? What am I doing wrong?
Background
I have a Scala/Spark application currently running on Spark 1.6.1 standalone. The application runs a spray-can http server using spray 1.3.3, which requires akka 2.3.9 (Spark 1.6.1 standalone includes a compatible akka 2.3.11).
I am trying to migrate the application to a new Cloudera-based Spark cluster running the CDH 5.7 version of Spark 1.6. The problem is that Spark 1.6 in CDH 5.7 is bundled with akka 2.2.3 which is not sufficient for spray 1.3.3 to function properly.
Attempted solution
Following the suggestion in this post, I decided to shade akka 2.3.9 and bundle it along with my application. Although this time I stumbled upon a new problem - akka has it's default configuration defined in a reference.conf file, which should be located on the application's classpath. Due to a known issue in sbt-assembly's shading feature, it seems that the shaded akka library would require a separate configuration.
So, I ended up shading akka with the following shade rule:
ShadeRule.rename("akka.**" -> "akka_2_3_9_shade.#1")
.inLibrary("com.typesafe.akka" % "akka-actor_2.10" % "2.3.9")
.inAll
and including an additional reference.conf file in my project, which is identical to akka's original reference.conf, but with all occurances of "akka" replaced with "akka_2_3_9_shade".
Now, though, it seems that the Spark-provided akka gets mixed up somehow with the shaded akka, as I'm getting the following error:
Exception in thread "main" java.lang.IllegalArgumentException: Cannot instantiate MailboxType [akka.dispatch.UnboundedMailbox], defined in [akka.actor.default-mailbox], make sure it has a public constructor with [akka.actor.ActorSystem.Settings, com.typesafe.config.Config] parameters
at akka_2_3_9_shade.dispatch.Mailboxes$$anonfun$1.applyOrElse(Mailboxes.scala:197)
at akka_2_3_9_shade.dispatch.Mailboxes$$anonfun$1.applyOrElse(Mailboxes.scala:195)
at scala.runtime.AbstractPartialFunction.apply(AbstractPartialFunction.scala:33)
at scala.util.Failure$$anonfun$recover$1.apply(Try.scala:185)
at scala.util.Try$.apply(Try.scala:161)
at scala.util.Failure.recover(Try.scala:185)
at akka_2_3_9_shade.dispatch.Mailboxes.lookupConfiguration(Mailboxes.scala:195)
at akka_2_3_9_shade.dispatch.Mailboxes.lookup(Mailboxes.scala:78)
at akka_2_3_9_shade.actor.LocalActorRefProvider.akka$actor$LocalActorRefProvider$$defaultMailbox$lzycompute(ActorRefProvider.scala:561)
at akka_2_3_9_shade.actor.LocalActorRefProvider.akka$actor$LocalActorRefProvider$$defaultMailbox(ActorRefProvider.scala:561)
at akka_2_3_9_shade.actor.LocalActorRefProvider$$anon$1.<init>(ActorRefProvider.scala:568)
at akka_2_3_9_shade.actor.LocalActorRefProvider.rootGuardian$lzycompute(ActorRefProvider.scala:564)
at akka_2_3_9_shade.actor.LocalActorRefProvider.rootGuardian(ActorRefProvider.scala:563)
at akka_2_3_9_shade.actor.LocalActorRefProvider.init(ActorRefProvider.scala:618)
at akka_2_3_9_shade.actor.ActorSystemImpl.liftedTree2$1(ActorSystem.scala:619)
at akka_2_3_9_shade.actor.ActorSystemImpl._start$lzycompute(ActorSystem.scala:616)
at akka_2_3_9_shade.actor.ActorSystemImpl._start(ActorSystem.scala:616)
at akka_2_3_9_shade.actor.ActorSystemImpl.start(ActorSystem.scala:633)
at akka_2_3_9_shade.actor.ActorSystem$.apply(ActorSystem.scala:142)
at akka_2_3_9_shade.actor.ActorSystem$.apply(ActorSystem.scala:109)
at akka_2_3_9_shade.actor.ActorSystem$.apply(ActorSystem.scala:100)
at MyApp.api.Boot$delayedInit$body.apply(Boot.scala:45)
at scala.Function0$class.apply$mcV$sp(Function0.scala:40)
at scala.runtime.AbstractFunction0.apply$mcV$sp(AbstractFunction0.scala:12)
at scala.App$$anonfun$main$1.apply(App.scala:71)
at scala.App$$anonfun$main$1.apply(App.scala:71)
at scala.collection.immutable.List.foreach(List.scala:318)
at scala.collection.generic.TraversableForwarder$class.foreach(TraversableForwarder.scala:32)
at scala.App$class.main(App.scala:71)
at MyApp.api.Boot$.main(Boot.scala:28)
at MyApp.api.Boot.main(Boot.scala)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
at org.apache.spark.deploy.SparkSubmit$.org$apache$spark$deploy$SparkSubmit$$runMain(SparkSubmit.scala:731)
at org.apache.spark.deploy.SparkSubmit$.doRunMain$1(SparkSubmit.scala:181)
at org.apache.spark.deploy.SparkSubmit$.submit(SparkSubmit.scala:206)
at org.apache.spark.deploy.SparkSubmit$.main(SparkSubmit.scala:121)
at org.apache.spark.deploy.SparkSubmit.main(SparkSubmit.scala)
Caused by: java.lang.ClassCastException: interface akka_2_3_9_shade.dispatch.MailboxType is not assignable from class akka.dispatch.UnboundedMailbox
at akka_2_3_9_shade.actor.ReflectiveDynamicAccess$$anonfun$getClassFor$1.apply(DynamicAccess.scala:69)
at akka_2_3_9_shade.actor.ReflectiveDynamicAccess$$anonfun$getClassFor$1.apply(DynamicAccess.scala:66)
at scala.util.Try$.apply(Try.scala:161)
at akka_2_3_9_shade.actor.ReflectiveDynamicAccess.getClassFor(DynamicAccess.scala:66)
at akka_2_3_9_shade.actor.ReflectiveDynamicAccess.CreateInstanceFor(DynamicAccess.scala:84)
... 34 more
The relevant code from my application's Boot.scala file is the following:
[45] implicit val system = ActorSystem()
...
[48] val service = system.actorOf(Props[MyAppApiActor], "MyApp.Api")
...
[52] val port = config.getInt("MyApp.server.port")
[53] IO(Http) ? Http.Bind(service, interface = "0.0.0.0", port = port)
OK, so eventually I managed to solve this.
Turns out akka loads (some of the) configuration settings from the config file using keys that are defined as string literals. You can find a lot of these in akka/actor/ActorSystem.scala, for example.
And it seems that sbt-assembly does not change references to the shaded library/package name in string literals.
Also, some configuration keys are being changed by sbt-assembly's shading. I haven't really taken the time to find where and how exactly they are defined in akka's source, but the following exception, which is being thrown during the ActorSystem init code, proves that this is indeed the case:
ConfigException$Missing: No configuration setting found for key 'akka_2_3_9_shade'
So, the solution it to include a custom config file (call it for example akka_spray_shade.conf), and copy the following configuration sections in it:
The contents of akka's original reference.conf, but having the akka prefix in the configuration values changed to akka_2_3_9_shade. (this is required for the hard-coded string literal config keys)
The contents of akka's original reference.conf, but having the akka prefix in the configuration values changed to akka_2_3_9_shade and having the root configuration key changed from akka to akka_2_3_9_shade. (this is required for the config keys which do get modified by sbt-assembly)
The contents of spray's original reference.conf, but having the akka prefix in the configuration values changed to akka_2_3_9_shade. (this is required to make sure that spray always refers to the shaded akka)
Now, this custom config file must be provided explicitly during the initialization of the ActorSystem in application's Boot.scala code:
val akkaShadeConfig = ConfigFactory.load("akka_spray_shade")
implicit val system = ActorSystem("custom-actor-system-name", akkaShadeConfig)
A small addition to the accepted answer.
It is not necessary to put this configuration in a custom-named file like akka_spray_shade.conf. The configuration can be placed into application.conf which is being loaded by default during ActorSystem creation when no custom configuration is explicitly specified: ActorSystem("custom-actor-system-name") effectively means ActorSystem("custom-actor-system-name", ConfigFactory.load("application")).
I struggled with this for a long time as well. It turns out that the default merge strategy in sbt-assembly excludes all the reference.conf files. Adding this to build.sbt solved it for me:
assemblyMergeStrategy in assembly := {
case PathList("reference.conf") => MergeStrategy.concat
}

Problems using the XSP Starter Kit

I followed the instructions to install the XSP Starter kit from openntf. Everything mentioned in the video I was able to do but I am not able to activate it.
When I activate the plugin in my application and try to open it I get an Error 500. Anybody any idea?
The server console tells me:
https://www.dropbox.com/s/w2a0nlmjj5prnxs/Error%20OSGI.jpg?dl=0
The log file contains:
<extendedDataElements name="CommonBaseEventLogRecord:Exception" type="string">
<values>java.lang.RuntimeException: com.ibm.xsp.FacesExceptionEx: javax.faces.FacesException: java.lang.InstantiationException: org.openntf.xsp.starter.renderkit.AbstractHtmlTagRenderer
at com.ibm.designer.runtime.domino.adapter.ComponentModule.initModule(ComponentModule.java:461)
at com.ibm.domino.xsp.module.nsf.NSFComponentModule.initModule(NSFComponentModule.java:498)
at com.ibm.domino.xsp.module.nsf.NSFService.createNSFModule(NSFService.java:752)
at com.ibm.domino.xsp.module.nsf.NSFService.loadModule(NSFService.java:735)
at com.ibm.domino.xsp.module.nsf.NSFService.doServiceInternal(NSFService.java:588)
at com.ibm.domino.xsp.module.nsf.NSFService.doService(NSFService.java:482)
at com.ibm.designer.runtime.domino.adapter.LCDEnvironment.doService(LCDEnvironment.java:350)
at com.ibm.designer.runtime.domino.adapter.LCDEnvironment.service(LCDEnvironment.java:306)
at com.ibm.domino.xsp.bridge.http.engine.XspCmdManager.service(XspCmdManager.j</values>
<values>ava:272)
Caused by: com.ibm.xsp.FacesExceptionEx: javax.faces.FacesException: java.lang.InstantiationException: org.openntf.xsp.starter.renderkit.AbstractHtmlTagRenderer
at com.ibm.xsp.config.CLBootStrap.initContext(CLBootStrap.java:89)
at com.ibm.xsp.config.BootStrap.init(BootStrap.java:82)
at com.ibm.xsp.config.ConfigureCoreListener.contextInitialized(ConfigureCoreListener.java:39)
at com.ibm.designer.runtime.domino.adapter.ComponentModule.initModule(ComponentModule.java:453)
... 8 more
Caused by: javax.faces.FacesException: java.lang.InstantiationException: org.openntf.xsp.starter.renderkit.AbstractHtmlTagRenderer
at com.sun.faces.config.ConfigureListener.contextInitialized(ConfigureListener.java:417)
at com.ibm.xsp.config.CLBootStrap.initContext(CLBootStrap.java:81)
... 11 more
Caused by: java.lang.InstantiationException: org.openntf.xsp.starter.renderkit.AbstractHtmlTagRenderer
at java.lang.J9VMInternals.newInstan</values>
<values>ceImpl(Native Method)
at java.lang.Class.newInstance(Class.java:1549)
at com.sun.faces.config.ConfigureListener.configure(ConfigureListener.java:926)
at com.sun.faces.config.ConfigureListener.configure(ConfigureListener.java:965)
at com.sun.faces.config.ConfigureListener.configure(ConfigureListener.java:489)
at com.sun.faces.config.ConfigureListener.contextInitialized(ConfigureListener.java:410)
... 12 more
</values>
</extendedDataElements>
There is a component that was available in the starter kit for org.openntf.xsp.starter.renderkit.AbstractHtmlTagRenderer. It's hitting an error trying to create that component. It's not a component designed to be used in a particular way, it's really there to show what needs to be created for a component - org.openntf.xsp.starter.AbstractHtmlTag is the component, html.xsp-config in META-INF defines the properties available to Domino Designer, html-faces-config adds the component to the server and defines which Java class to use for the component and which one for the renderer (to display the HTML). org.openntf.xsp.starter.renderkit.AbstractHtmlTagRenderer handles printing content to the browser.
I've not used the starter kit as is, but I did use it as a basis for my session at ICON UK http://www.slideshare.net/paulswithers1/from-xpages-hero-to-osgi-guru-taking-the-scary-out-of-building-extension-libraries-icon-uk-2014

IBM HTTP Server is showing HTTP 1.1 500 status in logs

I am new to IBM HTTP Server and Websphere commerce. I am trying to access our application, but access.log file is showing "HTTP 1.1 500" status code. When I checked the systemout.log for WAS Console, It is showing below error:
webapp E com.ibm.ws.webcontainer.webapp.WebApp logServletError SRVE0293E: [Servlet Error]-[Stores Request Servlet]: java.lang.NoClassDefFoundError: com.ibm.commerce.seo.url.helpers.SEOURLMapperSource (initialization failure)
at java.lang.J9VMInternals.initialize(J9VMInternals.java:140)
at com.ibm.commerce.webcontroller.RuntimeServletFilter.init(RuntimeServletFilter.java:151)
at com.ibm.ws.webcontainer.filter.FilterInstanceWrapper.init(FilterInstanceWrapper.java:142)
at com.ibm.ws.webcontainer.filter.WebAppFilterManager._loadFilter(WebAppFilterManager.java:548)
at com.ibm.ws.webcontainer.filter.WebAppFilterManager.loadFilter(WebAppFilterManager.java:462)
at com.ibm.ws.webcontainer.filter.WebAppFilterManager.getFilterInstanceWrapper(WebAppFilterManager.java:319)
at com.ibm.ws.webcontainer.filter.WebAppFilterManager.getFilterChain(WebAppFilterManager.java:379)
at com.ibm.ws.webcontainer.filter.WebAppFilterManager.doFilter(WebAppFilterManager.java:860)
at com.ibm.ws.webcontainer.servlet.ServletWrapper.handleRequest(ServletWrapper.java:935)
at com.ibm.ws.webcontainer.servlet.ServletWrapper.handleRequest(ServletWrapper.java:503)
at com.ibm.ws.webcontainer.servlet.ServletWrapperImpl.handleRequest(ServletWrapperImpl.java:181)
at com.ibm.ws.webcontainer.webapp.WebApp.handleRequest(WebApp.java:3954)
at com.ibm.ws.webcontainer.webapp.WebGroup.handleRequest(WebGroup.java:276)
at com.ibm.ws.webcontainer.WebContainer.handleRequest(WebContainer.java:942)
at com.ibm.ws.webcontainer.WSWebContainer.handleRequest(WSWebContainer.java:1592)
at com.ibm.ws.webcontainer.channel.WCChannelLink.ready(WCChannelLink.java:186)
at com.ibm.ws.http.channel.inbound.impl.HttpInboundLink.handleDiscrimination(HttpInboundLink.java:453)
at com.ibm.ws.http.channel.inbound.impl.HttpInboundLink.handleNewRequest(HttpInboundLink.java:515)
at com.ibm.ws.http.channel.inbound.impl.HttpInboundLink.processRequest(HttpInboundLink.java:306)
at com.ibm.ws.http.channel.inbound.impl.HttpInboundLink.ready(HttpInboundLink.java:277)
at com.ibm.ws.tcp.channel.impl.NewConnectionInitialReadCallback.sendToDiscriminators(NewConnectionInitialReadCallback.java:214)
at com.ibm.ws.tcp.channel.impl.NewConnectionInitialReadCallback.complete(NewConnectionInitialReadCallback.java:113)
at com.ibm.ws.tcp.channel.impl.AioReadCompletionListener.futureCompleted(AioReadCompletionListener.java:165)
at com.ibm.io.async.AbstractAsyncFuture.invokeCallback(AbstractAsyncFuture.java:217)
at com.ibm.io.async.AsyncChannelFuture.fireCompletionActions(AsyncChannelFuture.java:161)
at com.ibm.io.async.AsyncFuture.completed(AsyncFuture.java:138)
at com.ibm.io.async.ResultHandler.complete(ResultHandler.java:204)
at com.ibm.io.async.ResultHandler.runEventProcessingLoop(ResultHandler.java:775)
at com.ibm.io.async.ResultHandler$2.run(ResultHandler.java:905)
I checked for SEOURLMappersource class, and it is there in SEO-BaseComponentLogic.jar, which is already present in my wc.ear and other relevent classes to SEO are present in SEO-BaseComponentLogic-FEP.jar.
Please guide me for the error.
The (initialization failure) means that a class failed initialization. There should be a Caused by explaining that problem, but if there's not, search the logs for SEOURLMapperSource.<clinit> to find the underlying problem. If that doesn't yield any results either, then wrap your static{} block in a try{}catch{} to print the real problem (and don't forget to move any static ... = ... initializations into the static{} block as well).
I ran into the same problem described by this WC stack exception. I found out that on our system the owner/group for the related jar files was not set for the wc user but for the root user. Thus even though the class/jar present, it was not read due to permissions. This initialization exception went away after chown/chgrp and a restart.

How to localize JSF composite component?

I'm having trouble localizing a composite component (Mojarra 2.2, Glassfish 4.0).
I tried BalusC's solution here to put the properties file in the same directory as the composite component with the same file name as the composite component and a .properties extension -- that works to externalize the strings from the composite component's definition.
But when I want to localize the strings (by adding _en suffix to the property file's filename) I get this error (only thing changed is the name of the properties file):
[2013-08-08T13:49:04.234-0500] [glassfish 4.0] [WARNING] [] [javax.enterprise.web] [tid: _ThreadID=24 _ThreadName=http-listener-1(5)] [timeMillis: 1375987744234] [levelValue: 900] [[
StandardWrapperValve[Faces Servlet]: Servlet.service() for servlet Faces Servlet threw exception
java.lang.NullPointerException
at javax.faces.component.UIComponent.findComponentResourceBundleLocaleMatch(UIComponent.java:1204)
at javax.faces.component.UIComponent.getResourceBundleMap(UIComponent.java:1007)
at sun.reflect.GeneratedMethodAccessor1226.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
at javax.el.BeanELResolver.getValue(BeanELResolver.java:363)
at com.sun.faces.el.DemuxCompositeELResolver._getValue(DemuxCompositeELResolver.java:176)
at com.sun.faces.el.DemuxCompositeELResolver.getValue(DemuxCompositeELResolver.java:203)
at com.sun.el.parser.AstValue.getValue(AstValue.java:140)
at com.sun.el.parser.AstValue.getValue(AstValue.java:204)
at com.sun.el.ValueExpressionImpl.getValue(ValueExpressionImpl.java:226)
at org.jboss.weld.el.WeldValueExpression.getValue(WeldValueExpression.java:50)
at com.sun.faces.facelets.el.ELText$ELTextVariable.writeText(ELText.java:227)
at com.sun.faces.facelets.compiler.TextInstruction.write(TextInstruction.java:85)
at com.sun.faces.facelets.compiler.UIInstructions.encodeBegin(UIInstructions.java:82)
at com.sun.faces.renderkit.html_basic.HtmlBasicRenderer.encodeRecursive(HtmlBasicRenderer.java:302)
at com.sun.faces.renderkit.html_basic.GroupRenderer.encodeChildren(GroupRenderer.java:115)
at javax.faces.component.UIComponentBase.encodeChildren(UIComponentBase.java:894)
at javax.faces.component.UIComponent.encodeAll(UIComponent.java:1856)
...
I read an article (post from 24/Aug/12 03:50 PM) that JSF localizes differently than standard Java and that the properties files would go in resources/en/<library>/<component>.properties, so I put mycomp.properties there and got the error again.
My default locale is actually "en_US" -- I tried that as well with the same results.
So, this works:
resources/lib/mycomp.xhtml, resources/lib/mycomp.properties
These don't work:
resources/lib/mycomp.xhtml, resources/lib/mycomp_en.properties
resources/lib/mycomp.xhtml, resources/en/lib/mycomp.properties
What am I doing wrong?
I can reproduce your problem. This is quite embarrassing. Apparently something changed related to this in a newer Mojarra version. I can't get both the old and new approach to work in 2.2.0.
I peeked in the Mojarra source code again, starting at UIComponent#getResourceBundleMap(), and I learned that the resource bundle is first searched based on the FQN of the component's class. We could easily make use of it.
If not already done, first create a backing component class:
package com.example.composite;
#FacesComponent("myComposite")
public class MyComposite extends UINamingContainer {
// Can be kept empty.
}
And declare it in the composite component definition:
<cc:interface componentType="myComposite">
Then, you can simply put the MyComposite.properties, MyComposite_en.properties, etc in the very same com.example.composite package. It worked for me.

Accessing methods from imported jars in managed beans

I'm sure I'm missing something, but I'm not seeing it at all.
I'm creating PDFs using iText, and I want to do this in a bean. I've created one, but it's been erroring out. It seems some of the ways I've usually worked in Java don't seem to work in this bean.
For example, this line:
com.itextpdf.text.Document document1 = new com.itextpdf.text.Document();
will throw the error java.lang.NoClassDefFoundError: com.itextpdf.text.Document, even though the jar is imported, in the build path and com.itextpdf.text.Document is imported in the bean.
if you change it to this:
com.itextpdf.text.Document document1;
or
com.itextpdf.text.Document document1 = null;
the error goes away. I don't understand why one way works and the other doesn't, but it's a fairly easy change to make.
Now I need to set the page size. This will work in Eclipse:
document1.setPageSize(PageSize.LETTER);
but this is the error I get:
java.lang.NoClassDefFoundError: com.itextpdf.text.PageSize
Which might be because I've set it to null to initialize it. But
document1 = new Document();
and
document1 = new com.itextpdf.text.Document();
both throw java.lang.NoClassDefFoundError: com.itextpdf.text.Document
Oddly, the import statement for (iText) Document warns me it is never used.
document1.open();
will give the error java.lang.NoClassDefFoundError: com.itextpdf.text.Document as well.
So, am I missing something in the syntax in beans? I've created Notes Java agents, XAgents, and straight up Java Eclipse projects that work, but I can't get the methods to work in a 8.5.3 Java Bean. I imported the iText jars into WebContent\WEB-INF\lib and then added those (via add jars, not add external jars) to the build path. I've gotten the latest jars and I'm using them, I've built and cleaned, the bean is in faces-config. But I'm doing something wrong, and I can't see it.
If someone could point me in the right direction, I would be very grateful.
Cheers,
Brian
EDIT:
The license isn't a problem, but I still can't get the class to load even using the classLoader:
Thread currentThread = Thread.currentThread();
ClassLoader clCurrent = currentThread.getContextClassLoader();
//ClassLoader clCurrent=com.ibm.domino.xsp.module.nsf.NotesContext.getCurrent().getModule().getModuleClassLoader();
try {
currentThread.setContextClassLoader(Activator.class.getClassLoader());
DebugToolbar.get().info("after setting up FileOutputStream");
com.itextpdf.text.Document document1 = new com.itextpdf.text.Document();
//com.itextpdf.text.Document document1;
//com.itextpdf.text.Document document1 = null;
//document1 = new com.itextpdf.text.Document();
//document1.open();
document1.setPageSize(PageSize.LETTER);
I still get java.lang.NoClassDefFoundError: com.itextpdf.text.Document
I've cut the beans out, cleaned, built, pasted back in, cleaned built, still the error.
I appreciate the assistance.
Brian
Most likely you have a classloader isssue. Unless your app is strictly for internal use, you might reconsider use of iText since it is GPL. Apache PDFBox is an Apache licensed alternative (I'm particularly fond of) or Apache FOP (I'll complete the ]2 missing articles](http://www.wissel.net/blog/htdocs/DominoXSLT), promise). Of course OpenNTF's POI4XPages might just be what you need.
I called Lotus/ICS support. It seems for 8.5.3, if you put the jars in ~Lotus\Notes\jvm\lib\ext they will load. I'm testing this on my local, but the same path should work on the server. I'll test that Monday. I had researched, and if that is mentioned I didn't find it. Jars will be a design element in 9, putting them in a directory like this should not be needed for that version, but it seems that adding them this way is more consistent now. The jars have loaded properly for some applications I've made, so this confused me a bit.
Stephan and Panu, thank you for responding.
Brian

Resources