Different behaviour of Jcomponet's setEnable() method is required

Hi all,
I want JcheckBoxes and JradioButtons in following way
1) which are not allowed to select or de-select
2) with labels in black colour
i used jComponent's setEnabled(false) method which only satisfy the first rule i have mensioned above. Labels are shown in grey colour.
Is there any other way to do this rather than extending jcheckBox and jRadioButton and override above method?
Thanks and regards!!!

It is the responsibility of the UI object to render the component, so ideally you should replace that with one you have overridden (see BasicButtonUI.painttext(), which is the method that paints greyed out text when disabled).
Are you sure that's what you want, though? If I saw a checkbox with black text I'd expect it to work and would get a bit annoyed if it didn't.

Similar Messages

Different behaviour of j_security_check between 6.1 and 8.1

Hi,
we have a web-application that is secured via security-constraints in
the web.xml. We are authenticating using FORM-based authentification and
had this app deployed on a wls6.1. Now we have moved to 8.1 and have a
different behaviour between 6.1 and 8.1 for log-in forms using the
j_security_check. We have login-boxes on most pages:
<form method="POST" action="j_security_check">
Username<br><input type="text" name="j_username" size=11
class="texteingabe"><br>
Password<br><input type="password" name="j_password" size=8
class="texteingabe"> <input type=image
src="/dvrWebApp/htdocs/images/pfeil_rechts_hi.gif" border=0><br>
</form>
that on 6.1 redirected after the login to the page they were placed on -
on 8.1 the login redirects to the root of the web-app, regardless of the
page they are placed- can i change this back to the old 6.1-Behaviour?!
cheers
stf

This sounds like bollocks, I was doing some form based security recently under 8.1 and there was no attempt to direct to any page i was not trying to access.
The idea is you try to access a protected resource, your not authorized, so you are authenticated, then you continue on to that resource.
Are you sure, that the resource your accessing does not direct you there because of some inbuilt business logic in your JSP/servlet ?

SQL Server Management Studio and Native Client different behaviour on delete

I have a problem with transaction containing insert and delete to same table and some select/insert/update to some other tables. Problematic table has primary key defined as combination of column1 and column2.
When two different instances using Native Client execute simultaneously this code and make inserts to table then delete part of code causes deadlock. However this doesn't happen when trying this situation in MS SQL Server Management Studio query.
Is there some option that is missing from Native Client connection string which can cause this different behaviour?

Hello,
I don't think there is a difference in the behavior. SSMS uses ADO.NET and that Provider base on the Native Client.
The difference will be more that way, when the transaction is commited and so the locks released. I guess your application keeps the transaction (much) longer open; you should commit a transaction as soon as possible to avoid long time locks and so
deadlocks.
Olaf Helper
[ Blog] [ Xing] [ MVP]

In-different behaviour of join condition

My query is of in-different behaviour of join condition with join between a varchar2 column and a number column. I am using the following join condition :-
CM.UPDATED_BY=to_char(LM.LOGIN_ID)
where CM.UPDATED_BY is a varchar2 column and LM.LOGIN_ID is a number column. Now, CM.UPDATED_BY also has number only but some previous & old data is having varchar2 data. So, for that reason, i put the to_char before LM.LOGIN_ID, otherwise, only
CM.UPDATED_BY=to_char(LM.LOGIN_ID)
would having been okay. Now, my real question is that the query with the condition,
CM.UPDATED_BY=to_char(LM.LOGIN_ID)
works fine as long as there is no 'character' data in 'CM.UPDATED_BY'. If i put the condition:
CM.UPDATED_BY=to_char(LM.LOGIN_ID)
then, the query is taking too long and the output is also not coming. Please help in solving my doubt as i need it resolved urgently.

1) Did you intend for all 4 join conditions to be identical? From the text of your question, it sounds like some of the conditions should be different.
2) How do you compare the running time when CM.UPDATED_BY has non-numerica data and when it has numeric data? If you are altering the data in the table, are you reanalyzing the table between runs? Is there a difference in the query plan in the two cases?
Justin
Distributed Database Consulting, Inc.
www.ddbcinc.com/askDDBC

Different behaviour of XMLType storage

hi,
I have problem with different behaviour of storage type "BINARY XML" and regular storage ( simple CLOB I guess) of the XMLType datatype.
Setup
- Oracle Database 11g Enterprise Edition Release 11.1.0.6.0 - 64bit Production
- XML file ( "Receipt.xml" ) with a structure like :
<?xml version="1.0" encoding="UTF-8"?>
<ESBReceiptMessage xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
     <ESBMessageHeader>
          <MsgSeqNumber>4713</MsgSeqNumber>
          <MessageType>Receipt</MessageType>
          <MessageVersion>1.1</MessageVersion>
     </ESBMessageHeader>
     <Receipt>
          <ReceiptKey>1234567-03</ReceiptKey>
          <ReceiptLines>
               <ReceiptLine><Material><MaterialKey>00011-015-000</MaterialKey></Material><Qty>47.0</Qty></ReceiptLine>
               <ReceiptLine><Material><MaterialKey>00021-015-000</MaterialKey></Material><Qty>47.0</Qty></ReceiptLine>
               <ReceiptLine><Material><MaterialKey>00031-015-000</MaterialKey></Material><Qty>47.0</Qty></ReceiptLine>
.....etc....etc.....etc...
               <ReceiptLine><Material><MaterialKey>09991-015-000</MaterialKey></Material><Qty>47.0</Qty></ReceiptLine>
               <ReceiptLine><Material><MaterialKey>10001-015-000</MaterialKey></Material><Qty>47.0</Qty></ReceiptLine>
               <ReceiptLine><Material><MaterialKey>10011-015-000</MaterialKey></Material><Qty>47.0</Qty></ReceiptLine>
          </ReceiptLines>
     </Receipt>
</ESBReceiptMessage>=> 1 Header element : "Receipt" and exactly 1001 "ReceiptLine" elements.
Problem:
Test 1 :
drop table xml_ddb;
CREATE TABLE xml_ddb (id number,xml_doc XMLType);
INSERT INTO xml_ddb (id, xml_doc) VALUES (4716,XMLType(bfilename('XMLDIR', 'Receipt.xml'),nls_charset_id('AL32UTF8')));
select count(1) from (
SELECT dd.id,ta.Receiptkey,li.materialkey,li.qty
   FROM xml_ddb dd,
        XMLTable('/ESBReceiptMessage/Receipt' PASSING dd.xml_doc
                 COLUMNS ReceiptKey VARCHAR2(28) PATH 'ReceiptKey',
                         ReceiptLine XMLType PATH 'ReceiptLines/ReceiptLine') ta,
        XMLTable('ReceiptLine' PASSING ta.ReceiptLine
                 COLUMNS materialkey VARCHAR2(14) PATH 'Material/MaterialKey',
                         qty         NUMBER(10)    PATH 'Qty') li
COUNT(1)
      1001
1 row selected.The storage of the XMLType column has not been specified.
=> All 1001 detailled rows are selected.
=> Everything is fine
Test 2 :
drop table xml_ddb;
CREATE TABLE xml_ddb (id number,xml_doc XMLType) XMLType xml_doc store AS BINARY XML; -- <---- Different storage type
INSERT INTO xml_ddb (id, xml_doc) VALUES (4716,XMLType(bfilename('XMLDIR', 'Receipt.xml'),nls_charset_id('AL32UTF8')));
select count(1) from (
SELECT dd.id,ta.Receiptkey,li.materialkey,li.qty
   FROM xml_ddb dd,
        XMLTable('/ESBReceiptMessage/Receipt' PASSING dd.xml_doc
                 COLUMNS ReceiptKey VARCHAR2(28) PATH 'ReceiptKey',
                         ReceiptLine XMLType PATH 'ReceiptLines/ReceiptLine') ta,
        XMLTable('ReceiptLine' PASSING ta.ReceiptLine
                 COLUMNS materialkey VARCHAR2(14) PATH 'Material/MaterialKey',
                         qty         NUMBER(10)    PATH 'Qty') li
COUNT(1)
      1000
1 row selected.Storage of the XMLType column has been defined as "BINARY XML"
=> Only 1000 rows are select
=> One row is missing.
After some tests : There seems to be a "hard border" of 1000 rows that comes with the different datatype ( So if you put 2000 rows into the XML you will get also only 1000 rows back )
Question
As I am a newbie in XMLDB :
- Is the "construction" with the nested tables in the select-statement maybe not recommended/"allowed" ?
- Are there different ways to get back "Head" + "Line" elements in a relational structure ( even if there are more than 1000 lines) ?
Thanks in advance
Bye
Stefan

hi,
General
You are right. I have a predefined XSD structure. And now I try to find a way to handle this in Oracle ( up to now, we are doing XML handling in Java ( with JAXB ) outside the DB)
=> So I will take a look at the "object-relational" storage. Thank's for that hint.
Current thread
The question, whether there is an "artifical" border of 1000 rows, when joining 2 XML tables together, is still open....
(although it might be not interesting for me anymore :-), maybe somebody else will need the answer...)
Bye
Stefan

Different behaviour between 1.4,1.5_05, 1.5_07.

Hi and thanks in advance for your help,
Looking for pointers to a solution for a problem I have.
A set of Java classes subscribe to a subscription service and listen for updates on a network. To do this the JVM uses JNI (actually a JIntegra vendor product) to talk to the Windows DLL files on the server, it�s these files that actually listen for the updates. The information is then passed back up to the JVM (via the JIntegra libraries). The strange behaviour i get is as follows:
1.     No problems with JDK 1.4.*
2.     JDK1.5_05: The program runs fine for a few minutes and then crashes out BUT with no stack trace or errors at all (it just terminates).
3.     JDK 1.5_07: The program runs ok to start with but then consumes all the file handles on the Windows server. After approx 4hrs the program hangs as it has consumed all the servers spare file handles (in fact 3,800,000 of them).
The added problem of debugging this, is that we use a vendor for the Java/COM+ interaction and we don�t have the source code, But I have tried different versions of the JIntergra without any change in the behaviour (so i don't think its that). It appears to be the JVM version that causes the change in behaviour.
I do not understand why I get such different behaviour from the different versions of Java? Although both JDK1.5 don't work.
I was wondering if someone can point me in the right direction for trying to get JVM information outputted when the JDK1.5_05 crashes out.
How can I put a hook in the JVM in my code to output information when it exits. I realise its doing it unexpectedly so this type of solution might not work but I find it strange that no error is thrown.
Also; Does anyone know of any bugs that might possibly explain any this behaviour?
Any ideas anyone.

Jintegra recommend using 1.5. I will check the JNI bugs database to see if anything like this has happened before:
Got this one stacktrace recently:
# An unexpected error has been detected by HotSpot Virtual Machine:
# Internal Error (4D555445583F57494E13120E4350500080), pid=1944, tid=1500
# Java VM: Java HotSpot(TM) Client VM (1.5.0_07-b03 mixed mode, sharing)
# Can not save log file, dump to screen..
# An unexpected error has been detected by HotSpot Virtual Machine:
# Internal Error (4D555445583F57494E13120E4350500080), pid=1944, tid=1500
# Java VM: Java HotSpot(TM) Client VM (1.5.0_07-b03 mixed mode, sharing)
--------------- T H R E A D ---------------
Current thread is native thread
Stack: [0x045e0000,0x04620000), sp=0x0461fb08, free space=254k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
V [jvm.dll+0x11f2eb]
V [jvm.dll+0x62f13]
V [jvm.dll+0xd1741]
V [jvm.dll+0xd18f0]
V [jvm.dll+0x90d16]
--------------- P R O C E S S ---------------
Java Threads: ( => current thread )
0x03029730 JavaThread "J-Integra COM initialization thread (please don't touch)" daemon [_thread_blocked, id=1684]
0x00237c28 JavaThread "DestroyJavaVM" [_thread_blocked, id=3112]
0x009fc7c8 JavaThread "Thread-0" [_thread_blocked, id=2996]
0x009a16a8 JavaThread "Low Memory Detector" daemon [_thread_blocked, id=2860]
0x00238478 JavaThread "CompilerThread0" daemon [_thread_blocked, id=1464]
0x0099f730 JavaThread "Signal Dispatcher" daemon [_thread_blocked, id=3168]
0x009998e0 JavaThread "Finalizer" daemon [_thread_blocked, id=2928]
0x0023fae0 JavaThread "Reference Handler" daemon [_thread_blocked, id=2268]
Other Threads:
0x009982d8 VMThread [id=2036]
0x009a2ce8 WatcherThread [id=532]
VM state:not at safepoint (normal execution)
VM Mutex/Monitor currently owned by a thread: None
Heap
def new generation total 576K, used 244K [0x22ab0000, 0x22b50000, 0x22f90000)
eden space 512K, 47% used [0x22ab0000, 0x22aec330, 0x22b30000)
from space 64K, 6% used [0x22b40000, 0x22b410a8, 0x22b50000)
to space 64K, 0% used [0x22b30000, 0x22b30000, 0x22b40000)
tenured generation total 1408K, used 917K [0x22f90000, 0x230f0000, 0x26ab0000)
the space 1408K, 65% used [0x22f90000, 0x23075430, 0x23075600, 0x230f0000)
compacting perm gen total 8192K, used 1354K [0x26ab0000, 0x272b0000, 0x2aab0000)
the space 8192K, 16% used [0x26ab0000, 0x26c02a20, 0x26c02c00, 0x272b0000)
ro space 8192K, 67% used [0x2aab0000, 0x2b00d9f8, 0x2b00da00, 0x2b2b0000)
rw space 12288K, 46% used [0x2b2b0000, 0x2b853808, 0x2b853a00, 0x2beb0000)
Not sure what 'Internal Error (4D555445583F57494E13120E4350500080)' represents.
Thanks for your advice.

Different behaviour of Flash content when on server

Hi
I have noticed different behaviours of my Flash movie in case
a/ I am checking offline content (SWF) using the fault view (Show All)
b/ I am checking the SWF in a HTML file on a server.
More concrete: Depending on a number of conditions I attach a movieclip to a certain object. This works fine in offline mode.
Another example: Depending on a certain zoom level of the application, I unload some SWF.
All works fine offline.
When I check this online, the attach movieclip function only works in some cases, the unload of SWF does not work .
What can be the cause ?
bestregards
eG

Not sure about most of your questions -- this is all new stuff for me, too. But on this one item, I hope this helps:
For example it tells me that a plugin (which has already been installed) needs to be installed.If you installed the Mozilla browser after initially installing the java plugin in IE, then the plugin needs to be installed within the Mozilla browser's plugins directory. And I have never been able to get Netscape or Firefox to install a Forms plugin properly. It seems like I need to run IE to get the plugin installed automatically. Then I go back to the other browser and all is ok. Looking into the Mozilla-based browser's plugins folders, I can see that running the plugin install through IE also copies the corresponding .dll file into all the Mozilla-based browsers' plugins folders.
But since you have already installed the plugin in IE, I am not sure how you would get it to work for the other browser. But if you can identify the .dll required, just copy it yourself into your Mozilla browser's folder.

Different behaviour inside a Thread

Hello ,
I am developing a software to help in automating certain tasks related to certain voice switch , i connect to the switch using ssh . i send commands generally using a button that ptints the content of a textbox into the outputstream . every thing works fine as long as i print the command into the outputstream from the code of the button press event . This hangs the interdace because i have to wait for a specific output format . So i used a Thread to execute the same code so that the interface doesn't hang . The strange thing is after the thread finishes i am not able to receive any thing from the switch ( although the printing into the output stream doesn't produce any exceptions and this is not the same if i executed the same code without the thread) . The question is why the program has different behaviour inside a thread and outside it ?
Best Regards ,

>
Sounds like this actually is more related to Swing than concurrency (if I'm correct). I think that everything is working, but you are failing to update the UI with the result. You are only allowed to update the UI from the AWT thread, so you probably need to publish the result using invokeLater or use a SwingWorker.

EL - How do you call a method that requires a parameter

How do you call a method that requires a parameter
In scriplet code here is what I am trying to do
<%= car.getDefaultColor(car.getCarType()) %>
How do I do this in EL
Here is my guess (it generates the Exception described below)
${car.defaultColor(car.carType)}
Here is the Exception I am getting:
javax.servlet.ServletException: <h3>Validation error messages from tag library c</h3>tag = 'out' / attribute = 'value': An error occurred while parsing custom action attribute "value" with value "${car.defaultColor(car.carType)}": Encountered "(", expected one of ["}", ".", ">", "gt", "<", "lt", "==", "eq", "<=", "le", ">=", "ge", "!=", "ne", "[", "+", "-", "*", "/", "div", "%", "mod", "and", "&&", "or", "||"]
Any Ideas?
P.S. If it matters to you, I am using JSTL 1.0 and the code snippets above are actually within the value attribute of a <c:out value="" /> statement.

How do you call a method that requires a parameter
In scriplet code here is what I am trying to do
<%= car.getDefaultColor(car.getCarType()) %>
How do I do this in ELYou don't. EL is very strict in method signatures. All get methods must be public Type getProperty(void); And all set methods must be public void setProperty(Type t);
So you will have to re-work your Bean so it does not need an argument to the get method (getDefaultColor()). Since you are calling another method out of car, you might re-write the getDefaultColor method as such:
public Object getDefaultColor() {
    CarType ct = this.getCarType();
    //then do other stuff
}If that isn't suitable, then provide a helper method that is used to set the current car type and then call the getDefaultColor:
private CarType curCarType;
public void setCurrentCarType(CarType ct) { curCarType = ct; }
public Object getDefaultColor() {
    if (curCarType == null) throw new IllegalStateException("CarType must be set before getting color");
    //normal work using curCarType
<c:set target="${car}" property="currentCarType" value="${car.carType}"/>
<c:out value="${car.defaultColor}"/>It is better to do as little of the data manipulation (setting up the car type) in the JSP as possible, so the first option is better than the second. Also better then the second would be to set the current car type in a servlet or data access object (or wherever) from which your retreive the car to begin with. Manipulatig it in the JSP itself should be your last resort (to keep as much business logic out of the JSP as possible).
Here is my guess (it generates the Exception
described below)
${car.defaultColor(car.carType)}
Here is the Exception I am getting:
javax.servlet.ServletException: <h3>Validation error
messages from tag library c</h3>tag = 'out' /
attribute = 'value': An error occurred while parsing
custom action attribute "value" with value
"${car.defaultColor(car.carType)}": Encountered "(",
expected one of ["}", ".", ">", "gt", "<", "lt",
"==", "eq", "<=", "le", ">=", "ge", "!=", "ne", "[",
"+", "-", "*", "/", "div", "%", "mod", "and", "&&",
"or", "||"]
Any Ideas?
P.S. If it matters to you, I am using JSTL 1.0 and
the code snippets above are actually within the value
attribute of a <c:out value="" /> statement.

Different behaviour in JMS Cluster automatic failover

Hi,
          I am problem in JMS clustering, now let me explain the scenario.
          I have 2 managed servers participating in the weblogic cluster, now since JMS is a singleton service what i did is i have created 2 JMS servers and targeted them to Managedservers 1 and 2 respectively.I have also created a Distributed Destination and deploy they with the deployment "wizard" ("autodeploy") to all the member of the cluster.
          Now in my case I created two different type of client
          Asynchronous and synchronous .
          The first one register himself as MessageListener and also as ExceptionListener. When I bring down the managed server in which the client is connect the call back method onException is called.
          The second client instead register himself as ExceptionListener but not as MessageListener. It call in different thread the receive method on the destination.
          In this case if i I bring down the managed server in which the client is connect the call back method onException is NOT called, instead i receive the JMSException on all the call "receive".
          I expected that the behaviour was the same of the firts client.
          Thanks in advance.
          dani

Its not clear from your description what you're trying to do, as typical apps use a single module, including those that use distributed destinations, and typical apps do not use the convention of specifying a module name in their JNDI name. (The "!" syntax makes me suspect that you're not using JNDI to lookup destinations, rather you're using the rarely recommended JMS session "createQueue()" call.).
Never-the-less, I suspect the problem is simply that your using a distributed queue and haven't realized that queue browsers and consumers pin themselves to a single queue member. To ensure full coverage of a distributed queue, the best practice is to use a WebLogic MDB: WebLogic MDBs automatically ensure that each queue member has consumers.
By the way, if you are using a distributed queues, then the best practice config is as follows for each homogeneous set of JMS servers:
-- Configure a custom WL store per server, target to the server's default migratable target.
-- Configure a JMS server per server, target to the server's default migratable target, set the store for the JMS server to be the same as the custom store.
-- Configure a single JMS module, target to the cluster.
-- Configure a single subdeployment for the module that references each JMS server (and nothing else).
-- Configure one or more distributed queues for the module. Never use default targeting -- instead use advanced subdeployment targeting to target each distributed queue to the single subdeployment you defined earlier.
-- Configure one or more custom connection factories in the module, use default targeting.
I recommend that you read through the JMS admin and programmer's guides in the edocs if you haven't done so already. You might find that the JMS chapter of the new book "Professional Oracle WebLogic" is helpful.
Tom
Edited by: TomB on Nov 4, 2009 10:12 AM

JComboBox - different behaviour in 1.3 and 1.4

I have noticed that there is a difference in JCombobox behaviour in 1.3 and 1.4.
I think it is better to give the program than explaining the issue.
the below given program shows the difference.
import javax.swing.* ;
import java.awt.* ;
import java.awt.event.* ;
import java.util.* ;
* Test program to show difference between
* Combo behaviour in java1.3 and 1.4
public class CTest extends JFrame
     private JComboBox combo1 ;
     private JComboBox combo2 ;
     public CTest()
          super() ;
     public void init()
     combo1 = new JComboBox() ;
          combo1.addItemListener( new ItemListener()
                    public void itemStateChanged( ItemEvent event )
                    if (null != combo1.getSelectedItem() && event.getStateChange() == ItemEvent.SELECTED)
                         loadCombo2(combo1.getSelectedIndex()+1) ;
     combo2 = new JComboBox() ;
          combo2.addItemListener( new ItemListener()
                    public void itemStateChanged( ItemEvent event )
                    if (null != combo2.getSelectedItem() && event.getStateChange() == ItemEvent.SELECTED)
                         System.out.println("Combo2 item selected : "+ combo2.getSelectedItem()) ;
          JPanel panel = new JPanel(new BorderLayout()) ;
          panel.add(combo1,BorderLayout.NORTH) ;
          panel.add(combo2,BorderLayout.SOUTH) ;
          getContentPane().add(panel) ;
     public void loadCombo1()
          combo1.removeAllItems() ;
          for (int iCount = 0 ; iCount <5 ; iCount++)
               String strItem = "Item : "+iCount ;
          combo1.addItem(strItem) ;
          try
               combo1.setSelectedIndex(0) ;
          catch(Exception e)
     private void loadCombo2(int itemCount)
          combo2.removeAllItems() ;
          for (int iCount = 0 ; iCount <itemCount ; iCount++)
               String strItem = "Item : "+iCount ;
          combo2.addItem(strItem) ;
          try
               combo2.setSelectedIndex(0) ;
          catch(Exception e)
     public static final void main(String args[])
          CTest app = new CTest() ;
          app.init() ;
          app.setSize(100,100) ;
          app.setVisible(true) ;
          app.loadCombo1() ;
In jdk1.3 every time you change the selection in combo 1 there will be selection change in combo 2 also. but not in jdk1.4.
i am not sure whether it is a bug. But surely te behaviour is different.
any comments on this issue???

Anil,
I've just noticed this as well, so I had a quick look at the 1.4 sources. Quite simply, adding and removing items in a JComboBox will never fire an ItemStateChangedEvent, even if the selected item does change.
The culprits are intervalAdded() and intervalRemoved() in JComboBox.java. Under 1.3 these methods called contentsChanged() which would then fire an ItemStateChangedEvent if necessary. Under 1.4, these methods are empty. Why? I have no idea. It seems like a bug to me, but can't see anything in the bug database about it. Hope someone from Sun can explain it.
Regards,
Peter

JButton setEnabled method is not refreshing state

Hi there, I have a problem, I'm putting a few JButtons into a JPanel, so that I can display the options that an user has.
I validate the user options so I can put the set enabled method with argument true or false.
The app show a login JFrame and then the screen that has these options, that is like the main form.
The fact is that is try to login again via a change user option located on the main form,, then the login JFrame is displayed again and eventually the main form.
When I try enable the user options again, the method setEnabled of the JButton doesn´t seem to be working, it just doesn't change the state, I have the debugged it and it reaches in both cases the setEnabled line (((JButton) jpnlSistemas1.getComponents()).setEnabled(true);)
        Sistema sistema;
        JButton boton;
        for (int i = 0; i < jpnlSistemas1.getComponents().length; i++) {
            if (jpnlSistemas1.getComponents() instanceof JButton) {
boton = (JButton) jpnlSistemas1.getComponents()[i];
Iterator iteradorSistemas = global.getUsuario().getSistemas().iterator();
while (iteradorSistemas.hasNext()) {
sistema = (Sistema) iteradorSistemas.next();
if (((JButton) jpnlSistemas1.getComponents()[i]).getName().equals(sistema.getIdSistema())) {
((JButton) jpnlSistemas1.getComponents()[i]).setEnabled(true);
any ideas about what could it be?
thanks.

I'd do it differently. I'd have whatever class that holds the JButtons have a enableButton() method, and then simply call that method rather than searching for buttons among all the components of a window.

Possible Bug? Different behaviour for List and Set one-to-many mappings on deletePersistent()

Hi,
I have a PC class that represents a TreeNode object (a GcGroup), which
has a one-to-many relationship with itself to keep track of its descendants.
For example a hierarchy of A -> B -> C, where A has B,C as descendants
and B has C as a descendant. This is tracked by adding or removing a
descendant with a recursive method to update a TreeNode's parent's
descendants when a child is added or removed.
The odd behaviour happens when I delete a child and try to remove the
child manually from all my parent's descendant relations when I use a
HashSet (possibly happens with any Set). In this case kodo will remove
the relations with the following SQL statement:
DELETE FROM TREENODE_DESCENDANTSX JDOIDX = xxxx;
So when I do my recursive call I get a JDOException thrown stating that
the object xxxx has already been deleted.
When I change the relationship to an ArrayList this exception is not
thrown and I do not get the error.
Looking at the SQL generated they look the same:
2002-10-31 20:21:42,078 INFO
[com.solarmetric.kodo.impl.jdbc.ee.ManagedConnectionFactoryImpl.kodo] [ C:
2002-10-31 20:21:42,078 INFO
[com.solarmetric.kodo.impl.jdbc.ee.ManagedConnectionFactoryImpl.kodo]
27106317
2002-10-31 20:21:42,078 INFO
[com.solarmetric.kodo.impl.jdbc.ee.ManagedConnectionFactoryImpl.kodo] ; S:
2002-10-31 20:21:42,078 INFO
[com.solarmetric.kodo.impl.jdbc.ee.ManagedConnectionFactoryImpl.kodo]
28819334
2002-10-31 20:21:42,078 INFO
[com.solarmetric.kodo.impl.jdbc.ee.ManagedConnectionFactoryImpl.kodo] ; T:
2002-10-31 20:21:42,078 INFO
[com.solarmetric.kodo.impl.jdbc.ee.ManagedConnectionFactoryImpl.kodo]
10817575
2002-10-31 20:21:42,078 INFO
[com.solarmetric.kodo.impl.jdbc.ee.ManagedConnectionFactoryImpl.kodo] ; D:
2002-10-31 20:21:42,078 INFO
[com.solarmetric.kodo.impl.jdbc.ee.ManagedConnectionFactoryImpl.kodo]
02/10/31 20:21
2002-10-31 20:21:42,078 INFO
[com.solarmetric.kodo.impl.jdbc.ee.ManagedConnectionFactoryImpl.kodo] ]
2002-10-31 20:21:42,078 INFO
[com.solarmetric.kodo.impl.jdbc.ee.ManagedConnectionFactoryImpl.kodo]
UPDATE GCGroup SET JDOLOCKX=8, child_count=0 WHERE (id = 81 AND JDOLOCKX
= 7)
2002-10-31 20:21:42,078 INFO
[com.solarmetric.kodo.impl.jdbc.ee.ManagedConnectionFactoryImpl.kodo] [ C:
2002-10-31 20:21:42,078 INFO
[com.solarmetric.kodo.impl.jdbc.ee.ManagedConnectionFactoryImpl.kodo]
27106317
2002-10-31 20:21:42,078 INFO
[com.solarmetric.kodo.impl.jdbc.ee.ManagedConnectionFactoryImpl.kodo] ; S:
2002-10-31 20:21:42,078 INFO
[com.solarmetric.kodo.impl.jdbc.ee.ManagedConnectionFactoryImpl.kodo]
8331873
2002-10-31 20:21:42,078 INFO
[com.solarmetric.kodo.impl.jdbc.ee.ManagedConnectionFactoryImpl.kodo] ; T:
2002-10-31 20:21:42,078 INFO
[com.solarmetric.kodo.impl.jdbc.ee.ManagedConnectionFactoryImpl.kodo]
10817575
2002-10-31 20:21:42,078 INFO
[com.solarmetric.kodo.impl.jdbc.ee.ManagedConnectionFactoryImpl.kodo] ; D:
2002-10-31 20:21:42,078 INFO
[com.solarmetric.kodo.impl.jdbc.ee.ManagedConnectionFactoryImpl.kodo]
02/10/31 20:21
2002-10-31 20:21:42,078 INFO
[com.solarmetric.kodo.impl.jdbc.ee.ManagedConnectionFactoryImpl.kodo] ]
2002-10-31 20:21:42,078 INFO
[com.solarmetric.kodo.impl.jdbc.ee.ManagedConnectionFactoryImpl.kodo]
DELETE FROM GROUP__DESCENDANTSX WHERE JDOIDX = 12300
2002-10-31 20:21:42,078 INFO
[com.solarmetric.kodo.impl.jdbc.ee.ManagedConnectionFactoryImpl.kodo] [ C:
2002-10-31 20:21:42,078 INFO
[com.solarmetric.kodo.impl.jdbc.ee.ManagedConnectionFactoryImpl.kodo]
27106317
2002-10-31 20:21:42,078 INFO
[com.solarmetric.kodo.impl.jdbc.ee.ManagedConnectionFactoryImpl.kodo] ; S:
2002-10-31 20:21:42,078 INFO
[com.solarmetric.kodo.impl.jdbc.ee.ManagedConnectionFactoryImpl.kodo]
8331873
2002-10-31 20:21:42,078 INFO
[com.solarmetric.kodo.impl.jdbc.ee.ManagedConnectionFactoryImpl.kodo] ; T:
2002-10-31 20:21:42,093 INFO
[com.solarmetric.kodo.impl.jdbc.ee.ManagedConnectionFactoryImpl.kodo]
10817575
2002-10-31 20:21:42,093 INFO
[com.solarmetric.kodo.impl.jdbc.ee.ManagedConnectionFactoryImpl.kodo] ; D:
2002-10-31 20:21:42,093 INFO
[com.solarmetric.kodo.impl.jdbc.ee.ManagedConnectionFactoryImpl.kodo]
02/10/31 20:21
2002-10-31 20:21:42,093 INFO
[com.solarmetric.kodo.impl.jdbc.ee.ManagedConnectionFactoryImpl.kodo] ]
2002-10-31 20:21:42,093 INFO
[com.solarmetric.kodo.impl.jdbc.ee.ManagedConnectionFactoryImpl.kodo]
DELETE FROM GROUP__USERSX WHERE group_id = 12300
2002-10-31 20:21:42,093 INFO
[com.solarmetric.kodo.impl.jdbc.ee.ManagedConnectionFactoryImpl.kodo] [ C:
2002-10-31 20:21:42,093 INFO
[com.solarmetric.kodo.impl.jdbc.ee.ManagedConnectionFactoryImpl.kodo]
27106317
2002-10-31 20:21:42,093 INFO
[com.solarmetric.kodo.impl.jdbc.ee.ManagedConnectionFactoryImpl.kodo] ; S:
2002-10-31 20:21:42,093 INFO
[com.solarmetric.kodo.impl.jdbc.ee.ManagedConnectionFactoryImpl.kodo]
8331873
2002-10-31 20:21:42,093 INFO
[com.solarmetric.kodo.impl.jdbc.ee.ManagedConnectionFactoryImpl.kodo] ; T:
2002-10-31 20:21:42,093 INFO
[com.solarmetric.kodo.impl.jdbc.ee.ManagedConnectionFactoryImpl.kodo]
10817575
2002-10-31 20:21:42,093 INFO
[com.solarmetric.kodo.impl.jdbc.ee.ManagedConnectionFactoryImpl.kodo] ; D:
2002-10-31 20:21:42,093 INFO
[com.solarmetric.kodo.impl.jdbc.ee.ManagedConnectionFactoryImpl.kodo]
02/10/31 20:21
2002-10-31 20:21:42,093 INFO
[com.solarmetric.kodo.impl.jdbc.ee.ManagedConnectionFactoryImpl.kodo] ]
2002-10-31 20:21:42,093 INFO
[com.solarmetric.kodo.impl.jdbc.ee.ManagedConnectionFactoryImpl.kodo]
DELETE FROM GCGroup WHERE id = 12300
2002-10-31 20:21:42,093 INFO
[com.solarmetric.kodo.impl.jdbc.ee.ManagedConnectionFactoryImpl.kodo] [ C:
2002-10-31 20:21:42,093 INFO
[com.solarmetric.kodo.impl.jdbc.ee.ManagedConnectionFactoryImpl.kodo]
27106317
2002-10-31 20:21:42,093 INFO
[com.solarmetric.kodo.impl.jdbc.ee.ManagedConnectionFactoryImpl.kodo] ; T:
2002-10-31 20:21:42,093 INFO
[com.solarmetric.kodo.impl.jdbc.ee.ManagedConnectionFactoryImpl.kodo]
10817575
2002-10-31 20:21:42,093 INFO
[com.solarmetric.kodo.impl.jdbc.ee.ManagedConnectionFactoryImpl.kodo] ; D:
2002-10-31 20:21:42,093 INFO
[com.solarmetric.kodo.impl.jdbc.ee.ManagedConnectionFactoryImpl.kodo]
02/10/31 20:21
2002-10-31 20:21:42,093 INFO
[com.solarmetric.kodo.impl.jdbc.ee.ManagedConnectionFactoryImpl.kodo] ]
2002-10-31 20:21:42,093 INFO
[com.solarmetric.kodo.impl.jdbc.ee.ManagedConnectionFactoryImpl.kodo]
commit data store transaction
My methods look like the following:
public void removeChild(TreeNode t) {
     _children.remove(t);
     removeDescendant(t);
protected void removeDescendant(TreeNode t) {
     if (_parent != null) {
          _parent.removeDescendant(t);
     _descendants.remove(t);
The following is the stack trace from the exception when using a HashSet:
[com.solarmetric.kodo.impl.jdbc.ee.ManagedConnectionFactoryImpl.kodo] [ C:
2002-10-31 20:54:10,046 INFO
[com.solarmetric.kodo.impl.jdbc.ee.ManagedConnectionFactoryImpl.kodo]
18799851
2002-10-31 20:54:10,046 INFO
[com.solarmetric.kodo.impl.jdbc.ee.ManagedConnectionFactoryImpl.kodo] ; S:
2002-10-31 20:54:10,046 INFO
[com.solarmetric.kodo.impl.jdbc.ee.ManagedConnectionFactoryImpl.kodo]
30836962
2002-10-31 20:54:10,046 INFO
[com.solarmetric.kodo.impl.jdbc.ee.ManagedConnectionFactoryImpl.kodo] ; T:
2002-10-31 20:54:10,046 INFO
[com.solarmetric.kodo.impl.jdbc.ee.ManagedConnectionFactoryImpl.kodo]
29139395
2002-10-31 20:54:10,046 INFO
[com.solarmetric.kodo.impl.jdbc.ee.ManagedConnectionFactoryImpl.kodo] ; D:
2002-10-31 20:54:10,046 INFO
[com.solarmetric.kodo.impl.jdbc.ee.ManagedConnectionFactoryImpl.kodo]
02/10/31 20:54
2002-10-31 20:54:10,046 INFO
[com.solarmetric.kodo.impl.jdbc.ee.ManagedConnectionFactoryImpl.kodo] ]
2002-10-31 20:54:10,046 INFO
[com.solarmetric.kodo.impl.jdbc.ee.ManagedConnectionFactoryImpl.kodo]
UPDATE GCGroup SET JDOLOCKX=3, child_count=0 WHERE (id = 12450 AND
JDOLOCKX = 2)
2002-10-31 20:54:10,046 INFO
[com.solarmetric.kodo.impl.jdbc.ee.ManagedConnectionFactoryImpl.kodo] [ C:
2002-10-31 20:54:10,046 INFO
[com.solarmetric.kodo.impl.jdbc.ee.ManagedConnectionFactoryImpl.kodo]
18799851
2002-10-31 20:54:10,046 INFO
[com.solarmetric.kodo.impl.jdbc.ee.ManagedConnectionFactoryImpl.kodo] ; S:
2002-10-31 20:54:10,046 INFO
[com.solarmetric.kodo.impl.jdbc.ee.ManagedConnectionFactoryImpl.kodo]
28630940
2002-10-31 20:54:10,046 INFO
[com.solarmetric.kodo.impl.jdbc.ee.ManagedConnectionFactoryImpl.kodo] ; T:
2002-10-31 20:54:10,062 INFO
[com.solarmetric.kodo.impl.jdbc.ee.ManagedConnectionFactoryImpl.kodo]
29139395
2002-10-31 20:54:10,062 INFO
[com.solarmetric.kodo.impl.jdbc.ee.ManagedConnectionFactoryImpl.kodo] ; D:
2002-10-31 20:54:10,062 INFO
[com.solarmetric.kodo.impl.jdbc.ee.ManagedConnectionFactoryImpl.kodo]
02/10/31 20:54
2002-10-31 20:54:10,062 INFO
[com.solarmetric.kodo.impl.jdbc.ee.ManagedConnectionFactoryImpl.kodo] ]
2002-10-31 20:54:10,062 INFO
[com.solarmetric.kodo.impl.jdbc.ee.ManagedConnectionFactoryImpl.kodo]
UPDATE GCGroup SET JDOLOCKX=41 WHERE (id = 2 AND JDOLOCKX = 40)
2002-10-31 20:54:10,062 INFO
[com.solarmetric.kodo.impl.jdbc.ee.ManagedConnectionFactoryImpl.kodo] [ C:
2002-10-31 20:54:10,062 INFO
[com.solarmetric.kodo.impl.jdbc.ee.ManagedConnectionFactoryImpl.kodo]
18799851
2002-10-31 20:54:10,062 INFO
[com.solarmetric.kodo.impl.jdbc.ee.ManagedConnectionFactoryImpl.kodo] ; S:
2002-10-31 20:54:10,062 INFO
[com.solarmetric.kodo.impl.jdbc.ee.ManagedConnectionFactoryImpl.kodo]
29663640
2002-10-31 20:54:10,062 INFO
[com.solarmetric.kodo.impl.jdbc.ee.ManagedConnectionFactoryImpl.kodo] ; T:
2002-10-31 20:54:10,062 INFO
[com.solarmetric.kodo.impl.jdbc.ee.ManagedConnectionFactoryImpl.kodo]
29139395
2002-10-31 20:54:10,062 INFO
[com.solarmetric.kodo.impl.jdbc.ee.ManagedConnectionFactoryImpl.kodo] ; D:
2002-10-31 20:54:10,062 INFO
[com.solarmetric.kodo.impl.jdbc.ee.ManagedConnectionFactoryImpl.kodo]
02/10/31 20:54
2002-10-31 20:54:10,062 INFO
[com.solarmetric.kodo.impl.jdbc.ee.ManagedConnectionFactoryImpl.kodo] ]
2002-10-31 20:54:10,062 INFO
[com.solarmetric.kodo.impl.jdbc.ee.ManagedConnectionFactoryImpl.kodo]
DELETE FROM GROUP__DESCENDANTSX WHERE JDOIDX = 12451
2002-10-31 20:54:10,078 INFO
[com.solarmetric.kodo.impl.jdbc.ee.ManagedConnectionFactoryImpl.kodo] [ C:
2002-10-31 20:54:10,078 INFO
[com.solarmetric.kodo.impl.jdbc.ee.ManagedConnectionFactoryImpl.kodo]
18799851
2002-10-31 20:54:10,078 INFO
[com.solarmetric.kodo.impl.jdbc.ee.ManagedConnectionFactoryImpl.kodo] ; S:
2002-10-31 20:54:10,078 INFO
[com.solarmetric.kodo.impl.jdbc.ee.ManagedConnectionFactoryImpl.kodo]
29663640
2002-10-31 20:54:10,078 INFO
[com.solarmetric.kodo.impl.jdbc.ee.ManagedConnectionFactoryImpl.kodo] ; T:
2002-10-31 20:54:10,078 INFO
[com.solarmetric.kodo.impl.jdbc.ee.ManagedConnectionFactoryImpl.kodo]
29139395
2002-10-31 20:54:10,078 INFO
[com.solarmetric.kodo.impl.jdbc.ee.ManagedConnectionFactoryImpl.kodo] ; D:
2002-10-31 20:54:10,078 INFO
[com.solarmetric.kodo.impl.jdbc.ee.ManagedConnectionFactoryImpl.kodo]
02/10/31 20:54
2002-10-31 20:54:10,078 INFO
[com.solarmetric.kodo.impl.jdbc.ee.ManagedConnectionFactoryImpl.kodo] ]
2002-10-31 20:54:10,078 INFO
[com.solarmetric.kodo.impl.jdbc.ee.ManagedConnectionFactoryImpl.kodo]
DELETE FROM GROUP__USERSX WHERE group_id = 12451
2002-10-31 20:54:10,078 INFO
[com.solarmetric.kodo.impl.jdbc.ee.ManagedConnectionFactoryImpl.kodo] [ C:
2002-10-31 20:54:10,078 INFO
[com.solarmetric.kodo.impl.jdbc.ee.ManagedConnectionFactoryImpl.kodo]
18799851
2002-10-31 20:54:10,078 INFO
[com.solarmetric.kodo.impl.jdbc.ee.ManagedConnectionFactoryImpl.kodo] ; S:
2002-10-31 20:54:10,078 INFO
[com.solarmetric.kodo.impl.jdbc.ee.ManagedConnectionFactoryImpl.kodo]
29663640
2002-10-31 20:54:10,078 INFO
[com.solarmetric.kodo.impl.jdbc.ee.ManagedConnectionFactoryImpl.kodo] ; T:
2002-10-31 20:54:10,078 INFO
[com.solarmetric.kodo.impl.jdbc.ee.ManagedConnectionFactoryImpl.kodo]
29139395
2002-10-31 20:54:10,078 INFO
[com.solarmetric.kodo.impl.jdbc.ee.ManagedConnectionFactoryImpl.kodo] ; D:
2002-10-31 20:54:10,078 INFO
[com.solarmetric.kodo.impl.jdbc.ee.ManagedConnectionFactoryImpl.kodo]
02/10/31 20:54
2002-10-31 20:54:10,078 INFO
[com.solarmetric.kodo.impl.jdbc.ee.ManagedConnectionFactoryImpl.kodo] ]
2002-10-31 20:54:10,078 INFO
[com.solarmetric.kodo.impl.jdbc.ee.ManagedConnectionFactoryImpl.kodo]
DELETE FROM GCGroup WHERE id = 12451
2002-10-31 20:54:10,093 INFO
[com.solarmetric.kodo.impl.jdbc.ee.ManagedConnectionFactoryImpl.kodo] [ C:
2002-10-31 20:54:10,093 INFO
[com.solarmetric.kodo.impl.jdbc.ee.ManagedConnectionFactoryImpl.kodo]
18799851
2002-10-31 20:54:10,093 INFO
[com.solarmetric.kodo.impl.jdbc.ee.ManagedConnectionFactoryImpl.kodo] ; S:
2002-10-31 20:54:10,093 INFO
[com.solarmetric.kodo.impl.jdbc.ee.ManagedConnectionFactoryImpl.kodo]
5057297
2002-10-31 20:54:10,093 INFO
[com.solarmetric.kodo.impl.jdbc.ee.ManagedConnectionFactoryImpl.kodo] ; T:
2002-10-31 20:54:10,093 INFO
[com.solarmetric.kodo.impl.jdbc.ee.ManagedConnectionFactoryImpl.kodo]
29139395
2002-10-31 20:54:10,093 INFO
[com.solarmetric.kodo.impl.jdbc.ee.ManagedConnectionFactoryImpl.kodo] ; D:
2002-10-31 20:54:10,093 INFO
[com.solarmetric.kodo.impl.jdbc.ee.ManagedConnectionFactoryImpl.kodo]
02/10/31 20:54
2002-10-31 20:54:10,093 INFO
[com.solarmetric.kodo.impl.jdbc.ee.ManagedConnectionFactoryImpl.kodo] ]
2002-10-31 20:54:10,093 INFO
[com.solarmetric.kodo.impl.jdbc.ee.ManagedConnectionFactoryImpl.kodo]
DELETE FROM GROUP__DESCENDANTSX WHERE JDOIDX = 12452
2002-10-31 20:54:10,093 INFO
[com.solarmetric.kodo.impl.jdbc.ee.ManagedConnectionFactoryImpl.kodo] [ C:
2002-10-31 20:54:10,093 INFO
[com.solarmetric.kodo.impl.jdbc.ee.ManagedConnectionFactoryImpl.kodo]
18799851
2002-10-31 20:54:10,093 INFO
[com.solarmetric.kodo.impl.jdbc.ee.ManagedConnectionFactoryImpl.kodo] ; S:
2002-10-31 20:54:10,093 INFO
[com.solarmetric.kodo.impl.jdbc.ee.ManagedConnectionFactoryImpl.kodo]
5057297
2002-10-31 20:54:10,093 INFO
[com.solarmetric.kodo.impl.jdbc.ee.ManagedConnectionFactoryImpl.kodo] ; T:
2002-10-31 20:54:10,093 INFO
[com.solarmetric.kodo.impl.jdbc.ee.ManagedConnectionFactoryImpl.kodo]
29139395
2002-10-31 20:54:10,093 INFO
[com.solarmetric.kodo.impl.jdbc.ee.ManagedConnectionFactoryImpl.kodo] ; D:
2002-10-31 20:54:10,093 INFO
[com.solarmetric.kodo.impl.jdbc.ee.ManagedConnectionFactoryImpl.kodo]
02/10/31 20:54
2002-10-31 20:54:10,093 INFO
[com.solarmetric.kodo.impl.jdbc.ee.ManagedConnectionFactoryImpl.kodo] ]
2002-10-31 20:54:10,093 INFO
[com.solarmetric.kodo.impl.jdbc.ee.ManagedConnectionFactoryImpl.kodo]
DELETE FROM GROUP__USERSX WHERE group_id = 12452
2002-10-31 20:54:10,093 INFO
[com.solarmetric.kodo.impl.jdbc.ee.ManagedConnectionFactoryImpl.kodo] [ C:
2002-10-31 20:54:10,093 INFO
[com.solarmetric.kodo.impl.jdbc.ee.ManagedConnectionFactoryImpl.kodo]
18799851
2002-10-31 20:54:10,093 INFO
[com.solarmetric.kodo.impl.jdbc.ee.ManagedConnectionFactoryImpl.kodo] ; S:
2002-10-31 20:54:10,093 INFO
[com.solarmetric.kodo.impl.jdbc.ee.ManagedConnectionFactoryImpl.kodo]
5057297
2002-10-31 20:54:10,093 INFO
[com.solarmetric.kodo.impl.jdbc.ee.ManagedConnectionFactoryImpl.kodo] ; T:
2002-10-31 20:54:10,093 INFO
[com.solarmetric.kodo.impl.jdbc.ee.ManagedConnectionFactoryImpl.kodo]
29139395
2002-10-31 20:54:10,093 INFO
[com.solarmetric.kodo.impl.jdbc.ee.ManagedConnectionFactoryImpl.kodo] ; D:
2002-10-31 20:54:10,093 INFO
[com.solarmetric.kodo.impl.jdbc.ee.ManagedConnectionFactoryImpl.kodo]
02/10/31 20:54
2002-10-31 20:54:10,093 INFO
[com.solarmetric.kodo.impl.jdbc.ee.ManagedConnectionFactoryImpl.kodo] ]
2002-10-31 20:54:10,093 INFO
[com.solarmetric.kodo.impl.jdbc.ee.ManagedConnectionFactoryImpl.kodo]
DELETE FROM GCGroup WHERE id = 12452
2002-10-31 20:54:10,109 INFO
[com.solarmetric.kodo.impl.jdbc.ee.ManagedConnectionFactoryImpl.kodo] [ C:
2002-10-31 20:54:10,109 INFO
[com.solarmetric.kodo.impl.jdbc.ee.ManagedConnectionFactoryImpl.kodo]
18799851
2002-10-31 20:54:10,109 INFO
[com.solarmetric.kodo.impl.jdbc.ee.ManagedConnectionFactoryImpl.kodo] ; T:
2002-10-31 20:54:10,109 INFO
[com.solarmetric.kodo.impl.jdbc.ee.ManagedConnectionFactoryImpl.kodo]
29139395
2002-10-31 20:54:10,109 INFO
[com.solarmetric.kodo.impl.jdbc.ee.ManagedConnectionFactoryImpl.kodo] ; D:
2002-10-31 20:54:10,109 INFO
[com.solarmetric.kodo.impl.jdbc.ee.ManagedConnectionFactoryImpl.kodo]
02/10/31 20:54
2002-10-31 20:54:10,109 INFO
[com.solarmetric.kodo.impl.jdbc.ee.ManagedConnectionFactoryImpl.kodo] ]
2002-10-31 20:54:10,109 INFO
[com.solarmetric.kodo.impl.jdbc.ee.ManagedConnectionFactoryImpl.kodo]
roll back data store transaction
2002-10-31 20:54:10,109 INFO
[com.solarmetric.kodo.impl.jdbc.ee.ManagedConnectionFactoryImpl.kodo] [ C:
2002-10-31 20:54:10,109 INFO
[com.solarmetric.kodo.impl.jdbc.ee.ManagedConnectionFactoryImpl.kodo]
18799851
2002-10-31 20:54:10,109 INFO
[com.solarmetric.kodo.impl.jdbc.ee.ManagedConnectionFactoryImpl.kodo] ; S:
2002-10-31 20:54:10,109 INFO
[com.solarmetric.kodo.impl.jdbc.ee.ManagedConnectionFactoryImpl.kodo]
4629956
2002-10-31 20:54:10,109 INFO
[com.solarmetric.kodo.impl.jdbc.ee.ManagedConnectionFactoryImpl.kodo] ; T:
2002-10-31 20:54:10,109 INFO
[com.solarmetric.kodo.impl.jdbc.ee.ManagedConnectionFactoryImpl.kodo]
29139395
2002-10-31 20:54:10,109 INFO
[com.solarmetric.kodo.impl.jdbc.ee.ManagedConnectionFactoryImpl.kodo] ; D:
2002-10-31 20:54:10,109 INFO
[com.solarmetric.kodo.impl.jdbc.ee.ManagedConnectionFactoryImpl.kodo]
02/10/31 20:54
2002-10-31 20:54:10,109 INFO
[com.solarmetric.kodo.impl.jdbc.ee.ManagedConnectionFactoryImpl.kodo] ]
2002-10-31 20:54:10,109 INFO
[com.solarmetric.kodo.impl.jdbc.ee.ManagedConnectionFactoryImpl.kodo]
SELECT t0.id, t0.JDOLOCKX, t0.child_count, t0.description,
t0.global_read, t0.global_write, t0.name, t0.owner_id, t0.parent_id,
t0.rank, t0.root_id, t0.user_count, t0.user_exists, t0.visibility FROM
GCGroup t0 WHERE t0.id = 12451
2002-10-31 20:54:10,125 INFO
[com.solarmetric.kodo.impl.jdbc.ee.ManagedConnectionFactoryImpl.kodo] [ C:
2002-10-31 20:54:10,125 INFO
[com.solarmetric.kodo.impl.jdbc.ee.ManagedConnectionFactoryImpl.kodo]
18799851
2002-10-31 20:54:10,125 INFO
[com.solarmetric.kodo.impl.jdbc.ee.ManagedConnectionFactoryImpl.kodo] ; S:
2002-10-31 20:54:10,125 INFO
[com.solarmetric.kodo.impl.jdbc.ee.ManagedConnectionFactoryImpl.kodo]
2951648
2002-10-31 20:54:10,125 INFO
[com.solarmetric.kodo.impl.jdbc.ee.ManagedConnectionFactoryImpl.kodo] ; T:
2002-10-31 20:54:10,125 INFO
[com.solarmetric.kodo.impl.jdbc.ee.ManagedConnectionFactoryImpl.kodo]
29139395
2002-10-31 20:54:10,125 INFO
[com.solarmetric.kodo.impl.jdbc.ee.ManagedConnectionFactoryImpl.kodo] ; D:
2002-10-31 20:54:10,125 INFO
[com.solarmetric.kodo.impl.jdbc.ee.ManagedConnectionFactoryImpl.kodo]
02/10/31 20:54
2002-10-31 20:54:10,125 INFO
[com.solarmetric.kodo.impl.jdbc.ee.ManagedConnectionFactoryImpl.kodo] ]
2002-10-31 20:54:10,125 INFO
[com.solarmetric.kodo.impl.jdbc.ee.ManagedConnectionFactoryImpl.kodo]
SELECT t0.id, t0.JDOLOCKX, t0.child_count, t0.description,
t0.global_read, t0.global_write, t0.name, t0.owner_id, t0.parent_id,
t0.rank, t0.root_id, t0.user_count, t0.user_exists, t0.visibility FROM
GCGroup t0 WHERE t0.id = 12452
2002-10-31 20:54:10,140 INFO [STDOUT]
com.gulfnet.common.actions.GroupAction : The exception is:
javax.jdo.JDOException
2002-10-31 20:54:10,140 INFO [org.jboss.web.localhost.Engine] action:
com.gulfnet.common.actions.GroupAction : The exception is:
javax.jdo.JDOException
2002-10-31 20:54:10,140 INFO [STDOUT]
com.gulfnet.common.actions.GroupAction : java.lang.NullPointerException
2002-10-31 20:54:10,140 INFO [org.jboss.web.localhost.Engine] action:
com.gulfnet.common.actions.GroupAction : java.lang.NullPointerException
2002-10-31 20:54:10,140 ERROR [STDERR] javax.jdo.JDOException:
java.lang.NullPointerException
NestedThrowables:
java.lang.NullPointerException
2002-10-31 20:54:10,156 ERROR [STDERR] at
com.solarmetric.kodo.ee.EEPersistenceManager.rollback(EEPersistenceManager.java:169)
2002-10-31 20:54:10,156 ERROR [STDERR] at
com.gulfnet.usermanager.UserManager.deleteGroup(UserManager.java:775)
2002-10-31 20:54:10,156 ERROR [STDERR] at
com.gulfnet.common.actions.GroupAction.deleteObject(GroupAction.java:146)
2002-10-31 20:54:10,171 ERROR [STDERR] at
com.gulfnet.common.actions.GroupAction.doAction(GroupAction.java:58)
Kam

Forgot to add that I am using SQLServer 2000, Jboss 3.0.3 and Kodo 2.3.4
Kam

Two different ways to execute a custom method in an Application Module

I have a custom method exposed in an Application Module's Client Interface, and i know two different ways of executing it from my ADF Faces project (both works fine):
1) Calls the method directly through the Data Control:
MyModule service = (MyModule)JSFUtils.resolveExpression("#{data.MyModuleDataControl.dataProvider}");
service.myMethod();
2) Adding a Method Action in the PageDef's file:
<methodAction id="myMethod" InstanceName="MyModuleDataControl.dataProvider"
DataControl="MyModuleDataControl" MethodName="myMethod"
RequiresUpdateModel="true" Action="999"
IsViewObjectMethod="false"/>
//Call the method from the binding container
BindingContainer bindings = getBindings();
OperationBinding operationBinding = bindings.getOperationBinding("myMethod");
operationBinding.execute();
Basically i want to know: what are the differences (pros & cons) of each approach ??

Hi,
In my opinion the second way have a advantage, which its method could be invoke automatically using a invokeAction on pageDef, if necessary.
regards

Different behaviour in MAX vs. LabVIEW when writing to IMAQdx GigE attribute

Hi, I am controlling a Dalsa GigE camera in LabVIEW RT using IMAQdx. Apart from a couple of quirks with the interface we are acquiring images without much problems at the moment.
However, there are one or two issues that are confusing us. In this case, it is possible to set an attribute in MAX (a command attribute that instructs the camera to perform internal calibration) but when setting the same attribute in LabVIEW the error 0xBFF69010 (-1074360304) Unable to set attribute is thrown. See attached images.
I check whether the attribute is writable before attempting a write. It is, however the write is unsuccessful and reading the iswritable attribute then returns false. In MAX I can write to this attribute without any issues.
Is there anything that I need to configure/read/write in my LabVIEW code that MAX does. Does MAX write to all attributes (based on the values in the XML file) when it opens the camera or does it simply read all the values from the camera. When LabVIEW opens a camera reference does it perform the same steps as what MAX does - I'm trying to figure out what the difference between MAX and LabVIEW could be that could be causing this behaviour.
Any help will be appreciated.
Solved!
Go to Solution.
Attachments:
Diagram.png ‏15 KB
FrontPanel.png ‏8 KB
It works in MAX.png ‏20 KB

AnthonV wrote:
Hi, I am controlling a Dalsa GigE camera in LabVIEW RT using IMAQdx. Apart from a couple of quirks with the interface we are acquiring images without much problems at the moment.
However, there are one or two issues that are confusing us. In this case, it is possible to set an attribute in MAX (a command attribute that instructs the camera to perform internal calibration) but when setting the same attribute in LabVIEW the error 0xBFF69010 (-1074360304) Unable to set attribute is thrown. See attached images.
I check whether the attribute is writable before attempting a write. It is, however the write is unsuccessful and reading the iswritable attribute then returns false. In MAX I can write to this attribute without any issues.
Is there anything that I need to configure/read/write in my LabVIEW code that MAX does. Does MAX write to all attributes (based on the values in the XML file) when it opens the camera or does it simply read all the values from the camera. When LabVIEW opens a camera reference does it perform the same steps as what MAX does - I'm trying to figure out what the difference between MAX and LabVIEW could be that could be causing this behaviour.
Any help will be appreciated.
Hi AnthonV,
"Quirky" is a good way to describe the Spyder3 when it comes to the GigE Vision/GenICam interface (as opposed to Dalsa's driver which communicates using custom serial commands to the camera over ethernet)....
The Spyder3 has a lot of timing-dependent issues. It is possible that the delay between opening the camera and setting that feature is different via MAX vs your code in LabVIEW. Also, there are certain cases where MAX will surpress the error from being displayed. Ignoring the error shown vs. not, do you see the feature take effect in either of the two cases?
The basic behavior between MAX and LabVIEW is the same. In both cases when you open the camera all the settings are loaded from our camera file which has the saved camera settings. This file is created the first time you open the camera and is updated whenever you click Save in MAX or call an API function to save the settings. In any case, I do know that the Spyder3 has various issues saving/restoring settings to our camera files.
I suggest talking with Dalsa about the issues you are having. They might be able to set you up with newer firmware that addresses some of these problems (we have worked with them in the past to identify many of them).
Eric

Different behaviour of Jcomponet's setEnable() method is required

Similar Messages

Maybe you are looking for