I have these concerns: 1) Ensuring that resource properties don't persist in memory for the life of the app. Otherwise, this layer would start using a lot of memory resources. We can still use the Java class/fields generated by wsdl2java to get the data from an external source, therefore ensuring that the data doesn't persist in memory.
2) The ability to pass back properties that may only be known at runtime, so these can't be predefined in the wsdl. This expands on the resource "discovery" concept of Muse. So I was testing the approach of overriding the SimpleGetCapability methods. But as you mentioned, this bypasses the WSRP schema validator, so this may not be a good approach. The balance could be to predefine a property in the wsdl that happens to be a collection. Then, at runtime, this collection can be populated with various child properties, and then be passed to the client as a whole unit. 3) Building some kind of custom base resource class that has methods for getting the resource properties in a generic fashion. This way, all our resources can extend from this base class, and we won't need to implement anything new for each resource. In the current Muse architecture, the implementation is in a separate cability class, which would require us to define this feature in the wsdl and muse.xml for every resource. This is probably not a big deal, but anything that would help ease the development/maintenance efforts would be good. -----Original Message----- From: Daniel Jemiolo [mailto:[EMAIL PROTECTED] Sent: Wednesday, November 22, 2006 7:36 AM To: [email protected] Subject: Re: dynamic resource properties I would actually override SimpleGetCapability.getResourceProperty(), because the other two WSRP 'get' operations use getResourceProperty() as part of their implementation. So, if you override this one, you get the other two for free. This will work just fine, but I'm not sure the problem you stated is accurate. Muse reads in the WSRP document *schema* and creates data structures around it in order to provide proper WSRP behavior... but it certainly does not load your actual WSRP *document* (the thing with all of the actual names-values). The code that is generated by wsdl2java does have Java fields for each of your resource properties, but that's only because it has no other option (it has no idea what kind of technology you intend to use for state, so it just makes fields as a default). The process you're referring to is valuable in that it ensures you have setup your WSRP doc correctly, that it remains schema valid, that proper faults are thrown at proper times, and that there is some handler/implementor for each property (even if that's just one piece of code). So... you may want to just implement the getter methods generated by wsdl2java with logic similar to the above rather than modifying getResourceProperty(). Then you can read resource properties on the server side (between capabilities) without parsing DOM fragments. Either way, I don't think you want to disconnect the WSRP schema loader... Dan "Vinh Nguyen \(vinguye2\)" <[EMAIL PROTECTED]> wrote on 11/22/2006 05:21:58 AM: > What's the best way to customize Muse so that values in the resource > properties document can be loaded dynamically from an external source? > In a stateless environment, we do not want to use the default > implementation where resource properties are loaded into memory from the > wsdl file when the resource is first called. We'd like requests to pass > thru, and resource properties be retrieved from an external source, like > a database. > > For testing, I've been able to extend the SimpleGetCapability class and > override the getResourcePropertyDocument() method to dynamically add > properties to the collection to be returned. Then I specify my custom > class in muse.xml, replacing the original SimpleGetCapability reference. > > This method works easily, but I'm not sure if it's the best/recommended > way to do it. > -Vinh --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
