API for dispatching of async events
by Martin Fryč
Hi all,
Is it possible to have some API for applications to provide policy which
will decide which thread pool will be used for which type of events?
If all events share only one thread pool dedicated to processing of all
async event, usage of this type of events is very limited. For example:
ValidateTransactionDataEvent observed by more that one "application module"
LimitVerification module
AccessVerification module
...
LogTransactionEvent observed by some other modules
TechnicalLog module (could be blocked in IO)
If async events will be processed in similar way as async EJB methods -
usually implemented in app servers as one shared thread pool with limited
application control (discard policy, ...), both of these events will share
one thread pool and some type of events could fully blocked it and "stop"
application.
If threre will be some policy API like:
java.util.concurrent.ExecutorService dispatch(T event, Annotation...
qualifiers)
it will allow application to decide which thread pool should be used for
which type of event.
In EE environment, it must be ManagedExecutorService looked it up from
JNDI, in SE environment it could be ExecutorService created for
applications needs.
Martin
9 years, 12 months
[JBoss JIRA] (CDI-517) assignability to parameterized required type
by Jozef Hartinger (JIRA)
[ https://issues.jboss.org/browse/CDI-517?page=com.atlassian.jira.plugin.sy... ]
Jozef Hartinger commented on CDI-517:
-------------------------------------
{quote}2 days before the CDI-1.1 spec went PDF{quote}
False. See Martin's comment for details.
{quote}backward-incomatible change was made{quote}
False. CDI 1.0 did not allow this. Therefore, specifying this in CDI 1.1 is backward compatible from the spec point of view.
{quote}not compatible with the JavaEE6 RI and the CDI-1.0 RI where this was explicitly allowed.{quote}
False. It was never *explicitly allowed*. It was *implicity* allowed by a bug in CDI RI.
Now to get to your point the usage of "raw references to generic types" (called simply raw types hereafter) is discouraged by the JLS, supported only to provide compatibility with legacy pre Java 1.5 code and generates a compiler warning. Therefore, people should not be using it in the first place. You're right that fixing the Weld bug caused a few problems here and there where people were still using raw types. This is unfortunate but hardly anything can be done about it at this point especially given that this was already dealt with in CDI-304.
> assignability to parameterized required type
> --------------------------------------------
>
> Key: CDI-517
> URL: https://issues.jboss.org/browse/CDI-517
> Project: CDI Specification Issues
> Issue Type: Bug
> Components: Resolution
> Affects Versions: 1.1.PFD, 1.2.Final
> Reporter: Mark Struberg
>
> 2 days before the CDI-1.1 spec went PDF the following backward-incomatible change was made:
> {quote}
> -A raw bean type is considered assignable to a parameterized required type if the raw types are identical.
> + A raw bean type is considered assignable to a parameterized required type if the raw types are identical and all type parameters of the bean type are either unbounded type variables or java.lang.Object.
> {quote}
> This breaks a lot of projects and also is also not compatible with the JavaEE6 RI and the CDI-1.0 RI where this was explicitly allowed.
> This is a follow up to CDI-304.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 12 months
Next CDI meeting tuesday 17th
by Antoine Sabot-Durand
Hi All,
So we decided to move our weekly meeting on Tuesday at the same time (6:00pm CET). So Let’s meet next Tuesday with following point and action :
- Deciding last points for Java SE boot. John Ament is on the topic. If you need help or reviewer John let us know.
- Closing the Async Event chapter. I’m completing my Yet Another Doc On Async Event to put all the point we agreed on and will launch the final discussion points in the coming days
- Date for releasing the Early Draft 1 of CDI 2.0. The initial idea was to publish it during march, but I think it’s more realistic to aim mid-april. Let’s discuss the content and release fate of it.
Antoine,
10 years
[JBoss JIRA] (CDI-517) assignability to parameterized required type
by Martin Kouba (JIRA)
[ https://issues.jboss.org/browse/CDI-517?page=com.atlassian.jira.plugin.sy... ]
Martin Kouba commented on CDI-517:
----------------------------------
bq. Check out my sample app. It runs fine on Weld-1.1.23.Final but is broken in Weld-2.
This is expected.
bq. If there would be a working CDI-1.0 TCK test this would mean that Weld-1 does not pass the TCK.
Could you be more specific? What does it mean _"returning a ParameterizedType does NOT work in the EE6 RI"_? There is no test for assignability of a raw return type to a parameterized required type. But there's a test for assignability of a parameterized return type to a parameterized required type.
> assignability to parameterized required type
> --------------------------------------------
>
> Key: CDI-517
> URL: https://issues.jboss.org/browse/CDI-517
> Project: CDI Specification Issues
> Issue Type: Bug
> Components: Resolution
> Affects Versions: 1.1.PFD, 1.2.Final
> Reporter: Mark Struberg
>
> 2 days before the CDI-1.1 spec went PDF the following backward-incomatible change was made:
> {quote}
> -A raw bean type is considered assignable to a parameterized required type if the raw types are identical.
> + A raw bean type is considered assignable to a parameterized required type if the raw types are identical and all type parameters of the bean type are either unbounded type variables or java.lang.Object.
> {quote}
> This breaks a lot of projects and also is also not compatible with the JavaEE6 RI and the CDI-1.0 RI where this was explicitly allowed.
> This is a follow up to CDI-304.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
10 years
[JBoss JIRA] (CDI-517) assignability to parameterized required type
by Mark Struberg (JIRA)
[ https://issues.jboss.org/browse/CDI-517?page=com.atlassian.jira.plugin.sy... ]
Mark Struberg commented on CDI-517:
-----------------------------------
This is close to impossible. Check out my sample app. It runs fine on Weld-1.1.23.Final but is broken in Weld-2. If there would be a working CDI-1.0 TCK test this would mean that Weld-1 does not pass the TCK. That's highly unlikely...
> assignability to parameterized required type
> --------------------------------------------
>
> Key: CDI-517
> URL: https://issues.jboss.org/browse/CDI-517
> Project: CDI Specification Issues
> Issue Type: Bug
> Components: Resolution
> Affects Versions: 1.1.PFD, 1.2.Final
> Reporter: Mark Struberg
>
> 2 days before the CDI-1.1 spec went PDF the following backward-incomatible change was made:
> {quote}
> -A raw bean type is considered assignable to a parameterized required type if the raw types are identical.
> + A raw bean type is considered assignable to a parameterized required type if the raw types are identical and all type parameters of the bean type are either unbounded type variables or java.lang.Object.
> {quote}
> This breaks a lot of projects and also is also not compatible with the JavaEE6 RI and the CDI-1.0 RI where this was explicitly allowed.
> This is a follow up to CDI-304.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
10 years
Re: [cdi-dev] Changing our meeting time slot?
by Werner Keil
Hi,
Just filled out my preferences. Note, the strong occurrence of 2-3 calls
(EC/JSR 364 and 362) makes Tue hard for me, especially the 6pm slot. As of
now the client's site and firewall blocks everything including the web IRC
clients. Which is why 8pm is the safer option (I am home practically every
day before 8) for the next few months.
Werner
On Tue, Mar 10, 2015 at 9:48 AM, <cdi-dev-request(a)lists.jboss.org> wrote:
> Send cdi-dev mailing list submissions to
> cdi-dev(a)lists.jboss.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://lists.jboss.org/mailman/listinfo/cdi-dev
> or, via email, send a message with subject or body 'help' to
> cdi-dev-request(a)lists.jboss.org
>
> You can reach the person managing the list at
> cdi-dev-owner(a)lists.jboss.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of cdi-dev digest..."
>
>
> Today's Topics:
>
> 1. Re: [weld-dev] How to skip CDI injection if a property is not
> configured in batch application? (Jozef Hartinger)
> 2. Re: [weld-dev] How to skip CDI injection if a property is not
> configured in batch application? (Jozef Hartinger)
> 3. Changing our meeting time slot? (Antoine Sabot-Durand)
> 4. [JBoss JIRA] (CDI-517) assignability to parameterized
> required type (Mark Struberg (JIRA))
> 5. [JBoss JIRA] (CDI-517) assignability to parameterized
> required type (Mark Struberg (JIRA))
> 6. [JBoss JIRA] (CDI-517) assignability to parameterized
> required type (Martin Kouba (JIRA))
> 7. [JBoss JIRA] (CDI-517) assignability to parameterized
> required type (Mark Struberg (JIRA))
>
>
> ----------------------------------------------------------------------
>
>
> Message: 3
> Date: Mon, 9 Mar 2015 11:40:27 +0100
> From: Antoine Sabot-Durand <antoine(a)sabot-durand.net>
> Subject: [cdi-dev] Changing our meeting time slot?
> To: cdi-dev <cdi-dev(a)lists.jboss.org>
> Message-ID: <FA84829E-B403-4EFE-8739-24EC8521933D(a)sabot-durand.net>
> Content-Type: text/plain; charset="utf-8"
>
> Hi all,
>
> Following last week discussion, you?ll find a Doodle link below to choose
> your the best time slot for our meeting. I propose time slot on several
> days for 6-7pm CET or 8-9pm CET (I?m usually not available between 7-8pm).
> I took into consideration USA and Europe (majority of us) TZ.
> Please fill the doodle so we could change our meeting slot and have more
> people able to join.
>
> http://doodle.com/izh845adznk37vww <http://doodle.com/izh845adznk37vww>
>
> thanks
>
> Antoine
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:
> http://lists.jboss.org/pipermail/cdi-dev/attachments/20150309/90a37dbe/at...
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: signature.asc
> Type: application/pgp-signature
> Size: 495 bytes
> Desc: Message signed with OpenPGP using GPGMail
> Url :
> http://lists.jboss.org/pipermail/cdi-dev/attachments/20150309/90a37dbe/at...
>
> ------------------------------
> _______________________________________________
> cdi-dev mailing list
> cdi-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/cdi-dev
>
> Note that for all code provided on this list, the provider licenses the
> code under the Apache License, Version 2 (
> http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas
> provided on this list, the provider waives all patent and other
> intellectual property rights inherent in such information.
>
> End of cdi-dev Digest, Vol 52, Issue 45
> ***************************************
>
10 years
[JBoss JIRA] (CDI-517) assignability to parameterized required type
by Martin Kouba (JIRA)
[ https://issues.jboss.org/browse/CDI-517?page=com.atlassian.jira.plugin.sy... ]
Martin Kouba commented on CDI-517:
----------------------------------
bq. It's at least fine from a pure Java aspect
Works but it's not recommended and you get a compiler warning.
bq. Also note that returning a ParameterizedType does NOT work in the EE6 RI, nor in WebSphere and also not in older JBossAS versions.
I don't understand. There is a TCK test (since 1.0.x) for a producer method which returns a parameterized type: [ProducerMethodDefinitionTest#testParameterizedReturnType()|https://github...].
> assignability to parameterized required type
> --------------------------------------------
>
> Key: CDI-517
> URL: https://issues.jboss.org/browse/CDI-517
> Project: CDI Specification Issues
> Issue Type: Bug
> Components: Resolution
> Affects Versions: 1.1.PFD, 1.2.Final
> Reporter: Mark Struberg
>
> 2 days before the CDI-1.1 spec went PDF the following backward-incomatible change was made:
> {quote}
> -A raw bean type is considered assignable to a parameterized required type if the raw types are identical.
> + A raw bean type is considered assignable to a parameterized required type if the raw types are identical and all type parameters of the bean type are either unbounded type variables or java.lang.Object.
> {quote}
> This breaks a lot of projects and also is also not compatible with the JavaEE6 RI and the CDI-1.0 RI where this was explicitly allowed.
> This is a follow up to CDI-304.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
10 years
[JBoss JIRA] (CDI-517) assignability to parameterized required type
by Mark Struberg (JIRA)
[ https://issues.jboss.org/browse/CDI-517?page=com.atlassian.jira.plugin.sy... ]
Mark Struberg edited comment on CDI-517 at 3/10/15 4:48 AM:
------------------------------------------------------------
It's at least fine from a pure Java aspect. See the discussion over at DeltaSpike LONG before this change got made to the spec.
The problem is that there are many libraries and customer projects out there which behave that way (returning a raw type in the producer) and I gave all the arguments already in CDI-304.
Also note that returning a ParameterizedType does NOT work in the EE6 RI, nor in WebSphere and also not in older JBossAS versions. Been there, done that...
was (Author: struberg):
It's at least fine from a pure Java aspect. See the discussion over at DeltaSpike LONG before this change got made to the spec.
The problem is that there are many libraries and customer projects out there which behave that way (returning a raw type in the producer) and I gave all the arguments already in CID-304.
Also note that returning a ParameterizedType does NOT work in the EE6 RI, nor in WebSphere and also not in older JBossAS versions. Been there, done that...
> assignability to parameterized required type
> --------------------------------------------
>
> Key: CDI-517
> URL: https://issues.jboss.org/browse/CDI-517
> Project: CDI Specification Issues
> Issue Type: Bug
> Components: Resolution
> Affects Versions: 1.1.PFD, 1.2.Final
> Reporter: Mark Struberg
>
> 2 days before the CDI-1.1 spec went PDF the following backward-incomatible change was made:
> {quote}
> -A raw bean type is considered assignable to a parameterized required type if the raw types are identical.
> + A raw bean type is considered assignable to a parameterized required type if the raw types are identical and all type parameters of the bean type are either unbounded type variables or java.lang.Object.
> {quote}
> This breaks a lot of projects and also is also not compatible with the JavaEE6 RI and the CDI-1.0 RI where this was explicitly allowed.
> This is a follow up to CDI-304.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
10 years
[JBoss JIRA] (CDI-517) assignability to parameterized required type
by Mark Struberg (JIRA)
[ https://issues.jboss.org/browse/CDI-517?page=com.atlassian.jira.plugin.sy... ]
Mark Struberg commented on CDI-517:
-----------------------------------
It's at least fine from a pure Java aspect. See the discussion over at DeltaSpike LONG before this change got made to the spec.
The problem is that there are many libraries and customer projects out there which behave that way (returning a raw type in the producer) and I gave all the arguments already in CID-304.
Also note that returning a ParameterizedType does NOT work in the EE6 RI, nor in WebSphere and also not in older JBossAS versions. Been there, done that...
> assignability to parameterized required type
> --------------------------------------------
>
> Key: CDI-517
> URL: https://issues.jboss.org/browse/CDI-517
> Project: CDI Specification Issues
> Issue Type: Bug
> Components: Resolution
> Affects Versions: 1.1.PFD, 1.2.Final
> Reporter: Mark Struberg
>
> 2 days before the CDI-1.1 spec went PDF the following backward-incomatible change was made:
> {quote}
> -A raw bean type is considered assignable to a parameterized required type if the raw types are identical.
> + A raw bean type is considered assignable to a parameterized required type if the raw types are identical and all type parameters of the bean type are either unbounded type variables or java.lang.Object.
> {quote}
> This breaks a lot of projects and also is also not compatible with the JavaEE6 RI and the CDI-1.0 RI where this was explicitly allowed.
> This is a follow up to CDI-304.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
10 years
[JBoss JIRA] (CDI-517) assignability to parameterized required type
by Martin Kouba (JIRA)
[ https://issues.jboss.org/browse/CDI-517?page=com.atlassian.jira.plugin.sy... ]
Martin Kouba commented on CDI-517:
----------------------------------
Well, it was added in this commit [42f5f8ec974e24dfdca5c34eadd3f85785077ca5|https://github.com/cdi-spec/cdi/...] (authored on 25 Feb 2013), the Proposed Final Draft was published on *06 Mar, 2013*, and the Final Release was on *24 May, 2013*. That's enough time for revision. It was also discussed in [DELTASPIKE-295|https://issues.apache.org/jira/browse/DELTASPIKE-295]. So I don't understand your "2 days" sentence.
In any case, it is incompatible in the sense that it *was not defined in CDI 1.0*. And in my opinion it was a mistake.
Also note that it's very easy to fix (and follow the rules explicitly defined in the CDI spec):
http://grepcode.com/file/repo1.maven.org/maven2/org.apache.deltaspike.mod...
Honestly Mark, do you think it's correct to allow something like this?
{code:java}
class Foo<T> {
private T ref;
public Foo(T ref) {
this.ref = ref;
}
}
@Produces
Foo createFoo() {
Foo<Integer> foo = new Foo<Integer>(10);
return foo;
}
// The producer would be assignable...
@Inject
Foo<String> stringFoo;
{code}
> assignability to parameterized required type
> --------------------------------------------
>
> Key: CDI-517
> URL: https://issues.jboss.org/browse/CDI-517
> Project: CDI Specification Issues
> Issue Type: Bug
> Components: Resolution
> Affects Versions: 1.1.PFD, 1.2.Final
> Reporter: Mark Struberg
>
> 2 days before the CDI-1.1 spec went PDF the following backward-incomatible change was made:
> {quote}
> -A raw bean type is considered assignable to a parameterized required type if the raw types are identical.
> + A raw bean type is considered assignable to a parameterized required type if the raw types are identical and all type parameters of the bean type are either unbounded type variables or java.lang.Object.
> {quote}
> This breaks a lot of projects and also is also not compatible with the JavaEE6 RI and the CDI-1.0 RI where this was explicitly allowed.
> This is a follow up to CDI-304.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
10 years
