[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, 6 months
[webbeans-dev] Replacement pattern for Manager.getInstanceByType
by Clint Popetz
>From what I can tell, code that used to do:
manager.getInstanceByType(clazz)
now need to do:
manager.getReference(manager.getBeans(clazz).iterator().next(),clazz);
(plus checking that the set contains only one element and throwing an
exception if not.)
Is that really true? Is there no more direct way to obtain this in the
SPI? It seems like a pretty common case. If not, I can have a utility
method to do the above in the core, as many things don't cast to
ManagerImpl, so I'd rather not put it there.
-Clint
--
Clint Popetz
http://42lines.net
Scalable Web Application Development
16 years, 8 months
[webbeans-dev] Re: Instead of deployment types
by Gavin King
BTW, what exactly are the implications of adopting this rule for the SPI?
Do we still need to pass some sort Module object around, or can the
container figure it out based upon the Class objects?
Does the container just call theClass.getClassLoader() and then cast
it to some internal ClassLoader subclass to determine exactly where
the class came from?
We need to figure out how this works so I can update the SPI.
On Wed, May 20, 2009 at 9:37 PM, Gavin King <gavin.king(a)gmail.com> wrote:
> Folks, I spent a bunch of time with Bill Shannon and Roberto today.
> The results of these discussion were:
>
> Inter-module dependencies
> =====================
> We shouldn't introduce any special module-level dependency mechanism
> or module-private dependencies (such as my proposal for @Exported
> beans). We should wait for the Java Module System for that kind of
> thing.
>
> Instead we'll say that an injection point of a class X can resolve to
> a bean Y only when the Java EE spec requires that the bean class Y is
> visible to X (section 8.3 of the spec). So, for example, a bean in
> ejb-jar A is not available for injection into a bean in another
> ejb-jar B unless A declares a dependency to B in manifest.mf.
>
> This solution isn't quite as powerful as module-private dependencies,
> but it solves the cases I raised earlier today, and we'll get
> something more powerful when the Java Module System arrives.
--
Gavin King
gavin.king(a)gmail.com
http://in.relation.to/Bloggers/Gavin
http://hibernate.org
http://seamframework.org
16 years, 9 months
Re: [webbeans-dev] conversation context lifecycle
by Gavin King
2009/5/30 Michael Youngstrom <youngm(a)gmail.com>:
> I'm not really happy with this solution. Over the last couple of
> hours I've really grown to like the power of a more servlet general
> conversation available to the full request. If a developer doesn't
> care about using a request parameter they shouldn't have to live with
> the post Filter restriction.
I'm also finding this idea to be pretty seductive.
> Isn't there some way we can make the conversation context more
> pluggable/extensible itself? WebBeans could ship with a general
> friendly request parameter based conversation propagation mechanism
> and other frameworks like Wicket could replace or extend the provided
> Conversation Manager to better fit their propagation requirements
> along with the potential limitations?
In this release I don't want to do something extremely complex here.
If there is a simple solution that covers the major integration
usecases that we can think of, fine, let's go with it. But if not, I
would rather defer it.
--
Gavin King
gavin.king(a)gmail.com
http://in.relation.to/Bloggers/Gavin
http://hibernate.org
http://seamframework.org
16 years, 9 months
Re: [webbeans-dev] conversation context lifecycle
by Gavin King
Or we could say it is an event that is observable by Extensions:
void request(@Observes BeforeRestoreConversation brc) {
brc.setId( brc.getRequest().getParameter("specialcid") );
}
where we define the following interface:
public interface BeforeRestoreConversation {
String getId();
void setId(String id);
ServletContext getContext();
HttpServletRequest getRequest();
}
This seems to me like the better option, WDYT?
On Sat, May 30, 2009 at 1:31 PM, Gavin King <gavin.king(a)gmail.com> wrote:
> On Sat, May 30, 2009 at 12:43 PM, Gavin King <gavin.king(a)gmail.com> wrote:
>
>>> Looking at the Conversation public API I don't see any programmatic
>>> way to restore a conversation. Perhaps we should add such an API?
>>
>> Ugh, I really didn't want to go there in this release, though it
>> would, very clearly, be a very useful feature.
>>
>> If we were going to go there, the way I would do it is to say that the
>> conversation context is defined for all servlet requests, but it is by
>> default transient. The container would be required to call back to
>> Extensions to obtain a conversation id.
>
> Actually, upon reflection, I think we need to do this :-/
>
> Because even in JSF, we want a way to customize the mechanism for
> conversation propagation.
>
> So we could say that an Extension may optionally implement this interface:
>
> public interface ConversationExtension {
> String getConversationId(HttpServletRequest request,
> ServletContext context);
> }
>
> And say that before any Filter is called, the container calls all
> ConversationExtensions looking for a conversation id, and if it finds
> one, restores the conversation.
>
> Alternatively, we could say that the conversation is only restored
> *after* all ServletFilters have been called, and say that the
> container looks in a specially-named request attribute, for example
> "javax.contexts.spi.conversationId". Then we would not need a special
> interface, and any servlet filter could do conversation management.
> This seems more elegant, but means you don't get a conversation
> context in your filters.
>
> WDYT?
>
> --
> 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
16 years, 9 months
Fwd: [webbeans-dev] conversation context lifecycle
by Gavin King
Thoughts?
---------- Forwarded message ----------
From: Gavin King <gavin.king(a)gmail.com>
Date: Sat, May 30, 2009 at 1:31 PM
Subject: Re: [webbeans-dev] conversation context lifecycle
To: Java Community Process JSR #299 Expert List <JSR-299-EG(a)jcp.org>
On Sat, May 30, 2009 at 12:43 PM, Gavin King <gavin.king(a)gmail.com> wrote:
>> Looking at the Conversation public API I don't see any programmatic
>> way to restore a conversation. Perhaps we should add such an API?
>
> Ugh, I really didn't want to go there in this release, though it
> would, very clearly, be a very useful feature.
>
> If we were going to go there, the way I would do it is to say that the
> conversation context is defined for all servlet requests, but it is by
> default transient. The container would be required to call back to
> Extensions to obtain a conversation id.
Actually, upon reflection, I think we need to do this :-/
Because even in JSF, we want a way to customize the mechanism for
conversation propagation.
So we could say that an Extension may optionally implement this interface:
public interface ConversationExtension {
String getConversationId(HttpServletRequest request,
ServletContext context);
}
And say that before any Filter is called, the container calls all
ConversationExtensions looking for a conversation id, and if it finds
one, restores the conversation.
Alternatively, we could say that the conversation is only restored
*after* all ServletFilters have been called, and say that the
container looks in a specially-named request attribute, for example
"javax.contexts.spi.conversationId". Then we would not need a special
interface, and any servlet filter could do conversation management.
This seems more elegant, but means you don't get a conversation
context in your filters.
WDYT?
--
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
16 years, 9 months
[webbeans-dev] conversation context lifecycle
by Dan Allen
Gavin,
Since you reached an interlude (however brief it may be), I'd like to take
the opportunity to reconsider the conversation context lifecycle. Currently,
the spec states:
- For a JSF faces request, the context is active from the beginning of the
apply request values phase until the response is complete.
- For a JSF non-faces request, the context is active during the render
response phase.
I feel that these boundaries are two narrow. I'll focus first on the faces
request. In Seam, it's necessary to delay resuming the conversation until
the apply request values phase because the conversation id is stored in the
view root. At one time, the conversation context was even stored in the view
root, making it even more imperative. But we get a chance to start fresh.
There are three factors that call for the boundaries to be extended:
- As of JSF 2.0, parts of the component tree is visited in the restore view
phase, which happens to resolve value expressions bound to UIData
components. This triggers a scope not active exception if a
conversation-scoped bean is hit.
- JSF 2.0 gives us far greater flexibility to control inbound and outbound
requests. So it's no longer necessary to store the id in the view root. The
query string would be sufficient (I've already modified Web Beans to
prototype this)
- Servlets on subsequent requests may want to participate in the
conversation (and perhaps even servlet filters)
For all of these reasons, I'd like the conversation lifecycle to wrap the
entire JSF lifecycle and i'd like the conversation id to be propagated using
a query string parameter since that's the most universal way of propagating
state. As a result, custom servlets can read this value and restore the
conversation as needed. It's really inconvenient for the conversation id to
be hidden away into the component tree, aside from being problematic in JSF
2.0.
Please reconsider. Thanks.
-Dan
--
Dan Allen
Senior Software Engineer, Red Hat | Author of Seam in Action
http://mojavelinux.com
http://mojavelinux.com/seaminaction
http://in.relation.to/Bloggers/Dan
NOTE: While I make a strong effort to keep up with my email on a daily
basis, personal or other work matters can sometimes keep me away
from my email. If you contact me, but don't hear back for more than a week,
it is very likely that I am excessively backlogged or the message was
caught in the spam filters. Please don't hesitate to resend a message if
you feel that it did not reach my attention.
16 years, 9 months
