[cosmo]

Another thing that comes to my mind is if Jboss AS and the OS have the same config in every instance.

So in order to test this out you'd need to copy Jboss AS from your dev instance to your integration instance.

If it fails you will know for sure that the problem is outside Jboss, maybe an OS or network constraint. Else, the problem is within JBoss AS configuration.

[caffeineborg]

Aldo,

Thanks for sticking with this -- no solution yet.

I did pull over the dev JBoss tree and got the same results. 

  This had initially lead me to thinking it was a 64-bit issue.  My hesitation is due to the fact I would expect a different kind of result -- like not working ... an error that says ~~"can not run that here on a 64-bit ... blah blah"

I am swimming here as the error has lead to no details that aid in resolution. 

Can there be other places to turn up logging/debugging? 

  Are there any suggestions where to look? 

Have a great day

[caffeineborg]

What configuration details or files or setup would effect this?  Like specifically where would I look?  In a JBOSS.xml file (example) or a dir for certain .jars (where?)?

As a note to above the dev and QA are 32 bit and production / integration are 64 bit. 

my continued gratitude for your feedback

[cosmo]

Java's main benefit: code once, run everywhere, which should mean that a JDK's produced bytecode should work in every JRE.

According to what you are saying I am inclined to think that the problem is outside JBoss AS/Seam because the very same JBoss AS work in one place and then fails in another.

For this reason I would check the following things
- Does JBoss AS start with no errors when no ear or war is deployed?
- Does the user that execute JBoss AS has enough privileges?
- Are any of the ports that JBoss AS uses already being used by other process?
- Is your prod/integration RDBMS listening on the same port?
- Is the target DB already created in the prod/integration RDBMS?
- Is your prod/integration RDBMS authentication mode correct?

[caffeineborg]

I may note be totally out of the woods but the integration environment (post the db changes (alter table ...)) will run the applicaiton wth the code changes --> the .ear file deploys.

Based on the discovery that database structure is different I have a LOT of QA to do.

A quick summary:

new .ear file deployed against differnet datbase strutures created the error that the component could not instantiate (ear file not deployed).

It was the database -- I was living in a  false impression I had code and structure that were what ran in production. 

The access was correct and the application user had the correct privileges.  The core element is that the code and database structure I was given and enhanced where not what was in production.  The previous team did not delivery the correct resources. That is my fault for not digging into the database. I did not correctly connect the dots. 

I am thankful for your attention and questions.  It was in fact an issue the the production environment and the code base where out of sync.   Specifically, there was a change in the database structure (two column changes of note (longtext changed to varchars) that were not documented.


  Your notice helped me look at an area (database structure) that I was not treating as part of the variables.  I had made code changes that worked in dev and QA (extrapolation should work in production) and I was working on the premise that the code base was what was in production, that was not the case.

  Let me know if it would be instructive to add more to this thread.

I thank you again and hope your weekend is great.