I started migrating my applications to PHP7 last year already using the PHP7 release candidate (7.0.0RC5) available at the time. I successfully made all required changes and the apps are all running fine on that version (PHP 7.0.0RC5).
Recently I started testing the code with the latest and greatest PHP-7 version (7.0.11) and everywhere in the code where 'require_once()' is used (not only my code but also in 3rd party libraries) the code breaks with " 'fileA.php'...failed to open stream: No such file or directory in...'fileB.php>' ".
I double-checked and compared all the php.ini settings between the two versions and I am certain there are no differences.
Question: Has anything changed between 7.0.0RC5 and now that causes the behavior of require_once to be different? Even just a pointer would be highly appreciated.
Related
Hallo I've failed to bind both versions of a LiteDB library to my project. There's a necessity to consume both versions to access old and new databases from GUI though.
Nothing, I've found on internet, functioned. The project took the newest one, 4.1.5.0 every time. Can You post the abrupts from .csproj and .config files which succeed?
I noticed that runtime version of both versions is identical. Can it be the cause?
Does anyone have a guide on setting up AHBot in an AzerothCore 3.3.5 server? I can find no mention of ahbot in the world.conf and no DB tables like auctionhousebot in the database or any references. It is included in TrinityCore so all the google references that I find point me back there.
Our server is just two of us and it would be nice to have some items on the auction house. At the moment, if you need a silver bar you have to go out in the world and find it. That was exciting the first couple of times... but gets old.
I followed the guide to install off github: https://www.azerothcore.org/wiki/Installation and am using the latest release under Ubuntu linux.
Thank you for any help. You are my last hope...
AHBot is not currently an 'official' supported module of AzerothCore (which would be why you aren't finding any settings in the worldserver or anywhere else regarding it).
There is a module in development that isn't currently part of the AC list, but I've gotten it working on my personal server: https://github.com/AyaseCore/mod-ahbot Note that this is a bit different than a normal module as there is also a git patch that needs to be applied manually.
Theres a module in azerothCore repository you have to apply patch manually but it wont compile on Win x64 and unix x64 comes up with an error about 9 arguments, but seems to compile for some
I'm trying to profile a web application with xDebug and Webgrind since I'm doing it in a remote Linux server. For some weird reason it doesn't show call names or file source. I was suspecting that there might be some kind problem with readying the script files (not sure if it's doing it) but giving target folders 777 didn't make any difference. Does anybody have a clue where I'm failing?
Thanx!
The webgrind version found on google code does not work for xDebug 2.3.
Here is a fork that works: webgrind
Ok, 24h later:
Seems that webcache grind doesn't support cachegrind file function compression feature that was introduced in xDebug 2.3 (released 2015). The latest webgrind was released ~2008-2009 so makes sens that it doesn't work. The same applies to WinCacheGrind client. Currently seems that only Windows cachegrind analyzer is qCacheGrind and linux client kCacheGrind
When I maange to find some free time I'll fork the project and make it compatible with compression.
I have a XPage application where I use JavaMail in one of my managed beans. Currently I have added the jar-file C:\Programme\IBM\Notes\framework\shared\eclipse\plugins\com.ibm.designer.lib.javamail_9.0.0.20130301-1431\lib\mail.jarto the build-path of the manged bean. This works well. But now I want to use a newer version of JavaMail as the Domino server uses version 1.3 but I need version 1.4.x.
I have downloaded the new JavaMail jar-files from Oracle. In Domino Designer (version 9) I add this jar-file to the new design element "Code / Jars" and remove the old jar-files from the build path.
My managed bean is still compiling and running as desired, but if I check the version the bean is using it reports still version 1.3. To check the version number I use the debug property of JavaMail and it's reporting version 1.3 to the domino server console.
Is there a way to tell the domino server to use the jar-files in the application (i.e. the nsf) and not his own? Is there another approach to update the JavaMail version?
The reason I want to use a newer version of JavaMail is as follows: I want to read mails from an imap server with ssl. To avoid the problem of importing ssl-certificates I simply want to trust all hosts. This can be be done via MailSSLSocketFactory, but this is only available since version 1.4.2. Therefore I want to use a newer version of JavaMail.
Another reason I want to use a newer version is as follows: the method "getSortedMessages" of "IMAPFolder" is only available since version 1.4.4. (and so are some other features of JavaMail).
This may be a little too late for you... I think the right approach may be to include the jar file as an OSGi plugin.
I have spent some time to figure out how to do that - and recently succeeded :-) I have described the steps to perform to make this work in two articles. The first is about wrapping a JAR into a plug-in: http://www.dalsgaard-data.eu/blog/wrap-an-existing-jar-file-into-a-plug-in/ - the second is about deployment (and there is a link in the first one).
/John
You can solve the problem by creating an OSGi plug-in that supersedes the one that sports the JavaMail library: com.ibm.designer.lib.javamail.
In order to do that do the following:
Create an OSGi plugin whose id is com.ibm.designer.lib.javamail (Dalsgaard's tutorial on how to do it)
Set its version to a higher number than the one the Domino server is shipped with (to know the version type tell http osgi ss com.ibm.designer.lib.javamail). As of now using 9.0.1.qualifier should be fine
Deploy the plugin either through an update site or by directly copying it under the domino\workspace\applications\eclipse\plugins folder.
Restart the HTTP service. The higher version - the one you created - will now be used
I've got the same problem here, but found a solution. Be warned, this is not the best answer but it will work. Simply download the latest javamail jar here and rename the jar file to 'mail.jar'. Just replace the current file in IBM\Notes\framework\shared\eclipse\plugins\com.ibm.designer.lib.javamail_9.0.0.20130301-1431\lib\mail.jar with this file. Quit the http task and restart it. The code will now work with the latest version.
Possibly this is related to Using a plugin generated with Firebreath in a Firefox Extension?; however, my question is possibly more specific, so here goes...
I'm working on Linux (Ubuntu 11.04), and I have built a Mozilla/Firefox (Firefox 7) plugin using FireBreath. The resulting plugin on this platform is an "npXXX.so" file, which I got symlinked in ~/.mozilla/plugins. Then, I have coded an extension that uses this plugin - and apart from the symlink, nothing else seems required - all seems to work just smashing :)
So, knowing that "firefox supports installing your plugin via XPI. This is not recommended by the FireBreath team", now I'd still like to package the extension AND the plugin into an XPI file. So, I'm reading a bit on Structure of an installable bundle - MDN, and I can see these two possibilities:
/components/* XPCOM components (*.js, *.dll), and interface files from *.xpt (>=1.7)
...
/plugins/* NPAPI Plugins (>=1.8)
...
binary-component components/linux/mycomponent.so ABI=Linux_x86-gcc3
Now, it says: "The older XPCOM- and LiveConnect-based APIs for plugins should not be used.", so I guess the "/components" directory should not be used (even if it is given as an example in the above page). And I can not find this stated explicitly anywhere, but I'm guessing FireBreath builds NPAPI plugins - so presumably "/plugins" is the way to go. (There is also mention of "/platform", but it clearly says it's been deprecated for Firefox > 3.6).
Ok, so far so good... So I try to copy the plugin file to plugins/linux inside the extension directory:
cp -L ~/.mozilla/plugins/npXXX.so plugins/linux/
... and then insert the following in chrome.manifest:
binary-component plugins/linux/npXXX.so ABI=Linux_x86-gcc4
... then I zip the whole extension directory (the plugin included) as an .xpi, try to install it on a different computer. There, the .xpi succesfully installs, the .so file is indeed unpacked under the profile's extensions/XXX/plugins/linux/ directory - and every cross-platform (javascript) code of the extension works fine; except that the plugin cannot be found.
Now, of course, the user could themselves symlink the extension .so to ~/.mozilla/plugins/; however, I would like to spare the user of that :)
How would I go about this kind of packaging thing - is there a recommended way to do it?
Many thanks in advance for any answers,
Cheers!
Edit: found Shipping a plugin as a Toolkit bundle - MDN which claims only install.rdf , and a plugins/obj.so is needed; then I found Running Quake Live in Firefox 4, 5 and 6 on Linux [fixes inside], referring to a QuakeLivePlugin_433-modded_ff10.xpi, and that one does indeed follow such a simple structure.. If I install that, I get both a Quake extension and a Quake plugin (and that even with Error Console complaining "Could not read chrome manifest file '/path/to/extensions/quakeliveplugin#idsoftware.com/chrome.manifest'.") .... but if I try the same with my FireBreath plugin (e.g. just an install.rdf and plugin in /plugins), only extension gets shown - no plugin (and no reasonable error messages).. Could this be a problem with FireBreath?
Well, I'll post this as an answer - I have just confirmed that FireBreath plugin does in fact work being packaged in the simple "toolkit bundle" way as an .xpi extension.
Basically, I just cleared up my development PC's Firefox profile, and tried to install the .xpi carrying the plugin there - and on the dev PC, the plugin shows in about:plugins and runs just fine (even if it's just unpacked in profile/extensions/EXT/plugins/obj.so, and not in ~/.mozilla/plugins)... In fact, I packaged both the extension and the plugin in separate .xpi's, which were then merged in a single one as recommended in Multiple Item Package - MDN - and that works fine too (upon loading the merged xpi, one gets prompted about installing two extensions - one for the plugin carrying one, and the other for the "plain" extension)...
So the problem was on the other test computer only - and the problem seems to be that I'm using Gnome libraries in the plugin, and while my dev PC is Ubuntu 11.04 - I think this test PC was Ubuntu 10.04 ... So, quite likely, the problem is incompatible Gnome libraries in the plugin build; unfortunately, I don't get many errors back from firefox, even if I do:
NSPR_LOG_MODULES=IPCPlugins:5 NSPR_LOG_FILE=/tmp/plugins.log /path/to/firefox -P myprofile
(... as recommended in Logging Multi-Process Plugins - MDN - however, the /tmp/plugins.log remains empty). The only thing Firefox on the problem machine spits is something like this to stdout:
WARNING: Application calling GLX 1.3 function "glXCreatePixmap" when GLX 1.3 is not supported! This is an application bug!
WARNING: Application calling GLX 1.3 function "glXDestroyPixmap" when GLX 1.3 is not supported! This is an application bug!
(firefox:6548): GLib-GObject-WARNING **: /build/buildd/glib2.0-2.24.1/gobject/gsignal.c:1149: unable to lookup signal "text-insert" for non instantiatable type `AtkText'
... and I cannot tell if this has something to do with the plugin or not... But I guess at least the packaging part got confirmed as working now :) Cheers!
EDIT: After a while, the Firefox on the test PC did spit out the following (although I would have expected this message to pop up instantly):
LoadPlugin: failed to initialize shared library /path/to/profile/extensions/extXXX/plugins/npXXX.so [/usr/lib/libstdc++.so.6: version ``GLIBCXX_3.4.14' not found (required by /path/to/profile/extensions/extXXX/plugins/npXXX.so)]
... which finally confirms it was a build problem I have had.