[webbeans-dev] CDI Quartz Extension and SE Example
by Peter Royle
Hi,
I know you're all really busy right now with the spec updates, but
I've got a new extension for possible inclusion into WebBeans, plus a
new example app for SE which uses it.
== Quartz Extension ==
WebBeans-Quartz.zip
The extension is a Quartz extension. It basically fires events @Every
Second, @Every Minute and @Every Hour, which can be observed like so:
public void updateSomething(@Observes @Every Hour hour) { // blah }
On startup the extension first checks for the presence of observers
for each type of event and if there are no observers for a particular
type of event, no events will be scheduled.
I intend to extend it by:
1) introducing a way to define arbitrary schedules (in annotations or
in a properties file which is then referenced by name in an annotation
- which can then be made typesafe by subclassing the annotation). Eg:
package org.jboss.webbeans.extension.scheduler;
public @interface Scheduled {
String name();
}
-----------
public @interface AfterHours extends Scheduled{
String name() default "afterHours";
}
-----------
schedule.properties:
afterHours=0 1 * * * *
-----------
public void batchProcess(@Observes @AfterHours Schedule schedule)
{ ... }
2) Adding whatever is necessary to make this usable in EE environment.
Any pointers?
3) Any other suggestions?
== Memory Graph Example ==
MemoryGrapher.zip
This is another Swing based example, which renders a graph of the VM's
free memory, updating every second and calling garbage collection
every minute using the above extension. It's a nice concise example of
how to bootstrap and shutdown SE, how to observe events and how to use
the injectable logger. Plus everyone loves a pretty graph!
I know there is some obvious clean up work required, and maybe
removing the name Quartz (?) - which I'm happy to do prior to checking
in.
What do you think?
Pete.
16 years, 11 months
[webbeans-dev] event type with type variable
by Dan Allen
In several places, the specification reiterates that an event type may not
contain a type variable. However, it appears that this restriction is only
enforced at runtime when the event object is passed to either Event#fire()
or BeanManager#fireEvent() method. I would suggest that an validation check
be added so that the container detects an illegal Event definition at
deployment type. Here's an example of an illegal definition (from my
understanding):
public class VoterRegistration<T> { ... }
@Any Event<VoterRegistration<Democrat>> democratRegisteredEvent;
-Dan
--
Dan Allen
Senior Software Engineer, Red Hat | Author of Seam in Action
Registered Linux User #231597
http://mojavelinux.com
http://mojavelinux.com/seaminaction
http://in.relation.to/Bloggers/Dan
17 years
[webbeans-dev] Webbeans Junit Runner
by Aslak Knutsen
Hi,
I've written a Junit Runner for Webbeans support in TestCases. The following
features are supported:
- TestCase class field injection
- TestMethod arg injection
- Producers / Observers in the TestCase seems to work without any extras..
- 'Should' run in any EE/Servlet/SE enviroment (Only SE tested at the
moment)
The Runner tries to locate the appropriate BeanManager based on the
following rules in order:
- Lookup "java:comp/BeanManager" via JNDI -> EE enviroment
- If success use that BeanManager.
- Call CurrentManager.rootManager() -> Servlet enviroment / Previously
initiated SE enviroment
- If success use that BeanManager.
- Load class "org.jboss.webbeans.environment.se.StartMain" -> SE enviroment
- If success, initialize the enviroment using StartMain.main(new String[0])
and use CurrentManager.rootManager().
Overrides the default Junit TestMethod validation with a new set of rules:
- validatePublicVoid (default validatePublicVoidNoArgs)
- validateBindingTypeParameters (only arguments annotated with a BindingType
allowed)
Overrides the createTest method to inject TestCase fields:
pesudo: for each Field "annotated with a BindingType" set getInstanceByType
Overrides methodInvoker to inject TestMethod args:
pesudo: for each Arg getInstanceByType
Annotate the TestCase with @RunWith(Webbeans.class) and one should be good
to go..
If interested, the code with TestCase example can be found at:
http://pastebin.com/m66ad1894
--
--
Aslak Knutsen; +47 952 38 791; fax +47 22 33 60 24
Kongens gate 14; Boks 805 Sentrum, 0104 Oslo;
http://www.conduct.no; mailto:aslak@conduct.no
Conduct AS - Professional Open Source Services
- Red Hat/JBoss Premier System Integrator
- Pentaho Preferred Integration Partner
- Atlassian Technology Partner
17 years
[webbeans-dev] Package for PassivationCapable
by David Allen
Hi Gavin,
I don't see the PassivationCapable interface listed in Appendix B
anywhere in the 20090625 version of the spec. I assume it belongs in
B.8 for the extensions SPI.
- David
17 years
[webbeans-dev] producer method trumps raw dependent type?
by Dan Allen
After the recent revisions of the JSR-299 spec, I'm finding that I'm a tad
confused about the bean selection algorithm when a producer method exists.
Consider the following:
class PotatoChip {
}
class SnackFactory() {
public @Produces PotatoChip createPotatoChip() {
return new PotatoChip();
}
}
1) Does the produced PotatoChip take precedence over the raw dependent type
when being selected for injection?
2) How do I get the Bean<PotatoChip> that represents the producer method?
BeanManager#getBeans(PotatoChip.class) returns two beans that are
indistinguishable from the public API.
3) What if the producer method is @RequestScoped? How do I get the
request-scoped produce instead of the dependent bean?
Bean<PotatoChip> potatoChipBean = null;
for (Bean<PotatoChip> candidate : getBeans(PotatoChip.class))
{
if (candidate.getScopeType().equals(RequestScoped.class))
{
potatoChipBean = candidate;
break;
}
}
Sorry if this sounds like a dumb question. The spec has changed a lot and my
memory is getting mixed in with the current set of facts.
-Dan
--
Dan Allen
Senior Software Engineer, Red Hat | Author of Seam in Action
Registered Linux User #231597
http://mojavelinux.com
http://mojavelinux.com/seaminaction
http://in.relation.to/Bloggers/Dan
17 years
Re: [webbeans-dev] ts
by Ales Justin
>> All of that testsuite should pass atm. Is this with your new
>> deployment stuff enabled?
>
> I now rewrote it.
> Currently only porting the Flat approach of Deployment to more generic
> architecture..
> I need to think a bit more about how to do Structure properly.
>
> The server starts fine.
> Hence I doubt the new deployers are the cause.
>
> I can commit and you do a quick check?
OK, committed, so I don't loose it. :-)
Can you try, and if it doesn't work for you, you can rollback,
*but* please create me a separate branch *before*,
and I'll have a look what's causing those potential failures.
Or if someone can dig in and identify the cause. ;-)
17 years
[webbeans-dev] TCK - grouping broken etc. tests
by Pete Muir
Hi all,
I just spent some time working through the tests marked as ri-broken
tests in the TCK. I've fixed those I can easily, and filed WBRI JIRAs
for the rest. It made me realize we need some guidelines on how to
handle tests which don't work:
http://www.seamframework.org/WebBeans/GroupingTests
* If the test isn't working properly (e.g. you haven't finished it,
you need to check it in to get advice from others, you find a test and
can see it is broken, either due to changes in the spec, or due to a
bad test in the first place, you need to add it to the "broken" group
- @Test (groups={"broken"}). Please also add a note saying what is
wrong with the test, and if you've spent some time with it, note where
you got to with understanding/fixing it. Broken tests are highlighted
in the audit in yellow. If you are working on a section, always check
to see if you can't fix the broken tests. Alternatively, if you've
written a test which will work standalone, but won't work in the
container, add it to the incontainer-broken group
* If you think the test is correct, but it won't run against the RI
you need to:
- add it to the ri-broken group - @Test groups={"broken"})
- alternatively, if the test will pass standalone, but won't pass
in JBoss AS (e.g. we've had this where serialization is involved),
then add it to the incontainer-ri-broken group
- check and see if there is already a matching WBRI issue, if
there isn't create one
- add a note to the issue with the FQN of the test method (use
copy qualified name in eclipse on the method)
- add a comment to the test indicating the WBRI issue number
* If you find a test that is correct, but could be more complete, add
it to the rewrite group @Test(groups={"rewrite"})
* Do not use the stub group any more
* Feel free to tag tests using groups to mark what they relate to.
Eventually, I would like to go through and make a consistent effort at
this with a well defined list of tags, but this is very low priority.
* We will also use this approach to allow testing on an embeddable EJB
3.1 container. If you are tagging a test that will definitely run on
this container (for example, a JSF test won't run, a servlet test
won't run) then please add the ejb-embeddable tag. Again, this is low
priority for now
Pete
17 years
