Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cocoon.apache.org
Message-ID: <870156457.1232808120175.JavaMail.jira@brutus>
Date: Sat, 24 Jan 2009 06:42:00 -0800 (PST)
From: "Grzegorz Kossakowski (JIRA)" <jira@apache.org>
To: dev@cocoon.apache.org
Subject: [jira] Issue Comment Edited: (COCOON3-14) Use generics for pipeline
 assembly
In-Reply-To: <1902978338.1232707259648.JavaMail.jira@brutus>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ https://issues.apache.org/jira/browse/COCOON3-14?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12666936#action_12666936 ] 

grek edited comment on COCOON3-14 at 1/24/09 6:41 AM:
----------------------------------------------------------------------

> The supplied patch does not change how the components interact with each other.
> The PipelineComponent interface remains unchanged. 

I didn't formulate my question clearly: what is our intention. Do we want a generic API for event exchange or each pair of components will be dealing with this in it's implementation by doing some of instanceof checks?

>This is always the case when the Pipeline is assembled at runtime from a provided description, like the Sitemap.
> While the PipelineAPI is intended do be used with direct calls from the user's code, we should not forget that automatic pipeline 
> construction using some kind of description is still a valid use case and that basically no assumptions about 
> the actual components can be made in such a case (iow Generics are pretty much worthless for that)

It's not entirely true that generics are worhtless at runtime. Take a look at quick prototype:
{code:title=PipelineComponent.java|borderStyle=solid}
package test;

public interface PipelineComponent<T, U> {
	U execute(T event);
}
{code}

---------------------------------------- TestComponent.java ----------------------------------------
package test;

import java.util.LinkedList;
import java.util.List;

public class TestCompoent implements PipelineComponent<String, List<String>> {
	
	public List<String> execute(String event) {
		List<String> list = new LinkedList<String>();
		list.add(event);
		return list;
	}
	
}

---------------------------------------- main.java ----------------------------------------
package test;

import java.lang.reflect.ParameterizedType;
import java.lang.reflect.Type;

public class main {

	public static void main(String[] args) {
		Type[] interfaces = TestCompoent.class.getGenericInterfaces();
		for (Type i : interfaces) {
			if (i instanceof ParameterizedType) {
				ParameterizedType pt = (ParameterizedType)i;
				if (pt.getRawType().equals(PipelineComponent.class)) {
					Type[] typeArguments = pt.getActualTypeArguments();
					Type input  = typeArguments[0];
					Type output = typeArguments[1];
					System.out.println(TestCompoent.class + " is " +
					" PipelineComponent<" + input + ", " + output + ">");
				}
			}
		}
	}

}


This gives me following output:
class test.TestCompoent is  PipelineComponent<class java.lang.String, java.util.List<java.lang.String>>

My point is that Pipeline *can* and *should* check if it's valid (given components can be combined). Of course this will work only if one component accepts one type of input and produces one type of output but I don't see this as a problem.

      was (Author: grek):
    > The supplied patch does not change how the components interact with each other.
> The PipelineComponent interface remains unchanged. 

I didn't formulate my question clearly: what is our intention. Do we want a generic API for event exchange or each pair of components will be dealing with this in it's implementation by doing some of instanceof checks?

>This is always the case when the Pipeline is assembled at runtime from a provided description, like the Sitemap.
> While the PipelineAPI is intended do be used with direct calls from the user's code, we should not forget that automatic pipeline 
> construction using some kind of description is still a valid use case and that basically no assumptions about 
> the actual components can be made in such a case (iow Generics are pretty much worthless for that)

It's not entirely true that generics are worhtless at runtime. Take a look at quick prototype:
{code}
---------------------------------------- PipelineComponent.java ----------------------------------------
package test;

public interface PipelineComponent<T, U> {
	U execute(T event);
}
{code}

---------------------------------------- TestComponent.java ----------------------------------------
package test;

import java.util.LinkedList;
import java.util.List;

public class TestCompoent implements PipelineComponent<String, List<String>> {
	
	public List<String> execute(String event) {
		List<String> list = new LinkedList<String>();
		list.add(event);
		return list;
	}
	
}

---------------------------------------- main.java ----------------------------------------
package test;

import java.lang.reflect.ParameterizedType;
import java.lang.reflect.Type;

public class main {

	public static void main(String[] args) {
		Type[] interfaces = TestCompoent.class.getGenericInterfaces();
		for (Type i : interfaces) {
			if (i instanceof ParameterizedType) {
				ParameterizedType pt = (ParameterizedType)i;
				if (pt.getRawType().equals(PipelineComponent.class)) {
					Type[] typeArguments = pt.getActualTypeArguments();
					Type input  = typeArguments[0];
					Type output = typeArguments[1];
					System.out.println(TestCompoent.class + " is " +
					" PipelineComponent<" + input + ", " + output + ">");
				}
			}
		}
	}

}


This gives me following output:
class test.TestCompoent is  PipelineComponent<class java.lang.String, java.util.List<java.lang.String>>

My point is that Pipeline *can* and *should* check if it's valid (given components can be combined). Of course this will work only if one component accepts one type of input and produces one type of output but I don't see this as a problem.
  
> Use generics for pipeline assembly
> ----------------------------------
>
>                 Key: COCOON3-14
>                 URL: https://issues.apache.org/jira/browse/COCOON3-14
>             Project: Cocoon 3
>          Issue Type: Improvement
>          Components: cocoon-pipeline
>            Reporter: Carsten Ziegeler
>            Assignee: Cocoon Developers Team
>         Attachments: generics.patch
>
>
> This is a simple patch to add generics to the pipeline interface and impl. With additionally introducing marker interfaces for the component types (SAX, Stax, dom)
> this would allow compile time checks if all components have the correct type when assembling the pipeline.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.