In conjunction with this proposal, I would like to propose that we have a "special" XML namespace, which instead of mapping to a single package, maps to several packages. This is an ease of use feature for commonly used types. The namespace "urn:java:javax" is a shortcut that may be used to refer to types in any of the following packages (as long as there is no ambiguity): javax.annotation javax.interceptor javax.decorator javax.context javax.inject javax.stereotype javax.event javax.ejb javax.xml.ws javax.persistence Potentially even: javax.jms javax.sql javax.annotation.security JAX-RS On Tue, Jan 20, 2009 at 5:18 PM, Gavin King <gavin(a)hibernate.org&gt; wrote: > Here's a proposal for API repackaging: > > javax.annotation: (existing package) > @NonBinding > > javax.interceptor: (existing package) > @Interceptor > @InterceptorBindingType > > javax.decorator: (decorators) > @Decorator > @Decorates > > javax.stereotype: (stereotypes) > @Stereotype > @Model > > javax.context: (scopes and contexts) > @ScopeType > @ApplicationScoped > @RequestScoped > @SessionScoped > @ConversationScoped > Context > Contextual > ContextNotActiveException > Conversation > > javax.inject: (injection, binding types, deployment types) > @BindingType > @DeploymentType > @Named > @Initializer > @New > @Specializes > @Realizes > @Current > @Production > @Standard > @Produces > @Disposes > @Obtains > Instance > DefinitionException > DeploymentException > ExecutionException > IllegalProductException > CreationException > AmbiguousDependencyException > DuplicateBindingTypeException > InconsistentSpecializationException > NullableDependencyException > UnproxyableDependencyException > UnsatisfiedDependencyException > UnserializableDependencyException > TypeLiteral > AnnotationLiteral > > javax.inject.manager: (framework integration SPI) > @Initialized > @Deployed > Bean > InjectionPoint > Decorator > Interceptor > InterceptionType > Manager > > javax.event: (events) > @Observes > @Asynchronously > @IfExists > @AfterTransactionCompletion > @AfterTransactionFailure > @AfterTransactionSuccess > @BeforeTransactionCompletion > @Fires > Event > Observer > ObserverException > > > The types I'm most uncomfortable with are TypeLiteral and > AnnotationLiteral, which aren't really specific to injection. I wonder > if there's some other place they could go....? > > Arguably @Named belongs somewhere else.... > > And there's a piece of me which wants to put @Realizes and > @Specializes in javax.stereotype, for some reason which I can't quite > put my finger on.... > > Thoughts? > > -- > Gavin King > gavin.king(a)gmail.com > http://in.relation.to/Bloggers/Gavin > http://hibernate.org > http://seamframework.org > -- Gavin King gavin.king(a)gmail.com http://in.relation.to/Bloggers/Gavin http://hibernate.org http://seamframework.org

On Jan 19, 2009, at 10:33 PM, Gavin King wrote: > In conjunction with this proposal, I would like to propose that we > have a "special" XML namespace, which instead of mapping to a single > package, maps to several packages. This is an ease of use feature for > commonly used types. I like the idea, but I'd want a consistent mechanism as an extension of normal WebBeans urn:java handling: For example, Given xmlns:foo="urn:java:com.foo" 1. <foo:MyBar> - WebBeans looks for com.foo.MyBar for a class or annotation (same as current rule). 2. if com.foo has an "import list" of packages, then WebBeans also looks in those packages. As long as the spec defines "urn:java:javax.javaee" along that kind of rule, the "package import" doesn't need to be an explicit part of the current spec. Just as long as it could be generalized for a future spec. > The namespace "urn:java:javax" is a shortcut that may be used to refer > to types in any of the following packages (as long as there is no > ambiguity): It would need to be "urn:java:javax.javaee" because the JavaEE specs don't have ownership over all of "urn:java:javax". > > Potentially even: > > javax.jms > javax.sql > javax.annotation.security > JAX-RS Eventually, javax.servlet.http.annotation.WebServlet :) <qa:MyServlet> <javaee:WebServlet value="/foo"/> </qa:MyServlet> -- Scott > > > > On Tue, Jan 20, 2009 at 5:18 PM, Gavin King <gavin(a)hibernate.org&gt; wrote: >> >> Here's a proposal for API repackaging: >> >> javax.annotation: (existing package) >> @NonBinding >> >> javax.interceptor: (existing package) >> @Interceptor >> @InterceptorBindingType >> >> javax.decorator: (decorators) >> @Decorator >> @Decorates >> >> javax.stereotype: (stereotypes) >> @Stereotype >> @Model >> >> javax.context: (scopes and contexts) >> @ScopeType >> @ApplicationScoped >> @RequestScoped >> @SessionScoped >> @ConversationScoped >> Context >> Contextual >> ContextNotActiveException >> Conversation >> >> javax.inject: (injection, binding types, deployment types) >> @BindingType >> @DeploymentType >> @Named >> @Initializer >> @New >> @Specializes >> @Realizes >> @Current >> @Production >> @Standard >> @Produces >> @Disposes >> @Obtains >> Instance >> DefinitionException >> DeploymentException >> ExecutionException >> IllegalProductException >> CreationException >> AmbiguousDependencyException >> DuplicateBindingTypeException >> InconsistentSpecializationException >> NullableDependencyException >> UnproxyableDependencyException >> UnsatisfiedDependencyException >> UnserializableDependencyException >> TypeLiteral >> AnnotationLiteral >> >> javax.inject.manager: (framework integration SPI) >> @Initialized >> @Deployed >> Bean >> InjectionPoint >> Decorator >> Interceptor >> InterceptionType >> Manager >> >> javax.event: (events) >> @Observes >> @Asynchronously >> @IfExists >> @AfterTransactionCompletion >> @AfterTransactionFailure >> @AfterTransactionSuccess >> @BeforeTransactionCompletion >> @Fires >> Event >> Observer >> ObserverException >> >> >> The types I'm most uncomfortable with are TypeLiteral and >> AnnotationLiteral, which aren't really specific to injection. I wonder >> if there's some other place they could go....? >> >> Arguably @Named belongs somewhere else.... >> >> And there's a piece of me which wants to put @Realizes and >> @Specializes in javax.stereotype, for some reason which I can't quite >> put my finger on.... >> >> Thoughts? >> >> -- >> Gavin King >> gavin.king(a)gmail.com >> http://in.relation.to/Bloggers/Gavin >> http://hibernate.org >> http://seamframework.org >> > > > > -- > Gavin King > gavin.king(a)gmail.com > http://in.relation.to/Bloggers/Gavin > http://hibernate.org > http://seamframework.org > > _______________________________________________ webbeans-dev mailing list webbeans-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/webbeans-dev

On Jan 21, 2009, at 1:48 PM, Gavin King wrote: > How would the "import list" be specified? I'd assume a text file in the classpath like javax/javaee/urn.java.imports or META-INF, if that's more appropriate. It's just a list of packages, so the file is trivial. I believe JAXB has a similar kind of file called jaxb.index, but I can't remember where it lives or exactly what it contains. As long as an IDE or WebBeans implementation can grab and parse the file using ClassLoader.getResource, it doesn't really matter. -- Scott > > > On Thu, Jan 22, 2009 at 4:55 AM, Scott Ferguson <ferg(a)caucho.com&gt; wrote: >> >> On Jan 19, 2009, at 10:33 PM, Gavin King wrote: >> >>> In conjunction with this proposal, I would like to propose that we >>> have a "special" XML namespace, which instead of mapping to a single >>> package, maps to several packages. This is an ease of use feature for >>> commonly used types. >> >> I like the idea, but I'd want a consistent mechanism as an extension of >> normal WebBeans urn:java handling: >> >> For example, >> >> Given xmlns:foo="urn:java:com.foo" >> >> 1. <foo:MyBar> - WebBeans looks for com.foo.MyBar for a class or >> annotation >> (same as current rule). >> >> 2. if com.foo has an "import list" of packages, then WebBeans also looks >> in >> those packages. >> >> As long as the spec defines "urn:java:javax.javaee" along that kind of >> rule, >> the "package import" doesn't need to be an explicit part of the current >> spec. Just as long as it could be generalized for a future spec. >> >>> The namespace "urn:java:javax" is a shortcut that may be used to refer >>> to types in any of the following packages (as long as there is no >>> ambiguity): >> >> It would need to be "urn:java:javax.javaee" because the JavaEE specs >> don't >> have ownership over all of "urn:java:javax". >> >>> >>> Potentially even: >>> >>> javax.jms >>> javax.sql >>> javax.annotation.security >>> JAX-RS >> >> Eventually, javax.servlet.http.annotation.WebServlet :) >> >> <qa:MyServlet> >> <javaee:WebServlet value="/foo"/> >> </qa:MyServlet> >> >> -- Scott >> >>> >>> >>> >>> On Tue, Jan 20, 2009 at 5:18 PM, Gavin King <gavin(a)hibernate.org&gt; wrote: >>>> >>>> Here's a proposal for API repackaging: >>>> >>>> javax.annotation: (existing package) >>>> @NonBinding >>>> >>>> javax.interceptor: (existing package) >>>> @Interceptor >>>> @InterceptorBindingType >>>> >>>> javax.decorator: (decorators) >>>> @Decorator >>>> @Decorates >>>> >>>> javax.stereotype: (stereotypes) >>>> @Stereotype >>>> @Model >>>> >>>> javax.context: (scopes and contexts) >>>> @ScopeType >>>> @ApplicationScoped >>>> @RequestScoped >>>> @SessionScoped >>>> @ConversationScoped >>>> Context >>>> Contextual >>>> ContextNotActiveException >>>> Conversation >>>> >>>> javax.inject: (injection, binding types, deployment types) >>>> @BindingType >>>> @DeploymentType >>>> @Named >>>> @Initializer >>>> @New >>>> @Specializes >>>> @Realizes >>>> @Current >>>> @Production >>>> @Standard >>>> @Produces >>>> @Disposes >>>> @Obtains >>>> Instance >>>> DefinitionException >>>> DeploymentException >>>> ExecutionException >>>> IllegalProductException >>>> CreationException >>>> AmbiguousDependencyException >>>> DuplicateBindingTypeException >>>> InconsistentSpecializationException >>>> NullableDependencyException >>>> UnproxyableDependencyException >>>> UnsatisfiedDependencyException >>>> UnserializableDependencyException >>>> TypeLiteral >>>> AnnotationLiteral >>>> >>>> javax.inject.manager: (framework integration SPI) >>>> @Initialized >>>> @Deployed >>>> Bean >>>> InjectionPoint >>>> Decorator >>>> Interceptor >>>> InterceptionType >>>> Manager >>>> >>>> javax.event: (events) >>>> @Observes >>>> @Asynchronously >>>> @IfExists >>>> @AfterTransactionCompletion >>>> @AfterTransactionFailure >>>> @AfterTransactionSuccess >>>> @BeforeTransactionCompletion >>>> @Fires >>>> Event >>>> Observer >>>> ObserverException >>>> >>>> >>>> The types I'm most uncomfortable with are TypeLiteral and >>>> AnnotationLiteral, which aren't really specific to injection. I wonder >>>> if there's some other place they could go....? >>>> >>>> Arguably @Named belongs somewhere else.... >>>> >>>> And there's a piece of me which wants to put @Realizes and >>>> @Specializes in javax.stereotype, for some reason which I can't quite >>>> put my finger on.... >>>> >>>> Thoughts? >>>> >>>> -- >>>> Gavin King >>>> gavin.king(a)gmail.com >>>> http://in.relation.to/Bloggers/Gavin >>>> http://hibernate.org >>>> http://seamframework.org >>>> >>> >>> >>> >>> -- >>> Gavin King >>> gavin.king(a)gmail.com >>> http://in.relation.to/Bloggers/Gavin >>> http://hibernate.org >>> http://seamframework.org >>> >>> >> >> _______________________________________________ >> webbeans-dev mailing list >> webbeans-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/webbeans-dev >> > > > > -- > Gavin King > gavin.king(a)gmail.com > http://in.relation.to/Bloggers/Gavin > http://hibernate.org > http://seamframework.org > > _______________________________________________ webbeans-dev mailing list webbeans-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/webbeans-dev

https://jira.jboss.org/jira/browse/WBRI-117 we'll do this for alpha1. On 22 Jan 2009, at 00:59, Gavin King wrote: > Yes, that's also what I concluded. > > On Thu, Jan 22, 2009 at 9:09 AM, Scott Ferguson <ferg(a)caucho.com&gt; > wrote: >> >> On Jan 21, 2009, at 1:48 PM, Gavin King wrote: >> >>> How would the "import list" be specified? >> >> I'd assume a text file in the classpath like javax/javaee/ >> urn.java.imports >> or META-INF, if that's more appropriate. It's just a list of >> packages, so >> the file is trivial. >> >> I believe JAXB has a similar kind of file called jaxb.index, but I >> can't >> remember where it lives or exactly what it contains. >> >> As long as an IDE or WebBeans implementation can grab and parse >> the file >> using ClassLoader.getResource, it doesn't really matter. >> >> -- Scott >> >>> >>> >>> On Thu, Jan 22, 2009 at 4:55 AM, Scott Ferguson <ferg(a)caucho.com&gt; >>> wrote: >>>> >>>> On Jan 19, 2009, at 10:33 PM, Gavin King wrote: >>>> >>>>> In conjunction with this proposal, I would like to propose that >>>>> we >>>>> have a "special" XML namespace, which instead of mapping to a >>>>> single >>>>> package, maps to several packages. This is an ease of use >>>>> feature for >>>>> commonly used types. >>>> >>>> I like the idea, but I'd want a consistent mechanism as an >>>> extension of >>>> normal WebBeans urn:java handling: >>>> >>>> For example, >>>> >>>> Given xmlns:foo="urn:java:com.foo" >>>> >>>> 1. <foo:MyBar> - WebBeans looks for com.foo.MyBar for a class or >>>> annotation >>>> (same as current rule). >>>> >>>> 2. if com.foo has an "import list" of packages, then WebBeans >>>> also looks >>>> in >>>> those packages. >>>> >>>> As long as the spec defines "urn:java:javax.javaee" along that >>>> kind of >>>> rule, >>>> the "package import" doesn't need to be an explicit part of the >>>> current >>>> spec. Just as long as it could be generalized for a future spec. >>>> >>>>> The namespace "urn:java:javax" is a shortcut that may be used >>>>> to refer >>>>> to types in any of the following packages (as long as there is no >>>>> ambiguity): >>>> >>>> It would need to be "urn:java:javax.javaee" because the JavaEE >>>> specs >>>> don't >>>> have ownership over all of "urn:java:javax". >>>> >>>>> >>>>> Potentially even: >>>>> >>>>> javax.jms >>>>> javax.sql >>>>> javax.annotation.security >>>>> JAX-RS >>>> >>>> Eventually, javax.servlet.http.annotation.WebServlet :) >>>> >>>> <qa:MyServlet> >>>> <javaee:WebServlet value="/foo"/> >>>> </qa:MyServlet> >>>> >>>> -- Scott >>>> >>>>> >>>>> >>>>> >>>>> On Tue, Jan 20, 2009 at 5:18 PM, Gavin King >>>>> <gavin(a)hibernate.org&gt; wrote: >>>>>> >>>>>> Here's a proposal for API repackaging: >>>>>> >>>>>> javax.annotation: (existing package) >>>>>> @NonBinding >>>>>> >>>>>> javax.interceptor: (existing package) >>>>>> @Interceptor >>>>>> @InterceptorBindingType >>>>>> >>>>>> javax.decorator: (decorators) >>>>>> @Decorator >>>>>> @Decorates >>>>>> >>>>>> javax.stereotype: (stereotypes) >>>>>> @Stereotype >>>>>> @Model >>>>>> >>>>>> javax.context: (scopes and contexts) >>>>>> @ScopeType >>>>>> @ApplicationScoped >>>>>> @RequestScoped >>>>>> @SessionScoped >>>>>> @ConversationScoped >>>>>> Context >>>>>> Contextual >>>>>> ContextNotActiveException >>>>>> Conversation >>>>>> >>>>>> javax.inject: (injection, binding types, deployment types) >>>>>> @BindingType >>>>>> @DeploymentType >>>>>> @Named >>>>>> @Initializer >>>>>> @New >>>>>> @Specializes >>>>>> @Realizes >>>>>> @Current >>>>>> @Production >>>>>> @Standard >>>>>> @Produces >>>>>> @Disposes >>>>>> @Obtains >>>>>> Instance >>>>>> DefinitionException >>>>>> DeploymentException >>>>>> ExecutionException >>>>>> IllegalProductException >>>>>> CreationException >>>>>> AmbiguousDependencyException >>>>>> DuplicateBindingTypeException >>>>>> InconsistentSpecializationException >>>>>> NullableDependencyException >>>>>> UnproxyableDependencyException >>>>>> UnsatisfiedDependencyException >>>>>> UnserializableDependencyException >>>>>> TypeLiteral >>>>>> AnnotationLiteral >>>>>> >>>>>> javax.inject.manager: (framework integration SPI) >>>>>> @Initialized >>>>>> @Deployed >>>>>> Bean >>>>>> InjectionPoint >>>>>> Decorator >>>>>> Interceptor >>>>>> InterceptionType >>>>>> Manager >>>>>> >>>>>> javax.event: (events) >>>>>> @Observes >>>>>> @Asynchronously >>>>>> @IfExists >>>>>> @AfterTransactionCompletion >>>>>> @AfterTransactionFailure >>>>>> @AfterTransactionSuccess >>>>>> @BeforeTransactionCompletion >>>>>> @Fires >>>>>> Event >>>>>> Observer >>>>>> ObserverException >>>>>> >>>>>> >>>>>> The types I'm most uncomfortable with are TypeLiteral and >>>>>> AnnotationLiteral, which aren't really specific to injection. >>>>>> I wonder >>>>>> if there's some other place they could go....? >>>>>> >>>>>> Arguably @Named belongs somewhere else.... >>>>>> >>>>>> And there's a piece of me which wants to put @Realizes and >>>>>> @Specializes in javax.stereotype, for some reason which I >>>>>> can't quite >>>>>> put my finger on.... >>>>>> >>>>>> Thoughts? >>>>>> >>>>>> -- >>>>>> Gavin King >>>>>> gavin.king(a)gmail.com >>>>>> http://in.relation.to/Bloggers/Gavin >>>>>> http://hibernate.org >>>>>> http://seamframework.org >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Gavin King >>>>> gavin.king(a)gmail.com >>>>> http://in.relation.to/Bloggers/Gavin >>>>> http://hibernate.org >>>>> http://seamframework.org >>>>> >>>>> >>>> >>>> _______________________________________________ >>>> webbeans-dev mailing list >>>> webbeans-dev(a)lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/webbeans-dev >>>> >>> >>> >>> >>> -- >>> Gavin King >>> gavin.king(a)gmail.com >>> http://in.relation.to/Bloggers/Gavin >>> http://hibernate.org >>> http://seamframework.org >>> >>> >> >> _______________________________________________ >> webbeans-dev mailing list >> webbeans-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/webbeans-dev >> > > > > -- > Gavin King > gavin.king(a)gmail.com > http://in.relation.to/Bloggers/Gavin > http://hibernate.org > http://seamframework.org > _______________________________________________ > webbeans-dev mailing list > webbeans-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/webbeans-dev _______________________________________________ webbeans-dev mailing list webbeans-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/webbeans-dev

javax.stereotype: (stereotypes) @Stereotype @Model

Arguably @Named belongs somewhere else....

And there's a piece of me which wants to put @Realizes and @Specializes in javax.stereotype, for some reason which I can't quite put my finger on....