Der Oracle Fusion Middleware Stack beinhaltet eine leistungsstarke und vollkommen integrierte Enterprise Scheduler Lösung, Oracle Enterprise Scheduler (ESS). Es ist ein bekanntes 11g Produkt der Oracle Fusion Applications und ermöglicht, auf einfache Weise, die Definition einer Vielzahl an unterschiedlichen Job Typen (Java, PL/SQL, Webservices, uvm.) und deren Einplanung zu vorher bestimmten Zeiten. Seit Version 12c ist das Produkt auch in der Oracle SOA Suite verfügbar.
Ein primärer Fokus von Version 12c der Oracle SOA Suite war die Steigerung der Entwicklungsproduktivität. Zwei prominente Neuerungen sind die Einführung von diversen SOA Templates sowie die Unterstützung von Maven als Build-Tool. Die nun existierenden SOA Templates können in vielen Ebenen der SOA Suite Entwicklung genutzt werden. Sie unterstützen die Entwicklung sinnvoll, haben teilweise jedoch Limitierungen hinsichtlich ihrer Flexibilität.t An dieser Stelle wird die Möglichkeit Maven als alternatives Build-Tool in der SCA Entwicklung zu nutzen interessant.
From Linux distributions I was used to have a context menu entry within file browsers which opened a terminal at the current folder. In standard configuration Mac OS X’s Finder does not provide this functionality. However, the service exists and it just has to be activated.
In order to activate this service open the following screen in System Preferences:
System Preferences > Keyboard > Shortcuts > Services
Two options can be activated:
- New Terminal at Folder
- New Terminal Tab at Folder
Afterwards the service is available within folder context menus.
Recently, I had a strange behaviour with my Eclipse installation. I think the error occurred after I had to kill Eclipse due to some issue during a build. Afterwards Eclipse was unable to restore the workspace.
If you run into the same issue try these three things:
- Try to delete the following folder:
- If error still persists and using Eclipse 4 delete following file aswell:
- Create a new workspace and import projects. If you did set the broken workspace as default open the following file:
In this file search for preference SHOW_WORKSPACE_SELECTION_DIALOG and set it to true.
Automatic email forwarding for certain emails can be quite handy. Here is a quick guide how you create forwarding filters in Google Mail.
To start off with we need to add a new forwarding email address and verify that we are allowed to forward emails to this address. In order to do this open up Google Mail settings and click the Forwarding and POP/IMAP tab.
Within the upcoming tab click on the Add forwarding address button and enter an email address in the new dialogue.
As soon as the new forwarding email address is added the owner should get an email containing a verification code. With this code one can verify that one is allowed to forward emails to this address. The code can be entered within the Forwarding and POP/IMAP tab.
After verification emails can be forwarded to this address. Google Mail provides two options for forwarding emails. First option is to forward all emails to a certain address. The second option is to define filters which identify certain emails and forward these to a specific email address. The later option is of interest for us.
In order to create a new filter navigate to the settings Filters tab. Here one can see existing and create new filters.
Creating a filter is very simple. First of all one has to define the filter criteria, which can also be done by simply typing search terms into Google Mail’s email search field.
Secondly, one has to define which actions should be applied to emails matching the defined filter criteria. In order to forward emails one has to check the Forward it to action and select the desired destination email address.
After creating the filter all actions, including Forward it to, should be applied to emails matching the filter criteria.
As I prefer Git as version control system I often end up working with it as client for Subversion (SVN) repositories. Recently, I had to interact with a SVN repository which was moved to another location after my initial cloning.
As Git stores the SVN URL and includes it into the SHA-1 hash calculation you can end up having the following problem as soon as you change the repository URL and try to push your changes to the remote repository:
Unable to determine upstream SVN information from HEAD history. Perhaps the repository is empty. at /usr/libexec/git-core/git-svn line 519.
The problem is that by changing the SVN repository URL calculated SHA-1 hashes differ and Git cannot determine the proper commit to push to. In order to overcome these problems you can add the rewriteRoot option to your configuration file and afterwards change the URL:
git config --replace-all svn-remote.svn.rewriteRoot http://old.repository.com/url git config --replace-all svn-remote.svn.url http://new.repository.com/url
Next time you try to push your changes they will be pushed to the new repository destination (newURL) but Git pretends it to be the old repository destination (oldURL).
Recently I wanted to migrate an existing Subversion (SVN) repository trunk to a new Git repository. Here is a short description how you can do it in four simple steps.
First of all, create a new bare repository:
$ mkdir NewGitRepo $ cd NewGitRepo/ $ git init --bare
Secondly, checkout the old SVN repository using Git and enter the repository folder. For this post I created a sample SVN repository on my local hard drive:
$ git svn clone file:///some/file/path/OldSVNRepo/trunk ./OldSVNRepoGit $ cd OldSVNRepoGit
Thirdly, add your new Git repository as additional remote branch to the checked out SVN repository:
$ git remote add origin /some/file/path/NewGitRepo/
Finally, push SVN contents to new Git bare repository:
$ git push -u origin master Counting objects: 12, done. Delta compression using up to 2 threads. Compressing objects: 100% (5/5), done. Writing objects: 100% (12/12), 1016 bytes, done. Total 12 (delta 3), reused 0 (delta 0) Unpacking objects: 100% (12/12), done. To /some/file/path/NewGitRepo/ * [new branch] master -> master Branch master set up to track remote branch master from origin.
As stated in the heading, this is just a simple way. Additional information regarding this topic can be found in the Pro Git book by Scott Chacon:
Recently I had some problems staying under my monthly mobile bandwidth cap. One reason being an increased travel and tethering time. Although working on an up to date system is preferable most of the time, I started to turn off automatic updates on my Mac while working using my mobile connection.
The automatic update settings can be found under System Preferences -> App Store.
When traveling you can uncheck all but the “Automatically check for updates” check box. That way you get notified if new updates are available and can set yourself a reminder to update your system when a landline connection is available.
When working on SOA projects I am used to create some developer test suites for myself in order to do some initial web service QA. For this purpose SoapUI is a commonly used functional testing tool. Depending on the project these “small” test suites can actually become quite big. That is fine as long only one service endpoint has to be tested, however most likely you end up with several endpoints for different development stages (development, integration, production). Gladly SoapUI provides a functionality to set web service endpoints for all service request. Only problem is to find this functionality 😉
To demonstrate the functionality I took a standard global weather service and created a small SoapUI project.
Within the project I created some requests and test suites for both operations. Furthermore, I added some additional endpoints to the GlobalWeatherSoap Interface. You can access this view by double clicking the respective web service interface.
In order to set the endpoint required for the next test run, you have to select it from the list and click the Assign button in the top menu. As result an additional dialogue opens which provides several options.
In this example we want to set the new endpoint for all requests and test requests, therefore this option has to be selected. Afterwards all requests point to the new endpoint and the test suite can be executed.
Just required some Oracle Metadata Repository (MDS) partitions for some testing. If you ever get to the same situation just use MDS_INTERNAL_COMMON.getOrCreatePartitionID procedure which is shipped with the MDS Schema when installing it using the Repository Creation Utility (rcu):
DECLARE lv_partitionID MDS_PATHS.PATH_PARTITION_ID%TYPE; lv_partitionExists integer; BEGIN mds_internal_common.getorcreatepartitionid( lv_partitionID, lv_partitionExists, 'foo' ); mds_internal_common.getorcreatepartitionid( lv_partitionID, lv_partitionExists, 'bar' ); END; /
After the anonymous block is completed you can check out your brand new partitions: