I'm trying to build a native bundle, specially for mac os x, but also in windows. And in both environments the .app, .dmg, .exe get generated correctly, but when I run them, I get many java.security.NoSuchAlgorithmException exceptions. For example:
Caused by: java.security.NoSuchAlgorithmException: SunTlsRsaPremasterSecret KeyGenerator not available
Caused by: java.security.NoSuchAlgorithmException: PBEWithMD5AndDES SecretKeyFactory not available
My program uses TLS, to establish xmpp connections. And also I have a webview with HTTPS which is not loading eighter.
Does anybody have any idea why this could be happening?
I should note that if I run the generated jar alone, it works fine, it only happens with the .exe and .app.
This is my build.xml fx:deploy code:
<fx:deploy width="${javafx.run.width}" height="${javafx.run.height}"
nativeBundles="all"
outdir="${basedir}/${dist.dir}" outfile="${application.title}">
<fx:application name="${application.title}"
mainClass="${javafx.main.class}"/>
<fx:resources>
<fx:fileset dir="${basedir}/${dist.dir}"
includes="*.jar"/>
<fx:fileset dir="${basedir}/${dist.dir}" includes="lib/*.jar"/>
</fx:resources>
<fx:info title="${application.title}"
vendor="${application.vendor}"/>
</fx:deploy>
Appreciate your help.
I hadn't seen this post before: JavaFX WebView Not Loading HTTPS Page
What's happening is that the jre's bundle doesn't include the /ext folder, so you have to copy it with a script when you build the bundle.
Related
I installed and registered Sencha Architect 4.3.2.19. However, after I created a new classic ExtJs 7.6.0 project, it doesn't initialize Cmd properly, and in the command output I see:
Exception in thread "Thread-15"
com.sencha.exceptions.BasicException: com.sencha.exceptions.ExState: Directory C:\Users\costa\Documents\Architect\frameworks/ext76/7.6.0.41/commercial does not contain a valid framework.
at com.sencha.tools.server.service.tasks.DispatchTask.execute(DispatchTask.java:55)
at com.sencha.tools.server.service.tasks.BaseServiceTask$1.run(BaseServiceTask.java:42)
at com.sencha.util.ThreadUtil$1.run(ThreadUtil.java:65)
at com.sencha.util.ThreadUtil$2.run(ThreadUtil.java:162)
at java.base/java.lang.Thread.run(Thread.java:1589)
Caused by: com.sencha.exceptions.ExState: Directory C:\Users\costa\Documents\Architect\frameworks/ext76/7.6.0.41/commercial does not contain a valid framework.
at com.sencha.command.app.AppCommands$InitCommand.validateEnvironment(AppCommands.java:1874)
at com.sencha.command.app.AppCommands$InitCommand.execute(AppCommands.java:1750)
at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
at java.base/java.lang.reflect.Method.invoke(Method.java:578)
at com.sencha.util.MethodInvoker$Arguments.invoke(MethodInvoker.java:175)
at com.sencha.cli.Command.dispatch(Command.java:43)
at com.sencha.command.BasePluginCommands$BasePluginCommand.dispatch(BasePluginCommands.java:289)
at com.sencha.cli.Commands.dispatch(Commands.java:64)
at com.sencha.cli.Commands.dispatch(Commands.java:64)
at com.sencha.command.Sencha.dispatch(Sencha.java:80)
at com.sencha.cli.AbstractCommand.dispatch(AbstractCommand.java:124)
at com.sencha.tools.server.service.tasks.DispatchTask.execute(DispatchTask.java:52)
... 4 more
The Cmd base directory is set to: C:\Users\costa\bin\Sencha\Cmd which contains the subdirectory 7.6.0.87.
Any idea on how to fix the exception? Time to open a ticket?
Edit: I've got the previous error on Windows 2016. I just gave SA 4.3.2.19 for macosx a try. It has a different problem. I created a blank ExtJs 7.6.0 Modern project. When I save the project in the folder I get (I set the app name to App) :
/Users/costa/bin/Sencha/Cmd/7.6.0.87/extensions/sencha-service/shell-wrapper.sh: line 41: cordova: command not found
/Users/costa/bin/Sencha/Cmd/7.6.0.87/extensions/sencha-service/shell-wrapper.sh: line 41: phonegap: command not found
[INF] Initializing empty workspace at /Users/costa/Documents/development/javascript/TestAppModern01
[INF] Copying framework to /Users/costa/Documents/development/javascript/TestAppModern01/ext
[INF] Added framework ext to workspace.json
[ERR] The specified string cannot be converted into a valid namespace identifier
Exception in thread "Thread-61" com.sencha.exceptions.BasicException: com.sencha.exceptions.ExState: Invalid namespace : App
at com.sencha.tools.server.service.tasks.DispatchTask.execute(DispatchTask.java:55)
at com.sencha.tools.server.service.tasks.BaseServiceTask$1.run(BaseServiceTask.java:42)
at com.sencha.util.ThreadUtil$1.run(ThreadUtil.java:65)
at com.sencha.util.ThreadUtil$2.run(ThreadUtil.java:162)
at java.base/java.lang.Thread.run(Thread.java:833)
Caused by: com.sencha.exceptions.ExState: Invalid namespace : App
at com.sencha.util.NameUtil.stringToNamespace(NameUtil.java:76)
at com.sencha.command.generator.GeneratorCommands$AppCommand.validateAppName(GeneratorCommands.java:680)
at com.sencha.command.generator.GeneratorCommands$AppCommand.execute(GeneratorCommands.java:420)
at com.sencha.command.app.AppCommands$InitCommand.execute(AppCommands.java:1819)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:568)
at com.sencha.util.MethodInvoker$Arguments.invoke(MethodInvoker.java:175)
at com.sencha.cli.Command.dispatch(Command.java:43)
at com.sencha.command.BasePluginCommands$BasePluginCommand.dispatch(BasePluginCommands.java:289)
at com.sencha.cli.Commands.dispatch(Commands.java:64)
at com.sencha.cli.Commands.dispatch(Commands.java:64)
at com.sencha.command.Sencha.dispatch(Sencha.java:80)
at com.sencha.cli.AbstractCommand.dispatch(AbstractCommand.java:124)
at com.sencha.tools.server.service.tasks.DispatchTask.execute(DispatchTask.java:52)
... 4 more
An identical error occurs when I save a classic project.
What am I missing? There seems to be something wrong overall with SA 4.3.2, or maybe it's missing something.
Both versions, windows & macosx, don't allow me to set Build Tools to Enabled. I click Save, I come back to the dialog and Build Tools is set to Disabled.
More than that, I downloaded ExtJs 7.6.0 and unzipped in a local folder, then in the above dialog I chose Complete or Custom Path, I entered the folder where I unzipped ExtJs, clicked Save, came back to the dialog and Build Tools is Disabled again.
Thank you
ok, I found a workaround for the first problem I had on windows. I installed Sencha Cmd from the installer - I don't know if that made a difference or not.
After creating the classic app, and saving it in SA, I went to the command line and I ran inside the project folder: C:\Users\costa\bin\Sencha\Cmd\7.6.0.87\sencha.exe app init -n App -e ..\..\ext760 --classic
You'd have to adjust the parameters according to your needs. I re-opened the project in SA, and it got its brains back. In my case I used a workspace, and the folder for the workspace was 2 levels up from the project folder. I placed the 7.6.0 ExtJs files in the ext760 directory.
Update: I created a ticket with Sencha and they came back with the fix.
The framework code has been incorrectly installed by SA 4.3.2 in this folder: C:\Users\<UserName>\Documents\Architect\frameworks\ext76\7.6.0.41\commercial\ext-7.6.0. The solution is to copy the files in this folder one level up, i.e. in C:\Users\<UserName>\Documents\Architect\frameworks\ext76\7.6.0.41\commercial, and then it's going to work.
For my master thesis, I have to modify the source code of Cassandra. So, as suggested by https://wiki.apache.org/cassandra/HowToBuild, I git clone, then run ant, and everything seems nice (I managed to build the project without any error), but when I run the unitTests (cassandra/test), I have this strange error:
org.apache.cassandra.exceptions.ConfigurationException:
Expecting URI in variable: [cassandra.config].
Found[cassandra.yaml].
Please prefix the file with [file:\\\] for local files and
[file:\\<server>\] for remote files.
If you are executing this from an external tool, it needs
to set Config.setClientMode(true) to avoid loading configuration.
at org.apache.cassandra.config.YamlConfigurationLoader.getStorageConfigURL(YamlConfigurationLoader.java:80)
at org.apache.cassandra.config.YamlConfigurationLoader.loadConfig(YamlConfigurationLoader.java:100)
at org.apache.cassandra.config.DatabaseDescriptor.loadConfig(DatabaseDescriptor.java:252)
at org.apache.cassandra.config.DatabaseDescriptor.daemonInitialization(DatabaseDescriptor.java:131)
at org.apache.cassandra.auth.jmx.AuthorizationProxyTest.setup(AuthorizationProxyTest.java:48)"
I would like to test my modifications on the source code with the unitTests (because I didn't find any tutorial of how to set up cassandra from the source code on Windows, so if you have one, I would like to have the link ^^) but I didn't manage to find any solution for this bug :(. Anyone know a solution to this problem?
I am working on Windows 10 with IntelliJ and I have updated my Jdk and ant to the latest version.
I was facing the same issue. Those variables ("cassandra.config", "cassandra.storagedir", etc...) are System variables.
You can either set them in your code by doing something like:
System.setProperty("cassandra.config", "file:///<PATH>/cassandra.yaml");
You can also set them whilst running the jar file:
java -Dcassandra.config=file:///<PATH>/cassandra.yaml -jar <JAR>
Best,
Shabir
Start a new process in jdk 1.8 and start embedded cassandra in it. and run your junit in your java version. I faced similar isue which jdk11 upgrade. Now i fixed this.
import org.cassandraunit.utils.EmbeddedCassandraServerHelper;
import org.springframework.boot.autoconfigure.SpringBootApplication;
#SpringBootApplication
public class EmbeddedCassandraApplication {
public static void main(String[] args) throws Exception {
EmbeddedCassandraServerHelper.startEmbeddedCassandra("cassandra-test.yaml");
}
}
UPDATE 8/6:
The beefed up logging has shown me that there is an issue deleting the old jar from the cache, which leads to the fatal "not found" error. There are other threads similar to this, but only when someone is locking the file with their IDE. We are running a single groovy script from Jenkins, and no one is logged into this box.
We ran process explorer right after the failure and there were no locks. Then I login with the user that Jenkins is using to run the script, and I get no error deleting the files.
Also it seems there was a fix in IVY 2.1 to not fail when the jar cannot be deleted, and I'm on Ivy 2.2 (Groovy 1.8.4). What gives?
Couldn't delete outdated artifact from cache: C:\Users\myUser\.groovy\grapes\com.a.b.c\x-y-z\jars\x-y-z-1.496.jar
then the false(?) error:
Caught: java.lang.ExceptionInInitializerError
java.lang.ExceptionInInitializerError
Caused by: java.lang.RuntimeException: Error grabbing Grapes -- [unresolved dependency: com.a.b.c#x-y-z;1.+: not found]
at smokeTestSuccess.<clinit>(smokeTestSuccess.groovy)
Interestingly enough, this happens everyday the first time the script is run after 5am. I guess the cache gets invalidated through some default config at 5am? Is this some kind of clue??
Original post:
I am intermittently getting an error when running a number of different Groovy scripts which all share an identical #Grab declaration. (file names changed to protect the innocent). First the full Grab declaration:
#GrabResolver(name = 'libs.release', root = 'http://myserver:8081/artifactory/libs-release', m2compatible = 'true') #Grapes([
#Grab(group = 'com.a.b.c, module = 'x-y-z', version = '1.+', changing = true),
#Grab('commons-lang:commons-lang:2.3'),
#Grab('log4j:log4j:1.2.16'),
#Grab('gpars:gpars:0.12'),
#Grab('jsr166y:jsr166y:1.7.0'),
#Grab('org.codehaus.groovy.modules.http-builder:http-builder:0.6'),
#Grab('org.apache.commons:commons-collections:3.2.1'),
#Grab('org.apache.httpcomponents:httpclient:4.2.2'),
#Grab('org.apache.httpcomponents:httpcore:4.2.3'),
#Grab('org.cyberneko.html:nekohtml:1.9.17'),
#Grab('xerces:xercesImpl:2.11.0'),
]) #GrabConfig(systemClassLoader = true)
Then the error:
Caught: java.lang.ExceptionInInitializerError
java.lang.ExceptionInInitializerError
Caused by: java.lang.RuntimeException: Error grabbing Grapes -- [unresolved dependency: com.a.b.c#x-y-z;1.+: not found]
Upon doing numerous internet searches, the cause always seems to be very simple, either one of these two basic problems:
1. Repository unreachable
2. Jar file doesn’t exist
However, in the artifactory logs, I've proven that the file is actually being downloaded:
*Artifactory did accept the request for download:
2014-07-17 07:58:19,938 [ACCEPTED DOWNLOAD] libs-release-local:com/a/b/c/x-y-z/1.477/x-y-z-1.477.jar for anonymous/165.226.40.155.
*Artifactory did deliver jar:
20140717075820|156|REQUEST|165.226.40.155|non_authenticated_user|GET|/libs-release/com/a/b/c/x-y-z/1.477/x-y-z-1.477.jar|HTTP/1.1|200|1276695
The scripts all work about 100% of the time if they are simply restarted. This all leads me to believe that the issue is the Grab timing out. Theoretically the second time I run the script, the file is in the cache, and things happen faster, thus it doesnt fail.
For the above real request, I can see about 20 seconds of elapsed time in the http log from request to download.
Questions:
Does my theory seem correct?
Is there a way to increase the amount of time that the script will wait for the #Grab to resolve?
Does putting a try / catch block around the #Grab statements seem like a good idea? Or will that just hide the real problem?
thanks in advance!!!!
I think I finally figured out the answer to my own question.
I believe there is some sort of bug within Groovy 1.8.4 (or Ivy 2.2), especially since this behavior does mirror an ancient documented Ivy bug with this exact error message scheme and behavior.
Upgrading to Groovy 2.3.6 (which includes Ivy 2.3) appears to solve the issue.
I also still have no idea why the jars cannot be deleted, nothing is locking them. I experimented with moving the grape cache to a less secure folder to rule out a permission issue, but this didn't help:
-Dgrape.root=D:\Temp\grapeCache
UPDATE 8/19:
Once we upgraded to Groovy 2.3.6, the error went away, but I then figured out that the jar was no longer being downloaded at all, when using the "1.+" resolver. Something in the defaultgrapeConfig.xml was causing an issue. Everything is finally working properly after (in addition to the Groovy upgrade) we overrode defaultgrapeConfig.xml with our own stripped down file using this command line JAVA_OPT:
-Dgrape.config=D:\Temp\myGrapeConfig.xml
which had these contents:
<ivysettings>
<settings defaultResolver="downloadGrapes"/>
<resolvers>
<chain name="downloadGrapes">
</chain>
</resolvers>
</ivysettings>
ALSO:
For completeness (further steps):
In Jenkins GUI, update the job(s):
a. Update the drop down for each script: Execute Groovy Script > Groovy Version > Groovy-2.3.6
b. Update the JAVA_OPTS for each script (have to click the ‘advanced’ button under the script to see JAVA_OPTS):
-Dgrape.config=D:\Software\SfGrapeConfig.xml
Optional logging switches: -Dgroovy.grape.report.downloads=true -Divy.message.logger.level=4
In the actual Groovy script itself, delete this option within the #GrabResolver annotation: , m2compatible = 'true'
If you get this or a similar error:
"could not find client or server jvm under [Whatever JAVE_HOME is], please check that it is a valid jdk / jre containing the desired type of jvm"
Delete groovy.exe & groovyw.exe from D:\Software\Groovy-2.3.6\bin (if the exe’s do not exist, the Jenkins groovy plugin will use the bat file versions of these, and they handle the 32-bit / 64-bit problem better than the exe’s)
I want to upgrade from JSF implementation Mojarra 2.1.3 in Netbeans7.1 (Glassfish 3.1.1).
You might ask first why I don't just upgrade to Netbeans7.3, and the reasons include that it it runs Glassfish 3.1.2.2 and that I have some other 3rd party software in my web application that is not yet compatible with Glassfish higher than 3.1.1, and besides it only has Mojarra 2.1.6 anyway.
I used to be able to upgrade Mojarra by simply replacing jsf-api.jar and jsf-impl.jar under /glassfish/modules, but that does not work with:
https://maven.java.net/content/repositories/releases/com/sun/faces/jsf-api/2.1.21/jsf-api-2.1.21.jar
https://maven.java.net/content/repositories/releases/com/sun/faces/jsf-impl/2.1.21/jsf-impl-2.1.21.jar
I get the following error:
SEVERE: java.lang.reflect.InvocationTargetException
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at com.sun.enterprise.glassfish.bootstrap.GlassFishMain.main(GlassFishMain.java:97)
at com.sun.enterprise.glassfish.bootstrap.ASMain.main(ASMain.java:55)
Caused by: com.sun.enterprise.module.ResolveError: Failed to start Bundle Id [301] State [INSTALLED] [org.glassfish.web.weld-integration(Weld integration for glassfish):3.1.1]
at org.jvnet.hk2.osgiadapter.OSGiModuleImpl.start(OSGiModuleImpl.java:177)
at org.jvnet.hk2.osgiadapter.OSGiModuleImpl$2$1$1.loadClass(OSGiModuleImpl.java:344)
at com.sun.hk2.component.LazyInhabitant.loadClass(LazyInhabitant.java:124)
at com.sun.hk2.component.LazyInhabitant.fetch(LazyInhabitant.java:111)
at com.sun.hk2.component.EventPublishingInhabitant.get(EventPublishingInhabitant.java:135)
at com.sun.hk2.component.AbstractInhabitantImpl.get(AbstractInhabitantImpl.java:76)
at org.jvnet.hk2.component.Habitat$5.get(Habitat.java:701)
at java.util.AbstractList$Itr.next(AbstractList.java:345)
at java.util.AbstractCollection.toArray(AbstractCollection.java:124)
at java.util.ArrayList.addAll(ArrayList.java:472)
at com.sun.enterprise.v3.server.SnifferManagerImpl.getSniffers(SnifferManagerImpl.java:92)
at com.sun.enterprise.v3.server.SnifferManagerImpl.getSniffer(SnifferManagerImpl.java:120)
at com.sun.enterprise.v3.server.ApplicationLifecycle.getSniffersFromApp(ApplicationLifecycle.java:2140)
at com.sun.enterprise.v3.server.ApplicationLoaderService.processApplication(ApplicationLoaderService.java:375)
at com.sun.enterprise.v3.server.ApplicationLoaderService.postConstruct(ApplicationLoaderService.java:219)
at com.sun.hk2.component.AbstractCreatorImpl.inject(AbstractCreatorImpl.java:131)
at com.sun.hk2.component.ConstructorCreator.initialize(ConstructorCreator.java:91)
at com.sun.hk2.component.AbstractCreatorImpl.get(AbstractCreatorImpl.java:82)
at com.sun.hk2.component.SingletonInhabitant.get(SingletonInhabitant.java:67)
at com.sun.hk2.component.EventPublishingInhabitant.get(EventPublishingInhabitant.java:139)
at com.sun.hk2.component.AbstractInhabitantImpl.get(AbstractInhabitantImpl.java:76)
at com.sun.enterprise.v3.server.AppServerStartup.run(AppServerStartup.java:253)
at com.sun.enterprise.v3.server.AppServerStartup.doStart(AppServerStartup.java:145)
at com.sun.enterprise.v3.server.AppServerStartup.start(AppServerStartup.java:136)
at com.sun.enterprise.glassfish.bootstrap.GlassFishImpl.start(GlassFishImpl.java:79)
at com.sun.enterprise.glassfish.bootstrap.GlassFishDecorator.start(GlassFishDecorator.java:63)
at com.sun.enterprise.glassfish.bootstrap.osgi.OSGiGlassFishImpl.start(OSGiGlassFishImpl.java:69)
at com.sun.enterprise.glassfish.bootstrap.GlassFishMain$Launcher.launch(GlassFishMain.java:117)
... 6 more
Caused by: org.osgi.framework.BundleException: Unresolved constraint in bundle org.glassfish.web.weld-integration [301]: Unable to resolve 301.0: missing requirement [301.0] package; (&(package=com.sun.faces.spi)(version>=2.1.0)) [caused by: Unable to resolve 213.1: missing requirement [213.1] package; (package=javax.faces) [caused by: Unable to resolve 211.1: missing requirement [211.1] package; (&(package=javax.el)(version>=2.2.1))]]
at org.apache.felix.framework.Felix.resolveBundle(Felix.java:3443)
at org.apache.felix.framework.Felix.startBundle(Felix.java:1727)
at org.apache.felix.framework.BundleImpl.start(BundleImpl.java:922)
at org.jvnet.hk2.osgiadapter.OSGiModuleImpl.start(OSGiModuleImpl.java:169)
I tried web app specific JSF but that also fails:
glassfish change default jsf impl
Added to web.xml:
<class-loader delegate="false" />
<property name="useBundledJsf" value="true" />
I get the error:
Error occurred during deployment: Exception while loading the app :
java.lang.IllegalStateException: ContainerBase.addChild: start:
org.apache.catalina.LifecycleException: java.lang.RuntimeException:
com.sun.faces.config.ConfigurationException: CONFIGURATION FAILED!
org.glassfish.weld.jsf.WeldFacesConfigProvider cannot be cast to
com.sun.faces.spi.ConfigurationResourceProvider. Please see server.log for more details.
Grateful for suggestions.
Try following steps
Download jsf 2.1.21 jar from here
Rename it to javax.faces.jar .
Take backup of javax.faces.jar available at docroot\glassfish\modules
Paste and replace the old javax.faces.jar with downloaded javax.faces.jar available at docroot\glassfish\modules
Delete the osgi cache glassfish3\glassfish\osgi for the changes to
take effect
OK I finally have 2 workarounds (only) for getting Mojarra-2.1.21 running with Netbeans7.1.
Firstly, the following recommended approach does not as far as I can tell work in Netbeans7.1, it stubbornly refuses to recognise the server installed javax.faces.jar.
From https://weblogs.java.net/blog/edburns/archive/2011/09/26/try-out-mojarra-220-snapshot?force=714:
Once you download the javax.faces.jar, you must take some steps to install it in GlassFish 3.1 or 3.1.1.
Remove jsf-api.jar and jsf-impl.jar from the modules directory.
Put javax.faces.jar in the modules directory.
You must modify the default-web.xml file in domains/domain1/config and lib/templates. In
each directory, remove any mention of jsf-api.jar and jsf-impl.jar from the default.web.xml file.
In place of the two jars, add a reference to javax.faces.jar.
No matter what I do with Netbeans7.1 (and no matter whether clear osgi-cache and netbeans cache or whether remove then re-add server in Netbeans7.1 or how many times I restart glassfish3.1.1 and/or netbeans7.1), Netbeans7.1 will NOT see javax.faces.jar.
If you try to add the javax.faces.jar (only) to your web app libs and use this in glassfish-web.xml to for it to use web-app specific JSF, it will prevent import errors in your Netbeans7.1 project, but it still will not run:
<class-loader delegate="false" />
<property name="useBundledJsf" value="true" />
I get this error:
Error occurred during deployment: Exception while loading the app :
java.lang.IllegalStateException: ContainerBase.addChild: start:
org.apache.catalina.LifecycleException: java.lang.RuntimeException:
com.sun.faces.config.ConfigurationException: CONFIGURATION FAILED!
org.glassfish.weld.jsf.WeldFacesConfigProvider cannot be cast to
com.sun.faces.spi.ConfigurationResourceProvider.
The reason is described here: http://java.dzone.com/articles/upgrading-latest-mojarra
The issue seems to be that there are two versions of
ConfigurationResourceProvider on the class path: one at the web app
level (your bundled jar file) and a second at the parent class loader
level (provided by GlassFish). WeldFacesConfigProvider extends
ConfigurationResourceProvider at the parent class loader, but it ends
up casting this to ConfigurationResourceProvider at the web app class
loader. ...
Workaround: Adding the missing dependency to your app If you can't cast across class loaders you have to make the missing part available
to the right class-loader. Not replacing the javax.faces.jar in your
server's modules leads to adding the magic WeldFacesConfigProvider to
your app. It is contained in the
glassfish3\glassfish\modules\weld-integration.jar and by simply
putting that as an additional library to your application you also
solve the issue.
You now have 2 workaround choices:
Include the weld-integration.jar in your web app libs, and run with web app JSF settings in glassfish-web.xml.
Dirty trick: With .../glassfish/modules/javax.faces.jar still in place and also in your web app libs, disable or uncomment the bit in your glassfish-web.xml. It will then run with the server javax.faces.jar (and will see /modules/weld-integration.jar), and Netbeans will see the web app specific lib for imports.
This is unsatisfactory, I don't consider the question fully answered.
Q: How can one run JSF Mojarra 2.1.21 as Glassfish3.1.1 server JSF libs in NetBeans7.1 ?
And again, the reason I can't just upgrade Netbeans+Glassfish is that I have multiple problems with ObjectDB with versions of Glassfish above 3.1.1, which is why I am so adamant about installing JSF Mojarra 2.1.21 on Netbeans7.1+Glassfish3.1.1.
Grateful for any further suggestions.
I am trying to test a Mozilla plugin (developed using FireBreath) in the form of an .so shared object file. The plugin was developed on Ubuntu, where it works fine.
I am now trying it under OpenSUSE - so I first symlinked the .so file in ~/.mozilla/plugins:
> ln -s /path/to/npXXX.so ~/.mozilla/plugins/
... and then ran Firefox (7) from command line:
> /path/to/firefox -P myprofile
...
LoadPlugin: failed to initialize shared library libXext.so [libXext.so: cannot open shared object file: No such file or directory]
LoadPlugin: failed to initialize shared library /path/to/npXXX.so [/path/to/npXXX.so: undefined symbol: gtk_widget_get_mapped]
# and the LoadPlugin messages do NOT show a second time - probably because plugin is disabled (via about:addons).
And so I thought to try different stuff to look into this - but first, I restarted Firefox, and realized that on the second run I do not get the "LoadPlugin: failed to initialize" messages anymore! Then I tried removing the plugins symlink, and restarting FF; and adding it again, and restarting FF - still no error messages!
So, this tells me that probably Firefox somehow disabled/blacklisted the plugin (but which one: libXext, npXXX or both?) , but searching (grepping) for (np)XXX in '/path/to/myprofile/blocklist.xml' returns nothing (the plugin should use a email-like id, not those number GUIDs, so I'd expect that string to show in blocklist.xml if it's there).
Does anyone know: is the default behavior of Firefox to disable/blocklist plugins, that fail to load at first? If so, is there a way to force Firefox to load them again (and spit out error messages)? If you'd also have links to where this behavior is documented, it will be much appreciated :)
Many thanks in advance for any answers,
Cheers!
Note: after I stopped seeing the error messages, I did the following:
I am trying "about:plugins": "No enabled plugins found";
then trying "about:addons", and clicking under Plugins: "You don't have any add-ons of this type installed";
This plugin is not embedded in an extension, so nothing new should be added in "about:addons" under "Extensions" - and as expected, nothing new shows there. Under Ubuntu (where all works), just by symlinking the plugin to ~/.mozilla/plugins, the above two locations/screens start showing the plugin info.
This one of the things that puzzle me - if it just showed the plugin as "disabled", maybe I would have had a chance to re-enable it again (to get a new batch of error messages) - however, "about:plugins" and "about:addons" simply show nothing - so there's nothing I can use to enable from there. Which tells me Firefox has used a different method to disable the plugin(s) - but I cannot tell what it is...
Firefox has a cache for XPCOM modules ("fastload cache"), if a module fails to load Firefox won't try again. The cache is reset automatically if an extension is installed or if the application is updated. Starting with Firefox 4 you can also use -purgecaches command line flag to discard the cache.