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.
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.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.
Created attachment 21088 [details]
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
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.
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.
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
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.
If you open the log on deployment and execution as part of this fix, you may
also be able to mark issue 55239 fixed.
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
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.
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
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.
Iteam agreed for p3 nb.
Adding the RELNOTE keywork per team agreement.
Ludo, could this bug be fixed in Appserver 8.1 ur2 ?
I'll ask, but I am afraid not...
Let's wait and see...
Well, my big issue if that the deployment does not fail!!! so I cannot emit a
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
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
a P2 for the ejbjar project... Could you have someone seeing if this could be done?
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
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...
What should happen, if verification fails? Some warning dialog? Jirko, can you
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
all the cases that may get wrong. Marking as 4.1_WAIVER_REQUEST.
Adding docs guys.
CR 6254405 has been filed on app server side...
It will be evaluated for the 8.1 UR2 release.
*** Issue 60733 has been marked as a duplicate of this issue. ***
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.
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.