Seam 3: Java 5 support

[petemuir]

We should probably maintain Java 5 support for Seam 3 - I see some  
Java 6 deps creeping in (like the java.util.ServiceLoader in bridge-
api).
_______________________________________________
seam-dev mailing list
seam-dev@...
https://lists.jboss.org/mailman/listinfo/seam-dev

[Dan Allen (mojavelinux)]

On Fri, May 29, 2009 at 7:29 AM, Pete Muir <pmuir@...> wrote:

We should probably maintain Java 5 support for Seam 3 - I see some Java 6 deps creeping in (like the java.util.ServiceLoader in bridge-api).

Absolutely. I just threw that in there right now to get it working quickly as a prototype. That module is still under review so I didn't want to spend time on writing a Java 5 substitute for ServiceLoader until we got it resolved.

Speaking of which, we have brainstormed several approaches to this problem, one of which is to use a custom servlet as a way to capture the BeanManager from an injection and store it in the application context. However, wouldn't it still be reasonable to have an SPI to hide this detail, with the implementation being to consult the application context? JSF's ExternalContext is available through a static call (via FacesContext#getCurrentInstance()), but what about other frameworks like Wicket? You are now faces with the issue of getting access to the application context (maybe there is a way in Wicket).

And one other thought. In the SeamELResolver we want to be able to instantiate the WebBeansELResolver for resolving named beans via EL expressions in the Java API (an example is in a bundle message). But the ELResolver is impl specific. So again, we would need a portable way to instantiate this class. I was going to use an SPI for that and put it in this module. But then we do need an impl per 299 impl.

-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.

_______________________________________________
seam-dev mailing list
seam-dev@...
https://lists.jboss.org/mailman/listinfo/seam-dev

[petemuir]

This bridge stuff is basically a stinking pile of poo IMO, and needs to go away ;-) It's a lazy way of achieving stuff, which if we think properly about the problem domain, we can get around.

Actually, Gavin, this is something that would be useful to expose via the BeanManager:

public ELResolver getELResolver()

We need this for the TCK (we currently expose a custom SPI that someone using the TCK must impl) and it seems we want it for Seam.

WDYT?

On 29 May 2009, at 14:50, Dan Allen wrote:

On Fri, May 29, 2009 at 7:29 AM, Pete Muir <pmuir@...> wrote:

We should probably maintain Java 5 support for Seam 3 - I see some Java 6 deps creeping in (like the java.util.ServiceLoader in bridge-api).

Absolutely. I just threw that in there right now to get it working quickly as a prototype. That module is still under review so I didn't want to spend time on writing a Java 5 substitute for ServiceLoader until we got it resolved.

Speaking of which, we have brainstormed several approaches to this problem, one of which is to use a custom servlet as a way to capture the BeanManager from an injection and store it in the application context. However, wouldn't it still be reasonable to have an SPI to hide this detail, with the implementation being to consult the application context? JSF's ExternalContext is available through a static call (via FacesContext#getCurrentInstance()), but what about other frameworks like Wicket? You are now faces with the issue of getting access to the application context (maybe there is a way in Wicket).

And one other thought. In the SeamELResolver we want to be able to instantiate the WebBeansELResolver for resolving named beans via EL expressions in the Java API (an example is in a bundle message). But the ELResolver is impl specific. So again, we would need a portable way to instantiate this class. I was going to use an SPI for that and put it in this module. But then we do need an impl per 299 impl.

-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.

_______________________________________________
seam-dev mailing list
seam-dev@...
https://lists.jboss.org/mailman/listinfo/seam-dev

[Dan Allen (mojavelinux)]

On Fri, May 29, 2009 at 10:05 AM, Pete Muir <pmuir@...> wrote:

This bridge stuff is basically a stinking pile of poo IMO, and needs to go away ;-) It's a lazy way of achieving stuff

Stellar. Well, I wanted to get somewhere with Seam and whatever the official solution is becomes an easy drop-in replacement anyway.
 

, which if we think properly about the problem domain, we can get around.

Great. I await ideas. I just need to get the reference somehow. The impl in the jndi-bridge folder does a JNDI lookup, btw, so that at least is a generic approach. I'd like to see something suggested in the spec or WB ref doc. Clearly the Seam project is not the only thing that will need to solve this problem.
 

Actually, Gavin, this is something that would be useful to expose via the BeanManager:

public ELResolver getELResolver()

+1

--
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.

_______________________________________________
seam-dev mailing list
seam-dev@...
https://lists.jboss.org/mailman/listinfo/seam-dev

[petemuir]

On 29 May 2009, at 16:37, Dan Allen wrote:

On Fri, May 29, 2009 at 10:05 AM, Pete Muir <pmuir@...> wrote:

This bridge stuff is basically a stinking pile of poo IMO, and needs to go away ;-) It's a lazy way of achieving stuff

Stellar. Well, I wanted to get somewhere with Seam and whatever the official solution is becomes an easy drop-in replacement anyway.
 

, which if we think properly about the problem domain, we can get around.

Great. I await ideas. I just need to get the reference somehow. The impl in the jndi-bridge folder does a JNDI lookup, btw, so that at least is a generic approach. I'd like to see something suggested in the spec or WB ref doc. Clearly the Seam project is not the only thing that will need to solve this problem.

We've been through this on the phone - we can inject into a managed servlet object and propagate it into JSF from there... (I know, I have to get servlet injection working in JBoss first - I spoke to Jason and we have a plan ;-)

Next? ;-)

 

Actually, Gavin, this is something that would be useful to expose via the BeanManager:

public ELResolver getELResolver()

+1

--
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.

_______________________________________________
seam-dev mailing list
seam-dev@...
https://lists.jboss.org/mailman/listinfo/seam-dev

[Dan Allen (mojavelinux)]

On Fri, May 29, 2009 at 11:38 AM, Pete Muir <pmuir@...> wrote:

On 29 May 2009, at 16:37, Dan Allen wrote:

On Fri, May 29, 2009 at 10:05 AM, Pete Muir <pmuir@...> wrote:

This bridge stuff is basically a stinking pile of poo IMO, and needs to go away ;-) It's a lazy way of achieving stuff

Stellar. Well, I wanted to get somewhere with Seam and whatever the official solution is becomes an easy drop-in replacement anyway.
 

, which if we think properly about the problem domain, we can get around.

Great. I await ideas. I just need to get the reference somehow. The impl in the jndi-bridge folder does a JNDI lookup, btw, so that at least is a generic approach. I'd like to see something suggested in the spec or WB ref doc. Clearly the Seam project is not the only thing that will need to solve this problem.

We've been through this on the phone - we can inject into a managed servlet object and propagate it into JSF from there... (I know, I have to get servlet injection working in JBoss first - I spoke to Jason and we have a plan ;-)

Right. And I've said I just haven't gotten to that yet (and from what you just said it wouldn't work yet anyway). So, for now, the bridge let's me move forward with actually getting some other stuff developed and then we can circle back and correct it. There really are few places where we need to go through this portal (Dan pictures a hole opening in the universe).

-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.

_______________________________________________
seam-dev mailing list
seam-dev@...
https://lists.jboss.org/mailman/listinfo/seam-dev

[petemuir]

I know, that's fine, but every time you propose adding something else, I will complain ;-)

As this approach is dead, I wouldn't spend time on it, if you need to get the manager, use JNDI and we make that a requirement of these seam alphas... We should try both the paths.

--

Pete Muir

http://in.relation.to/Bloggers/Pete 

On 29 May 2009, at 16:54, Dan Allen <dan.j.allen@...> wrote:

On Fri, May 29, 2009 at 11:38 AM, Pete Muir <pmuir@...> wrote:

On 29 May 2009, at 16:37, Dan Allen wrote:

On Fri, May 29, 2009 at 10:05 AM, Pete Muir <pmuir@...> wrote:

This bridge stuff is basically a stinking pile of poo IMO, and needs to go away ;-) It's a lazy way of achieving stuff

Stellar. Well, I wanted to get somewhere with Seam and whatever the official solution is becomes an easy drop-in replacement anyway.
 

, which if we think properly about the problem domain, we can get around.

Great. I await ideas. I just need to get the reference somehow. The impl in the jndi-bridge folder does a JNDI lookup, btw, so that at least is a generic approach. I'd like to see something suggested in the spec or WB ref doc. Clearly the Seam project is not the only thing that will need to solve this problem.

We've been through this on the phone - we can inject into a managed servlet object and propagate it into JSF from there... (I know, I have to get servlet injection working in JBoss first - I spoke to Jason and we have a plan ;-)

Right. And I've said I just haven't gotten to that yet (and from what you just said it wouldn't work yet anyway). So, for now, the bridge let's me move forward with actually getting some other stuff developed and then we can circle back and correct it. There really are few places where we need to go through this portal (Dan pictures a hole opening in the universe).

-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.

_______________________________________________
seam-dev mailing list
seam-dev@...
https://lists.jboss.org/mailman/listinfo/seam-dev

[Dan Allen (mojavelinux)]

On Fri, May 29, 2009 at 12:46 PM, Pete Muir <pmuir@...> wrote:

I know, that's fine, but every time you propose adding something else, I will complain ;-)

As this approach is dead, I wouldn't spend time on it, if you need to get the manager, use JNDI and we make that a requirement of these seam alphas... We should try both the paths.

Okay.

--
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.

_______________________________________________
seam-dev mailing list
seam-dev@...
https://lists.jboss.org/mailman/listinfo/seam-dev