Deploying datasources

[meetoblivion]

So based on what I've seen, I'm inclined to say that Arquillian doesn't support @DataSourceDefinition

I assume this because I put the following in a bean, but the DS never gets deployed (even though this is getting deployed to a GFV3 env)

@DataSourceDefinition(name = "java:global/env/ServerDS",

      minPoolSize = 0,

      initialPoolSize = 0,

      className = "org.apache.derby.jdbc.ClientXADataSource",

      user = "APP",

      password = "APP",

      databaseName = "TDB01",

      properties = {"connectionAttributes=;create=true"}

   )

So what I"m wondering is if there's a best way to deploy a datasource to do some JPA testing.

[locrianmode]

For glassfish, you can specifiy the datasources in the domain.xml of your installation. So how would it work with arquillian and glassfish embedded?

Here's a short write-up (have to hack a little though). Basically, you need to tell Arqullian to run the embedded glassfish container instance from a permanent location where you can specify the domain.xml with all the datasources you want. It's not the best way but it works for me

[meetoblivion]

hmm that's actually a pretty nifty trick.  i'm not sure i like the idea of having the directory structure of glassfish in source control but other than that it looks cool.

i should be able to, in theory, point it to a real domain on the file system though?

i feel like instanceRoot should be a parameter that arquillian takes in when starting the container.  i'm currently also thinking about an issue if there's multiple unit tests running, what happens to glassfish binding on port 8080?

[aslak]

i should be able to, in theory, point it to a real domain on the file system though?

I havn't tested this my self, but i believe so.

i feel like instanceRoot should be a parameter that arquillian takes in when starting the container.  i'm currently also thinking about an issue if there's multiple unit tests running, what happens to glassfish binding on port 8080?

Working on this,  https://jira.jboss.org/jira/browse/ARQ-95,  https://jira.jboss.org/jira/browse/ARQ-33

Should be part of Alpha-2.

I'm not sure why the @DataSourceDefnition doesn't work, it shouldn't need any integration with Arquillian. I'll post back when i figure it out.

[meetoblivion]

not sure if it helps, but the datasource definition is in test.jar, the generated archive in the test case

hmm i'm seeing a weird issue, probably not related. new thread time.

[meetoblivion]

well the good thing is that the only real issue I'm seeing is that the generated test.ear doesn't always get cleared out.  as a result, i sometimes have to delete it myself.

a nifty work around is to just lookup the EJB by itself, since arquillian doesn't inject singletons/no interface beans.  file system approach is working well though, if a bit slow.

[meetoblivion]

alright, another interesting side effect of this.

CDI injection points are being processed correctly for beans defined in src/main.  They are not being processed correctly for src/test.

E.g. I have a bean (in my real code) that has something like

@Inject AnotherBean anotherBean;

and it gets injected properly (I can see log messages stating so)

But if I do the same thing in my test, it's null.

it's something w/ glassfish, as I have another project that was running against weld, running the UT against Weld SE works.  Running them against glassfish fails.

[locrianmode]

John Ament wrote:

But if I do the same thing in my test, it's null.

it's something w/ glassfish, as I have another project that was running against weld, running the UT against Weld SE works.  Running them against glassfish fails.

Thought I read somewhere in the Arquillian spaces that CDI is not  working yet for glassfish embedded.

It's somehow related to this glassfish issue . Watching it

[aslak]

The Arquillian Glassfish CDI issue is related to this issue:  https://glassfish.dev.java.net/issues/show_bug.cgi?id=11497

The issue is fixed in the latest 3.0.1/3.1 nightly builds of Glassfish, but I've had problems verifying the fix due to some completely unrelated startup issue with Glassfish.

[aslak]

What kind of 'bean' are you adding the DataSourceDefinition annotation to? EJB, CDI, JSF?

As far as I could read from the EE spec it's suppose to be a EE managed component in a EE module.

That means on a EJB, Servlet, ServletListener or Application Client in a EJB Jar, War or Client jar.

A CDI Bean Archive (any jar with beans.xml in it) is not defined as a EE Module.

[meetoblivion]

this is being attached to an EJB.  the archive should be getting acknowledged as an ejb archive as it has an ejb-jar.xml in it, with 3.1 listed as the version.  this is test.jar though.

[meetoblivion]

Aslak Knutsen wrote:

The Arquillian Glassfish CDI issue is related to this issue:  https://glassfish.dev.java.net/issues/show_bug.cgi?id=11497

The issue is fixed in the latest 3.0.1/3.1 nightly builds of Glassfish, but I've had problems verifying the fix due to some completely unrelated startup issue with Glassfish.

as far as this goes, i just tried against 3.1 snapshot (from april 2) and it's still failing.  EJB tests passed.

or do i need to get the nightly from somewhere else?