i am writing an eclipse plugin that will connect to a server (no database!).
for each platform and each release of said server there will be a different jar to use for connecting and a different set of .dll/.so files used by said driver jar.
i'd like to create a mechanism like the one for jdbc drivers allowing the user to create a profile for a specific configuration of platform/release and select an existing profile to create a connection to a specific server.
thus, it is pretty much similar to what most databse plugins do where one can configure different jdbc drivers for different databases and use such a profile to create a databse connection.
maybe i haven't found the right search terms, but so far i failed to get an example how to write this kind of mechanism.
can someone please point me to a working example for eg jdbc?
to summarize:
- store location of jar
- store location of native shared libraries (dll/so)
- when connection export the location of the shared libs (at least in linux i currently need to export LD_LIBRARY_PATH) and use/load the configured jar
I cannot point you to a working example, but I would suggest to define an extension point in your core application. For each configuration create a "driver plug-in" which implements an extension to this extension point. In those driver plug-ins you could bundle the platform specific dlls and so on. Concerning platforms (operating system level) additionally consider to user fragments. For more details on how to implement your own extension point look Eclipse FAQ How do I declare my own extension point?
In the core application you can programatically query all extensions (driver plug-ins) which are available and for example let the user choose which configuration he would like to use via a dropdown box .
Related
I've created a SAP program and I want to deploy it in another SAP system.
I know I can import the Transport Request files with the created program to the new system but I'm looking for other options.
Is it possible to "install"/import my program to another SAP system?
Regards
I can only think you don't want to use the transport system because the systems are not part of the same landscape? If so, you can still use the transport system, you just need to manually move the required files around.
But, there is another approach you can follow - using SAPlink. It's an open source program that allows you download ABAP source, dictionary objects, etc. from one system into files and then upload them into another system. Of course, both systems will need to have SAPlink installed for this to work.
This is somewhat by design, SAP is the largest OTS system available and there has to be some controls to ensure that people can not install software if they are not specifically given the authorization to do so.
Even to use SAPlink ( that mjturner suggests ) requires you to have the ability to install that software first and I doubt you will find it in very many productive landscapes so likely that wont be an option.
Assuming you have a developer authorization you can always download the source code from your development SAP system and then upload from within the ABAP editor (SE38) using utilities -> More utilities->Upload/Download. Note that this doesn't work in the class editor so cut and paste is another option.
Later.......
There are three ways to move transports from one system to another.
1. Moving the transport files form the directories “data” and “cofiles” manually.
When the transport is released in the source system SAP automatically puts the transport files into the transport directory on file system. This files easily can be copied to the second system an be imported via transaction “STMS”.
2. Using CAR files
CAR files are packed files like a zip file. The contain the data and cofiles.
car.exe -cvf packedFile.car data\R900000.XXX cofiles\K900000.XXX
(car.exe is a SAP standard tool, XXX is the system ID)
This CAR files can be imported via transaction SAINT. This allows import files from frontend into the data and cofiles directory without direct access to the file system. After importing the file via SAINT the transport can be imported using STMS. This is be the common way to transport software to other systems outside the current landscape.
3. Using SAR and PAT files
These files are more special. They allow to install software as Add-On in SAP. This is required if the program should be certified by SAP. They have to be created using the AAK (SAP Add-On Assembly Kit). Unfortunately, I have not created this files myself yet. But it seems to be very complex to get this running, because there are some checks which have to be passed. The files can be imported via transaction SPAM (upload) and SAINT (import).
I need a little help from you.
I have to migrate several applications from WAS 7 to WAS 8.5 with a script in Jython using wsadmin. The thing is that on WAS 7 there are a lot of Datasources and i only need to import the Datasources that are used by the applications that i have to migrate.
Long story short: i have to get the datasource properties for a specific application.
Thanks for your help!
UPDATE: After this I have to install the applications using the exported properties of datasources.
If your application developers were smart enough to use resource references, you can find JNDI names of the Datasources used by the application in the web admin console Applications > applicationName > Resource References. If not, you will have to somehow learn what the datasources are (application documentation, developers, sources). There is no other way than references to know datasources used by given app.
Then I'd suggest you to use Property files wsadmin commands to extract relevant information from one environment and apply to the other. (Or just give you datasources configuration for use in jython scripts).
If don't want to use Property files commands you can use command assistance in the console to help you create jython files, or use some already provide Jython script library
For details see:
Using properties files to manage system configuration
Accessing command assistance from the administrative console
JDBC configuration scripts (library)
im running multiple servers on weblogic domain.
Is it possible to run different ojdbc drivers on servers?
adding classpath under server start configuration doesnt work, also deploying with application and deploying on server as a library doesnt overrride default.
Thanks for help
First, basic checklist...you do use NodeManager don't you (server start tab won't do anything if you don't). Also, you made sure the new driver name is configured in the JDBC datasource (I'm assuming the driver is for a datasource right?)
Deploying in the app shouldn't do anything since the datasource object is created prior to deployment.
You might want to take the old ojdbc6.jar, for JDK 6, and ojdbc5.jar, for JDK 5, out of the directories to make sure they're not seen anymore.
Also, where in the classpath did you put the new path ? When you add another path you should always put it in the beginning (after patches though)
Using Spring Integration file:outbound-channel-adapter, is there a way to specify what user account to use when writing the file. We need to write files from one domain to another. We would like to be able to write them just using file shares, but to do this, we need to be able to log in to the remote box with an account in the remote domain.
We can get around this with FTP, but would like to use file writing.
Thanks
I assume you are talking about windows domains/shares.
There are SMB adapters in the Spring Integration Extensions repository.
It includes a sample configuration file.
You can build it from github or there's a snapshot in the spring snapshot repo.
I cannot use the Resource File API from within a file system plugin due to a PlatSec issue:
*PlatSec* ERROR - Capability check failed - Can't load filesystemplugin.PXT because it links to bafl.dll which has the following capabilities missing: TCB
My understanding of the issue is that:
File system plugins are dlls which are executed within the context of the file system process. Therefore all file system plugins must have the TCB PlatSec privilege which in turn means they cannot link against a dll that is not in the TCB.
Is there a way around this (without resorting to a text file or an intermediate server)? I suspect not - but it would be good to get a definitive answer.
The Symbian file server has the following capabilities:
TCB ProtServ DiskAdmin AllFiles PowerMgmt CommDD
So any DLL being loaded into the file server process must have at least these capabilities. There is no way around this, short of writing a new proxy process as you allude to.
However, there is a more fundamental reason why you shouldn't be using bafl.dll from within a fileserver plugin: this DLL provides utility functions which interface to the file servers client API. Attempting to use it from within the filer server will not work; at best, it will lead to the file server deadlocking as it attempts to connect to itself.
I'd suggest rethinking that you're trying to do, and investigating an internal file-server API to achieve it instead.
Using RFs/RFile/RDir APIs from within a file server plugin is not safe and can potentially lead to deadlock if you're not very careful.
Symbian 9.5 will introduce new APIs (RFilePlugin, RFsPlugin and RDirPlugin) which should be used instead.
Theres a proper mechanism for communicating with plugins, RPlugin.
Do not use RFile. I'm not even sure that it would work as the path is checked in Initialise of RFile functions which is called before the plugin stack.
Tell us what kind of data you are storing in the resource file.
Things that usually go into resource files have no place in a file server plugin, even that means hardcoding a few values.
Technically, you can send data to a file server plugin using RFile.Write() but that's not a great solution (intercept RFile.Open("invalid file name that only your plugin understands") in the plugin).
EDIT: Someone indicated that using an invalid file name will not let you send data to the plugin. hey, I didn't like that solution either. for the sake of completness, I should clarify. make up a filename that looks OK enough to go through to your plugin. like using a drive letter that doesn't have a real drive attached to it (but will still be considered correct by filename-parsing code).
Writing code to parse the resource file binary in the plugin, while theoratically possible, isn't a great solution either.