I had problem with my application with Canvas generation ( I'm using JavaFx ). Setting this option helped:
-Dprism.order=j2d
The thing that is problem to is that I cann't find any documentation for prism ( Dprism ). Second problem is that I would like to set up this option via config file.
Properties props = System.getProperties();
props.setProperty("com.sun.prism.order", "j2d");
Code above dosen't work for me.
These were the properties used by JavaFX 20 months ago (from the adamish blog):
com.sun.scenario.animation.adaptivepulse
com.sun.scenario.animation.AnimationMBean.enabled
com.sun.scenario.animation.nogaps
decora.purgatory
glass.platform
javafx.animation.framerate
javafx.animation.fullspeed
javafx.animation.pulse
javafx.debug
javafx.embed.isEventThread
javafx.sg.warn
javafx.toolkit
javafx.verbose
javafx.version
nativewindow.ws.name
prism.debug
prism.device
prism.dirtyregioncount
prism.disableBadDriverWarning
prism.forcerepaint
prism.multisample
prism.noFallback
prism.order
prism.printallocs
prism.reftype
prism.showcull
prism.showdirty
prism.shutdownHook
prism.tess
prism.tessaa
prism.trace
prism.verbose
quantum.debug
quantum.pulsedebug
quantum.verbose
I do not know what most of the above properties are, when they are set, what values they may have, how they are used or what they do.
The JavaFX Project Lead (Richard Bair), notes:
Just a word of caution, if we haven't documented the command line
switches, they're fair game for removal / modification in subsequent
releases :-)
There is an issue tracker request to get some of the properties officially documented and supported:
JDK-8092282 "Document officially supported system properties and command line switches"
The request is currently scheduled for implementation in Java 9. Access to the issue tracker requires a login, but anybody can signup and comment on the issue or vote for it.
I was having the same problem. The issues is that if your main class extends Application, there is a launcher class that kicks in before your main method and reads the prism properties before you set them.
If you use a class that doesn't extend Application as the main class and from this one you set the system properties and then call the main method of class extending Application, the properties go through
Related
I would like to try the new pipeline feature in MediatR: https://github.com/jbogard/MediatR/wiki/Behaviors
I tried the following, but it does not get executed
services.AddMediatR();
services.AddTransient(typeof(IRequestPostProcessor<,>), typeof(PostHandler<,>));
What am I missing?
You need to register the behavior associated with post-processors, like this unit test shows.
Your registration code would look like:
services.AddMediatR();
services.AddTransient(typeof(IRequestPostProcessor<,>), typeof(PostHandler<,>));
services.AddTransient(typeof(IPipelineBehavior<,>), typeof(RequestPostProcessorBehavior<,>));
That behavior will get all the post-processors you registered and execute them.
Edit
After a comment about the post-processor running twice, I had a look at the code that registers MediatR in the ASP.NET Core built-in DI container, and it turns out instances of IRequestPreProcessor<TRequest, TResponse> and IRequestPostProcessor<TRequest, TResponse> are automatically registered as you can see here. What's left to do to get them running in the pipeline is just register the associated behavior. So the necessary registration is then:
services.AddMediatR();
services.AddTransient(typeof(IPipelineBehavior<,>), typeof(RequestPostProcessorBehavior<,>));
I encountered the same issue as Larsi in the comment above. My code looked like this
services.AddScoped<IPipelineBehavior<AddMessageRequest, MessageResponse>, RequestPostProcessorBehavior<AddMessageRequest, MessageResponse>>();
but the behaviour still executed twice. My solution was to simply not register it manually, seems like the registration is handled otherwise now.
In my case services.AddMediatR(Assembly.GetExecutingAssembly()); was enough.
Would be nice if someone could expand on why this is.
In roboelectric when you write your test class you have declare the #RunWith annotation of which there is RobolectricGradleTestRunner and RobolectricTestRunner.class. What is the difference and which one should we use ? Why is there 2 in the first place. If I use RobolectricTestRunner then it does not work for me it says some weird error like :
"java.lang.IllegalStateException: You need to use a Theme.AppCompat theme (or descendant) with this activity."
However this seems to go away if I use RobolectricGradleTestRunner.
RobolectricTestRunner was first and is for maven based projects.
RobolectricGradleTestRunner was for gradle based projects because some paths have changed.
Since robolectric 3.1.1 this is not more necessary and is now deprecated.
For more details see also http://robolectric.org/getting-started/
What are the strategies to embed a unique version number in a Spring application?
I've got an app using Spring Boot and Spring Web.
Its matured enough that I want to version it and see it displayed on screen at run time.
I believe what you are looking for is generating this version number during build time (Usually by build tools like Ant, Maven or Gradle) as part of their build task chain.
I believe a quite common approach is to either put the version number into the Manifest.mf of the produced JAR and then read it, or create a file that is part of the produced JAR that can be read by your application.
Another solution would be just using Spring Boot's banner customization options described here: http://docs.spring.io/spring-boot/docs/current/reference/html/boot-features-spring-application.html#boot-features-banner
However, this will only allow you to change spring-boot banner.
I also believe that Spring Boot exposes product version that is set in Manifest.MF of your application. To achieve this you will need to make sure Implementation-Version attribute of the manifest is set.
Custom solution for access anywhere in the code
Lets assume you would like to have a version.properties file in your src/main/resources that contains your version information. It will contain placeholders instead of actual values so that these placeholders can be expanded during build time.
version=${prodVersion}
build=${prodBuild}
timestamp=${buildTimestamp}
Now that you have a file like this you need to fill it with actual data. I use Gradle so there I would make sure that processResources task which is automatically running for builds is expanding resources. Something like this should do the trick in the build.gradle file for Git-based code:
import org.codehaus.groovy.runtime.*
import org.eclipse.jgit.api.*
def getGitBranchCommit() {
try {
def git = Git.open(project.file(project.getRootProject().getProjectDir()));
def repo = git.getRepository();
def id = repo.resolve(repo.getFullBranch());
return id.abbreviate(7).name()
} catch (IOException ex) {
return "UNKNOWN"
}
}
processResources {
filesMatching("**/version.properties") {
expand (
"prodVersion": version,
"prodBuild": getGitBranchCommit(),
"buildTimestamp": DateGroovyMethods.format(new Date(), 'yyyy-MM-dd HH:mm')
)
}
}
processResources.outputs.upToDateWhen{ false }
In the code about the following is happening:
We defined a function that can take a build number out of the VCS
(in this case Git). The commit hash is limited to 7 characters.
We configure the processResources task to process
version.properties file and fill it with our variables.
prodVersion is taken from Gradle project version. It's usually set
as version in gradle.properties file (part of the general build
setup).
As a last step we ensure that it's always updated (Gradle
has some mechanics to detect if files ened to be processed
Considering you are on SVN, you will need to have a getSvnBranchCommit() method instead. You could for instance use SVNKit or similar for this.
The last thing that is missing now is reading of the file for use in your application.
This could be achieved by simply reading a classpath resource and parsing it into java.util.Properties. You could take it one step further and for instance create accessor methods specifically for each field, e.g getVersion(), getBuild(), etc.
Hope this helps a bit (even though may not be 100% applicable straight off)
Maven can be used to track the version number, e.g.:
<!-- pom.xml -->
<version>2.0.3</version>
Spring Boot can refer to the version, and expose it via REST using Actuator:
# application.properties
endpoints.info.enabled=true
info.app.version=#project.version#
Then use Ajax to render the version in the browser, for example using Polymer iron-ajax:
<!-- about-page.html -->
<iron-ajax auto url="/info" last-response="{{info}}"></iron-ajax>
Application version is: [[info.app.version]]
This will then show in the browser as:
Application version is: 2.0.3
I'm sure you've probably figured something out since this is an older question, but here's what I just did and it looks good. (Getting it into the banner requires you to duplicate a lot).
I'd recommend switching to git (it's a great SVN client too), and then using this in your build.gradle:
// https://github.com/n0mer/gradle-git-properties
plugins {
id "com.gorylenko.gradle-git-properties" version "1.4.17"
}
// http://docs.spring.io/spring-boot/docs/current/reference/html/deployment-install.html
springBoot {
buildInfo() // create META-INF/build-info.properties
}
bootRun.dependsOn = [assemble]
And this in your SpringBoot application:
#Resource
GitProperties props;
#Resource
BuildProperties props2;
Or this way to expose those properties into the standard spring environment:
#SpringBootApplication
#PropertySources({
#PropertySource("classpath:git.properties"),
#PropertySource("classpath:META-INF/build-info.properties")
})
public class MySpringBootApplication {
and then referencing the individual properties as needed.
#Value("${git.branch}")
String gitBranch;
#Value("${build.time}")
String buildTime;
I want to load dynamically XML meta-data files that are not in the classpath (the XML meta-data files will be generated after launching my app).
I thought I could call the method
MetaDataManager.registerFile(java.lang.String fileURLString, FileMetaData filemd, ClassLoaderResolver clr)
Then, I tried the API enhancement, so I added the following lines:
JDOEnhancer enhancer = JDOHelper.getEnhancer();
enhancer.setVerbose(true);
enhancer.addClasses(ClassToPersist.class.getName()).enhance();
getClass().getClassLoader().loadClass(ClassToPersist.class.getName());
The following jars are in the classpath: datanucleus-api-jdo.jar, datanucleus-connectionpool.jar, datanucleus-core.jar datanucleus-rdbms.jar, jdo-api.jar, asm.jar.
But when I launch my app, I get this exception:
Caused by: mypackage.MyException:
org.datanucleus.api.jdo.exceptions.ClassNotPersistenceCapableException: The class "mypackage.ClassToPersist" is not persistable. This means that it either hasnt been enhanced, or that the enhanced version of the file is not in the CLASSPATH (or is hidden by an unenhanced version), or the Meta-Data/annotations for the class are not found.
Do you please have any idea how to fix this ?
PS: I also noticed that the method enhance returns 0 which indicates that the class has not been enhanced (we could exclude the other options)
Thanks
I think I found an easy way to fix this.
At runtime, I created a jar that contains the updated metadata file as META-INF/package.jdo. Then I added this jar to the classpath as described here
Using this hacks, I didn't need to re-enhace my class since it is enhanced after compilation.
(But for information, I had to call JDOEnhancer.addFiles() to enhance my class.)
So your call to loadClass has loaded the unenhanced class (since it would have been loaded in order to perform the enhancement presumably), and you didn't follow the tutorial that is provided at http://www.datanucleus.org/documentation/development/dynamic_class_metadata_enhance_runtime.html
Is there a simple way to check if a content-type, or a specific object, has Versioning enabled/disabled in Plone (4.3.2)?
For context, I am making some unique conditionals around portal_actions. So instead of checking path('object/##iterate_control').checkout_allowed(), I need to first see if versioning is even enabled. Otherwise, the action in question does not display for items that have versioning disabled, because obviously it isn't checkout_allowed.
I didn't have any luck with good ole Google, and couldn't find this question anywhere here, so I hope it's not a dupe. Thanks!
I was able to get this working by creating a new script, importing getToolByName, and checking current content type against portal_repository.getVersionableContentTypes(). Then just included that script in the conditional.
I was looking for something like this that already existed, so if anyone knows of one let me know. Otherwise, I've got my own now. Thanks again!
The first thing that checkout_allowed does is check if the object in question supports versioning at all:
if not interfaces.IIterateAware.providedBy(context):
return False
(the interface being plone.app.iterate.interfaces.IIterateAware:
class IIterateAware( Interface ):
"""An object that can be used for check-in/check-out operations.
"""
The semantics Interface.providedBy(instance) are a bit unfortunate for usage in conditions or TAL scripts, because you'd need to import the interface, but there's a reversal helper:
context.portal_interface.objectImplements(context,
'plone.app.iterate.interfaces.IIterateAware')