Daryoush-- At this point, it seems best to throw some code at the virtual whiteboard and see what sticks. Hopefully this will help answer some of the questions you posed below.
:) Unfortunately, I don't expect to have lots of time to put into this over the next week or so, but I'll continue to do incremental work in the sandbox in an attempt to take the implementation to feature parity with trunk/. My goals for this prototyping are listed below; I think the rationale for these has been explained earlier in the thread though if anything is unclear, let me know. Feedback welcome on the code in sandbox/ekoneil/wsm/. Cheers, Eddie Goals: - support annotation processing in the spirit of APT by not requiring .class files for types available in source code. - support full build-time checking of annotated web services and related resources. - support pluggable code generation - make it possible to support reflection based annotation validation and model construction (note, this isn't supported in the tools / runtime today) - make it possible to add support for validating a WSDL referenced via @WebService.schemaLocation against an annotated web service On 6/23/05, Daryoush Mehrtash <[EMAIL PROTECTED]> wrote: > Comments below. > > > > Hm. I sort of disagree with the characterization that the current > > implementation is Mirror/Reflection agnostic. The WSM annotation > > processor uses the JavaTypeInfo interface and MirrorTypeInfo > > implementation (and the related classes) in an attempt to achieve this > > agnosticism. > > Exactly, the current design is based on IOC pattern to abstract out the > underlying processors (annotation processor, or reflection processor) from > the model creation/validation logic. It would allow us to reuse the model > creation/validation logic across APT and Reflection (and potentially > xdoclet). Why do you think this separation is wrong? > > > As far as supporting both Mirror and Reflection, the latter could be > > an interesting thing to do longer term, but I don't think we have a > > use case for this today. Correct? That being said, the model objects > > could be constructed from reflection data simply by writing a new > > model factory. > > > I see reflection use case as important use case. It would make our code > usable without requiring the source code. To me that is a valid and strong > use case to support. This wouldn't make much sense in NetUI, and Controls > as they both require extensive code generation. The WSM, however, can work > just fine with class files. > > In your terminology, I want to make sure the creation/validation logic is > shared between reflection and APT factories. Right now this is done with > IOC, if there are other alternatives I am open to that. I want to make sure > this is a requirement for any changes in the design. > > > > But, these Java*Info classes use java.lang.Class instances for both > > parameter types and method return types. This is problematic given a > > project structured as: > > > > src/ > > AccountService.java (an annotated web service) > > Account.java (a complex type returned by some web service > > method) > > > > This project won't currently build with the WSM annotation processor > > which can only handle Account.java as .class file meaning that must > > be compiled first. Ultimately, this means that the annotation > > processor does not cleanly separate Mirror and Reflection and that the > > project structure must be: > > > > src/ > > Account.java > > src-ws/ > > AccountService.java > > > > where src/ builds first in order to make .class files available for > > the annotation processing. Were there a way to use *just* Mirror, the > > first project model would be buildable and the Java*Info interfaces > > would return TypeDeclarations instead of Class types for method > > signature metadata. > > > I don't believe this is by product of the APT processing model; rather it is > based on our perceived requirements and potentially our lack of knowledge on > other ways to solve the problem. Let me explain…. > > The model as you pointed out does keep the class of the parameter and return > type for every method in the JWS. I break down your concern in two > questions: > > > 1) Does the model really need the class or can it live with just the name of > the types? > 2) If the does need the class, is there any way to get it from APT so as > not to require the compilation? > > If the model doesn't really need the class of the return and parameters then > there is a very easy fix to the src/src-ws issue. The solution would be to > change the model so that it only keeps the class name that is readily > available at APT and won't require the Reflection. This would solve the > problem right? > > But I think to do validation (which we need to do during the APT) the class > information is needed. To do a complete validation we would need to do > introspection on the method parameters/returns/faults (we don't right now, > but that is our validation logic isn't complete). > > Here is a use case, with @WebService annotation you can specify > wsdlLocation. If there is a wsdl associated with the JWS file, then the > validation should verify the validity of the WSDL vs the JWS. This would > mean you would have to introspect all your parameters, returns, and faults > classes (also handlers, and service end point interfaces also). The > validation needs make sure the type schema matches the WSDL definitions. > Bottom line is that we would need to introspect classes at the APT check() > and generate(). > > > If we assume we do need the class, then we are to the second question, > namely can I get it from APT without requiring reflection. There may be a > way; we didn't know how to do it. > > We would need to get the APT to do the type introspection for us, or > alternatively, force APT to compile the class for us. We didn't know how > to do either of them. But if there someone out there that knows how to > solve this problem then the need for additional compile step goes away. > > > So to summarize: > > > 1) It seems to me there are use cases where we do need to know detail type > information, > 2) I don't know how I can get that information without having the classes > compiled and available on the classpath before running APT. > > I think at one time there was another solution to the src/src-ws that may be > a good transparent alternative to the current src/src-ws model. If JWS > files and types files are all in the same source directory, wouldn't a Java > compile followed by APT compile of the source code satisfy all the issues? > Meaning we wont need src/src-ws separation and the additional steps are > abstracted out in ANT macros. > > > IMHO, we should be making progress toward getting WSM structured > > well to pass the TCK and to have a firm foundation upon which to add > > > > As far as passing TCK, I don't believe the current implementation would have > problems in annotation processing. We have been running this system for a > while and I am not aware of any issues with the annotation processing. > Sure, TCK may find a problem here to there, but I don't think there is > anything in the current annotation processing model that would prevent us > from passing TCK. > > > > new features. Some of these features could include: > > > > > - validating metadata and building the WSM model from reflection > > > > This is the functionality was in the Alpha release of the WSM, the IOC > model was definitely designed so that this would be possible. > > > > > - support for Axis-specific security annotations > > - providing extensibility models for code generation to perhaps > > support JAX-WS (etc) > > - and so on... > > > I believe the features you have listed are all possible and straight > forward with the current system. > > In particular let me talk to the JAX-WS that you mentioned. Chapter 8 in > the Jsr 181 specification describes the mapping between the JSR181 and 109 > specification artifacts. > > With the current implementation I think you can do this by a) extending our > WSM Apt processor, or alternatively b) by writing a standalone tool that > converts the object model to 109 artifacts. I would recommend the second > approach because: > > > a) The tool would be more universal as it would only require class files. > b) we also need to generate the WSDL, this would require the Axis run time > (as we do in test cases), which even though do-able, would be rather strange > to run Axis runtime inside APT. > > But if you really like to do the 109 artifacts in APT, you can still do this > by sub classing the WSM annotation processor and overwrite the generate() > method. The generate() method can take advantage of the model that is > created in check(). Why would either of these solutions be problematic? > > > Having said that, we all know that open source is about the constant > evolution of the code. I am all for that as long as we are not losing > functionality. > > > As I pointed out in my previous posting, looking at our APT processing and > the Sun's model (in documentation and their apis) my main concern is that we > are not based on the Visitor pattern. So if we are changing the > processing model, I think we should make sure this is inline with the Sun's > model (or at least a good reason why it should not be done as Visitors) > while keeping the two phase annotation, and APT agnostic factories. > > > Daryoush > > > On 6/23/05, Eddie ONeil <[EMAIL PROTECTED]> wrote: > > Daryoush-- > > > > Hm. I sort of disagree with the characterization that the current > > implementation is Mirror/Reflection agnostic. The WSM annotation > > processor uses the JavaTypeInfo interface and MirrorTypeInfo > > implementation (and the related classes) in an attempt to achieve this > > agnosticism. > > > > But, these Java*Info classes use java.lang.Class instances for both > > parameter types and method return types. This is problematic given a > > project structured as: > > > > src/ > > AccountService.java (an annotated web service) > > Account.java (a complex type returned by some web service > method) > > > > This project won't currently build with the WSM annotation processor > > which can only handle Account.java as .class file meaning that must > > be compiled first. Ultimately, this means that the annotation > > processor does not cleanly separate Mirror and Reflection and that the > > project structure must be: > > > > src/ > > Account.java > > src-ws/ > > AccountService.java > > > > where src/ builds first in order to make .class files available for > > the annotation processing. Were there a way to use *just* Mirror, the > > first project model would be buildable and the Java*Info interfaces > > would return TypeDeclarations instead of Class types for method > > signature metadata. > > > > Fortunately, I don't think we're very far away from fixing this > > problem and cleaning up the build-time part of WSM, and neither the > > Java*Info nor the Mirror*Info classes are even needed. :) > > > > WSM currently has the following: > > > > - BeehiveWs* abstract classes -- thees build up the model of a web service > > - Default*Impl classes -- these extend and fully implement the > > BeehiveWs* base classes > > - Jsr181*Impl classes -- these extend the Default*Impl classes and > > have constructors that act as 1) annotation checkers and 2) model > > factories > > > > If WSM was to break the Jsr181*Impl classes into two pieces -- > > annotation checking and model factories, I think we'd achieve the > > goals proposed in a previous mail about loosely coupling the > > annotation checking, model construction, and model objects. And, > > because the model construction just works on a TypeDeclaration or a > > Class, the Java*Info/Mirror*Info layer isn't needed. > > > > As far as supporting both Mirror and Reflection, the latter could be > > an interesting thing to do longer term, but I don't think we have a > > use case for this today. Correct? That being said, the model objects > > could be constructed from reflection data simply by writing a new > > model factory. > > > > IMHO, we should be making progress toward getting WSM structured > > well to pass the TCK and to have a firm foundation upon which to add > > new features. Some of these features could include: > > > > - validating metadata and building the WSM model from reflection > > - support for Axis-specific security annotations > > - providing extensibility models for code generation to perhaps > > support JAX-WS (etc) > > - and so on... > > > > Thoughts on any of this? > > > > Eddie > > > > ps -- as far as supporting XDoclet / Javadoc style metadata, that > > would be possible if there was a set of APIs similar to Mirror's > > TypeDeclaration interface that can be backed by both a Mirror and > > XDoclet implementation. JPF has something similar to this in its > > compiler layer. Then, the JSR 181 annotation checker can be written > > to work against this abstraction to support both Java 5 and Javadoc > > based metadata. My $0.02 there. :) > > > > > > > > On 6/22/05, Daryoush Mehrtash < [EMAIL PROTECTED]> wrote: > > > I agree with Eddie, that .ser file is an orthogonal issue. We need to > > > start a new thread on it to evaluate the merits of the .ser file for > > > the run time. > > > > > > I think one useful feature in the current implementation is that the > > > model creation process is APT/Reflection agnostic (potentially we can > > > even get annotation from as xdoclets also). I think we should > > > preserve this feature. Meaning I can build the model form APT or > > > Reflection and share common code in defaults and rule checking. > > > > > > There is a concern Eddie's post as to why we are generating an > > > artifact in the check() phase (.ser file) as oppose to the generate(). > > > I think this is done because a) to perform the validation you need > > > the model, b) the model can be used by a sub class of the WSM > > > annotation processor to do additional check() and generate(). For > > > instance you can sub class the WSM annotation processor and generate > > > 109 artifact knowing that the base class has created the model at > > > check(). > > > > > > As far as I am concern, if we can make the changes in the APT package > > > that would preserve the agnostic Reflection/APT behavior of the model, > > > and improves the code structure I am all for that. It would be nice > > > if we can get some code on this to compare the two implementations. > > > > > > > > > On that note, I have started looking at the APT processing model > > > that Sun seems to be promoting, namely using Visitors, see "A Simple > > > Sample Annotation Processor" section in > > > > > > > http://java.sun.com/j2se/1.5.0/docs/guide/apt/GettingStarted.html > > > > > > My expectation is that the Visitor model would be the preferred model > > > for others to extend the annotation processor. It seems to me our > > > changes should somehow marry the Visitor model into the check/generate > > > model of the two phase Annotation processing. > > > > > > I know we don't use the Visitor pattern in WSM, may be I missed > > > something, but I don't see us using the Visitor Pattern in the other > > > APT (NetUI and Controls) processors either. If we want to rework > > > the APT processor shouldn't we look closer at the Sun's model? > > > > > > > As a holistic solution to all of the above, it seems like there are > > > > four components that participate in the end-to-end WSM annotation > > > > processing: > > > > > > > > 1) a Jsr181AnnotationChecker -- just validates annotations > > > > 2) model objects (a la the BeehiveWs* classes today) implemented as > > > > JavaBeans > > > > 3) a factory layer used to create instances of the model objects > > > > 4) a generation abstraction. In today's use case, this would create > > > > the .ser file from the model objects in (2) > > > > > > > > > As part of patch that gave to Beehive-801 I think we have separated > > > the model and annotation checking. Eddie has a good point about the > > > builder being done in the constructor of the JSR181 classes, A factory > > > layer might be more appropriate. > > > > > > I would just be concern that we need to keep the Reflection/APT > > > agnostic. Also that validation is not on just in individual > > > annotation rather it is across annotations, JWS class information, > > > service endpoint interface, types that are used in the service, and > > > WSDL file. So the annotation checker would need model and host of > > > other information for it to do the validation. > > > > > > My suggestion is that if we are going down this lets route make the > > > new factory and the validation "layer" as Visitors. Also lets do > > > some prototypes and see how we can improve the APT processing. > > > > > > Daryoush > > > > > > > > > On 6/17/05, Rich Feit <[EMAIL PROTECTED]> wrote: > > > > I think this is a good summary/breakdown of the issues, and for my > part, > > > > I agree with the responsibilities of the annotation processor (vs. the > > > > runtime) that you've laid out here, as well as where the right plug > > > > points would live for supporting deployment to JAX-RPC, etc. > > > > > > > > Rich > > > > > > > > Eddie ONeil wrote: > > > > > > > > > I think two issues are being mixed here -- annotation processing > and > > > > >the .ser files. IMHO, these two are orthogonal. Here's why: > > > > > > > > > > The purpose of an annotation processors is twofold: > > > > > > > > > >1) perform build-time checking of annotations (this is the "check" > phase) > > > > >2) provide an opportunity to generate additional information / do > work > > > > >based on the annotations. This could include generating Java > sources, > > > > >deployment descriptors, XML files, etc (this is the "generate" phase) > > > > > > > > > > A generic JSR 181 annotation processor might include these steps: > > > > > > > > > >1) check the JSR 181 annotations > > > > >2) create a model representing valid annotations > > > > >3) do some generation to support a web service deployment environment > > > > > > > > > >Mapping this to the current WSM implementation, steps 1 and 2 are > > > > >performed inside of a Jsr181TypeMetadataImpl constructor, and step 3 > > > > >is performed at the end of the "check" phase and produces the .ser > > > > >file, which is a serialized Jsr181TypeMetadataImpl. The latter steps > > > > >is necessary because the Axis + WSM implementation of the web > > > > >service's deployment environment uses the .ser to create a > > > > >SOAPService. > > > > > > > > > > The point here is that step (3) above might be different depending > > > > >on whether one is targeting Axis, JAX-RPC, etc. For example, check > > > > >out this article about JAX-RPC 2.0 and specifically step (2) of the > > > > >development process which talks about generating a WSDL from the > > > > >annotated Java file: > > > > > > > > > > > http://www.artima.com/lejava/articles/threeminutes.html > > > > > > > > > >In this case, the "generate" step of annotation processing might > > > > >produce the WSDL (among other stuff) and not the ".ser" file. So, as > > > > >step (3) varies, the need for a .ser file seems like it would also > > > > >vary. If the web service runtime doesn't require the .ser file, > > > > >there's no need to produce it. That's why I called .ser files an > > > > >implementation detail of using Axis as a web service runtime and for > > > > >this reason that it seems like annotation (metadata) processing and > > > > >the .ser file are orthogonal since the ".ser" file is optional but > JSR > > > > >181 annotation checking isn't. > > > > > > > > > > :) > > > > > > > > > > Before going on here, I want to make clear that the user-model for > > > > >authoring JSR 181 based web services used on Axis is *great* -- > build, > > > > >deploy, run, and any suggestions below are not meant to change this > > > > >model in any way. And, features such as XMLBean handling and the > > > > >"from WSDL" case are not affected. In fact, hopefully they can > > > > >enhance it by providing an easier way of doing drop-in annotation > > > > >checking / deployment if there is interest in that. So... > > > > > > > > > > To address your points about annotation processing vs. reflection, > > > > >it should be possible to create a JSR 181 annotation checker that can > > > > >work on type metadata that comes from Mirror (via APT) or from > > > > >reflection. This would be a matter of implementing an annotation > > > > >checker that can operation on a set of type abstraction classes that > > > > >can be backed by Mirror or reflection. The Page Flow compiler has a > > > > >layer similar to this today -- see: > > > > > > > > > > > trunk/netui/src/compiler-core/org/apache/beehive/netui/compiler/typesystem/... > > > > > > > > > >While not a trivial amount of code, it's not significantly > complicated > > > > >either. Using such a layer, the JSR 181 checker can be implemented > to > > > > >handle either Mirror, reflection, or some other arbitrary > > > > >implementation of the TypeDeclaration-style APIs used by the JPF > > > > >compiler. I think that this would facilitate your #2 and #3 models > > > > >for building web services. > > > > > > > > > > As a holistic solution to all of the above, it seems like there are > > > > >four components that participate in the end-to-end WSM annotation > > > > >processing: > > > > > > > > > >1) a Jsr181AnnotationChecker -- just validates annotations > > > > >2) model objects (a la the BeehiveWs* classes today) implemented as > JavaBeans > > > > >3) a factory layer used to create instances of the model objects > > > > >4) a generation abstraction. In today's use case, this would create > > > > >the .ser file from the model objects in (2) > > > > > > > > > > The resulting framework would give WSM more flexibility to be > > > > >generally tested and to be extended by varying implementations of the > > > > >above participants. And, the "from WSDL" case is handled by building > > > > >a different factory (3) to provide the model in (2). The parts above > > > > >could be used to allow for: > > > > > > > > > >- plugging in additional annotations to support web service runtime > > > > >specific features such as security, buffering, etc > > > > >- building a reflection-based Axis runtime for WSM that skips the > > > > >build-time step > > > > > > > > > >And so on. > > > > > > > > > > Finally, on the point about the use of build-time checks, when > using > > > > >the annotation processor (to check annotations or some other metadata > > > > >format), if the annotation checking fails the build fails and no > > > > >.class files are produced. If the build succeeds and produces > > > > >classes, presumably the annotations are correct. It doesn't seem > that > > > > >WSM suffers from any more problems of possibly missing or invalid > > > > >classes than any other Java enterprise application. > > > > > > > > > > It's a long winded explanation to the annotation processor / .ser > > > > >questions. If you've kept reading this long, thanks! > > > > > > > > > > Hope it was helpful. :) > > > > > > > > > >Eddie > > > > > > > > > > > > > > > > > > > >On 6/16/05, Daryoush Mehrtash <[EMAIL PROTECTED]> wrote: > > > > > > > > > > > > > > >>> For example, if the WSM annotation processor produced a JSR 101 > / > > > > >>>109 deployable unit (or the source files / descriptors for such a > > > > >>>unit), it might include enough information that the .ser file > wouldn't > > > > >>>be needed. In this case, Beehive WSM only runs at build time and > > > > >>>doesn't have a runtime component. > > > > >>> > > > > >>> > > > > >>In the ".ser" mode of thinking the deployment descriptor for say > 109 > > > > >>would be generated from the .ser file. The idea is that 109 > > > > >>translator would not have to worry about any of the validation and > > > > >>defaults, it has a valid .ser file that it can work off. I am not > > > > >>sure where the spec is going on this, but it seems to me once you > have > > > > >>annotations the idea of 109 descriptor is rather obsolete. You > would > > > > >> think the container can figure most (if not all) of the information > > > > >>from the annotations that are in the class files. > > > > >> > > > > >> > > > > >>I see your concern, and far as WSM is concern, my personal view is > > > > >>that having a configuration file (.ser) defeats the purpose of the > > > > >>annotations. I also feel that even if you do all the validation at > > > > >>build time, the classes that the run time sees may not be valid > (e.g. > > > > >>missing classes). So even though you want the build time validation > > > > >>we can't avoid having the runtime validation. > > > > >> > > > > >>I think what is missing from the current system, or where we went > > > > >>wrong, is that we dropped the ability to build the service model > from > > > > >>class files and started to only rely on the build time artifacts. > In > > > > >>our Alpha (also in Beta I think) release of the WSM we only did the > > > > >>runtime deployment from class files, and it all worked fine (well > > > > >>except the default parameter names). > > > > >> > > > > >> > > > > >> I see three ways of building the web service object model: > > > > >> > > > > >>a) from WSDL, > > > > >>b) from mirror events, > > > > >>c) from class files. > > > > >> > > > > >>The (a) case would be used by the "from wsdl" use case in WSM and > > > > >>service control. (b) Would be used by IDEs or build process, (c) > > > > >>would be used by run time environments (also 109 type descriptor > > > > >>generator tool that would run during the build process). The (b) > and > > > > >>(c) differ in the way the annotation information is collected from > the > > > > >>files, but they both use the same underlying implementation to > enforce > > > > >>the Jsr 181 rules and defaults. The (a) case would use a different > > > > >>implementation where XML-Java rules are enforced. > > > > >> > > > > >> > > > > >>Make snese? > > > > >> > > > > >>Daryoush > > > > >> > > > > >> > > > > >>On 6/16/05, Eddie ONeil < [EMAIL PROTECTED]> wrote: > > > > >> > > > > >> > > > > >>> Sure... > > > > >>> > > > > >>> So, today, the WSM annotation processor produces .ser files in > order > > > > >>>to allow a web service stack (Axis 1.2 today) to discover the > formal > > > > >>>argument names of methods exposed as @WebMethod. > > > > >>> > > > > >>> I was speculating -- which perhaps I shouldn't do :) -- that if > WSM > > > > >>>were to target a web service technology in addition to Axis that > the > > > > >>>.ser file wouldn't necessarily be needed. > > > > >>> > > > > >>> For example, if the WSM annotation processor produced a JSR 101 / > > > > >>>109 deployable unit (or the source files / descriptors for such a > > > > >>>unit), it might include enough information that the .ser file > wouldn't > > > > >>>be needed. In this case, Beehive WSM only runs at build time and > > > > >>>doesn't have a runtime component. > > > > >>> > > > > >>> I agree that there is nothing Axis specific in the .ser file and > was > > > > >>>just making the point that the .ser file might not be needed > depending > > > > >>>on how WSM is integrated into Axis or if / when WSM targets > additional > > > > >>>web service stacks / standards. > > > > >>> > > > > >>> I'm not a web service expert by any means (clearly!), but it > seems > > > > >>>like generation / use of the .ser file should be a *choice* and not > a > > > > >>>requirement. > > > > >>> > > > > >>> Does that make more sense? > > > > >>> > > > > >>>Eddie > > > > >>> > > > > >>> > > > > >>> > > > > >>> > > > > >>>On 6/16/05, Daryoush Mehrtash < [EMAIL PROTECTED]> wrote: > > > > >>> > > > > >>> > > > > >>>>Eddie in the previous thread you said: > > > > >>>> > > > > >>>> The .ser file is an artifact of the fact that the services are > > > > >>>>deployed on Axis. Were the annotation processor targeting JAX-RPC > > > > >>>>directly, the output of the annotation processor might not use the > > > > >>>>.ser file. > > > > >>>> > > > > >>>> > > > > >>>> > > > > >>>>I am not sure I follow your point here. As I said in the previous > thread on > > > > >>>>the .ser file, the original of this was to solve the parameter > name default. > > > > >>>>We started off in WSM by deploying source and compile at runtime > (similar to > > > > >>>>the drop in deployment model in Axis), then evolved into having > seperate > > > > >>>>build time and run time phases that deployed services by doing > reflection on > > > > >>>>.class files, to the current iteration that uses the .ser file > which means > > > > >>>>all the work is done at build time.. > > > > >>>> > > > > >>>>You have looked at the .ser file more closely recently, but AFAIK, > there is > > > > >>>>nothing Axis specifc in it. It is essentially the 3rd itteration > of the > > > > >>>>model we are using to deploy services. It is true that our Axis > > > > >>>>implementation understands the .ser file, but if we were say to > port the WSM > > > > >>>>to XYZ stack, our apprach would be to write an extension in the > XYZ stack > > > > >>>>that would understand the .ser file. > > > > >>>> > > > > >>>>I don't follow what you mean when you say if we were "targeting > JAX-RPC > > > > >>>>directly....". Can you please be more specific here. > > > > >>>> > > > > >>>> > > > > >>>> > > > > >>>>-- > > > > >>>>Daryoush > > > > >>>> > > > > >>>>Weblog: http://perlustration.blogspot.com/ > > > > >>>> > > > > >>>> > > > > >>>> > > > > >>>> > > > > >>-- > > > > >>Daryoush > > > > >> > > > > >>Weblog: http://perlustration.blogspot.com/ > > > > >> > > > > >> > > > > >> > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > Daryoush > > > > > > Weblog: http://perlustration.blogspot.com/ > > > > > > > > > -- > > Daryoush > > Weblog: http://perlustration.blogspot.com/
