Exception logged when using custom css in JavaFX in Felix OSGI - osgi

I'm getting the exception below logged to stderr when trying to use my own custom css in JavaFX 2.2 (from JDK 7 update 11). It's funny because the css is actually found and used in my application so the only thing wrong is the exception in the logs. I also load up other resources this way (images, fonts etc) and there are no exceptions logged in these cases.
I'm loading the css like this:
val cssResource = getClass.getResource("/com/openaf/browser/gui/resources/openaf.css").toExternalForm
println("CSS Resource: " + cssResource)
println("")
scene.getStylesheets.add(cssResource)
and you can see from the output that it is found (and I'm not sure why in the exception it says **.bss but maybe that's felix doing some internal bundle renaming.
Does anyone know why this exception is being logged and/or how to get rid of it?
CSS Resource: bundle://21.57:1/com/openaf/browser/gui/resources/openaf.css
java.io.IOException: Resource does not exist: bundle://21.57:1/com/openaf/browser/gui/resources/openaf.bss
java.io.IOException: Resource does not exist: bundle://21.57:1/com/openaf/browser/gui/resources/openaf.bss
at org.apache.felix.framework.URLHandlersBundleURLConnection.<init>(URLHandlersBundleURLConnection.java:136)
at org.apache.felix.framework.URLHandlersBundleStreamHandler.openConnection(URLHandlersBundleStreamHandler.java:64)
at java.net.URL.openConnection(URL.java:971)
at java.net.URL.openStream(URL.java:1037)
at com.sun.javafx.css.Stylesheet.loadBinary(Stylesheet.java:201)
at com.sun.javafx.css.StyleManager.loadStylesheetUnPrivileged(StyleManager.java:572)
at com.sun.javafx.css.StyleManager.loadStylesheet(StyleManager.java:411)
at com.sun.javafx.css.StyleManager.updateStylesheets(StyleManager.java:858)
at javafx.stage.Window.impl_visibleChanging(Window.java:818)
at javafx.stage.Stage.impl_visibleChanging(Stage.java:922)
at javafx.stage.Window$10.invalidated(Window.java:689)
at javafx.beans.property.BooleanPropertyBase.markInvalid(BooleanPropertyBase.java:127)
at javafx.beans.property.BooleanPropertyBase.set(BooleanPropertyBase.java:161)
at javafx.stage.Window.setShowing(Window.java:782)
at javafx.stage.Window.show(Window.java:797)
at javafx.stage.Stage.show(Stage.java:229)
at com.openaf.browser.gui.BrowserStageManager.createStage(BrowserStageManager.scala:64)
at com.openaf.browser.gui.BrowserStageManager.start(BrowserStageManager.scala:41)
at com.openaf.browser.gui.BrowserBundleActivator$$anonfun$startUp$2.apply$mcV$sp(BrowserBundleActivator.scala:32)
at com.openaf.browser.gui.utils.BrowserUtils$$anon$1.run(BrowserUtils.scala:48)
at com.sun.javafx.application.PlatformImpl$4.run(PlatformImpl.java:173)
at com.sun.glass.ui.InvokeLaterDispatcher$Future.run(InvokeLaterDispatcher.java:76)

Either convert your CSS files to the binary BSS format:
http://docs.oracle.com/javafx/2/deployment/packaging.htm#BABCACBD
or use "-Dbinary.css=false" when you run your application.
Also note that I've recently released an initial version of Drombler FX, a modular RCP for JavaFX based on OSGi and Maven (POM-first):
http://puces-blog.blogspot.ch/2012/12/drombler-fx-building-modular-javafx.html
http://wiki.drombler.org/GettingStarted
By default it uses Apache Felix as well. Maybe you find it useful.

Related

Spring Boot: Static content serving CSS correctly but not JS

We're trying to serve a React app via Spring Boot.
Spring is able to serve the CSS folder's css files (src/main/resources/static/css/), but is not able to serve the JS folder's files (src/main/resources/static/js/). There is a main.8f965741.chunk.js inside the JS folder, and when we run the application, it is returning an error 404.
It is not a browser/caching issue.
It is not a folder/file permissions issue.
Any thoughts on how to debug this? Spring gives us essentially no output for the 404.
You can turn on DEBUG (or TRACE) level logs by adding the following to your application.properties:
logging.level.org.springframework.web: TRACE
Then try requesting the JS file directly, perhaps with curl (e.g., curl http://localhost:8080/js/main.8f965741.chunk.js)
The logs should tell you how the request was mapped and how it was subsequently handled. You can compare the logs generated here with a "known good" request (perhaps from requesting a css file).
If you've built a .jar or .war artifact, you can also unpack it (using jar xf ...) and double check if the js files are properly packaged there.

Spring Boot on Windows, invalid temporary upload location

I have a web service built in Spring Boot 2.0.2 and deployed on a Windows 10 based machine.
One of the tasks of the application is to accept an image via a POST request and then move the image to a specific location on the system, i.e. c:\ftp. Initially the application works fine, however, after a period of being left, upon a new request I'm seeing the error below;
Failed to parse multipart servlet request; nested exception is java.io.IOException: The temporary upload location [C:\\Users\\FRONTIER\\AppData\\Local\\Temp\\tomcat.10182171515108748004.8080\\work\\Tomcat\\localhost\\ROOT] is not valid
I suspect that Windows is deleting old temporary files/folders, resulting in the temporary upload path no longer being present.
Has anyone come across this issue before, and is there a way to fix it?
Hello SheppardDigital,
try adding the property
spring.servlet.multipart.location=C:\\Users\\admin\\Desktop\\Perfect_APP\\
to your application.properties file, this property sets the multipart temp location for uploaded files which the POST requests use.
Be sure to set an absolute URL.

freemarker.template.TemplateException: Error reading included file start_script.ftl

My application running in tomcat 6. I have integrated freemarker template with Spring MVC.
I have "abct.ftl" under "freemarker/pages" and "xyz.ftl" under "freemarker/pages
/formal". I am including "abc.ftl" in "xyz.ftl" using "<#include
"../abc.ftl"/>".
This is working fine on MACH and LINUX but its giving below error on windows 7. I did search
for this error in google and tried many things but nothing helped fixing this issue.
The exception stack trace is given below:
freemarker.template.TemplateException: Error reading included file abc.ftl
at freemarker.core.Include.accept(Include.java:167)
Caused by: java.io.FileNotFoundException: Template abc.ftl not found.
Please help me fixing this issue.
Thanks
Thanks everyone for helping me on this issue.
I have found the solution to this problem so wanted to share it with you guys.
I went through the following documentation on freemarker site and found the solution:
http://freemarker.org/docs/pgui_config_templateloading.html#autoid_41[freemarker.org]
As suggested in this documentation, I replaced <#include "../abc.ftl"/> with <#include "/pages/abc.ftl"/>.
Freemarker documentation says, “FreeMarker always normalizes the paths before passing them to the template loader, so the paths do not contain/../ and such, and are relative to the imaginary template root directory.”
The template root directory is the one that we specify in templateLoaderPath:
property name="templateLoaderPath" value="classpath:/freemarker"
I tested this fix on Windows, Linux, Mach and its working everywhere.

How to run the 46 line blog tutorial of Apache Sling?

I'm trying to go through this tutorial of Apache Sling and I'm stuck at the beginning. I can't display the blog form in my browser. Instead, I get the following message:
Resource dumped by HtmlRendererServlet
Resource path: /content/blog/*
Resource metadata: {sling.resolutionPathInfo=.html, sling.resolutionPath=/content/blog/*}
Resource type: sling:syntheticStarResource
Resource super type: -
Resource Value:
I saw on the README that this might be caused by org.apache.sling.samples.path-based.rtp not running. However I made sure the bundle was active in the Felix console. (I tried to install from the OSGi repository tab of the console, then by downloading the jar and dropping it under sling/startup/15 but it didn't change anything)
I'm wondering if there are extra configuration steps I should take?
Please note that I'm new to OSGi and Sling so this is probably a beginner's mistake.
Edit: I noticed in the Felix console in the component tab that org.apache.sling.samples.pathbasedrtp.DefaultResourceTypeProvider had the status "unsatisfied". Could it be related?
There was indeed a problem (visible by clicking the bundle name at /system/console/bundles) that prevented the o.a.s.samples.path-based.rtp bundle from starting with recent versions of Sling.
I have just fixed it ( https://issues.apache.org/jira/browse/SLING-2557 ), please try again!

Making sense of core taglibs migrating to Websphere 7

I am migrating an ADF application to run in Websphere 7.
Basically I am moving to jstl 1.2
I have created a new project and I am now at the point where I can run jsps.
I started getting errors with the taglibs. Then I found out that I have to replace all my c taglib declarations with the new uri of java.sun.com/jsp/jstl/core instead of java.sun.com/jstl/core
I did this to every one of my jsp files. Now when I publish and attempt to run it I get this error.
[Servlet Error]-[/index.jsp]: com.ibm.ws.jsp.JspCoreException: /index.jsp(742,56) /included.jsp(4,58) JSPG0240E: Attempt to redefine the prefix "c" to "http://java.sun.com/jstl/core", when it was already defined as "http://java.sun.com/jsp/jstl/core" in the current scope.
Now each page has the new uri. Why would it try to redefine it to the old uri?
Turns out the new stuff is very specific in regards to syntax
Notice this if you don't have spaces between the "#" and the "taglib" part of the text it blows up!
Also you have to have the space between the "c" and the end of the tag "%>"
If you don't do this it causes big ol stupid errors that say nothing about how to fix the issue.
I also have this problem at WAS v8. and fix it by:
Admin Console -> Application servers -> (serverName) -> Web
container -> Custom properties :
com.ibm.wsspi.jsp.allowtaglibprefixredefinition=true
PM38186: JSPG0240E: ATTEMPT TO REDEFINE THE PREFIX WHEN IT WAS ALREADY DEFINED IN CURRENT SCOPE ERROR IN WEBSPHERE APPLICATION SERVER 7
This fixed my problem!! My taglib imports were all the same so I still dont know the root cause of the problem in my environment (WebSphere 7 running in RAD 8.0.3). It shouldn't complain if the imports all point to the same namespace. This fix basically tells the server to ignore the error rather than preventing the error occurring.
I'll post back if I find more info.

Resources