lock is owned by another session Embedded WebLogic

UPDATE for new Release of JDeveloper:

the file now exists in:

C:\Documents and Settings\user\Application Data\JDeveloper\system11.1.1.1.33.54.07\DefaultDomain


remove the edit.lok from there.

---------------------------------------------------------------------------------

In JDeveloper 11.1.1.0.1, there is often some problem with Lock session:


weblogic.management.ManagementException: [Deployer:149164]The domain edit lock is owned by another session in exclusive mode - hence this deployment operation cannot proceed.

Simple solutions like restarting JDev, redeploying, clean , recompile and redeploy.. The problem persists.

Someone could easily suggest to remove system folder and restart JDev... But this will take time to reset your enviroment..

The session Lock is kept under Weblogic and in the following folder

C:\Oracle\Middleware\jdeveloper\system\system11.1.1.0.31.51.88\DefaultDomain

and is the file edit.lok.

rename it or remove it and start your application again. Weblogic will recreate the .lok file.

Starting OpenOffice 2.4 as a Service in Ubuntu

This yet another post of how to start OpenOffice as headless Service:
After you have installed your OpenOffice.

navigate to the executables directory. this is under:

usr/lib/openoffice/program

and type the following command:

soffice -headless -accept="socket,host=127.0.0.1,port=8100;urp;StarOffice.ServiceManager;" -nofirststartwizard

For More information regarding this topic refer to the following links

http://wiki.services.openoffice.org/wiki/Uno/FAQ

http://udk.openoffice.org/common/man/spec/uno-url.html

Adding different ActionListeners Programmatically

Here are some sample codes that anyone can use for adding different types of ActionListeners
to a RichCommandButton or RichCommandMenuItem or RichCommandToolbarButton Programmatically.

There might be cases that you need to add actions to some buttons programmatically; This means that you will need to search through the API to find out the appropriate java class of what you need. This Class saves you from this trouble and most of all saves you time!

I came across to this requirement and i think it might be very useful to others.

Also check Edwin Biemond's post for some handy code you might need.

Basically is a Utils Class called RichCommandComponentUtils.java and adds programmatically the following methods:

1. ActionListener
   
2. Action
3. ResetActionListener
4. FileDownLoadActionListener
5. ReturnListener
   

Each method has it's own MethodExpression method in order to be suitable for the component.
This can be very handy and useful in cases of Dynamically Generating Buttons as Andrej's post.
Of course it can be used where ever you think it is suitable

In a few words the process is this:

In order to have an ActionListener to , lets say a commandButton, porgrammatically we need to do the following steps:

1. Binding of the Button to a bean e.g. myActionListenerButton.
   
2. The ActionListener method which must have the following structure
   public void anActionListener(ActionEvent anActionEvent) { ... }
3. And the Usage of the RichCommandComponent class as follows:
   RichCommandComponentUtils.addActionListener( this.getMyActionListenerButton(),"#{main_Backing.anActionListener}");

And this is it.

Your button now has another ActionListener.
Here is a sample application that adds different types of listeners to some buttons.

In this sample application Listeners are added to the Buttons on Main and Second pages.
This happens on RenderResponce phase of each page.

NOTE: In the sample application I clear all actionListeners before adding some. This happens because actionListener are added which means that with this sample every time the page is rendered the Buttons will have plus one actionListener.


Feel free to update, fix, improve this Utils class. It is very usefull to me and other improved versions will come. Let me Know of what you think

regards!

Dependent LOV's in Query Criteria and View Accessor Workaround

Cascade LOVs is a very common request in many applications (refer to Andrejus Baranovskis's post for how to implement here )

Also the usage of Query Criteria component(af:Query) in pages is a very good practice when Complex search is needed.

There is always the ability to add more fields and set operators as desired in order to make your search fit to your needs.

There is a problem when trying to add second time the same LOV attribute that has bind variable(either in SQL or via ViewCriteria) in Query Criteria component(through Advanced feature). When trying to add the same LOV for second time the application crashes...

The Test Case:

In order to follow the test case we run this sample application

NOTE: to following test case is simple and does not reflect real conditions for real Design of cascade LOVs, it is an example.

Lets say that we want to make a search by EmployeeId =any value and have the following case about ManagerId.

ManagerId must be greater than 1 AND must NOT be equal to 2.

ManagerId produces LOV from ManagersView(a second Employees View Object) with View Criteria defined and a bind Variable.

This bind variable accepts value from EmployeeId in EmployeesView Object through View Accessor.This is a typical filtering process.

In order to follow our test case we run this sample application

1. Press Advanced in Query Criteria,
2. Press Add Fields,
3. Click on Manager Id field.
4. Press Again Add Fields,
5. Click on Manager Id field again.

The Problem:

After pressing second time the ManagerId the following error appears:

Table is gone! You might get a 500 error page as well.

Stack Trace:

Stack Trace indicates that the second time the field is added, the Attribute EmployeeId cannot be evaluated. The problem is reproduced only for LOV fields that use bind variables. Any other fields can be added without a problem...

No matter if it is a feature or a bug, the problem persists and to bring your application back to working state a restart on the server is required!!.

The Work Around:

The solution to this problem is simple. A single line of code actually! Here is where Groovy comes to play. After reading Steve Muench's Tips and Tricks, i applied a very simple script. As you saw while running the application; the first time the LOV is added, the EmployeeId is evaluated correctly. The second time though, is not. For some reason, userData cannot find the attribute (and yet the question remains: is it a feature or a bug???).

Simply add the following Groovy script in the View Accessors of the View Object.

And Everything will work fine.

It is a simple check if the Attribute exists in UserData; if not, set value to null..