OWF / ehcache versions

[coalesce....@gmail.com]

I am running OWF version 7.17 and am getting a

MissingMethodException
No Signature of Method
'ozone.owf.grails.domain.stack.removeFromGroups'

 In the tomcat container we have two different versions of ehcache 2.3.0 being used by OWF and 2.5.1 being used by our WARs. In out test environment due to the different versions we were unable to specify the ehcache.xml in the lib directory so we moved it down into webapps/owf/WEB-INF which worked. However in our deployment we are getting the MissingMethodException which I suspect is due to the version conflict and in the order in which the WARs are loading? The two solutions I can think of would be to either change our version of ehcache to match OWF or run them in separate tomcat containers. Has anyone experienced this issue? Can we run two different versions of ehcache in the same tomcat container?

[Ross Pokorny]

I believe that exception is related to a bug that was fixed in OWF 7.17.1,
which is currently in the Release Candidate phase. Please try your scenario
with OWF 7.17.1-RC1 and see if the problem occurs there too. If I am correct
about this then ehcache has nothing to do with it.

Ross Pokorny

[coalesce....@gmail.com]

You don't by chance know the conditions that exposes this issue? We will try the new version.

We are using puppet to deploy tomcat and our WARs. In our development environment we are not seeing this issue and I have walked through the webapps and lib folders trying to identify the difference with no luck.

Appreciate the quick response.

[Ross Pokorny]

After searching through the github tickets that were closed over the past
year, I see that I may have been mistaken about this being an issue that we
have already seen and fixed. In that case could you elaborate on what you are
seeing? What steps do you perform that lead up to this issue? Is there any
other information about the error, such as a stacktrace in the server log
files?

Note that I wouldn't necessarily think that this is a classloader issue.
Since OWF is written in groovy, which is dynamically typed,
MissingMethodExceptions are not uncommon.

Ross Pokorny

On Tuesday, December 6, 2016 5:36:47 AM EST coalesce....@gmail.com
wrote:

[coalesce....@gmail.com]

We have a tomcat server that we deploy OWF along with our WARs which are currently uber jars to avoid dependency conflicts. However OWF refuses to start due to the errors in the attached logs. My understanding is that the ehcache is shared between the wars? So my thought processes is maybe a newer version of OWF cache is being initialized and OWF is not compatible?  I know that the ehcache.xml that came with the OWF tomcat instance is not compatible with the version of ehcahe libraries that we are using which is why we had to move it down into webapps/owf/WEB-INF to avoid our WARs from picking it up.

[Ross Pokorny]

I see two separate exceptions in your logs. The first is the removeFromGroups
issue which I will address farther down in the email.

The second issue, and possibly the one which is a bigger problem, does
actually have to do with ehcache. The are a couple of caches that the app
expects to be defined in ehcache.xml. At least one of these configurations
seems to be missing, which causes a name lookup of that cache to return null,
which shortly thereafter causes a NullPointerException.

When I look closer at your description of what you have already done with
ehcache, I see that you moved OWF's ehcache.xml into webapps/owf/WEB-INF.
That is not the correct directory. To get it on the classpath it needs to be
in webapps/owf/WEB-INF/classes. I suspect that this misplacement is what is
preventing the configuration from being found and ultimately what is
preventing the app from starting.

Back to the removeFromGroups issue, that exception seems to imply that you
have at least one "App" in your database that does not have a corresponding
Default Group. I'm not sure how that would have happened but it is an invalid
state and is likely to continue causing problems in the future, even if we
work around or ignore this particular error. You said that this deployment is
in a test environment? What pre-existing database state is present when OWF
starts in this environment? Would it be feasible to blow away that data and
start over?

Ross Pokorny

On Tuesday, December 6, 2016 12:59:04 PM EST coalesce....@gmail.com
wrote:

> We have a tomcat server that we deploy OWF along with our WARs which are
> currently uber jars to avoid dependency conflicts. However OWF refuses to
> start due to the errors in the attached logs. My understanding is that the
> ehcache is shared between the wars? So my thought processes is maybe a
> newer version of OWF cache is being initialized and OWF is not compatible?
> I know that the ehcache.xml that came with the OWF tomcat instance is not
> compatible with the version of ehcahe libraries that we are using which is
> why we had to move it down into webapps/owf/WEB-INF to avoid our WARs from
> picking it up.
>
> On Tuesday, December 6, 2016 at 8:52:55 AM UTC-5, Ross Pokorny wrote:
> > After searching through the github tickets that were closed over the past
> > year, I see that I may have been mistaken about this being an issue that
> > we
> > have already seen and fixed. In that case could you elaborate on what you
> > are
> > seeing? What steps do you perform that lead up to this issue? Is there
> > any
> > other information about the error, such as a stacktrace in the server log
> > files?
> >
> > Note that I wouldn't necessarily think that this is a classloader issue.
> > Since OWF is written in groovy, which is dynamically typed,
> > MissingMethodExceptions are not uncommon.
> >
> > Ross Pokorny
> >
> > On Tuesday, December 6, 2016 5:36:47 AM EST coalesce....@gmail.com

> > <javascript:>

[coalesce....@gmail.com]

I had tried moving it down into the classes directory but it was still failing to start so I assumed it had no affect. Checking our development environment it is also in the classes directory so I moved it there again and like you said I am still getting the removeFromGroups issue. I assume the tables that would have the issue are domain_mapping and owf_groups then?

There is no preexisting database, puppet creates a fresh database during deployment which works on the development environment. This would indicate we may have an issue in our puppet configuration for our test environment which run the same scripts with different parameters. I am going to walk through the tables between development and test to see if I can locate the difference.

Thanks

[Ross Pokorny]

I agree that it sounds like there is something wrong with the database that
puppet is setting up. Does that database contain any actual data or just a
schema?

The tables that you should focus on are stack, owf_group, and stack_groups.
To explain what you should be looking for, I first need to explain that the
code that is failing is part of an upgrade mechanism for converting an OWF
7.15 or older database to an OWF 7.16 or newer database. In OWF 7.17, Stacks
(which are currently called Apps, in the UI) have a default_group column which
stores the id of the group that is part of the stack's functioning. For fully
upgraded databases, the default_group column should always contain the id of a
group and never null. Since you are just dealing with test data which you
have full control over, making sure that is true is probably your best bet.

Alternatively, older versions of OWF tracked the default group for a stack by
linking the stack and owf_group tables using a stack_groups table. This table
was used in conjunction with the stack_default flag on the group table. In
older databases, each stack should have been associated with at least one
group (via the stack_groups table) that had the stack_default flag set. In
the case of your data, it seems that neither the old way nor the new way is
true. That is, you have at least one stack that has a null default_group and
is not associated with any group that has the stack_default flag set. You
will need to adjust things so that at least one of those is true, preferably
the first.

Let me know if you have more questions there.

Also to clarify, did the NullPointerExceptions go away once you fixed the
ehcache.xml location?

Ross Pokorny

On Wednesday, December 7, 2016 5:34:48 AM EST coalesce....@gmail.com
wrote:

> > <javascript:>

[coalesce....@gmail.com]

Yeah the NPE went away.

So looking at the DB all the groups were duplicated. Somehow the DB script must have been ran twice and recreating the DB with puppet fixed the issue.

MissingMethodException sounded like a dependency conflict so I never made the connection it was an issue with our DB. I really appreciate your time and pointing me in the right direction.

Thanks!