I found the problem. One of the library modules had an empty EJB in it
(basically @Stateless public class ExampleEJB{} ).
The entire project has no issues with this extra ejb until the war was
introduced. My guess is that Glassfish should be changed in one of two
ways:
a) Glassfish should throw an exception when a shared library jar contains
any EJBs (if that isn't allowed by the ear packaging spec).
b) Glassfish should correctly allow redeployment of an exploded ear without
restart even if an EJB exists in a shared library jar.
Either approach could help avoid unnecessary frustration in the future.
Thoughts?
Jacques
On Sat, Mar 6, 2010 at 12:09 PM, Jacques <whshub_at_gmail.com> wrote:
> This makes the next deploy successful. However, if I try to undeploy and
> redploy the next time, it gives the same error. I'm trying to avoid having
> to undeploy, shutdown, remove all the generated files, restart, and redeploy
> every single time I want to redeploy. Is there a way to avoid this error
> all together? What causes it?
>
> Thanks for your help,
> Jacques
>
> On Sat, Mar 6, 2010 at 10:47 AM, Dominik Dorn <dominik.dorn_at_gmail.com>wrote:
>
>> undeploy your app,
>> stop glassfish
>> remove all folders&files in
>> glassfishhome/glassfish/domains/domain1/generated
>> start glassfish
>> deploy your app.
>>
>>
>>
>> --
>> [url=http://www.dominikdorn.com]Dominik Dorn[/url]
>>
>> Tausche Deine [url=http://www.studyguru.eu] Lernunterlagen auf
>> http://www.studyguru.eu[/url]!
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe_at_glassfish.dev.java.net
>> For additional commands, e-mail: users-help_at_glassfish.dev.java.net
>>
>>
>