I´m using OptaPlanner to solve optimization problems, I´m working with HardMediumSoftBigDecimalScore and OptaPlanner said me:
field private org.optaplanner.core.api.score.buid
in.hardmediumsoftbigdecimal.HardMediumSoftBigDecimalScore asota.lubricantselection.lsopt.domain.bearinglubricantsolution.BearingLubricantSolution.score) that returns a scoreType (class org.optaplanner.core.api.score.buildin.hardmediumsoftbigdecimal.HardMediumSoftBigDecimalScore) that is not recognized
as a default Score implementation.
If you intend to use a custom implementation, maybe set a scoreDefinition in the PlanningScore annotation.
I tried with 7.43.1 version and 7.40.0 version the same error persist.
Thank you in advance, I look forward to your comments.
I remember fixing this bug for master the other day. It was simply not hooked in.
The fix will be part of the 8.0.0.Beta1 release. The fix is not backported to 7.x at this point (if a customer submits a support ticket, we will prioritize the backport).
Workaround wise, there's nothing I can immediately think about... sorry.
Related
According to http://showcase.omnifaces.org/facesviews/ExtensionlessURLs by default, all URLs generated by ViewHandler.getActionURL(FacesContext, String), which is used by among others
<h:form>, <h:link>, <h:button>
and all extended tags, will also be extensionless.
I try using this by putting Facelets source files into /WEB-INF/faces-views directory.
I typed /context/entries in the browser and I got the page in /WEB-INF/faces-views/entries.xhtml. But when I used this in my facelet page:
<h:link outcome="entries">Entries</h:link>
The url resulted is /context/WEB-INF/faces-views/entries.xhtml which is not the desirable result. What went wrong?
I am using Mojara 2.2.12 and Omnifaces 2.6.9 and my faces servlet mapping is *.jsf.
There was a small mistake in FacesViews of specifically 2.6.9 which is fixed in 2.7-SNAPSHOT. While working on getting FacesViews to support folders with periods in names such as /foo.bar/baz, I have accidentally committed a part of the fix into 3.x only instead of into 2.x. That explains why it works just fine in 3.1, as demonstrated by the "viewsdemo" showcase. My mistake, this just proves again that I'm a human and not a machine.
There are a few options to get around this:
Downgrade to 2.6.8.
Or, migrate to 3.1.
Or, keep 2.6.9 and use the "Minimal configuration" approach of a single web.xml context parameter instead of "Zero configuration" approach of placing files in /WEB-INF/faces-views.
BalusC is right, switching to version 2.6.8 solves the problem. The credit is BalusC's as always, but he has too much credit so I think he wouldn't mind that I posted an answer myself, just don't want to bother him.
Change the servlet mapping to *.xhtml also solves the problem. With all due respect, Xtreme Biker: a bug is a bug. Even if I change the mapping to *.abc there should not be a problem.
I am trying to override the default liferay-multi-vm-clustered.xml for application level caching using a liferay hook. Any instruction or links? Already spent much time googling but didn't find anything useful.
Thanks in advance.
PS: Already know i can override it via manual deployment and portal.properties.
PPS: Sorry for the format new to stackoverflow.
I'm assuming that you're referring to Liferay 6.x
I'm not aware of any hook that can override this file. Specifically because hooks are only deployed after Liferay has fully been set up and started, it'd be changing the setup after the fact.
You can introduce a new file and reference it in portal-ext.properties. If you want to package this in a plugin, I'm afraid it'll be an ext-plugin. Even though I don't like to suggest using ext, in this case it's a well maintainable ext, so it does not bring the same maintenance-danger as code-containing ext plugins.
currently I am trying to register a Doctrine-Eventlistener for every request in my FLOW3-Package. Some research pointed me to the Package.php, but unfortunately the ObjectManager is not available when the boot()-Method is called.
I searched the whole FLOW3-Documentation http://flow3.typo3.org/documentation/guide/partiii/bootstrapping.html without luck
Any hints on which is the right place to do package-wide setup with access to the object manager?
thanks and best regards
Your are bit to early in the bootstrap to get every object, I have a problem, maybe related to yours, you can check my bug report on http://forge.typo3.org/issues/33838
Why do you need a Doctrine Eventlistener, maybe you can use AOP to have this kind of feature ?
I have a CakePHP ticketing app where I am using Revision Behavior to keep revision history of each tickets. The problem I have using this behavior is, it does not display validation error messages. Here is the line I have added in the model.
public $actsAs = array('Revision' => array('limit'=>10));
When I comment this line, it displays error messages and otherwise it does not. Also, when I debug it using x-debug, I see validationErrors variable is set and has all error message values set properly.
Please shed some light here.
Edit: I am using Cake 2.1
First, be sure to get the last version of this behavior : http://alkemann.googlecode.com/svn/trunk/models/behaviors/revision.php
for integration in CAKE 2.X, the problem comes from line 980 in the createShadowModel() function:
$Model->ShadowModel->alias = $Model->alias;
The behavior gives the same alias to the base model and its shadowmodel it will save in the _revs table and that seems to mess up the validation messages.
The problem is that this behavior is loaded automatically when you access your model, and the createShadowModel() function is called even if your input doesn't validate.
One of the solution would be to comment out this line from createShadowModel() and then to add it only to every function in the behavior that will make an operation in the DB . There is surely a better way than that, like detecting in the setup() if there is need to go further to initialization, but couldn't find how to do it. So that's my first step towards at least allowing to use this behavior in Cake 2.X.
There are a few things that could be happening here. Too much for one to simply tell you what is happening since we don't have any of your code. However, I am pretty certain that this behavior, being that it was written in 2008, will have issues with CakePHP version 2.1, which just released its first alpha. There have been a lot of changes to the infrastructure of Cake that could cause this not to work. I'd say this would probably work with version 1.3 and definitely with 1.2, but getting support for 2.1 probably won't happen without updates.
That said, this is a behavior, which should only alter model code. So, there should be not impact (theoretically) on your view. Are you sure you are using the proper conventions in your code to display errors (even though commenting it out changes displayed messages).
I'd look for a 2.0+ compatible version of the behavior. Or, you could throw the code on Github and start to port it yourself. You may get some help from some Cake people.
I have a Managed Object Context to which I add two different SQLite stores. I use Configurations in the Mananged Object Model to assign certain entities to one store and other entities to the other. The Configurations are called "UserDB" and "MainDB".
Everything works okay until I try to use automatic migration. After creating a new Managed Object Model version, and adding a new attribute to one of the entities in the UserDB Configuration, I get an exception when adding the old version store (for the UserDB related store) to the store coordinator: 'Model does not contain configuration 'UserDB'.' I can find no hits for this error on Google. Anyone out there using multiple stores with Configurations? Anyone have an idea what I might be doing wrong?
The stack looks like this:
objc_exception_throw
-[NSManagedObjectModel isConfiguration:compatibleWithStoreMetadata:]
-[NSStoreMigrationPolicy sourceModelForStoreAtURL:metadata:error:]
-[NSStoreMigrationPolicy(InternalMethods) _gatherDataAndPerformMigration:]
-[NSPersistentStoreCoordinator addPersistentStoreWithType:configuration:URL:options:error:]
-[MyAppDelegate persistentStoreCoordinator]
This looks like a bug with migration+configurations. I was able to work around the problem by going through the same motions and passing nil for configuration when calling addPersistentStoreWithType. The migration happens, and then I can make a new persistent store coordinator and add the stores again with the proper Configuration string arguments.
This is the second configuration related bug I've run into. Not a well tested feature apparently.
I had the same problem. The fact pattern was identical and the error message the same. It turned out, however, to be the result of my own mistake.
Let's say the old model was Blah.xcdatamodel and the new Blah 2.xcdatamodel. I had started making changes to Blah before realising my mistake and creating Blah 2. I then used my version control system (Git) to revert to the old Blah and then recreated Blah 2. Everything looked right. But I must have done something wrong in the reversion process, because when I thought to double check that Blah.xcdatamodel in my current project folder was really the same as Blah.xcdatamodel in the project folder I used to build the previous version of the app (fortunately I always keep a zipped archive of the project folder for each released version as I don't fully trust version control systems), I found that they were in fact different, albeit that they looked identical in XCode. The file size was different, for instance.
I substituted the old Blah into my current project folder, and lo and behold it all went perfectly, without any need for the workaround described by Ken.
I am not saying that Ken had necessarily made a similar mistake, but if you do encounter this message it is at least worth confirming that the model you are migrating from is REALLY the model that was used to create the data in question.