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