This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.

Bug 56910

Summary: App server is restarted when the EJB module isn't loaded
Product: javaee Reporter: Petr Blaha <blaha>
Component: EJB ProjectAssignee: Martin Adamek <madamek>
Status: RESOLVED WONTFIX    
Severity: blocker CC: geertjan, jkopsa, johnjullion, pjiricka
Priority: P2 Keywords: RELNOTE
Version: 4.x   
Hardware: All   
OS: All   
Issue Type: DEFECT Exception Reporter:
Attachments: test application

Description Petr Blaha 2005-03-24 09:44:19 UTC
[Build 200503221]
Steps:
1) open attached application in NB
2) deploy module to App server
3) everything is OK
4) change void debit(BigDecimal amount) throws InsufficientBalanceException,
java.rmi.RemoteException; method in SavingsAccountRemoteBusiness interface. 
Remove RemoteException.
5) Clean and build and deploy module few times.
6) App server is restarted after every deployment 
In app server's log is error:
UnExpected error occured while creating ejb container
java.lang.IllegalStateException: Method 'public abstract void
bean.SavingsAccountRemoteBusiness.debit(java.math.BigDecimal) throws
bean.InsufficientBalanceException' must throw at least one exception of type
java.rmi.RemoteException or one of its super-classes

This behavior is non-permissible from user's point of view. Since, he gets info
about successful deployment in output tab and server is restarted.
Comment 1 Petr Blaha 2005-03-24 09:45:16 UTC
Created attachment 21088 [details]
test application
Comment 2 _ ludo 2005-03-24 12:25:05 UTC
It might not be permissible, but deploy and execution are 2 things for the
appserver backend and we cannot fixe this beahvioour:
a sucessfull deploy can happen, and an execution can fail.
Execution failures are in the log file, so to mitigate the feedback we could
shown the log file always.
For the app server restart issue, again there might bre little we can do as the
restart flag is set by the backend it self. If the app aserver thinks it needs
to restart, we cannot fix that with the current shipping app server.
I'll invesitgate more with backend people.

This error could be detected by the j2eeserver or ejb project itself before
doing a deployment.
Then the issue if how much time can we spend in pre-verification of apps before
deployment.
The user can always run the verifier, but as you know it takes a long time, and
it;s not good to do that most of the time.
Comment 3 Petr Blaha 2005-03-24 13:38:11 UTC
Ludo, this behavior is confusing and time consuming (restart server before every
starting module). User doesn't know why the server is restarted. Similar issue
was reported by John before beta release. His app server was restarting before
every depolyment. Nobody din't know definitive reason of this. 

I agree with you that is the bug in App server itself. Fix the issue in App
server is only one right way. This is also evidence that we shall make some
effort in a good log viewer. 
Comment 4 _ ludo 2005-03-25 01:59:59 UTC
The restart issue is now solved: it was caused by the re-regsitration os the
server resources at every deploy time, and this would cause a server restart
flag tro be turned on.
We now do a diff between the registered resources and the ones in the project,
so if they do not change, there is no restart involved anymore. This is
integrated now.


What I am doing also is that a deploy action will display the log file (only
local mode) so that load errors can be seen by the user.

After that, I think the bug can be closed.
Comment 5 Rochelle Raccah 2005-03-25 02:07:16 UTC
If you open the log on deployment and execution as part of this fix, you may 
also be able to mark issue 55239 fixed.
Comment 6 _ ludo 2005-03-25 06:04:13 UTC
Only remaining thing is in case the log file view is closed after atarting the
server, it is not opened again at deploy time.
Will fix soon, but not p2 anymore, as most of the issues related to this are
addressed.
Comment 7 Petr Blaha 2005-03-29 09:35:59 UTC
I was able to reproduce the issue in daily build 20050328. I used attached
project with removed java.rmi.RemoteException exception from debit method. The
App server is restarted for every module execution.
Comment 8 _ ludo 2005-03-29 15:38:48 UTC
This is a backend bug...
When running the verifier from the IDE, we have this error message:

"For [ SavingsAccount#SavingsAccount#SavingsAccountBean ]
For remote interface [ bean.SavingsAccountRemoteBusiness ] method [ debit ]
Error: [ debit ] method was found, but does not properly throw
java.rmi.RemoteException.
"

So We suggest to add a display message whenever there is a deploy error to
mention the fact that the user should run the inegrated J2EE verifier to have
more details about why the archive can not be deployed.
Comment 9 _ ludo 2005-03-30 06:05:06 UTC
Iteam agreed for p3 nb.
Comment 10 Petr Jiricka 2005-03-30 12:27:56 UTC
Adding the RELNOTE keywork per team agreement.
Comment 11 Petr Jiricka 2005-03-31 07:35:27 UTC
Ludo, could this bug be fixed in Appserver 8.1 ur2 ?
Comment 12 _ ludo 2005-03-31 12:37:03 UTC
I'll ask, but I am afraid not...
Let's wait and see...
Comment 13 _ ludo 2005-03-31 16:32:59 UTC
Well, my big issue if that the deployment does not fail!!! so I cannot emit a
message there..
The failure occurs at application load time, and this is only displayed in the
server log file.....

Might have to move to P2, and either waive/document, or escalate with app server
org....
On NetBeans side, I really think this test about a remote method not throwing a
remoteException should be detected by the IDE before the deployment, so this
would be
a P2 for the ejbjar project... Could you have someone seeing if this could be done?
Comment 14 Petr Jiricka 2005-04-01 12:42:44 UTC
Agreed this is really a P2, changing priority accordingly. I am reluctant to add
some error detection mechanism to EJB project, because we don't know what are
all the cases that may get wrong. A remote method not throwing a RemoteException
could be just one of many possible cases. Let's discuss more in the next week's
meeting.
Comment 15 _ ludo 2005-04-02 20:08:26 UTC
Moving to ejbproject for an evaluation of this:
Could be, before creating the ejb jar achive, run a small test, that would look
for remote ejbs, and see if all their methods correctly throw a remoteexception?

It is hard to do, using MDR? and fast?
I know we cannot check for everythig, but for that, the AS 8.1 backend is not
smart at all, so this would clear user confusion a lot to detect early...
Comment 16 Martin Adamek 2005-04-04 16:06:42 UTC
What should happen, if verification fails? Some warning dialog? Jirko, can you
comment?
Comment 17 Martin Adamek 2005-04-06 15:23:53 UTC
i-team agreed to waive this one. Problem is on app server side and should be
fixed there. We don't want to make additional validations because we don't know
what are
all the cases that may get wrong. Marking as 4.1_WAIVER_REQUEST.
Comment 18 Martin Adamek 2005-04-11 09:59:22 UTC
Waiver approved.
Adding docs guys. 
Comment 19 _ ludo 2005-04-13 01:46:59 UTC
CR 6254405 has been filed on app server side...
It will be evaluated for the 8.1 UR2 release.
Comment 20 Vince Kraemer 2005-07-05 17:13:17 UTC
*** Issue 60733 has been marked as a duplicate of this issue. ***
Comment 21 Vince Kraemer 2005-07-06 18:40:42 UTC
This needs to get addressed.

We are seeing bugs getting filed with the same root cause against the plugin.

I also ran the following test:

I created two ejb modules.  One that is similar to the module in
SavingsAccount.tar.gz called 'Bad' and another module that did not have the
coding error (missing RemoteException declaration) that I called 'Good'.

If I deploy Bad, the server restarts on the next deploy (of either of the two
EJB Modules).  This may be contributing to the behavior mrkam claims to be
seeing in issue 60733.
Comment 22 Vince Kraemer 2005-07-20 23:56:59 UTC
*** Issue 60733 has been marked as a duplicate of this issue. ***
Comment 23 Petr Blaha 2005-08-16 15:40:39 UTC
The issue isn't bug in Netbeans itself and bug CR 6254405 for App server is
accepted and will be resolved in release 9.0. Therefore, I marking issue as wontfix.