I am building application in javafx using Derby embedded DB. Do I need to create two separate builds in order to run it as client server ?
The primary differences are:
different syntax for the JDBC Connection URL, and
different Derby jars in the CLASSPATH.
It is possible to include both sets of Derby jars in the CLASSPATH, meaning that the only thing your application must vary at runtime in the JDBC Connection URL.
derbyclient.jar is significantly smaller than derby.jar, however, so if executable package size is crucial to you, you might find it worth the effort to have two different modes of packaging.
Related
I have a big Monolithic Oracle DB. I may end up creating around 20 System APIs to get Various data from this DB. So instead of configuring DB connection in all 20 system APIs, like to create a DB connector and make it as a jar file. So that every system APIs can add this in their POM and use that for connection.
Is that something possible or is there any better approach to handle it?
One method if all applications are in the same server is to create a domain and share the configuration by placing it in the domain. This is usually the recommended approach. This method is documented at https://docs.mulesoft.com/mule-runtime/4.3/shared-resources
If that's not possible (for example CloudHub doesn't support domains) or desired, then you have to package the flow in a jar by following the instructions in this KB article: https://help.mulesoft.com/s/article/How-to-add-a-call-to-an-external-flow-in-Mule-4. Note that while the article title mentions flows, the method works with both configurations and flows.
I am starting to play around with MVC 6 and I am wondering, with the new config.json structure... are my connection strings safe in the config.json file?
Also, I was watching a tutorial video and I saw the person only put their connection strings in their config.dev.json file, not just the config.json. This will mean the application will not have the connection strings while on the production side, correct? He must have meant to put them in both.
Thanks a lot for the help!
I think the Working with Multiple Environments document sums it up pretty well.
Basically, you can farm secret settings such as connection strings out into different files. These files would then be ignored by your source control system and every developer will have to manually create the file on their system (it might help to add some documentation on how to setup a project from a fresh clone of SCC).
For production, the compile will include the production settings. Typically, these are provided by a build server where they are locked away from developers. I'm not sure if that is totally automatic with MVC core or you have to add some kind of build step to do it, but that is how it is normally done.
If you are worried about storing connection strings in the production environment securely, you can extend the framework with your own configuration provider.
We have an application written in Mono that needs to communicate with an Finder Sync App extension.
All is working fine until we tried our app on El Capitan instead of on Yosemite.
We use a shared SQLite database to tell what paths are in which state and use NSDistributedNotificationCenter for communication between the two.
The shared SQLite database is outside of the sandboxed env so we have putted an excepention in our entitlements com.apple.security.temporary-exception.files.home-relative-path.read-write
If we remove this exception from the app extension, the extension works (but obviously we can't read our db)
Then we tought of putting the SQLite DB into memory, but shared memory databases isn't possible over multiple processes.
I can't find how I can create a NSFileHandle for a Sqlite Connection.
We could send over all the info to the application extension, but then that has to keep it in memory (preferably in a SQLite, cause we need to do some querying.)
Does anyone has some pointers of what we could do?
Try to look in The Application Group Container Directory it might do in your case. Basically it allows you to have shared folder between apps/extension.
App group container directories. A sandboxed app can specify an entitlement that gives it access to one or more app group container directories, each of which is shared among all apps with that entitlement.
After some research on similar problem I found it's much easier to have simple TCP server in main app that responds to extension with file status. This way you can easily broadcast file status change to all extension instances etc.
When configuring a data source on WebLogic 11g does anyone know if it's possible for the class specified as the connection pool driver to be deployed as a shared library rather than being installed in wlserver_10.3/server/lib?
The reason for wishing to do this is that we thought it might be more manageable to be able to deploy the driver in a complex production environment.
I've run some tests by deploying the jar file containing the driver with various deployment order values but always get "cannot load driver class" on server startup.
Thanks.
You can use the shared libraries from virtually anywhere keeping this major rule in mind, Weblogic must have permissions to read it.
If that criteria is met, please reference your jar in commEnv.sh "WEBLOGIC_CLASSPATH" and restart the server and you should be good to go. This is handy for shared mounts with common libraries but always always always make sure you can read the file.
During our development of schemas orchestrations, ports, etc. We've been exporting MSI's and binding files for deployment into our test and ultimately production environment
So, for example, we set up a series of receive ports/locations in a single BizTalk app, for the purpose of receiving all HL7 v2 messages from our HCIS. We then exported that to a bindings file, and imported into test.
Then, as we developed new schemas, we exported each schema into it's own msi file and deployed that into the same BizTalk application in our test environment. We did that because the schemas are specific to the inbound messages from our HCIS.
So now, in test, we've ended up with a BizTalk application with the receive ports and schemas we need to receive messages from our HCIS. The issue I discovered is that, if I look at the installed programs list in the control panel, I only see 1 application. So if I want to uninstall and re-install a particular schema, I'm not sure what will happen. For some reason, I half expected to see an entry for every msi I installed, but I suppose that because they're all going into the same BizTalk application, they are all registered in windows as the same application. I'm betting there is a better way to do this, any suggestions?
You can, and probably should, create different applications for each logical grouping of code. If you examine the 'deploy' section of the project properties you'll see a text box to enter your application name. When you trigger a deploy they will be placed into a separate application with the name you provide. You'll see it in the BizTalk management console.
We deploy to dev using the framework mentioned below. Then to deploy to QA right click on the application and create an MSI from that point. It will allow creating an MSI for only one application.
NOTE: the deploy setting is NOT saved globally. If another developer opens the project his project will not inherit the application name you've set.
We use the biztalk deployment framework to help manage changes when we do development.
So now, in test, we've ended up with a BizTalk application with the receive ports and schemas we need to receive messages from our HCIS. The issue I discovered is that, if I look at the installed programs list in the control panel, I only see 1 application.
I can only think of two scenarios where you might observe this behaviour:
You have multiple different MSI's (once for each schema) which you are importing into BizTalk (and hence they are appearing in the BizTalk Admin Console), but you are not running the MSI on the local machine (and so it is not appearing in 'Installed Programs'); or
You MSI's are all named the same, in which case after the import into BizTalk and the local install, you only have a single program visible in 'Installed Programs'.
I'm betting there is a better way to do this, any suggestions?
With regards to approach, you are certainly along the correct lines. I tend to advise clients to group logical artifacts into a single logical bucket - either project or Application - that can be deployed (and redeployed) without affecting other parts of the system.
In a HL7 scenario, one logical bucket might be Patient artifacts (schemas and supporting maps) and a second may be Financial artifacts (schemas and supporting maps). These logical buckets can either be deployed to different BizTalk Applications, or the same BizTalk Application depending on your requirements. However, the main benefit here is that they are separate and therefore all artifacts do not need to be redeployed if you need to make a small modification to A19 - Patient Query/Response schema for example.
How to deploy is another question entirely. I'm a massive fan of MSBuild and have written comprehensive build scripts that I tweak and reuse for each project I work on. These deployment scripts will tear down an existing environment and re-build from the ground-up, creaing Applications, deploying Resources, importing Bindings, creating Hosts and Host Instances etc. before finally starting the application. This approach removes all human error from the process and tends to be favoured by clients who often have their infrastructure teams perform the deployment rather than their development teams.
I notice that Jay mentioned the use of the BizTalk Deployment Framework. I personally struggle with this tool, partly because I need to maintain my configuration in Excel which I can't check in to source control easily.