glassfish log kérdés

Fórumok

Sziasztok!

Egy probléma miatt túrom a glassfish logját, és az alábbi sort nem tudom hová tenni (többször is szerepel, sokszor egymás után)
[#|2009-06-04T06:12:56.471+0200|WARNING|sun-appserver2.1|javax.enterprise.system.container.ejb|_ThreadID=51;_ThreadName=TP-Processor7;_RequestID=17788e7f-771f-4c18-b241-0b62aa7ee9c1;|AccountHandlerBean: Cannot update timsestamp for: 4b90c2aa00e41f-ffffffff87cf6834-0; File does not exist|#]

(Az AccountHandlerBean Account entitásokat kezeli, az Account-nak van
@Column(name = "reg_date")
@Temporal(TemporalType.TIMESTAMP)
private Date regDate;
ilyen mezője, de file művelet az nicns egy szálse.)

Ez az a kategória hogy sz@rni rá, vagy kétségbe kell esni?

szerk.:
a másik:
[#|2009-06-07T07:01:05.433+0200|WARNING|sun-appserver2.1|javax.enterprise.system.container.ejb|_ThreadID=69;_ThreadName=p: thread-pool-1; w: 5429;_RequestID=1150328d-b6a6-4064-a1b2-462e3b355b0a;|AccountHandlerBean [InternalError] isNew() must be true for: 4b90c2aa00e41f-ffffffff87cf6834-1|#]

én nem írtam isNew() függvényt (az egész projectben egy darab ilyen függvény sincs) és ebből a hibaüzenetből meg sem tudom állapítanim, hogy hol keressem.

a harmadik:
[#|2009-06-08T05:26:50.718+0200|SEVERE|sun-appserver2.1|javax.enterprise.system.container.ejb|_ThreadID=65;_ThreadName=TP-Processor22;_RequestID=9de6ead2-5c8f-44ab-a8df-f34e6d70249e;|NRU-hu.oditech.millisoap.accounts.AccountHandlerBean: Cannot load from BACKUPSTORE FOR Key: <4b90c2aa00e41f-ffffffff87cf6834-f>|#]

erre meg lövésem sincs :(

Köszönöm az építő hozzászólásokat előre is.

Hozzászólások


[#|2009-06-08T05:26:50.718+0200|SEVERE|sun-appserver2.1|javax.enterprise.system.container.ejb|_ThreadID=65;_ThreadName=TP-Processor22;_RequestID=9de6ead2-5c8f-44ab-a8df-f34e6d70249e;|NRU-hu.oditech.millisoap.accounts.AccountHandlerBean: Cannot load from BACKUPSTORE FOR Key: <4b90c2aa00e41f-ffffffff87cf6834-f>|#]

az AccountHandlerBean a fenti log alapján nem glassfish componens

Peter
http://sunblog.hu/

Szerintem valamelyik metodusod neha RuntimeExceptiont dob, melynek hatasara az ejb bean eldobodik igy a kovetkezo hivasnal nem talalja (a backup store-ban sem, ahova passivate-kor tenne), ekkor irja ki a hibakat, a hatterben kozben csinal ujat, ezert nem latsz semmi kezzel foghatot.
De nem is ertem miert Stateful ejb-t hasznalsz, nincs allapota a bean-ednek, probald meg Stateless-szel.