Re: T5: replacing the ComponentInstantiatorSource service
On 15/09/2007, at 1:09 PM, Tom Davies wrote: I think I need to explictly @Inject 'Configuration configuration', but I can't figure out what Id to use... No! The services injected into buildCalComponentInstantiator needed to be injected explictly! Got it now! Thanks, Tom
Re: T5: replacing the ComponentInstantiatorSource service
Thanks for the help. On 14/09/2007, at 12:30 AM, Howard Lewis Ship wrote: Oh, then ComponentClassEnhancementWorker is almost certainly the way to go. At the moment I'm persisting with ComponentInstantiatorSource, as I can do *anything* to the class with that, and I'm still experimenting. I agree that the worker chain is cleaner. I'm trying to substitute my implementation (instead of just replacing the class) via my AppModule: public class AppModule { public CalComponentInstantiatorSourceImpl buildCalComponentInstantiator(@InjectService("ClassFactory") ClassFactory classFactory, ComponentClassTransformer transformer, Log log) { CalComponentInstantiatorSourceImpl source = new CalComponentInstantiatorSourceImpl(classFactory .getClassLoader(), transformer, log); //_updateListenerHub.addUpdateListener(source); -- fix this later return source; } public static void contributeAlias(@InjectService ("CalComponentInstantiator") ComponentInstantiatorSource myService, Configuration configuration) { configuration.add(AliasContribution.create (ComponentInstantiatorSource.class, myService)); } } but I get the error: java.lang.IllegalStateException: Construction of service 'Alias' has failed due to recursion: the service depends on itself in some way. Please check org.apache.tapestry.services.TapestryModule.build (Log, String, AliasManager, Collection) (at TapestryModule.java:249) for references to another service that is itself dependent on service 'Alias'. I've looked at TapestryModule.java, and Googled the error, but I'm not sure how to resolve it -- I think I need to explictly @Inject 'Configuration configuration', but I can't figure out what Id to use... I get a similar error if I contribute to AliasOverrides, and I'm not sure what the difference between the two is? Thanks, Tom - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: T5: replacing the ComponentInstantiatorSource service
Oh, then ComponentClassEnhancementWorker is almost certainly the way to go. What if the Cal methods were on an interface that had no implementation. And instance of the interface could be injected into a field of the component. The component would have access to the Cal methods via the field. The worker could provide the bridge to Cal in the form of an implementation of that interface, using either JDK dynamic proxies or Javassist (to create a class implementing the interface at runtime). The trick, of course, is for the worker to adapt to whatever interface you provide (including the annotations on the interface). Separation of concerns, and easy to test (because you can mock up the Cal interface using EasyMock). On 9/13/07, Tom Davies <[EMAIL PROTECTED]> wrote: > > > On 13/09/2007, at 9:09 AM, Howard Lewis Ship wrote: > > > I don't know much about CAL ... could this kind of thing be > > accomplished by > > extending the ComponentClassEnhancementWorker chain of command? Or > > is CAL > > based on the raw Javassist APIs? > > > > Hi Howard, > > I hadn't seen that class. It *almost* allows me to do what I want -- > ideally I'd like to be able to use abstract methods, to avoid the > need for a dummy body, but I can't get to CtClass.setModifiers() to > make the class concrete... > > (OT: CAL doesn't use Javassist -- it's just my way of hooking Java > functions to CAL ones) > > Thanks, >Tom > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Howard M. Lewis Ship Partner and Senior Architect at Feature50 Creator Apache Tapestry and Apache HiveMind
Re: T5: replacing the ComponentInstantiatorSource service
On 13/09/2007, at 9:09 AM, Howard Lewis Ship wrote: I don't know much about CAL ... could this kind of thing be accomplished by extending the ComponentClassEnhancementWorker chain of command? Or is CAL based on the raw Javassist APIs? Hi Howard, I hadn't seen that class. It *almost* allows me to do what I want -- ideally I'd like to be able to use abstract methods, to avoid the need for a dummy body, but I can't get to CtClass.setModifiers() to make the class concrete... (OT: CAL doesn't use Javassist -- it's just my way of hooking Java functions to CAL ones) Thanks, Tom - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: T5: replacing the ComponentInstantiatorSource service
I don't know much about CAL ... could this kind of thing be accomplished by extending the ComponentClassEnhancementWorker chain of command? Or is CAL based on the raw Javassist APIs? On 9/12/07, Tom Davies <[EMAIL PROTECTED]> wrote: > > > On 13/09/2007, at 12:00 AM, Howard Lewis Ship wrote: > > > I'd love to know why you want to do this ... it indicates to me > > that there > > needs to be some additional configuration available to CIS to > > support your > > needs. > > > > I don't know if I have a valid use-case, but what I'm doing is > experimenting with integrating Business Object's CAL language with > Java, so a page class from the tutorial app becomes: > > @Cal(workspace = "myworkspace.cws", module = "TDavies.Start") > public class Guess { > @Persist > private int _target; > > void setup(int target) > { > _target = target; > } > > public int getTarget() > { > return _target; > } > > private int _guess; > > public int getGuess() > { > return _guess; > } > > public void setGuess(int guess) > { > _guess = guess; > } > > @Persist > private String _message; > > public String getMessage() > { > return _message; > } > > String onActionFromLink(int guess) > { > _message = getNewMessage(guess, _target); > MaybeValue nextPage = getNextPage(guess,_target); > return nextPage.getValueField(); > } > > @Cal > String getNewMessage(int guess, int target) > { > return null; > } > @Cal > MaybeValue getNextPage(int guess, int target) > { > return null; > } > } > > Where the methods with the @Cal annotations are replaced by Javassist > with calls to CAL functions. I'm not even sure this is useful yet -- > I'm just exploring. > > To do this I needed to be able to apply a Javassist Translator to the > page classes as they were loaded (and javassist.Loader.addTranslator > should be named *setTranslator*!) > > Perhaps there is a better way? > > In any case, ComponentInstantiatorSourceImpl is quite monolithic -- > perhaps some of its components should be injected, e.g. a seperate > Translator, rather than having ComponentInstantiatorSourceImpl > implement Translator. > > Tom > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Howard M. Lewis Ship Partner and Senior Architect at Feature50 Creator Apache Tapestry and Apache HiveMind
Re: T5: replacing the ComponentInstantiatorSource service
On 13/09/2007, at 12:00 AM, Howard Lewis Ship wrote: I'd love to know why you want to do this ... it indicates to me that there needs to be some additional configuration available to CIS to support your needs. I don't know if I have a valid use-case, but what I'm doing is experimenting with integrating Business Object's CAL language with Java, so a page class from the tutorial app becomes: @Cal(workspace = "myworkspace.cws", module = "TDavies.Start") public class Guess { @Persist private int _target; void setup(int target) { _target = target; } public int getTarget() { return _target; } private int _guess; public int getGuess() { return _guess; } public void setGuess(int guess) { _guess = guess; } @Persist private String _message; public String getMessage() { return _message; } String onActionFromLink(int guess) { _message = getNewMessage(guess, _target); MaybeValue nextPage = getNextPage(guess,_target); return nextPage.getValueField(); } @Cal String getNewMessage(int guess, int target) { return null; } @Cal MaybeValue getNextPage(int guess, int target) { return null; } } Where the methods with the @Cal annotations are replaced by Javassist with calls to CAL functions. I'm not even sure this is useful yet -- I'm just exploring. To do this I needed to be able to apply a Javassist Translator to the page classes as they were loaded (and javassist.Loader.addTranslator should be named *setTranslator*!) Perhaps there is a better way? In any case, ComponentInstantiatorSourceImpl is quite monolithic -- perhaps some of its components should be injected, e.g. a seperate Translator, rather than having ComponentInstantiatorSourceImpl implement Translator. Tom - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: T5: replacing the ComponentInstantiatorSource service
I'd love to know why you want to do this ... it indicates to me that there needs to be some additional configuration available to CIS to support your needs. On 9/12/07, Tom Davies <[EMAIL PROTECTED]> wrote: > > Hi, > > I want to override the ComponentInstantiatorSource service with my > own implementation (so that I can add another Translator to the > Javassist ClassPool). > > It seems that I can't simply define a duplicate of the service in my > own module, which is fair enough. What's the approach to use? > > Thanks, >Tom > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Howard M. Lewis Ship Partner and Senior Architect at Feature50 Creator Apache Tapestry and Apache HiveMind
Re: T5: replacing the ComponentInstantiatorSource service
To quote HLS: "You supply a new implementation with a new id, and contribute to the Alias service configuration. This will allow injections based on type to prefer your implementation over the built-in one." See Alias/AliasOverrrides: http://tapestry.apache.org/tapestry5/tapestry-core/guide/alias.html Cheers, Nick. Tom Davies wrote: Hi, I want to override the ComponentInstantiatorSource service with my own implementation (so that I can add another Translator to the Javassist ClassPool). It seems that I can't simply define a duplicate of the service in my own module, which is fair enough. What's the approach to use? Thanks, Tom - 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]