Hi all, Re: https://enterprise.redhat.com/issue-tracker/175979 While resolving this case, customer asked how to transform the given JDBC CacheLoaderConfig section (see attached mbean-cacheloaderconfig.xml) into MC style deployment. The result can be found in the attached mc-cacheloaderconfig.xml. I'd like to put this somewhere and I can think 3 places for it: - wiki (my firm fav) - jbc docu - example deployment descriptor distributed with JBC and/or AS. Wiki is probably the best place to put this type of example configuration files as we're likely be asked to provide more like this and it's the easiest way for people to contribute. Thoughts? Staying on the same topic, while trying to create the MC version of that configuration, I worked with a prototype that use <property> elements for each of the cache loader configuration properties. However, this was not really viable because it would require setter/getter for each and every property, see attached mc-cacheloaderconfig-properties.xml. Initially, before I came out with the final solution, I was thinking of creating a JIRA to get the setter/getters created, but given the final solution does not require any changes and fits well the purpose of setProperties(), I don't think there's a need for a JIRA. Thoughts? Cheers,

+1, I agree with Brian that a JIRA should be raised even if it is minor. On 7 May 2008, at 15:11, Brian Stansberry wrote: > IMHO, if a cache loader supports a config option, the xxxConfig object > should expose a getter/setter for it. These classes are meant to be > java beans and should behave as such. I think the fact that > JDBCCacheLoaderConfig is missing some properties is a minor bug and we > should have a JIRA for it. > > Following from that, IMHO by default configuring these objects in the > MC should be via the getter/setter. That's something anyone with an > IDE or javadoc can figure out and follows typical IOC usage. The > workaround you came up with (good job!) of building a Properties > object and passing to setProperties() is a nice solution if we screw > up and forget a getter/setter. But it's not intuitive and is relying > on code that really exists just to support the limitations of our > service.xml parsing. I don't think we should encourage using it as the > standard way. > > From there I tend to incline toward a wiki for documenting this. In > the next JBC release the getters/setters should be there, so why > document a no-longer-necessary workaround for a previous release in > the main JBC docs? Yes, if it is just a temp workaround for a specific release, then use the wiki. A proper description of using the getters/setters should be in the main docs though. > Including an example in the AS docs folder is good, since in general > JDBCCacheLoader is a complex config and there aren't going to be any > uses of it in the AS for people to look at. > > Galder Zamarreno wrote: >> Hi all, >> Re: https://enterprise.redhat.com/issue-tracker/175979 >> While resolving this case, customer asked how to transform the given >> JDBC CacheLoaderConfig section (see attached >> mbean-cacheloaderconfig.xml) into MC style deployment. The result can >> be found in the attached mc-cacheloaderconfig.xml. >> I'd like to put this somewhere and I can think 3 places for it: >> - wiki (my firm fav) >> - jbc docu >> - example deployment descriptor distributed with JBC and/or AS. >> Wiki is probably the best place to put this type of example >> configuration files as we're likely be asked to provide more like >> this and it's the easiest way for people to contribute. Thoughts? >> Staying on the same topic, while trying to create the MC version of >> that configuration, I worked with a prototype that use <property> >> elements for each of the cache loader configuration properties. >> However, this was not really viable because it would require >> setter/getter for each and every property, see attached >> mc-cacheloaderconfig-properties.xml. >> Initially, before I came out with the final solution, I was thinking >> of creating a JIRA to get the setter/getters created, but given the >> final solution does not require any changes and fits well the purpose >> of setProperties(), I don't think there's a need for a JIRA. Thoughts? >> Cheers, > > -- > Brian Stansberry > Lead, AS Clustering > JBoss, a division of Red Hat > brian.stansberry(a)redhat.com > _______________________________________________ > jbosscache-dev mailing list > jbosscache-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/jbosscache-dev -- Manik Surtani Lead, JBoss Cache manik(a)jboss.org