I began stripping down the code to make a simple test case and found
something I was missing. I had added the connection pool and jdbc resource
to the resources element BUT I failed to add a resource-ref element to the
server element. Once I added a resource-ref the datasource became visible
and both code that programmatically looked up the datasource as well as the
reference in the persistence.xml began to work.
Thanks for the help, very much appreciated!
- Phillip
On Wed, Mar 2, 2011 at 1:30 AM, Jagadish Prasath Ramu <
jagadish.ramu_at_oracle.com> wrote:
> Hi Philip,
>
> Could you please send us a sample test-case and the exact steps you have
> followed (including the domain.xml that you use) so that we can see
> what's going on ?
> --
> Thanks,
> -Jagadish
>
> Sun, an Oracle Company.
>
>
> On Wed, 2011-03-02 at 00:01 -0500, Phillip Ross wrote:
> > Actually, I did try the default datasource since there is mention of
> > it in the 3.1 embedded documentation, but when I try to look it up, I
> > get derby errors... most likely because derby is not in the classpath
> > but havent verified that. I'm using postresql and those jdbc drivers
> > are definitely in the classpath. I did have some thoughts about
> > attempting to point the defined default datasource at the postgresql
> > connection pool and see if that has any interesting effect, but
> > figured that it might break something else that relies on the default
> > datasource and derby being in place. I guess I'll try that next to
> > see what happens just to get the datapoint. I'll let you know what
> > happens.
> >
> >
> > Thanks!
> > - Phillip
> >
> > On Tue, Mar 1, 2011 at 10:41 PM, Marina Vatkina
> > <marina.vatkina_at_oracle.com> wrote:
> > Hi Phillip,
> >
> > Does it work if you use jdbc/__default (or comment out the
> > jts-data-source in persistence.xml)? May be the database
> > driver is not in the classpath?
> >
> > -marina
> >
> > Phillip Ross wrote:
> > Hi Marina, thanks for your response.
> >
> > I did make sure the names were the same. When this
> > was all initially working against 3.0.1 I was just
> > using a name such as "jdbc/test_ds" which uses no
> > global naming syntax or anything. The persistence.xml
> > used this name as well. With 3.0.1 I was also able to
> > programmatically get a reference to the datasource by
> > obtaining a context from the ejb container reference
> > and doing a lookup.
> >
> > When working against 3.1, I initially tried without
> > any prefixes but was not able to do a programatic
> > lookup nor have persistence.xml find the datasource.
> > If I remove the persistence.xml I'm NOT able to find
> > the datasource with a lookup.
> >
> > The database is definitely up and running. In
> > searching for answers I found two links on a java
> > howto blog which both work:
> >
> http://javahowto.blogspot.com/2011/02/ejb-lite-jpa-datasource-embedded-in.html
> >
> http://javahowto.blogspot.com/2011/02/glassfish-embedded-jpa-ejb-datasource.html
> >
> > They both work so I know database connectivity is at
> > least possible, though the examples are using
> > application scoped resources which seem to not work
> > for me either :(
> >
> >
> >
> >
> > On Tue, Mar 1, 2011 at 9:31 PM, Marina Vatkina
> > <marina.vatkina_at_oracle.com
> > <mailto:marina.vatkina_at_oracle.com>> wrote:
> >
> > Hi Phillip,
> >
> > Did you try the name that you gave it in the
> > jdbc-resource
> > definition, without any prefixes? Can you look up
> > this resource in
> > your code if you remove persistence.xml? Is your
> > database up and
> > running?
> >
> > -marina
> >
> >
> > Phillip Ross wrote:
> >
> > Hi all,
> >
> > I've been working on updating code bases from
> > 3.0.1 to 3.1 and
> > am having problems getting the embedded ejb
> > container to work
> > in unit tests. The existing code simple
> > defines a domain.xml
> > that was sort of hacked from an existing 3.0.1
> > installation
> > which contained a connection pool and jdbc
> > resource definition
> > of the database being tested against. This
> > works great with
> > 3.0.1.
> >
> > Now with 3.1 I took the domain.xml file that
> > was referred to
> > in the 3.1 embedded documentation, added the
> > jdbc connection
> > pool and resource definitions, but the
> > datasource is not
> > found. When the createEJBContainer method is
> > invoked, it
> > returns a null reference, and there are stack
> > traces with
> > naming exceptions explaining that the
> > datasource name which is
> > defined in the persistence.xml is not found. I
> > tried various
> > naming schemes for the datasource such as using
> > java:global,
> > java:app, and java:module prefixes, but none of
> > those make a
> > difference. I also tried creating a
> > glassfish-resources.xml
> > with the pool and datasource definitions in the
> > META-INF dir
> > beside the persistence.xml and tried various
> > naming schemes
> > for the datasource in there... but no luck. If
> > I remove the
> > persistence.xml, I get a container reference
> > that I can use to
> > get a jndi context and lookup the stateless
> > ejbs, so I'm
> > fairly certain this is a datasource resolution
> > issue. I know the domain.xml file is being
> > parsed, as other errors
> > are shown when I induce malformed xml elements
> > in the file, it
> > just seems as if the datasource is not visible
> > to the code.
> > Is there anything else I can do to narrow down
> > the problem or
> > identify the issue? I'm out of ideas.
> >
> > Thanks
> > - Phillip
> >
> >
> >
> >
> >
>
>