[webbeans-dev] Re: Packages proposal

[Gavin King]

Yes, that's also what I concluded.

On Thu, Jan 22, 2009 at 9:09 AM, Scott Ferguson <ferg at caucho.com> 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 at caucho.com> 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 at hibernate.org> 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 at gmail.com
>>>>> http://in.relation.to/Bloggers/Gavin
>>>>> http://hibernate.org
>>>>> http://seamframework.org
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Gavin King
>>>> gavin.king at gmail.com
>>>> http://in.relation.to/Bloggers/Gavin
>>>> http://hibernate.org
>>>> http://seamframework.org
>>>>
>>>>
>>>
>>> _______________________________________________
>>> webbeans-dev mailing list
>>> webbeans-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/webbeans-dev
>>>
>>
>>
>>
>> --
>> Gavin King
>> gavin.king at gmail.com
>> http://in.relation.to/Bloggers/Gavin
>> http://hibernate.org
>> http://seamframework.org
>>
>>
>
> _______________________________________________
> webbeans-dev mailing list
> webbeans-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/webbeans-dev
>



-- 
Gavin King
gavin.king at gmail.com
http://in.relation.to/Bloggers/Gavin
http://hibernate.org
http://seamframework.org