I'm trying to embed Apache Derby into an application. When I run it directly from IntelliJ, everything works fine, but sbt run generates the exception:
Caused by: java.security.AccessControlException: access denied org.apache.derby.security.SystemPermission( "engine", "usederbyinternals" )
This seems to relate to the SecurityManager that SBT uses. Are there ways to disable, reconfigure, or override the default SBT SecurityManager?
JGC provided the insight in this question.
In the relevant app:
System.setSecurityManager(null)
Alternatively, one could simply provide a preferred security manager in this way.
Related
Let's say that I have two F# projects targeting NET5 and producing console applications. Let's call them MyService and MyAdminConsole. When I build the solution, then the folders, e.g. ...\MyService\bin\x64\Debug\net5.0 and ...\MyAdminConsole\bin\x64\Debug\net5.0 will contain:
...
appsettings.json
...
MyService.exe
MyService.dll
MyService.deps.json
MyService.runtimeconfig.json
MyService.runtimeconfig.dev.json
...
and
...
MyAdminConsole.exe
MyAdminConsole.dll
MyAdminConsole.deps.json
MyAdminConsole.runtimeconfig.json
MyAdminConsole.runtimeconfig.dev.json
...
where appsettings.json, obviously, exists only in MyService because it is the service, which needs the settings.
Now, I want to build both the service and the admin console into the same folder so that admin console could have access to the same appsettings.json and I stress the same appsettings.json, not a copy of it.
This seems straightforward, right? Just add a reference to MyAdminConsole into MyService project. However, when I rebuild the solution, then MyAdminConsole.exe and MyAdminConsole.dll are copied into ...\MyService\bin\x64\Debug\net5.0 but MyAdminConsole.*.json are not. Subsequently, MyAdminConsole won't work from that folder.
Sure, I can add post build steps and actually copy these json files where needed. However, that seems ugly and just plain wrong.
I wonder what is a proper solution? Thanks.
PS This is probably applicable to C# solutions as well but I have not checked that yet.
If I understand your issue correctly then please take a look at the workarounds proposed in https://github.com/dotnet/sdk/issues/1675
All,
I'm trying to get Play Framework to recognize JVM arguments in all modes (test, run start) by setting them in Build.scala.
Unfortunately, Play ignores everything I've thrown at it.
I've set Keys.javaOptions and Keys.fork, but it SBT flat out ignores the fork command. I also tried going at this by replacing Build.scala with build.sbt, but that doesn't seem to work either.
I realize you can set JAVA_OPTS or PLAY_OPTS in your environment, but this is really lousy way of doing things. One should be able to configure this at the application level and play should be smart enough to either spawn a new process or re-launch itself with the appropriate configuration.
Anyone able to get this to work? If so, can you provide a complete, working solution?
The Play Framework SBT keys override javaOptions you pass, and therefore it will not work.
The way to do it ,according to the documentation, is to pass those arguments at the start command.
The syntax changes a bit from version to version, but at 2.2.x it is:
$ /path/to/bin/<project-name> -J-Xms128M -J-Xmx512m -J-server
I am just starting with Meteor and working on an existing project. I am running into an issue with one of the packages(observatory-apollo) that's has the following line:
__meteor_bootstrap__.app.use Observatory.logger #TLog.useragent
It is complaining that __meteor_bootstrap__.app is undefined.
What is __meteor_boostrap__ exactly? I can't seem to find a description of what it is but from threads, people seem to know how to use it. I can only see it defined in boot.js, but it doesn't really tell me much...
Meteor uses connect npm module under the hood for various reasons, to serve static files, for example. __meteor_bootstrap__.app was the reference to connect app instance.
Before it was __meteor_bootstrap__.app but it changed couple of releases ago and became WebApp.connectHandlers object and is part of WebApp package.
WebApp is a standard package of Meteor, core package for building webapps. You don't usually need to add explicitly as it is a dependency of standard-app-packages.
Example of usage the connectHandlers is to inject connect middlewares in the same way as you would use any connect middleware (or some express middlewares, express is built on top of connect):
WebApp.connectHandlers
.use(connect.query())
.use(this._config.requestParser(bodyParser))
You can look at meteor-router Atmosphere package and take it as an example: https://github.com/tmeasday/meteor-router/blob/master/lib/router_server.js
More about connect: https://npmjs.org/package/connect
I recently take over a web application project using websphere and log4j running under AIX. To create a development environment, I setup all the components in windows, using eclipse to compile a WAR file and deploy it.
All is working fine except that log file is not created.
I changed the log file in log4j.properties from something like in below and and give everyone full access permission to the directory:
log4j.appender.F1.File=/abc/def/logs/admin.log
to
log4j.appender.F1.File=c:/logs/admin.log
What else can I check?
I create a simple standalone testapp which use the same log4j.properties and it can create the log file, but when the servlet deployed to websphere, it doesn't work. Please help! Thanks!
Ok, I think this article should help you. It seems that WebSphere CE uses log4j by default and controls it with a global properties file. There is a section on how to use application-specific properties files.
Here is what I try and do to troubleshoot similar issues.
Turn on log4j debugging to see where it actually picks up the file from. You need evidence of which file is picked up (so turning the debug on is a worthwhile activity) This provides you information with what log4j is trying to do to locate the configuration file.
-Dlog4j.debug=true
I would not hardcode the log4j location in the code. Instead I
would use the log4j.configuration System property and state that in
the JVM arguments. This way even I don't need to touch my code.
-Dlog4j.configuration=file:///home/manglu/log4j.properties
I would use this approach irrespective of the runtime server that I use (be it Tomcat or WAS CE or WAS)
Hope this helps
I suggest you use environment variables set on your server like this :
You must access the admin console of your server.
Under custom properties
Server_path=/abc/def/logs
In your log4j, use this : {$server_path}/log.txt
Make sure the user running the app has access to that directory.
I'm looking for a .NET coverage tool, and had been trying out PartCover, with mixed success.
I see that OpenCover is intended to replace PartCover, but I've so far been unable to link it with TypeMock Isolator so my mocked-out tests pass while gathering coverage info.
I tried replicating my setup for Partcover, but there's no defined profilename that works with the "link" argument for Isolator. Thinking that OpenCover was based on Partcover, I tried to tell Isolator to link with Partcover, and it didn't complain (I still had Partcover installed), but the linking didn't work - Isolator thought it wasn't present.
Am I missing a step? Is there a workaround? Or must I wait for an Isolator version that is friends with OpenCover?
Note: I work at Typemock
I poked around with the configuration a little bit and managed to get OpenCover to run nicely with Isolator. Here's what you can do to make them work together, until we add official support:
Register OpenCover profiler by running runsvr32 OpenCover.Profiler.dll (you will need an Administrator's access for this).
Locate the file typemockconfig.xml, it should be under your installation directory, typically C:\Program Files (x86)\Typemock\Isolator\6.0.
Edit the file, and add the following entry towards the end of the file, above </ProfilerList>:
<Profiler Name="OpenCover" Clsid="{1542C21D-80C3-45E6-A56C-A9C1E4BEB7B8}" DirectLaunch="false">
<EnvironmentList />
</Profiler>
Save the file, you will now have a new entry in the Typemock Configuration utility, called OpenCover. Press the Link button to link them. You will now be able to run your tests using OpenCover.Console.exe and Isolator. For example, here's how to run your tests with MSTest:
OpenCover.Console.exe
-target:"C:\Program Files (x86)\Microsoft Visual Studio 9.0\Common7\IDE\MSTest.exe"
-targetargs:"/testcontainer:"d:\code\myproject\mytests.dll"
-output:opencovertests.xml
There is still a minor issue running this with TMockRunner -link (that is, with late linking). I will need to look at it further at work.
Hope that helps.