BZ 973415

Lukas Krejci lkrejci at redhat.com
Wed Jun 12 15:18:13 UTC 2013


On Wednesday, June 12, 2013 10:22:24 Jay Shaughnessy wrote:
> This sounds like a bug in AS5/6 to me.  It creates the config file when
> adding a NEW entity,  but doesn't remove it when deleting that entity.
> And then blocks you from re-creating that entity because it didn't clean
> it up.  That is what you are saying, I think.   The file then can hold
> configuration for an entity no longer found in the internal data
> structures...
> 

Well, internally, AS considers the datasource/queue/topic/whatever a 
"component". Components are contained in "deployments".

The config file is considered a "deployment". So it is easily possible to 
delete the config file if it'd contain 0 components after the removal.

The reason AS doesn't clean up (I think) is because, generally, the 
"deployments" can contain any number of components and can be named 
artbitrarily. So I can have "my-service.xml" which would contain definitions 
of 5 datasources, 15 queues and 1 topic. I'm not sure if it is OK to delete 
that config file if the user removes all 21 components from the AS 
configuration. I mean, logically it is, but it is not how AS5/6 behaves.

On contrary, it makes absolute sense to delete it if the config file was 
created as a result of the deployment of the component through the API and 
thus contains only the single component.

I mean, this definitely is AS's mess, but the question is what should we be 
doing about it. If we had a way of distinguishing between an auto-created 
config file and user deployed config file, I'd probably not ask this question, 
but there doesn't seem to be a way.

> Is there a way to actually determine the file so that we can clean it up
> manually?  I wouldn't put too much stick in the AS5/6 philosophy, that
> philosophy resulted in a total redesign in AS7. I'd say clean it up if
> possible, the delete/recreate scenario is not that uncommon.
> 
> On 6/12/2013 7:22 AM, Lukas Krejci wrote:
> > While looking at the $SUBJECT, I've come across an interesting problem
> > that I don't have a clear answer for.
> > 
> > The problem in the BZ is that in AS5/6, you can configure any type of
> > "entity" (datasources, connection factories, queues, topics, ...) in any
> > number of (almost) arbitrarily named configuration files in the deploy
> > directory.
> > 
> > Now if you create a NEW entity using API (ProfileService of AS5/6) (i.e.
> > not by directly placing a config file into the deploy directory), the API
> > will create a new config file to place the configuration in for you.
> > 
> > Now if you delete entity (again, using API), you may end up with a
> > configuration file in the deployment directory that is essentially
> > ineffective - AS doesn't change the contents of the file but records the
> > changes made to it in its internal data structures.
> > 
> > The problem with that is that when you try to re-create the entity in such
> > a way that the AS APIs would want to put it in the same configuration
> > file as before, you'll end up with an error. The ineffective deployment
> > (of which the configuration file still hangs around in the deploy dir)
> > prevents the new one from being created.
> > 
> > Now to the question I don't have a definitive answer for.
> > 
> > Is it OK to automatically REMOVE the ineffective deployments?
> > 
> > First I thought, that yes of course it is, they don't contribute to the
> > configuration of the server so why should they take up the place in the
> > deploy dir?
> > 
> > But then I realized that it is the philosophy of AS5/6 to NOT TOUCH the
> > deploy dir and only record the changes to the files in the internal data
> > structures. If a user had a user-defined config file with a bunch of
> > entities in it, once s/he removed all of the entities originally present
> > in the config file, we'd delete the config file itself.
> > 
> > I'm still leaning towards this being OK, but at the same time I can see
> > someone being surprised about this change of behavior.
> > 
> > What do you think?
> > 
> > Thanks,
> > 
> > Lukas
> > 
> > _______________________________________________
> > rhq-devel mailing list
> > rhq-devel at lists.fedorahosted.org
> > https://lists.fedorahosted.org/mailman/listinfo/rhq-devel
> 
> _______________________________________________
> rhq-devel mailing list
> rhq-devel at lists.fedorahosted.org
> https://lists.fedorahosted.org/mailman/listinfo/rhq-devel


More information about the rhq-devel mailing list