hi mike, thanks for the answer. some comments inline.
Mike Edwards <[EMAIL PROTECTED]> wrote on 09/23/2007 02:08:23 PM: > Florian, > > This isn't quite the way that componentType is intended to work. Let me > try to explain. > > A componentType file is something that is really associated with an > implementation, not with the component that uses the implementation. In > effect, "componentType" is really a description of the external > characteristics of the implementation, which can then be configured by > the component which uses the implementation. (ie a listing of the > services, references, properties, of the implementation). Some folks > have even suggested a better name for the file of "implementationInfo", > just to drive the point home... I understand this so far, the name componentType is still missleading. I would vote for implementationInfo because I makes it clear that it is meta information about the implementation not the component (what the name now suggests). > In many ways, the ideal situation is where the componentType of an > implementation is derived through inspection / introspection of the > implementation artifact(s). This is generally the case for Java > classes, for example. I also implement that for Splice components at the moment but for now, I use componentType files to specify references etc. > SCA allows for the case where implementation types cannot be > introspected - and this is where the componentType file comes in. The > componentType file allows the developer of the implementation to > describe the "external characteristics" of the implementation in an XML > file. The componentType file is usually placed in a location associated > with the implementation artifact(s) (eg in the same directory) and > usually has a name directly related to the name of the implementation > artifact. > > So, let me take a guess that the Splice implementation artifact in your > example is a file called "echo.splice" in the > src/test/resources/flowdir/ directory. In this case, if you need to > supply a componentType file with this, it could be called > echo.componentType and placed in that same directory alongside the > echo.splice file. exactly what I have now. I currently have "invented" name attribute on the splice.implementation that identifies my .componentType file which resides in the src/main/resources of a project alongside with the .composite file. but probably your suggestion to put it alongside with the echo.splice is better. have to think about that. > Then, when your implementation processor is told to go retrieve the > echo.splice implementation, you can find the echo.componentType file by > a simple search in the same directory... > > All this assumes that you can't introspect the splice implementations > for the relevant information, of course... i'm working on that right now. should be finished soon. Thanks again for your insights. -Florian > Florian Rosenberg wrote: > > folks, > > > > I'm writing a component impl type and in my artifact processor I would need > > the name attribute from a component defined in the composite file to be > > able to use a constistant resolving mechanism for my componentType files > > that describe the component. > > > > Example: > > <component name="FooComponent"> > > <tuscany:implementation.splice baseDir:="src/test/resources/flowdir/" > > path="echo" url="echo" contentType="text/plain" /> > > <reference name="..." /> > > </component> > > > > Is there a way to get that name (FooComponent) in the read() or resolve () > > method of the StAXArtifactProcessor implementation reading the > > implementation.splice attribute? The FooComponent.componentType is then > > used to describe the component, its references, etc. > > > > I could not figure out a way to retrieve it, probably I missed something. > > > > Thanks, > > -Florian > > > > > > --------------------------------------------------------------------- > > 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]
