Yeah, wasted the weekend on this myself.
I never had problems with @Stateless beans being found and deployed. I only had problems once those beans started hitting JPA. I went through many iterations of installroot/instanceroot and they all sucked.
My project is pretty simple (it was just to preflight GFv3 for deployment and testing before moving from Hibernate/Spring/Tomcat) and is exclusively maven.
I haven't had a chance to post cleaned up version of it to see if others are having similar problems.
Please post your success/failure when you get the chance.
greg
On Apr 7, 2010, at 15:02, glassfish_at_javadesktop.org wrote:
>> I agree it's horrific but it got rid of a bunch of
>> crappy code that I'd have to maintain.
>
> I hear you there. :-)
>
>> It wasn't a straightforward search (I meandered
>> through a bunch of pages for a couple days before I
>> found it):
>>
>> http://blog.blackbit.be/?p=5
>
> But even here he's indicating that the domain.xml file solves a JPA integration problem, not a classpath scanning problem. That is, before he put the domain.xml down, he could (presumably) get the EJBContainer to find his EJBs. I can't do that, with exactly his code. The only thing that has changed is that I am depending on v3.0.1b02, not b74 as he has in his example.
>
> I think I'm going to make a dirt simple maven project that manifests this problem and file it as a critical showstopping bug, because at least that way someone else can reproduce it and explain to me how all these tutorials have it wrong. Man, what a frustrating day.
>
> Thanks again.
> [Message sent by forum member 'ljnelson']
>
> http://forums.java.net/jive/thread.jspa?messageID=395778
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: users-help_at_glassfish.dev.java.net
>