new to Fluent/NHibernate and trying to upgrade code base to the latest FluentNHibernate from version 1.1.0.685. The PersistenceConfiguration type used to have a Cache method (below) and no longer there. Is this done differently in subsequent releases? I couldn't find anything in their release notes of the changes.
public TThisConfiguration Cache(Action<CacheSettingsBuilder> cacheExpression)
{
cacheExpression(this.cache);
return (TThisConfiguration) this;
}
Related
I am currently working on upgrading an existing Typo3 8.7 instance to Typo3 9.5, following along with the instructions in the official docs.
I have a problem though with a custom extension (written by not-me) that uses TYPO3\CMS\Extensionmanager\Utility\ConfigurationUtility to obtain various configuration values used in the extension.
Usage of the class is as follows:
public function getConfiguration(): array
{
$configuration = $this->baseConfigurationUtility->getCurrentConfiguration('sbb_oauth');
return array_column($configuration, 'value', 'name');
}
which is in turn used by this method:
public function getConfigurationOption(string $name)
{
$configuration = $this->getConfiguration();
return (isset($configuration[$name]) ? $configuration[$name] : null);
}
The other methods in the class all call getConfigurationOption(string $name) in order to get some specific value from the configuration fetched by ConfigurationUtility.
The problem now is that TYPO3\CMS\Extensionmanager\Utility\ConfigurationUtility is no longer present in Typo3 9.5, and I haven't been able to find any official instructions as to how to properly migrate code that uses it, neither by online search nor by looking through the API.
Since I am not a PHP programmer, and I don't have any experience with Typo3 and its extension system (I just inherited the system and am trying to upgrade it as cleanly as I can), I would appreciate any tips/hints, including "please look [link goes here]", in case I've managed to miss something utterly obvious - thanks in advance!
Is there a way to use sun.reflect in OpenJDK11, by maybe adding something in "--add-exports"? Our code fails since a jide pkg internally uses sun.reflect package and I'm trying to see if there's a way to make it work.
I've already tried with the below but that doesn't help.
"--add-exports jdk.unsupported/sun.reflect=ALL-UNNAMED"
Here's the exception, where the underlying class references sun.reflect.Reflection
java.lang.NoClassDefFoundError: sun/reflect/Reflection
I had this problem and fixed it by using a newer version of jide. Changing from jide-whatever:3.2.3 to jide-whatever:3.7.6 was enough to make it work in my case.
If you cannot migrate to newer versions, the solution is to make a wrapper around Throwable().getStackTrace()[n].getClass() and put it in WEB-INF/classes folder
This is simple workaround. It works in many cases.
package sun.reflect;
public class Reflection {
public static Class<?> getCallerClass(int n){
StackTraceElement[] elements = new Throwable().getStackTrace();
return elements[n].getClass() ;
}
}
https://github.com/rafaljot/NoClassDefFoundError-sun-reflect-Reflection
It can be fixed when you update the version of the jars.
I am busy migrating a project from NHibernate 3.3.3.4 to 5.1.3. I have picked up an error when committing a transaction or flushing the session.
The error I am currently receiving is as follows:
Method not found: 'System.Data.IDbCommand NHibernate.AdoNet.AbstractBatcher.get_CurrentCommand()'.
I have looked into the NHibernate 5.1.3 code and release notes and I can see that there has been a change to the CurrentCommand property getter for the AbstractBacther class. In this major release of NHibernate, this property has changed from being of type IDbCommand to type DbCommand. See the difference below:
Version 3.3.x Permalink
protected IDbCommand CurrentCommand
{
get { return _batchCommand; }
}
Version 5.1.3 Permalink
protected DbCommand CurrentCommand
{
get { return _batchCommand; }
}
I am using the SqlAzureClientDriver (NHibernate.SqlAzure) for reliable SQL Azure connections. I have noticed that the latest version of NHibernate.SqlAzure is still using the IDbCommand implementation.
Has anybody else using SqlAzureClientDriver experienced this problem and been able to resolve it?
Use the NHibernate5 version of SqlAzureClientDriver which can be installed as the nuget package NHibernate5.SqlAzure.
This was the standard boiler plate I was using:
var stage = new createjs.Stage("canvas1");
createjs.Ticker.addEventListener("tick",stage);
stage.enableMouseOver();
...
createjs.Ticker.setFPS(12);
createjs.Ticker.addListener(stage,false);
Apparently createjs.Ticker.addListener is no longer supported. How should the above code be changed?
Your example shows both the correct and deprecated usage.
// OLD
createjs.Ticker.addListener(stage,false);
// NEW
createjs.Ticker.addEventListener("tick", stage);
//OR
createjs.Ticker.on("tick", stage);
The changes make Ticker use the same Event dispatcher pattern that the rest of CreateJS does.
Additionally, the framerate method has changed to a setter:
// OLD
createjs.Ticker.setFPS(12);
// NEW
createjs.Ticker.framerate = 12;
It will depend on what version you use of EaselJS. I updated the demo you posted to the latest version using those changes: http://jsfiddle.net/lannymcnie/Aprdf/80/
Unfortunately there are still demos out there with out-of-date code. Let me know if you have any other questions.
I have the following in my feature.template.xml
...
<VersionRange BeginVersion="1.0.0.1" EndVersion="1.0.0.2">
<CustomUpgradeAction Name="1.0.0.1_TO_1.0.0.2"></CustomUpgradeAction>
</VersionRange>
<VersionRange BeginVersion="1.0.0.2" EndVersion="1.0.0.3">
<CustomUpgradeAction Name="1.0.0.2_TO_1.0.0.3"></CustomUpgradeAction>
</VersionRange>
...
My feature upgrade event is as follows:
public override void FeatureUpgrading(SPFeatureReceiverProperties properties, string upgradeActionName, System.Collections.Generic.IDictionary<string, string> parameters)
{
using (SPSite site = (SPSite)properties.Feature.Parent)
using (SPWeb mySite = site.RootWeb)
{
switch (upgradeActionName)
{
case "1.0.0.1_TO_1.0.0.2":
//execute logicA
break;
case "1.0.0.2_TO_1.0.0.3":
//execute logicB
break;
default:
break;
}
}
Am I correct in saying that if the site is currently version 1.0.0.0, it will be upgraded to v 1.0.03, executing both logicA and logicB above. This means that sharepoint would call featureupgrading event for each version upgrade.Is this correct? Or do I need to do something different to achieve this?
I also have the following concerns:
What exactly do the the BeginVersion and EndVersion mean.
I especially do not understand the BeginVersion. What happens if instead of 1.0.0.2 I set it to 1.0.0.1 as well?
Any assistance would be greately appreciated, as I did not find any good relevant details online or on books.
When you add a new Feature to your VS SharePoint project, Visual studio initializes your Feature with version 0.0.0.0.
In the properties window you can set a version number for your feature.
When you want to upgrade an existing feature you'll have to define the range of versions for which you want your upgrade actions (code, new manifest, ...) to happen.
E.g.: You deployed your feature without changing the version number. Your current deployed feature has version number 0.0.0.0.
You want to upgrade your feature and set the version number to 2.0.0.0.
If you define a versionrange as follows:
<VersionRange BeginVersion="1.0.0.0" EndVersion="2.0.0.0">
You'll notice nothing will happen when you call SPFeature.Upgrade() since 0.0.0.0 is not in the defined versionrange.
If you use this versionrange
<VersionRange EndVersion="2.0.0.0">
or
<VersionRange BeginVersion="0.0.0.0" EndVersion="2.0.0.0">
You'll notice your FeatureUpgrading eventreceiver or other upgrade actions will be triggered.
Your upgraded feature will now have version number 2.0.0.0.
If you call SPFeature.Upgrade again nothing will happen again, because 2.0.0.0 exceeds the defined versionrange. So BeginVersion is included, EndVersion not.
Every feature with a version number between [0.0.0.0 - 1.x.x.x] will be upgraded if you use the latter versionranges.
I think you can also leave the BeginVersion and EndVersion attributes entirely out. Then you're upgradeactions will be triggered at every SPFeature.Upgrade() call. (To be verified)
For more information: Chris O'Brien wrote an interesting articles series about this topic, cfr. http://www.sharepointnutsandbolts.com/2010/06/feature-upgrade-part-1-fundamentals.html