undeploy bug

[baal]

Hi everbody ! There is a little bug in ui-fw. When I remove
AbscenceRequest from the /var/deploy, it seems to be undeployed
correctly from ode, but it's always in the process list of ui-fw. If
we click on it, the xform is correctly drawed, but when we click on
send, of course it fails. If re-put the AbscenceRequest directory into
the /var/deploy, it's correctly re-imported (the date in ui-fw process
panel has changed), and the workflow is working nice.

So, is anybody can correct this bug, or say to me how to do ?

Thanks in advance.

[Antoine Toulme]

This is not a bug - rather a limitation of the current approach. The lifecycle of a form is not paired to the lifecycle of the process.

You need to remove forms manually.

Thanks,

Antoine

--
You received this message because you are subscribed to the Google Groups "tempo-dev" group.
To post to this group, send email to temp...@googlegroups.com.
To unsubscribe from this group, send email to tempo-dev+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/tempo-dev?hl=en.

[baal]

I have readed the code, and I saw something that let me think that is
perhaps a bug.

let me explain :

The Abscence request contains 3 directory, one for pipa, one for ode,
and one for xform.

The DeploymentServiceImpl have a scan() method that check new
directories, and deleted ones. If it detect at least one deleted dir,
it call the undeployAssembly method. This method get each
ComponentManager for the assembly, and then call the
ComponentManager.undeploy.

The undeploy work for ode. But As I can always see the Task in UI-FW,
I have supposed that the problem was in tms.

In TMS , we have a PIPAComponentManager, called as described before.
In the undeploy method we see :

String assembly = name.getAssemblyId().getAssemblyName();
HashSet<AssemblyId> set = _versions.get(assembly);
if (set == null || set.size() < 1) {
// if set is equal to 1, we have one more version remaining.
// fix for WF-1324
....

I don't really understand the goal of this test. If a replace the
condition with " if (set == null || set.size() <= 1) " it's working,
the task disappear from ui-fw when I remove the AbscenceRequest
directory.
What's the fix WF-1324 ? The _version hashSet if filled by the deploy
method of ComponentManager :

public void deployed(ComponentId name, File path, List<String>
deployedResources, boolean active) {
// increment number of versions for the given assembly
String assembly = name.getAssemblyId().getAssemblyName();
HashSet<AssemblyId> set = _versions.get(assembly);
if (set == null)
set = new HashSet<AssemblyId>();
set.add(name.getAssemblyId());
_versions.put(assembly, set);
}

What's the real goal of this : set.add(name.getAssemblyId()); ?

On 9 mar, 18:36, Antoine Toulme <antoine.tou...@gmail.com> wrote:
> This is not a bug - rather a limitation of the current approach. The
> lifecycle of a form is not paired to the lifecycle of the process.
>
> You need to remove forms manually.
>
> Thanks,
>
> Antoine
>

> On Tue, Mar 9, 2010 at 06:05, baal <yann.blaz...@gmail.com> wrote:
> > Hi everbody ! There is a little bug in ui-fw. When I remove
> > AbscenceRequest from the /var/deploy, it seems to be undeployed
> > correctly from ode, but it's always in the process list of ui-fw. If
> > we click on it, the xform is correctly drawed, but when we click on
> > send, of course it fails. If re-put the AbscenceRequest directory into
> > the /var/deploy, it's correctly re-imported (the date in ui-fw process
> > panel has changed), and the workflow is working nice.
>
> > So, is anybody can correct this bug, or say to me how to do ?
>
> > Thanks in advance.
>
> > --
> > You received this message because you are subscribed to the Google Groups
> > "tempo-dev" group.
> > To post to this group, send email to temp...@googlegroups.com.
> > To unsubscribe from this group, send email to

> > tempo-dev+...@googlegroups.com<tempo-dev%2Bunsu...@googlegroups.com>

[baal]

Why nobody answer me ?

> > > tempo-dev+...@googlegroups.com<tempo-dev%2Bunsubscribe@googlegroups .com>

[Antoine Toulme]

We're busy.

The problem described in WF-1324 is related to a complex scenario:

deploy twice a process (two versions of a process)

undeploy the first version of the process

it will undeploy the forms too.

So WF-1324 fixes that. Do you have a better fix for it ?

Thanks,

Antoine

To unsubscribe from this group, send email to tempo-dev+...@googlegroups.com.