Jdev 11.1.2.0.0 & Hot Swap

[Passmore, Richard]

Howdy,

        We have an application composed of many dozen jars that are included into a single launching application. From what I learned while playing, to use "Fast Swap", I include the project(s) that I want to use with Fast Swap, set them as dependencies (as build output) on the launching project, enable the setting, and redeploy… In SIMPLE cases, this appears to work great… Our project includes jsff and taskflows in the dependencies - I get exceptions related to not being able to find the task flows which exist in the dependent projects - works fine if I switch back to the JAR approach but, of course, that disables Fast Swap.... Has anyone encountered this scenario? If so, is there a "work around" which will let us use hot swap? At the moment, it appears for a large app like ours that Fast Swap is D.O.A. - I REALLY want it to work since it'll save us days on redeploys…  Any advice would be helpful! If I can't find a way here or, through playing, I'll have to submit a bug to Oracle...

 

Thanks,

Richard

 

 

[Aino]

Hi Richard,

As far as I know the 'fast-swap' reloads the ADF-business components and web configs at run-time in a standard ADF setup, i.e. with a model and viewcontroller project. And in this configuration it seems to work quite qell.

I'm actually not surprised that 'fast-swap' doesn't work with your setup, having taskflows in separate projects. Taskflow projects must always be included as an ADF library. Using the build output just doesn't work as expected. 

In my opinion this is still a major issue. I prefer to develop my taskflows in a modular way in separate ADF projects / applications and create ADF libraries from and have a 'super web' application that uses them (just as you described). However when you change a taskflow it must be rebuild and redeployed before you finally see the change in the 'super web'. btw, this also limits the debugging possibilities (unless you build the sources too). 

This would actually be a decent development process, but only if you could easily test the separate modules. But since page fragments cannot run on their own, you need test pages, test managed beans and other code. And since the ADF library deploy profile has limited configuration options these files are all included in the library too and may easily cause conflicts in the main superweb. It's often also a challenge to setup the test environment in the right way with all the plumbing code, especially when using the UIShell.

We do this modular approach and test the modules separately. Common plumbing code is also developed in separate projects so it can be used in both the modules and the superweb application. We've automated the build process using ant, Maven and ojdeploy to allow fast redeployment and to include the sources and javadoc for debugging purposes too.

Although this works, it's quite complex to setup (especially the automated build), it's still confusing for the developers and regularly results in conflict situations in the superweb application.

It would be great if your taskflows could also be included via the build-output option as this would make a much more comprehensible development cycle and could allow 'hot-swapping' and debugging too and without the complexity.

Ciao

  Aino

--
You received this message because you are subscribed to the ADF Enterprise Methodology Group (http://groups.google.com/group/adf-methodology). To unsubscribe send email to adf-methodolo...@googlegroups.com
 
All content to the ADF EMG lies under the Creative Commons Attribution 3.0 Unported License (http://creativecommons.org/licenses/by/3.0/). Any content sourced must be attributed back to the ADF EMG with a link to the Google Group (http://groups.google.com/group/adf-methodology).