Community
Participate
Working Groups
In order to edit a driver definition's jarList and/or properties, one must either use its Editing UI page or directly edit an exported profile file (provided it is not encrypted). In some use cases, an exported (encrypted) profile file needs to be deployed on multiple servers, which may have a different installation path for the JDBC driver. Furthermore, for load balancing purpose, one might want to adjust the URL to point to a mirrored database server. A system administrator would normally copy the same exported profile file to each of the deployment servers; and would then need to adjust the appropriate jarlist and properties. It would be very useful if a system administrator type user can externally configure a driver definition's jarList and/or properties. Such configuration info can perhaps be a properties file that would, if exists, override the values defined for a profile instance in an exported file.
This is a "must have" for BIRT. If it is not in Connectivity, they will need to implement something similar directly in BIRT to handle this case. When talking to Linda, we were thinking that this should be available as a single file (that could contain multiple driver definitions) and the file could be loaded by a call through the DriverManager or other utility method to load drivers. Perhaps feed a file path to the configuration file to the utility method. Definitely not user-accessed functionality, API only. Linda has offered to help code if we can come up with a design.
Ok... Been doing some thinking about this one... If we're going to do it right, we need to think of it from an adopter perspective. 1) I'm thinking we add a new extension point to register a "driver provider". This class would have a single method -- loadPropertySets(), which would return a list of IPropertySet objects. 2) We then provide a default implementation of this class that uses the underlying XMLFileManager (same that the DriverManager uses) to grab the property sets (i.e. driver instances) from a file somewhere in the file system. Extenders could then use this default implementation, simply extending it to provide the location where they want to get the file from. 3) Then in the DriverManager, when we load the saved driver instances, we poll for the list of these driver providers and merge in the property sets needed. What this doesn't account for is... What if one of the driver providers returns one or more driver instances that are defined elsewhere in the saved drivers? This kind of conflict bugs me. I tend to feel in this case it's the adopter who needs to account for this and the first driver instance loaded with a particular ID wins. To make sure that the ones coming from the "driver providers" win, we process those first, then the ones from the workspace-relative file. This seems more organic to me than trying to shoehorn a file into a known location in the file system. Let the implementer determine how to find that file and we just load it and process it accordingly. What do you think? --Fitz
The "file" needed by the XMLFileManager is specified in two parts -- the storage location (IPath) and the filename (string). We could wrap that up to simplify it for the default case, but by providing the IPath I think you have some flexibility. Hopefully enough flexibility to do what you're thinking in BIRT. This way you could have a set of driver provider XML files defined in the same format as we define the driver storage file now (pretty simple format) in a common BIRT-related location and then pick them up one at a time or process multiple drivers from a single file, whatever you need.
Discussed this at today's Connectivity team meeting. We are now thinking this would be best served by some simple command-line utility that would allow a sysadmin to take an exported file of profiles and process it property by property to allow them to change individual property values where required, then write out a "processed" export file that could be imported on the server side. Larry is looking into the command line utility part. I'm looking into the import/export code. And Linda will look into merging the two into a coherent whole.
Created attachment 96267 [details] Sample plug-in that provides the ability to update url & jar list Hi guys... I mocked up this plug-in. It adds a "Sample->IE Admin Tool" menu to connection profiles in the DSE. You provide an input file (a profile export file) and an output file (the new profile export file). Hit Update and it loads the profiles and prompts the user if they want to update the url or jar list for each profile in the file. At this point, I just inject a dummy value, but it would be trivial to prompt the user for such information. But this should provide enough detail hopefully to do what we were discussing on Monday at the connectivity meeting. Let me know if you have any questions. The code is pretty self explanatory. Just look at the "update" method on the AdminDialog class and it handles the grunt work. Code was lifted from the import & export actions/dialogs. --Fitz
Pushing this off to RC1 as a possible side-project not in the main codeline
Created attachment 97892 [details] Example of how to do a cmd line eclipse app Hi Linda & Larry... This is what I've hit upon... You can export this guy, stick it in your eclipse/plugins directory, then run this at a command line from within your eclipse directory: c:>eclipsec -nosplash -application org.eclipse.datatools.connectivity.sample.admin.cmd.id1 I have it to the point where it knows if it's being passed incoming arguments and it can prompt for input. Linda, here's your solution -- just merge the first example I attached with this one. You should be able to prompt for each profile's various bits and pieces and go from there. Hope this helps! --Fitz
Note that the ID* attribute of the application extension is key. For example, if you call it "george" as the ID, it's prefaced in the runtime by the ID of the plug-in, so the whole application ID in this case would be "my.plugin.id.george" and that's what you pass as the -application argument when calling your app
Linda, I'm throwing this back into your queue. I've given you the two halves of the equation and you just need to figure out how you want to merge them. If you need additional help, please let me know. Thanks.
Created attachment 99815 [details] Extracted method to check for encrypted file As the admin tool would need to know whether an input file is encrypted, it would be nice to re-factor that code in ConnectionProfileMgmt for re-use. The attached patch extracted that code to a public method.
Delivered a new console editor application for users to view and update the contents of an exported file containing DTP connection profiles. When a DTP exported file is copied to a server platform for deployment, an user can use this editor tool to quickly adjust the connection profile properties without having to bring up the DTP Data Source Explorer UI workbench. Instructions on how to use the tool is attached and included in the plugin.
Created attachment 100358 [details] Info on how to use the console editor.
Closing bugs
