On 28 Mar 2011, at 19:19, Alexey Kazakov wrote:
> I'm a bit concerned about you scanning weld* jars - what are you trying to
discover by doing this? Do you have a list of beans discovered this way?
See the list here
http://pastebin.com/U902Din1
And see related JBT issues
https://issues.jboss.org/browse/JBIDE-8017 and
https://issues.jboss.org/browse/JBIDE-8019
Currently this is exposing a lot of classes that are part of the private impl detail of
Weld and won't work at runtime (at least this is only confusing for the user, not
potentially breaking for their app). Really, I think it would be better if you just
scanned cdi-api.jar and weld-api.jar as this exposes the interfaces that are part of the
public API of CDI and Weld.
Currently some of the stuff from Weld's API doesn't have qualifiers on the
interfaces (e.g. HttpConversationContext should be @Default @Http) but file a JIRA to get
those added. You will also need some "special" logic here as these are of course
interfaces which aren't normally beans.
> BTW Wweld-extensions doesn't exist anymore.
>
> No documented way to do this right now, but I'm also not sure of a good way to do
this for the reasons below. We do need something though, I agree. Can you make a CDI issue
for this, so it doesn't fall off our radar?
We have an issue in Weld Jira -
https://issues.jboss.org/browse/WELD-815
Should we create another one against CDI?
> Thanks!
>
> On 25 Mar 2011, at 18:22, Alexey Kazakov wrote:
>
>> We are going to support Seam 3 extensions (such as @Veto, generic, ...) so we
don't need to have some extra meta for such beans.
>> We are going to look at META-INF/services/javax.enterprise.inject.spi.Extension
and handle all the known extensions properly.
>> But is it enough for Seam 3? For instance for weld we had to scan
*weld*.jar's in a special way since they don't have beans.xml. But some of those
beans we should not load (for example we don't load weld-extensions*.jar). How we
supposed to recognize such beans in design time? Is there any documented way to do it?
>>
>>
>>
>> On 03/25/2011 03:37 AM, Pete Muir wrote:
>>> I thought the plan was for JBDS to natively understand Solder annotations to
overcome this problem.
>>>
>>> I really don't think that forcing some xml file on extension developers
is very clever - either they would have to use this as the canonical source of info in
which case we're back to programming in XML and it doesn't look good when people
ask for examples of using CDI extensions, or we have to keep this stuff in sync.
>>>
>>> On 24 Mar 2011, at 20:56, Max Rydahl Andersen wrote:
>>>
>>>> Hi,
>>>>
>>>> Talking with Seam/CDI tooling team at EclipseCon and we are still in the
dark on how tooling are supposed to identify CDI extensions that are registered
programmatically and often does not have a beans.xml to "mark" them.
>>>>
>>>> Today we do it by simply scanning jars with *weld*.jar naming pattern
(very brittle and not good for 3rd party extensions).
>>>>
>>>> Furthermore we also have a list of classes to include/exclude since some
components in these jars aren't CDI compliant.
>>>>
>>>> How do we go about identifying these things ?
>>>>
>>>> The idea discussed with Dan/Pete on this topic previously were to add a
design-beans.xml
>>>> and use that as a marker + list the classes we should load/configure as
possible injection/navigation candidates in the tooling.
>>>>
>>>> I was hoping this were settled before Seam 3 GA but it seem to fallen
through the cracks ?
>>>>
>>>> Something I missed ?
>>>>
>>>> /max
>>>>
http://about.me/maxandersen
>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> seam-dev mailing list
>>>> seam-dev(a)lists.jboss.org
>>>>
https://lists.jboss.org/mailman/listinfo/seam-dev