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.

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
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.

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.

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
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.

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?

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.

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...

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.

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.