On 02/24/10 08:21, Dan Labrecque wrote: > I'm looking at an apache bug (9316), which claims IP addresses are not > validated remotely. The bug report suggests that "the firewall panel > currently employs a NetworkingMXBean that perhaps should be made > generally available and used here". I was under the impression that the > introduction of rad already made code generally available to all panels, > but I've discovered a couple issues.
The server technology actually didn't change anything here. Making an API generally available has two parts: The first part is a functional one -- we need to make sure the API is indeed available. Technically it can be accessed by anyone who knows it's there, but we also need to make sure it is there when it needs to be (i.e. we need the correct package dependencies), and make sure any client-side code is put in a common location for use by multiple consumers. The second part is a logical one -- we need to decide and declare that the API is serving a general purpose, and that its evolution will determined not by the panel that originally introduced it, but by general requirements. This can a functional impact: we might decide that the interfaces need to change to meet the general need. > 1. Bean interfaces generated by ...apis/*.xml are still placed in a > separate jar files for each panel. > > In order to use NetworkingMXBean and NetworkingUtil from the firewall > panel, I need to include vpanels-panels-firewall.jar in the java > classpath. I modified the build.xml file to include that; however, I > don't see a way to declare a build dependency to ensure firewall is > built prior to apache. It appears that panel directories are built > recursively (i.e., the build iterates over any/all directories in > ...java/vpanels/panels). > > 2. Even after a successful build, I still get a NoClassDefFoundError > exception when launching the apache panel. Obviously the > vpanels-panels-firewall.jar file was not available during runtime. Is > there a way to modify the build to include this jar? How is the rad jar > file made available during runtime? > > That said, I suspect that the build environment isn't setup to handle > this scenario. Thus, any classes I need must be contained in the same > vpanels-panels-apache.jar. I can duplicate NetworkingMXBean > functionality in apache, but thought I'd try to reuse code first. Any > suggestions on how to make bean code generically available? Rather than have panels reference other panels' implementations, these interfaces should move go into a common location, such as vpanels-panel. We'll eventually need to make vpanels-panel less monolithic (to make it less unwieldy and to handle versioning), but until then it's the best place. Dave
