Hi, A few comments inline
Thanks - Venkat On 10/11/06, Jim Marino <[EMAIL PROTECTED]> wrote:
On Oct 10, 2006, at 7:53 AM, ant elder wrote: > I'd be really happy for all those to become part of the core, but > I'm not > sure I see how all that remains will be a few three-line > statements. How > about I move this to a container-helper as I suggested before, we > pull all > the bits out and do the refactoring and before we cut M2 see whats > left and > if there really is nothing much left just doc it otherwise re- > evaluate then > what to do with what remains? I took a closer look at the ComponentType encapsulation problem. The problem resides in the fact that the generic component type element loader creates a generic component type as the component type side file is processed. What should happen is that the component type should be created by the implementation loader (e.g. PojoComponentType, or maybe ScriptComponentType) and passed into the loader. The load method on StAXElementLoader would need to be changed to: load(CompositeComponent parent, ModelObject object, XMLStreamReader reader, DeploymentContext deploymentContext) would Where "object" was a model object the loader would populate or null, in which case the loader would be responsible for creating one.
+1. So when object is null there simply no specialized component type and just the base would do. Right ? In
the case of custom component types, the implementation loader would create a subclass of ComponentType and pass it back into the loader registry. A script component type loader would then be responsible for introspecting the custom component type side file.
Here again is there a way where the custom component type loaders are only called for extensions i.e. only for those elements that are not known to the base ComponentType. This way we can avoid duplication of how the common stuff of properties / references / services get loaded. Am I off track ? Without this, we can't properly support scopes in side files so I'd
like to get this fix in.
Not only for the scopes. We are not able to get the basic sidefile stuff up in Pojo - meaning today if we wanted to try out Pojo implementation of a component with side files, we will end up in exceptions. In addition, I'd like to get duplicate code
taken care of (AsyncTargetInvoker, EasyInstanceFactory). I'm willing to take this on and help out since I think this is important we clear up. Also, I still believe once we take care of these issues we probably won't need a separate extension library. One issue is this does affect the SPI and I think we need to assess the risk of these changes on getting the release out. If people are o.k. with me doing these changes, I'll jump in and make them. If it poses too much risk, I suggest we consider branching. Thoughts? Jim > > ...ant > > On 10/10/06, Jim Marino <[EMAIL PROTECTED]> wrote: >> >> I looked at this some more and I think we can make a change in core >> to support loading of custom component types. This will allow us to >> get rid of having to use encapsulation for component types. Also, the >> async invoker should move into an extension class in core. Finally, I >> think ObjectFactory can replace EasyInstanceFactory. Given this, the >> classes that remain are: >> - EasyComponent >> -EasyComponentBuilder >> -EasyImplementation >> -EasyImplementationBuilder >> - EasyInvoker >> >> Assuming we make the above mentioned change in core, most of the >> above code contains "template" code that would have to be integrated >> with container-specific code (e.g. handling of references). Given >> that, would it be better to just document these code snippets in the >> extension documentation as they are generally three-line statements? >> I may be missing some extra functionality so please let me know. >> >> Jim >> >> >> On Oct 9, 2006, at 11:47 AM, Jim Marino wrote: >> >> > >> > On Oct 9, 2006, at 3:42 AM, ant elder wrote: >> > >> >> On 10/7/06, Jim Marino <[EMAIL PROTECTED]> wrote: >> >>> >> >>> >> >>> On Oct 7, 2006, at 10:42 AM, Jim Marino wrote: >> >>> >> >>> > >> >>> > On Oct 7, 2006, at 7:22 AM, ant elder wrote: >> >>> > >> >>> >> This is all working quite well now so i'd like to move it >> from my >> >>> >> sandbox to >> >>> >> be with the other containers. BSF 2.4 has just come out and >> the >> >>> >> jar is >> >>> >> available from a proper maven repo and the script container >> >>> >> supports all the >> >>> >> SCA things like references, properties and async, also the >> >>> start of a >> >>> >> website page describing it which I'll move to the site once >> its a >> >>> >> bit more >> >>> >> done: >> >>> >> https://svn.apache.org/repos/asf/incubator/tuscany/sandbox/ >> ant/ >> >>> >> container.script/doc/sca-java-container-script.xml >> >>> >> >> >>> >> https://svn.apache.org/repos/asf/incubator/tuscany/sandbox/ >> ant/ >> >>> >> container.script/ >> >>> >> https://svn.apache.org/repos/asf/incubator/tuscany/sandbox/ >> ant/ >> >>> >> container.easy/ >> >>> >> >> >>> > I'm fine with this as long as the name of "container.easy" >> can be >> >>> > changed to something that denotes it has to do with scripting, >> >>> > something like "container.bsf". >> >>> > >> >>> After looking at the code more instead of having something >> separate, >> >>> why wouldn't we look to see if we can merge the "easy container" >> >>> into >> >>> the extension API? I'd like to get a clearer direction on this >> >>> before >> >>> we move things around. >> >>> >> >>> Specifically, I have a few questions related to this: >> >>> >> >>> 1. Is this container just for scripting? It appears not to be >> >>> tied to >> >>> scripting >> >>> 2. What value does this container provide over the extension API? >> >>> Does it automate certain coding tasks only relevant to a >> subset of >> >>> containers or all containers? Could we just merge such automation >> >>> with AtomicComponentExtension >> >>> 3. There appears to be a bit of code duplication, some of >> which may >> >>> be a vestige from the Groovy container which needs to be >> refactored. >> >>> For example, AsyncInvoker. In a merge, maybe we could >> eliminate the >> >>> need for this? >> >>> >> >>> Jim >> >> >> >> >> >> Way back I was moaning about the complexity of the SPI and it was >> >> suggested >> >> having a separate extension project for a simplified SPI for >> >> extensions with >> >> simpler requirements. >> > Could you outline where you think core is too complex for "simple >> > requirements"? I'd like to get an extension into core. What I >> > specifically want to avoid is creating a parallel extension >> mechanism. >> >> I can't find a link, maybe the 1st sandbox phone call >> >> or an old IRC chat? Thats where this came from. Its not quite >> >> finished yet, >> >> there's some parts that could be simplified further. I'd also like >> >> to do the >> >> same thing for bindings but haven't got to that yet. This is not >> >> necessarily >> >> tied to only scripting containers but thats all we've tried it >> >> with so far, >> >> and as Venkat suggests there likely is a bit more work required to >> >> make it >> >> more generally useful. There probably are some parts that could be >> >> moved to >> >> existing SPI classes, but there are also parts that may be a bit >> >> inflexible >> >> to be made part of the general extension SPI. As you point out the >> >> async bit >> >> does seem pretty isolated so that probably could be easily moved >> >> out. Given >> >> we're trying to get an M2 release out real soon I'm not sure about >> >> messing >> >> with the existing SPI classes now. How about for now moving the >> >> obvious bits >> >> like async out but keeping the rest in say a separate >> >> container.helperproject or in a separate SPI package like >> >> org.apache.tuscany.spi.extension.container? >> >> >> > What parts are you suggesting to move up? I definitely do not want >> > to create another SPI package. Perhaps you could list the parts of >> > the classes you would move into a helper library as well as the >> > areas they are trying to simplify? This way we could decide whether >> > the core spi can be simplified directly? To start with, I assume >> > the following would not be included: >> > >> > - AsyncTargetInvoker >> > - AsyncMonitor >> > - EasyInstanceFactory since that can be done using an ObjectFactory >> > >> > Some specific questions I have are: >> > >> > - How are script scopes handled? I'm assuming we want to have the >> > runtime manage statefull scripts, as we get that for free. >> > >> > - I also noticed the scope is set by default to Module. The default >> > SCA Java is stateless. I agree module scope may be a better default >> > but do you think we should be consistent with other SCA language >> > specs here? >> > >> > - EasyComponentType encapsulates another ComponentType. I would >> > have thought there would be an inheritance relationship. Was this >> > because we need a specialization of ComponentType to be created by >> > the generic side-file loader? If so, I think we should fix that in >> > core. >> > >> > - More generally on component types, I haven't been following the >> > PHP spec work but my understanding based on proposals from the >> > people working on it to the assembly group is that the trend is to >> > move away from having to author side-files and more towards code- >> > level metadata and defaults. Would we want to emphasize that? Maybe >> > you could ping Graham Charters who has been working on these >> issues? >> > >> > - Do scripts need to be defined by the Java idl or could I use WSDL >> > or JSON or something else (assuming the proper extension)? >> > >> > - What does EasyInstanceFactory.getResponseClasses(List<Class> >> > services) do? >> > >> > - How are references handled? Can they be injected onto fields in >> > prototype-based languages? >> > >> > I think the best way to figure out what would go into core versus >> > an extension library is to get a list of classes you propose moving >> > into core versus into the library. Does that work for you? >> > >> > Jim >> > >> >> ...ant >> >> >> >> ...ant >> > >> > >> > >> --------------------------------------------------------------------- >> > 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] >> >> --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
