Re: Integration of JSF2 specific API calls
no, that's a GREAT idea! :) On Fri, Dec 18, 2009 at 9:11 AM, Gurkan Erdogdu cgurkanerdo...@gmail.com wrote: It is a good idea. 2009/12/18 Sven Linstaedt sven.linsta...@googlemail.com I also thought about migrating all JSF compile time depend classes from webbeans-impl to webbeans-jsf for a clearer seperation. wdyt? br, Sven 2009/12/17 Mark Struberg strub...@yahoo.de Yes we can start that way. But having 2 modules would have the benefit that we can define the corresponding dependencies and thus make sure that we do not use 'newer' features at compile time. LieGrue, strub --- Gurkan Erdogdu cgurkanerdo...@gmail.com schrieb am Do, 17.12.2009: Von: Gurkan Erdogdu cgurkanerdo...@gmail.com Betreff: Re: Integration of JSF2 specific API calls An: openwebbeans-dev@incubator.apache.org Datum: Donnerstag, 17. Dezember 2009, 10:49 I think we will start hacking on the feature and if we hit the point of no return we should create an own module. We could definitely create a new package for unique JSF2 features if we will have under webbeans-jsf project. So management and configuration are much more easy with having one JSF module. 2009/12/17 Gurkan Erdogdu cgurkanerdo...@gmail.com What I mean is that, Our code base has nothing regarding to JSF 1.2 like other JSF Frameworks/Tools etc. do. We have just implemented 2 class for conversation service 1* WebBeansPhase Listener -- For restore conversations 2* Custom View Handler -- For adding cid to view handler Both of them work on any JSF1.2 or JSF2 implementation. Therefore it is not rational to define new jsf2 project from my point of view. If we were implementing lots of code unique to JSF 1.2 then it will be reasonable to define new JSF2 project but we did not. Actually it is meaningless for me to separate JSF 1.2 and JSF 2. We must not think of such a backward compatibility with JSF 1.2 etc because we have been implementing Java EE 6 defined JSR-299 specification. --Gurkan 2009/12/17 Mark Struberg strub...@yahoo.de Gurkan, I was not talking about special products, I also meant the API and I mentioned RichFaces-3.3.2 only as an example. You can google for the incompatibility problems. Matter of fact: .) EE6 WebProfile defines JSF-2, so from this point I'm with you But: .) there is no full stack for JSF-2 on the market currently (the component libraries are missing, since they are mostly incompatible) Plus, there will be lot old projects which still use JSF-1.2 but may like to use OWB for new extensions. and as such: .) providing an easy migration path to EE6 by allowing to use JSF-1.2 + OWB would imho be a pretty nice goodie. I don't think it will confuse users if they have a choice between a JSF-1.2 and a JSF-2 plugin if we explain the differences in the documentation. I think we will start hacking on the feature and if we hit the point of no return we should create an own module. wdyt? LieGrue, strub --- Gurkan Erdogdu cgurkanerdo...@gmail.com schrieb am Do, 17.12.2009: Von: Gurkan Erdogdu cgurkanerdo...@gmail.com Betreff: Re: Integration of JSF2 specific API calls An: openwebbeans-dev@incubator.apache.org Datum: Donnerstag, 17. Dezember 2009, 10:03 Hey Mark, E.g. try running RichFaces-3.3.2 on a JSF-2 container ;) Java EE standards do not depend on any special product! Standards talk about API. In JSF-1.2 there was no standardised ajax handling, so we would have no chance to use those features in a portable fashion. JSR-299 is contained in Java EE 6. Java EE 6 defines JSF2 and when we talk about JSF functionality, it means JSF2 not JSF1.2 or earlier. We wrote a little JSF code for conversations and at that time there was no offical MyFaces JSF2 API to use. Now there is one and we will update our pom to use MyFaces JSF2 and we will go ahead with it. In fact, our codes in webbeans-jsf must work within JSF2. Moreover, JSF2 is compatible with JSF1.2 as written in Java EE 6 specification. So all functionality must go into package webbeans-jsf. There is no need to create extra project modules that confuses developers minds. Thnks; --Gurkan 2009/12/17 Mark Struberg strub...@yahoo.de JSF2 is backward compatible Not when it comes to the details! E.g. try running RichFaces-3.3.2 on a JSF-2 container ;) There have been a few changes which allows us to create better support for JSF2, mostly in the AJAX area. In
Re: Fw: [jira] Created: (OWB-125) Les Diasporas Plurielles:: angosso.com - The Plural Diasporas here and in the world
I took care of it. I meant to do this the other day when it came in. On Sat, Jul 25, 2009 at 3:12 PM, Gurkan Erdogdu gurkanerdo...@yahoo.comwrote: Yes. +1 From: James Carman jcar...@carmanconsulting.com To: openwebbeans-dev@incubator.apache.org Sent: Saturday, July 25, 2009 5:22:19 PM Subject: Re: Fw: [jira] Created: (OWB-125) Les Diasporas Plurielles:: angosso.com - The Plural Diasporas here and in the world Yes, delete it. +1 On Sat, Jul 25, 2009 at 3:48 AM, Mark Struberg strub...@yahoo.de wrote: hmm, looks like a cross site scripting hack attempt? Should we delete it from JIRA? We should be prepared to get SPAM via JIRA in the future. A few days ago some bots created dozens of JIRA accounts at codehaus and started creating hundreds of maven issues with explicit content. LieGrue, strub
Re: Pluggable State Storage Mechanism...
Understood. I don't want to get our cart before our horse here, but I did want to raise the idea. I think providing a Terracotta implementation might be wise (they did this for Wicket's page storage mechanism). You could even use ehcache, I would assume. On Thu, Jun 18, 2009 at 9:53 AM, Gurkan Erdogdu cgurkanerdo...@gmail.comwrote: It is a good idea and it could be an OWB extension. Could you create a Jira for this? But I think, firstly we have to adapt the last draft specification requirements to our implementation :) Thanks; /Gurkan 2009/6/18 James Carman ja...@carmanconsulting.com All, It would be great if we could make the conversational state storage mechanism pluggable so that you could perhaps keep the memory footprint of your conversational state at a minimum. What do you guys think about that? James -- Gurkan Erdogdu http://gurkanerdogdu.blogspot.com
Re: Pluggable State Storage Mechanism...
On Thu, Jun 18, 2009 at 10:43 AM, Gurkan Erdogducgurkanerdo...@gmail.com wrote: AFAIK, Terracotta provides distributed cache for multiple nodes. And generally it is used for saving user sessions for fail-over scenarios. Does wicket use it for clustering page data? Yes, there is terracotta support for wicket page state, so that it replicates across nodes. Pretty slick from what I understand, but I haven't had a chance to use it yet. Actually, we have not implemented the session related scenarios like activation/passivation of the sessions. For example, when container passivates session, passivation occurs and OWB will passivate all component instances that have passivated capable scope types (like session and conversation scopes). I think that this can be easily done by implementing the HttpSessionActiovationListener. I would assume so, yes.
Re: build problem ?
In maven2 releases should have SNAPSHOT dependencies. On Thu, May 28, 2009 at 3:57 AM, Gurkan Erdogdu cgurkanerdo...@gmail.com wrote: Yeah, you are right. We forget to update main pom while releasing M2 properties openwebbeans.version1.0.0-incubating-M2/openwebbeans.version -- *This must be 1.0.0-incubating-SNAPSHOT* siteId/OWB/1.0.0-incubating-M2/plugins/siteId /properties Change after M2 release :) Thanks; --Gurkan 2009/5/28 Matthias Wessendorf mat...@apache.org trying to build OWB on my box, I see that the -IMPL has a dependency to org.apache.openwebbeans:openwebbeans-api:jar:1.0.0-incubating-M2 the API from the trunk, however, is declared as openwebbeans-api-1.0.0-incubating-SNAPSHOT so, hard to build, he ? :) -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -- Gurkan Erdogdu http://gurkanerdogdu.blogspot.com
Re: [VOTE] Release OpenWebBeans 1.0.0-incubating-M2
The locations are the same part is what troubled me. For Commons,
we make sure we generate all new artifacts (the artifacts are suffixed
with -rc1 or -rc2). If you keep reusing the same locations for
your artifacts, then how are we to know we're getting the correct
version of the file? How do we know that we're not involved in a race
condition (we grab a file before you send out the email)?
On Sat, May 23, 2009 at 1:17 AM, Gurkan Erdogdu gurkanerdo...@yahoo.com wrote:
Hi James;
Yes, I did it. I removed old tag and artifacts and I generated a new release
candidate and tag.
Please have a look at it
Thanks;
--Gurkan
From: James Carman jcar...@carmanconsulting.com
To: openwebbeans-dev@incubator.apache.org
Sent: Saturday, May 23, 2009 1:05:14 AM
Subject: Re: [VOTE] Release OpenWebBeans 1.0.0-incubating-M2
IMHO, you should really generate a new release candidate (along with
tags). That's the way we do it in Commons.
On Fri, May 22, 2009 at 1:43 PM, Gurkan Erdogdu gurkanerdo...@yahoo.com
wrote:
Ok, I have re-uploaded the artifacts and svn tag. Locations are the same.
New svn tag is 777602.
Thanks;
-- Gurkan
From: Gurkan Erdogdu gurkanerdo...@yahoo.com
To: openwebbeans-dev@incubator.apache.org
Sent: Friday, May 22, 2009 12:48:39 PM
Subject: Re: [VOTE] Release OpenWebBeans 1.0.0-incubating-M2
Embedded error: Prohibited package name: java.lang
If anyone knows how to avoid this problem, let me know...
Sorry, I am not a maven expert. Maybe Mark can answer this question.
Running RAT on the source reveals the following files missing
apache src license headers. These must be fixed. You should be running
RAT as part of a build or as part of the release process...
Is it required to retag into svn? Or is it enough to checkout the tagged
version and applying changes and then commit?
Thanks;
--Gurkan
From: Kevan Miller kevan.mil...@gmail.com
To: openwebbeans-dev@incubator.apache.org
Sent: Friday, May 22, 2009 6:10:55 AM
Subject: Re: [VOTE] Release OpenWebBeans 1.0.0-incubating-M2
Afraid that I'm currently unable to build. So, I can't fully review...
My build issue seems to be a Mac OS / mvn issue. I'm failing with:
[INFO]
[INFO] Building OpenWebBeans :: WebBeans-API
[INFO] task-segment: [clean, install]
[INFO]
[INFO] [clean:clean]
[INFO] Deleting directory
/Users/kevan/tmp/owb/openwebbeans-1.0.0-incubating-M2/webbeans-api/target
[INFO] [remote-resources:process {execution: default}]
[INFO] inceptionYear not specified, defaulting to 2009
[INFO] [resources:resources]
[WARNING] Using platform encoding (MacRoman actually) to copy filtered
resources, i.e. build is platform dependent!
[INFO] Copying 0 resource
[INFO] Copying 4 resources
[INFO] [compiler:compile]
[INFO] Compiling 65 source files to
/Users/kevan/tmp/owb/openwebbeans-1.0.0-incubating-M2/webbeans-api/target/classes
[INFO]
[ERROR] BUILD ERROR
[INFO]
[INFO] Fatal error compiling
Embedded error: Prohibited package name: java.lang
If anyone knows how to avoid this problem, let me know...
Running RAT on the source reveals the following files missing apache src
license headers. These must be fixed. You should be running RAT as part of a
build or as part of the release process...
samples/reservation/src/main/webapp/main.css
webbeans-geronimo/pom.xml
webbeans-jpa/pom.xml
webbeans-jsf/pom.xml
--kevan
Re: [VOTE] Release OpenWebBeans 1.0.0-incubating-M2
And, new tags in SVN. Tags are cheap and it helps us to know what has
changed between rcs.
On Sat, May 23, 2009 at 8:15 AM, Gurkan Erdogdu gurkanerdo...@yahoo.com wrote:
If you keep reusing the same locations for
your artifacts, then how are we to know we're getting the correct
version of the file? How do we know that we're not involved in a race
condition (we grab a file before you send out the email)?
Upps, himm. Ok, I am learning a new thing each day :). Next time I will apply
your comments that creating new locations for release candidates.
For example : M2-rc1/plugins...
M2-rc2/plugins...
etc..
Thanks;
--Gurkan
From: James Carman jcar...@carmanconsulting.com
To: openwebbeans-dev@incubator.apache.org
Sent: Saturday, May 23, 2009 2:17:36 PM
Subject: Re: [VOTE] Release OpenWebBeans 1.0.0-incubating-M2
The locations are the same part is what troubled me. For Commons,
we make sure we generate all new artifacts (the artifacts are suffixed
with -rc1 or -rc2). If you keep reusing the same locations for
your artifacts, then how are we to know we're getting the correct
version of the file? How do we know that we're not involved in a race
condition (we grab a file before you send out the email)?
On Sat, May 23, 2009 at 1:17 AM, Gurkan Erdogdu gurkanerdo...@yahoo.com
wrote:
Hi James;
Yes, I did it. I removed old tag and artifacts and I generated a new release
candidate and tag.
Please have a look at it
Thanks;
--Gurkan
From: James Carman jcar...@carmanconsulting.com
To: openwebbeans-dev@incubator.apache.org
Sent: Saturday, May 23, 2009 1:05:14 AM
Subject: Re: [VOTE] Release OpenWebBeans 1.0.0-incubating-M2
IMHO, you should really generate a new release candidate (along with
tags). That's the way we do it in Commons.
On Fri, May 22, 2009 at 1:43 PM, Gurkan Erdogdu gurkanerdo...@yahoo.com
wrote:
Ok, I have re-uploaded the artifacts and svn tag. Locations are the same.
New svn tag is 777602.
Thanks;
-- Gurkan
From: Gurkan Erdogdu gurkanerdo...@yahoo.com
To: openwebbeans-dev@incubator.apache.org
Sent: Friday, May 22, 2009 12:48:39 PM
Subject: Re: [VOTE] Release OpenWebBeans 1.0.0-incubating-M2
Embedded error: Prohibited package name: java.lang
If anyone knows how to avoid this problem, let me know...
Sorry, I am not a maven expert. Maybe Mark can answer this question.
Running RAT on the source reveals the following files missing
apache src license headers. These must be fixed. You should be running
RAT as part of a build or as part of the release process...
Is it required to retag into svn? Or is it enough to checkout the tagged
version and applying changes and then commit?
Thanks;
--Gurkan
From: Kevan Miller kevan.mil...@gmail.com
To: openwebbeans-dev@incubator.apache.org
Sent: Friday, May 22, 2009 6:10:55 AM
Subject: Re: [VOTE] Release OpenWebBeans 1.0.0-incubating-M2
Afraid that I'm currently unable to build. So, I can't fully review...
My build issue seems to be a Mac OS / mvn issue. I'm failing with:
[INFO]
[INFO] Building OpenWebBeans :: WebBeans-API
[INFO] task-segment: [clean, install]
[INFO]
[INFO] [clean:clean]
[INFO] Deleting directory
/Users/kevan/tmp/owb/openwebbeans-1.0.0-incubating-M2/webbeans-api/target
[INFO] [remote-resources:process {execution: default}]
[INFO] inceptionYear not specified, defaulting to 2009
[INFO] [resources:resources]
[WARNING] Using platform encoding (MacRoman actually) to copy filtered
resources, i.e. build is platform dependent!
[INFO] Copying 0 resource
[INFO] Copying 4 resources
[INFO] [compiler:compile]
[INFO] Compiling 65 source files to
/Users/kevan/tmp/owb/openwebbeans-1.0.0-incubating-M2/webbeans-api/target/classes
[INFO]
[ERROR] BUILD ERROR
[INFO]
[INFO] Fatal error compiling
Embedded error: Prohibited package name: java.lang
If anyone knows how to avoid this problem, let me know...
Running RAT on the source reveals the following files missing apache src
license headers. These must be fixed. You should be running RAT as part of
a build or as part of the release process...
samples/reservation/src/main/webapp/main.css
webbeans-geronimo/pom.xml
webbeans-jpa/pom.xml
webbeans-jsf/pom.xml
--kevan
Re: [VOTE] Release OpenWebBeans 1.0.0-incubating-M2
I'm not trying to tell you how to run your project or anything. I'm
just telling you how we do it in Commons. We place votes like
release Commons Foo 1.2 from rc2. Check out this document:
http://commons.apache.org/releases/prepare.html
Again, this is just how we do it, but it seems to work well for us.
On Sat, May 23, 2009 at 8:20 AM, James Carman
jcar...@carmanconsulting.com wrote:
And, new tags in SVN. Tags are cheap and it helps us to know what has
changed between rcs.
On Sat, May 23, 2009 at 8:15 AM, Gurkan Erdogdu gurkanerdo...@yahoo.com
wrote:
If you keep reusing the same locations for
your artifacts, then how are we to know we're getting the correct
version of the file? How do we know that we're not involved in a race
condition (we grab a file before you send out the email)?
Upps, himm. Ok, I am learning a new thing each day :). Next time I will
apply your comments that creating new locations for release candidates.
For example : M2-rc1/plugins...
M2-rc2/plugins...
etc..
Thanks;
--Gurkan
From: James Carman jcar...@carmanconsulting.com
To: openwebbeans-dev@incubator.apache.org
Sent: Saturday, May 23, 2009 2:17:36 PM
Subject: Re: [VOTE] Release OpenWebBeans 1.0.0-incubating-M2
The locations are the same part is what troubled me. For Commons,
we make sure we generate all new artifacts (the artifacts are suffixed
with -rc1 or -rc2). If you keep reusing the same locations for
your artifacts, then how are we to know we're getting the correct
version of the file? How do we know that we're not involved in a race
condition (we grab a file before you send out the email)?
On Sat, May 23, 2009 at 1:17 AM, Gurkan Erdogdu gurkanerdo...@yahoo.com
wrote:
Hi James;
Yes, I did it. I removed old tag and artifacts and I generated a new
release candidate and tag.
Please have a look at it
Thanks;
--Gurkan
From: James Carman jcar...@carmanconsulting.com
To: openwebbeans-dev@incubator.apache.org
Sent: Saturday, May 23, 2009 1:05:14 AM
Subject: Re: [VOTE] Release OpenWebBeans 1.0.0-incubating-M2
IMHO, you should really generate a new release candidate (along with
tags). That's the way we do it in Commons.
On Fri, May 22, 2009 at 1:43 PM, Gurkan Erdogdu gurkanerdo...@yahoo.com
wrote:
Ok, I have re-uploaded the artifacts and svn tag. Locations are the same.
New svn tag is 777602.
Thanks;
-- Gurkan
From: Gurkan Erdogdu gurkanerdo...@yahoo.com
To: openwebbeans-dev@incubator.apache.org
Sent: Friday, May 22, 2009 12:48:39 PM
Subject: Re: [VOTE] Release OpenWebBeans 1.0.0-incubating-M2
Embedded error: Prohibited package name: java.lang
If anyone knows how to avoid this problem, let me know...
Sorry, I am not a maven expert. Maybe Mark can answer this question.
Running RAT on the source reveals the following files missing
apache src license headers. These must be fixed. You should be running
RAT as part of a build or as part of the release process...
Is it required to retag into svn? Or is it enough to checkout the tagged
version and applying changes and then commit?
Thanks;
--Gurkan
From: Kevan Miller kevan.mil...@gmail.com
To: openwebbeans-dev@incubator.apache.org
Sent: Friday, May 22, 2009 6:10:55 AM
Subject: Re: [VOTE] Release OpenWebBeans 1.0.0-incubating-M2
Afraid that I'm currently unable to build. So, I can't fully review...
My build issue seems to be a Mac OS / mvn issue. I'm failing with:
[INFO]
[INFO] Building OpenWebBeans :: WebBeans-API
[INFO] task-segment: [clean, install]
[INFO]
[INFO] [clean:clean]
[INFO] Deleting directory
/Users/kevan/tmp/owb/openwebbeans-1.0.0-incubating-M2/webbeans-api/target
[INFO] [remote-resources:process {execution: default}]
[INFO] inceptionYear not specified, defaulting to 2009
[INFO] [resources:resources]
[WARNING] Using platform encoding (MacRoman actually) to copy filtered
resources, i.e. build is platform dependent!
[INFO] Copying 0 resource
[INFO] Copying 4 resources
[INFO] [compiler:compile]
[INFO] Compiling 65 source files to
/Users/kevan/tmp/owb/openwebbeans-1.0.0-incubating-M2/webbeans-api/target/classes
[INFO]
[ERROR] BUILD ERROR
[INFO]
[INFO] Fatal error compiling
Embedded error: Prohibited package name: java.lang
If anyone knows how to avoid this problem, let me know...
Running RAT on the source reveals the following files missing apache src
license headers. These must be fixed. You should be running RAT as part of
a build or as part of the release process...
samples
Re: [VOTE] Release OpenWebBeans 1.0.0-incubating-M2
IMHO, you should really generate a new release candidate (along with
tags). That's the way we do it in Commons.
On Fri, May 22, 2009 at 1:43 PM, Gurkan Erdogdu gurkanerdo...@yahoo.com wrote:
Ok, I have re-uploaded the artifacts and svn tag. Locations are the same. New
svn tag is 777602.
Thanks;
-- Gurkan
From: Gurkan Erdogdu gurkanerdo...@yahoo.com
To: openwebbeans-dev@incubator.apache.org
Sent: Friday, May 22, 2009 12:48:39 PM
Subject: Re: [VOTE] Release OpenWebBeans 1.0.0-incubating-M2
Embedded error: Prohibited package name: java.lang
If anyone knows how to avoid this problem, let me know...
Sorry, I am not a maven expert. Maybe Mark can answer this question.
Running RAT on the source reveals the following files missing
apache src license headers. These must be fixed. You should be running
RAT as part of a build or as part of the release process...
Is it required to retag into svn? Or is it enough to checkout the tagged
version and applying changes and then commit?
Thanks;
--Gurkan
From: Kevan Miller kevan.mil...@gmail.com
To: openwebbeans-dev@incubator.apache.org
Sent: Friday, May 22, 2009 6:10:55 AM
Subject: Re: [VOTE] Release OpenWebBeans 1.0.0-incubating-M2
Afraid that I'm currently unable to build. So, I can't fully review...
My build issue seems to be a Mac OS / mvn issue. I'm failing with:
[INFO]
[INFO] Building OpenWebBeans :: WebBeans-API
[INFO] task-segment: [clean, install]
[INFO]
[INFO] [clean:clean]
[INFO] Deleting directory
/Users/kevan/tmp/owb/openwebbeans-1.0.0-incubating-M2/webbeans-api/target
[INFO] [remote-resources:process {execution: default}]
[INFO] inceptionYear not specified, defaulting to 2009
[INFO] [resources:resources]
[WARNING] Using platform encoding (MacRoman actually) to copy filtered
resources, i.e. build is platform dependent!
[INFO] Copying 0 resource
[INFO] Copying 4 resources
[INFO] [compiler:compile]
[INFO] Compiling 65 source files to
/Users/kevan/tmp/owb/openwebbeans-1.0.0-incubating-M2/webbeans-api/target/classes
[INFO]
[ERROR] BUILD ERROR
[INFO]
[INFO] Fatal error compiling
Embedded error: Prohibited package name: java.lang
If anyone knows how to avoid this problem, let me know...
Running RAT on the source reveals the following files missing apache src
license headers. These must be fixed. You should be running RAT as part of a
build or as part of the release process...
samples/reservation/src/main/webapp/main.css
webbeans-geronimo/pom.xml
webbeans-jpa/pom.xml
webbeans-jsf/pom.xml
--kevan
Re: JSR 299 / WebBeans - Expert Group
On Thu, Apr 16, 2009 at 4:35 AM, Matthias Wessendorf mat...@apache.org wrote: I want to step back from the Expert Group. Question is now: Does one of you want to be on that EG ? This community would make most sense to have an active OWB committer being part of the spec/EG. I would be interested in joining, but I am not an OWB committer. I'm very interested in making sure the spec stays agnostic when it comes to the environment in which it runs. The specification should make it easy to use in Wicket, or Tapestry, or just plain ole JSP applications.
Re: JSR 299 / WebBeans - Expert Group
For the record, I'm +1 on Gurkan, too. I just offered myself up because I have interest in the topic and I do have quite a bit of experience in the dependency injection arena (and dynamic proxies). On Thu, Apr 16, 2009 at 8:19 AM, Mohammad Nour El-Din nour.moham...@gmail.com wrote: +1 for Gurkan, he has been so active on this project since the first days of it. On Thu, Apr 16, 2009 at 1:31 PM, Matthias Wessendorf mat...@apache.org wrote: On Thu, Apr 16, 2009 at 1:28 PM, Mark Struberg strub...@yahoo.de wrote: Hi! One feature we've discussed was exactly the conversation scope. His opinion as far as I remember was: the spec says JSF but it doesn't say we aren't allowed to make it independent as long as we _also_ have conversations for JSF in place. The same applies to EJB. The 2nd suggestion was the injection of Java natives (int, long, ...) for producer methods via XML. The spec defines this only for field injection but not yet for initializers and producers. Pete said they will probably add this too in the future (but there is no time left to bring it into the spec yet for 1.0). So the underlying message was: make the whining guys happy (you know of whom I'm talking about) Not really. the non-jsf folks ? Or those that want DI on JavaSE layer ? -M and then make the 1,0 spec final the sooner the better! LieGrue, strub --- Matthias Wessendorf mat...@apache.org schrieb am Do, 16.4.2009: Von: Matthias Wessendorf mat...@apache.org Betreff: Re: JSR 299 / WebBeans - Expert Group An: openwebbeans-dev@incubator.apache.org Datum: Donnerstag, 16. April 2009, 13:07 On Thu, Apr 16, 2009 at 1:03 PM, Mark Struberg strub...@yahoo.de wrote: Hi! I've talked with Pete Muir at the JSFDays about the JSR-299 spec a lot. Since he has taken over the lead from Gavin, he is the IMPL lead, at JBoss. And now the JBoss rep. on JSF 2.0 it should be possible to change an EG member also. And also to add another person. Yes, that's correct. That was the reason why I brought this up The Spec for 1.0 is almost finished, there are a few things which should be addressed but there is not enough time to get it rdy for EE6! So this is basically a situation where we have to get rid of all showstoppers but we shouldn't add additional functionality at this point! I think the common ground of the JSR-299 Spec is solid enough and fairly extendable. We have to implement what's in the Spec but are completely free to add additional functionality! I also talked with Pete about a few features they will add, and they now also have SE support which is not mentioned in the Spec. So I think it will not be a problem to have new features added which are compatible in RI and OWB _without_ having them written down in the WebBeans-1.0 Spec but in a later one! sounds interesting. What features you were discussing? Can you bring it up here ? -Matthias One possible thing that still may come is that some functionality (like eventing or interceptors, cannot remember which) may be removed from WebBeans and moved over to EJB or another spec. So one who does this Job really needs to know OWB insideout _plus_ a good amount of understanding of the whole EE business I don't think you are deep enough into OWB yet, but personally would highly appreciate to see you as a committer on OWB in the future :) LieGrue, strub --- James Carman jcar...@carmanconsulting.com schrieb am Do, 16.4.2009: Von: James Carman jcar...@carmanconsulting.com Betreff: Re: JSR 299 / WebBeans - Expert Group An: openwebbeans-dev@incubator.apache.org Datum: Donnerstag, 16. April 2009, 12:35 On Thu, Apr 16, 2009 at 4:35 AM, Matthias Wessendorf mat...@apache.org wrote: I want to step back from the Expert Group. Question is now: Does one of you want to be on that EG ? This community would make most sense to have an active OWB committer being part of the spec/EG. I would be interested in joining, but I am not an OWB committer. I'm very interested in making sure the spec stays agnostic when it comes to the environment in which it runs. The specification should make it easy to use in Wicket, or Tapestry, or just plain ole JSP applications. -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -- Thanks - Mohammad Nour - LinkedIn: http://www.linkedin.com/in/mnour Life is like riding a bicycle. To keep your balance you must keep moving - Albert Einstein
Re: JSR 299 / WebBeans - Expert Group
On Thu, Apr 16, 2009 at 8:31 AM, Mohammad Nour El-Din nour.moham...@gmail.com wrote: It seems that we need two so why not you and Gurkan :) ? Sorry, I followed this thread partly on my phone, so it was somewhat tough to follow I guess. Do we need two?
Re: JSR 299 / WebBeans - Expert Group
On Thu, Apr 16, 2009 at 8:56 AM, Matthias Wessendorf mat...@apache.org wrote: Does not hurt. Originally we were two as well. Both from Shale (James and I) Well, it wouldn't hurt to have someone else on there that isn't a JSFer. From what I understand Crazy Bob is interested in allowing the use of JSR-299 in Java SE environments (meaning anywhere I guess) as well.
Re: JSR 299 / WebBeans - Expert Group
On Thu, Apr 16, 2009 at 9:09 AM, Matthias Wessendorf mat...@apache.org wrote: to be honest, I never understood, why the DI layer needs to be part of an JEE tied spec... There should be a flexible/extensible DI layer at SE. Extensions for that could be added to JEE... +1000! :) I really don't understand why the specs try to be so application server heavy (then again, most of the expert groups have folks like IBM on them, who sell application servers). It doesn't seem that tough to do most of these things outside the realm of one of these fat servers. It would be great if these specifications could just say as long as I have these particular services available to me, I can run and then we just come up with a nice pluggable services platform (kind of like how Geronimo is set up I guess).
Re: JSR 299 / WebBeans - Expert Group
On Thu, Apr 16, 2009 at 12:08 PM, Mark Struberg strub...@yahoo.de wrote: Bob originally was interested in having IOC for SE also. But from what I've seen so far, he is imho one of those who requests that all the annotations should go under javax.se. To me this sounds more like 'oh this thing can't beat guice, so it should be for EJB only which we do not use anyway' ... So, why write a spec that's loosely based on Guice (a lot of concepts look similar; along with Seam) when it can't be used in place of it? That seems silly. We should strive for the best all-around IoC paradigm for Java, regardless of where it's running. It should have hooks for different scopes (similar to Guice and Spring and HiveMind, etc)
Re: WEBBEANS_XML_LOCATIONS keeps connection open
Do you have to parse it more than one time? On Tue, Apr 14, 2009 at 10:29 AM, Gurkan Erdogdu cgurkanerdo...@gmail.com wrote: Hi; It will used by the XML parser to parse the beans.xml files. Gurkan 2009/4/14 Mark Struberg strub...@yahoo.de Hi! Since WEBBEANS_XML_LOCATIONS in the MetaDataDiscoveryService is a WEBBEANS_XML_LOCATIONS.put(addPath.getFile(), addPath.openStream()); and URL#openStream() is basically equivalent to openConnection().getInputStream() we have all the beans.xml opened all the time. Is this really necessary? Can we somehow change the WEBBEANS_XML_LOCATIONS to only keep the URI and not even the URL (may cause opening a connection in some situations too)? txs and LieGrue, strub PS: I will rename the variable to camelCase since it is no constant with my next checkin, so please wait for it - txs :) -- Gurkan Erdogdu http://gurkanerdogdu.blogspot.com
Re: WEBBEANS_XML_LOCATIONS keeps connection open
If you only parse it once, then why keep it around at all? On Tue, Apr 14, 2009 at 2:37 PM, Mark Struberg strub...@yahoo.de wrote: My proposal is to only keep the filenames stored as Strings and not the whole InputStream. So we do not have to mess with open filehandles etc... Should I work on this till tomorrow? LieGrue, strub --- Gurkan Erdogdu gurkanerdo...@yahoo.com schrieb am Di, 14.4.2009: Von: Gurkan Erdogdu gurkanerdo...@yahoo.com Betreff: Re: WEBBEANS_XML_LOCATIONS keeps connection open An: openwebbeans-dev@incubator.apache.org Datum: Dienstag, 14. April 2009, 19:26 Seems that this is a defect. Actually, it may be closed after the stream is handled. It is used for parsing by the public static Element getRootElement(InputStream stream) throws WebBeansException Maybe adding finally block to close the stream in this method. Gurkan From: Mark Struberg strub...@yahoo.de To: openwebbeans-dev@incubator.apache.org Sent: Tuesday, April 14, 2009 5:43:31 PM Subject: Re: WEBBEANS_XML_LOCATIONS keeps connection open thank you guys! The question is: will the streams be used frequently in the future and are they left open intentionally? Or is this a code artifact which could/should be cleaned up? I now checked in the refactoring described in OWB-89. It would be cool if you can give it a quick ride since I'm not 100% sure about my Eclipse reliance since I've updated to the latest subclipse plugin. txs and LieGrue, strub --- James Carman jcar...@carmanconsulting.com schrieb am Di, 14.4.2009: Von: James Carman jcar...@carmanconsulting.com Betreff: Re: WEBBEANS_XML_LOCATIONS keeps connection open An: openwebbeans-dev@incubator.apache.org Datum: Dienstag, 14. April 2009, 16:32 Do you have to parse it more than one time? On Tue, Apr 14, 2009 at 10:29 AM, Gurkan Erdogdu cgurkanerdo...@gmail.com wrote: Hi; It will used by the XML parser to parse the beans.xml files. Gurkan 2009/4/14 Mark Struberg strub...@yahoo.de Hi! Since WEBBEANS_XML_LOCATIONS in the MetaDataDiscoveryService is a WEBBEANS_XML_LOCATIONS.put(addPath.getFile(), addPath.openStream()); and URL#openStream() is basically equivalent to openConnection().getInputStream() we have all the beans.xml opened all the time. Is this really necessary? Can we somehow change the WEBBEANS_XML_LOCATIONS to only keep the URI and not even the URL (may cause opening a connection in some situations too)? txs and LieGrue, strub PS: I will rename the variable to camelCase since it is no constant with my next checkin, so please wait for it - txs :) -- Gurkan Erdogdu http://gurkanerdogdu.blogspot.com
[jira] Commented: (OWB-87) move all non-JSF specific parts of Conversations handling to an own general package
[ https://issues.apache.org/jira/browse/OWB-87?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12689498#action_12689498 ] James Carman commented on OWB-87: - When I try to ask the current conversation (obtained by doing Manager.getInstanceByType(Conversation.class)), if it's long-running, I get: java.lang.NullPointerException at org.apache.webbeans.util.JSFUtil.getViewRoot(JSFUtil.java:78) at org.apache.webbeans.util.JSFUtil.getConversationId(JSFUtil.java:83) at org.apache.webbeans.component.ConversationComponent.createInstance(ConversationComponent.java:34) at org.apache.webbeans.component.ConversationComponent.createInstance(ConversationComponent.java:23) at org.apache.webbeans.component.AbstractComponent.create(AbstractComponent.java:163) at org.apache.webbeans.context.AbstractContext.getInstance(AbstractContext.java:127) at org.apache.webbeans.context.AbstractContext.get(AbstractContext.java:104) at org.apache.webbeans.intercept.InterceptorHandler.invoke(InterceptorHandler.java:61) at org.apache.webbeans.jsf.ConversationImpl_$$_javassist_0.isLongRunning(ConversationImpl_$$_javassist_0.java) at org.wicketstuff.candi.WebBeansIntegrationLogic.onEndRequest(WebBeansIntegrationLogic.java:66) So, looks like ConversationImpl definitely has JSF-specific logic in it (hence the jsf package I presume). Is there another way to manage conversations? I was following the JSF phase listener's lead here. move all non-JSF specific parts of Conversations handling to an own general package --- Key: OWB-87 URL: https://issues.apache.org/jira/browse/OWB-87 Project: OpenWebBeans Issue Type: Task Components: Context and Scopes Affects Versions: M1 Reporter: Mark Struberg Assignee: Mark Struberg Fix For: M2 Most of the conversation handling code is currently in the package org.apache.webbeans.jsf but all non-JSF specific stuff should finally land in something like org.apache.webbeans.conversation to also support common conversation functionality for e.g. a Wicket integration -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: setting conversation at request startup
I like this idea! It'll help me a lot! :) I did see something weird in the code, though. The ConversationManager.getInstance() method blasts the map of conversations every time it's called (it creates a new one). This code is called from multiple places, so it would seem like we're losing conversations. On Thu, Mar 26, 2009 at 5:50 PM, Gurkan Erdogdu gurkanerdo...@yahoo.com wrote: I have added the SPI for the conversation service. It is located in the spi/conversation package. I have also added the default conversation management that is based on the JSF. Default configuration is in the META-INF/openwebbeans/openwebbeans-default.properties with #conversation service org.apache.webbeans.spi.conversation.ConversationService=org.apache.webbeans.spi.conversation.jsf.JSFConversationServiceImpl Now, I think it is easy to add other conversation handling code via implementing the ConversationService and also context management like WebBeansPhaseListener. WDYT ? Gurkan From: Gurkan Erdogdu gurkanerdo...@yahoo.com To: openwebbeans-dev@incubator.apache.org Sent: Thursday, March 26, 2009 11:21:28 PM Subject: Re: setting conversation at request startup So my idea was to store the conversationId in a kind of @RequestScoped bean at start of the ServletRequest, so the ConversationComponent doesn't need to get the cid from the FacesContext but instead simply asks this 'ConversationBean'. Hmm the longer I think about it, why don't we simply create the Conversation at request startup? Currently we create it for each request, but as specification said at each JSF request. (see WebBeansPhaseListener) My basic idea was: we should move the conversationId detection out of the ConversationComponent, and make it part of the 'integration stuff'. So for ServletContainers this may work different than for PortletBridges and also different for freaky things like a standalone Swing application. Currently, idea is that I write the conversation id into the JSF UIView root as hidden component with id javax_webbeans_ConversationId at the render response phase if the conversation is long-running. At the next JSF post back, I am using this hidden component value as conversation id to get saved conversation. If the request is not post back, I am looking for the *cid* parameter that is set by the WebBeansJSFFilter for JSF redirects. How could we get the conversation id's from the client in other scenarios other than JSF? Conversation ids must be passed between the client and server. In the JSF scenario, we are getting it from the client via jsf hidden component. We can create a SPI for conversation id management. For JSF we can get it from the UIViewRoot. But for other scenarios, in addition to the conversation id management implementation, it is also necessary to handle context management that we did for JSF in the phase listener. Gurkan From: Mark Struberg strub...@yahoo.de To: openwebbeans-dev@incubator.apache.org Sent: Thursday, March 26, 2009 10:26:21 PM Subject: setting conversation at request startup Gurkan, I think I need help :) Currently we set the Converation via the ConversationComponent which gets the conversationId from the FacesContext. The FacesContext is essentially the same thing as we already have with our WebBeansContext. It's 'simply' a ThreadLocal container for session/app/request/page information. So my idea was to store the conversationId in a kind of @RequestScoped bean at start of the ServletRequest, so the ConversationComponent doesn't need to get the cid from the FacesContext but instead simply asks this 'ConversationBean'. Hmm the longer I think about it, why don't we simply create the Conversation at request startup? My basic idea was: we should move the conversationId detection out of the ConversationComponent, and make it part of the 'integration stuff'. So for ServletContainers this may work different than for PortletBridges and also different for freaky things like a standalone Swing application. txs and LieGrue, strub
Re: setting conversation at request startup
Would it be necessary (or at least nice :) to perhaps implement a portlet-specific implementation of the conversation management, too? Also, would you guys like me to submit some patches to help out? Is there anything that you'd feel comfortable letting me tackle? On Thu, Mar 26, 2009 at 7:04 PM, Mark Struberg strub...@yahoo.de wrote: apologise for not checking this in, my girlfriend pulled me off my chair for watching a movie :) I didn't look at the code yet, but I like the idea with the SPI. Guess this is the most simple solution here. Wdyt about OWB-88? I think it should be possible to split the whole JSF part into an own module without breaking the spec or losing performance. txs and LieGrue, mark --- Gurkan Erdogdu gurkanerdo...@yahoo.com schrieb am Do, 26.3.2009: Von: Gurkan Erdogdu gurkanerdo...@yahoo.com Betreff: Re: setting conversation at request startup An: openwebbeans-dev@incubator.apache.org Datum: Donnerstag, 26. März 2009, 22:31 Firstly I have got compile error in the WebBeansFinder class. It uses *import org.apache.webbeans.conversation.ConversationManager;* but it seems that you have not committed this package yet, ConversationManager is still in the jsf package. I have changed the packages. I have just added the *conversation* package and added ConversationManager and ConversationImpl into it removing from the jsf package. Gurkan From: Gurkan Erdogdu gurkanerdo...@yahoo.com To: openwebbeans-dev@incubator.apache.org Sent: Thursday, March 26, 2009 10:43:12 PM Subject: Re: setting conversation at request startup Hi Mark; Firstly I have got compile error in the WebBeansFinder class. It uses *import org.apache.webbeans.conversation.ConversationManager;* but it seems that you have not committed this package yet, ConversationManager is still in the jsf package. For Conversation stuff, As I said before, specification defines the conversations at the JSF level. It does not define anything for other than JSF. Maybe we can extend it to use any technology other than JSF. I will think about it. Gurkan From: Mark Struberg strub...@yahoo.de To: openwebbeans-dev@incubator.apache.org Sent: Thursday, March 26, 2009 10:26:21 PM Subject: setting conversation at request startup Gurkan, I think I need help :) Currently we set the Converation via the ConversationComponent which gets the conversationId from the FacesContext. The FacesContext is essentially the same thing as we already have with our WebBeansContext. It's 'simply' a ThreadLocal container for session/app/request/page information. So my idea was to store the conversationId in a kind of @RequestScoped bean at start of the ServletRequest, so the ConversationComponent doesn't need to get the cid from the FacesContext but instead simply asks this 'ConversationBean'. Hmm the longer I think about it, why don't we simply create the Conversation at request startup? My basic idea was: we should move the conversationId detection out of the ConversationComponent, and make it part of the 'integration stuff'. So for ServletContainers this may work different than for PortletBridges and also different for freaky things like a standalone Swing application. txs and LieGrue, strub
Re: setting conversation at request startup
Right! I don't think Wicket is going to be that tough. The Seam folks have already created a Wicket integration project, so we can kind of mimic what they've done. Although, I think they went about it the wrong way. :) On Thu, Mar 26, 2009 at 7:33 PM, Mark Struberg strub...@yahoo.de wrote: not for JSF. In JSF, the FacesContext behaves different if you run under a Portlet or under a ServletContainer. But for Wicket, there may be something to be done manually (ServletRequest vs PortletRequest). But I suggest to first concentrate on nacked ServletContainers and full J2EE stacks. I think there is enough work left to do ;) LieGrue, strub --- James Carman jcar...@carmanconsulting.com schrieb am Fr, 27.3.2009: Von: James Carman jcar...@carmanconsulting.com Betreff: Re: setting conversation at request startup An: openwebbeans-dev@incubator.apache.org Datum: Freitag, 27. März 2009, 0:09 Would it be necessary (or at least nice :) to perhaps implement a portlet-specific implementation of the conversation management, too? Also, would you guys like me to submit some patches to help out? Is there anything that you'd feel comfortable letting me tackle? On Thu, Mar 26, 2009 at 7:04 PM, Mark Struberg strub...@yahoo.de wrote: apologise for not checking this in, my girlfriend pulled me off my chair for watching a movie :) I didn't look at the code yet, but I like the idea with the SPI. Guess this is the most simple solution here. Wdyt about OWB-88? I think it should be possible to split the whole JSF part into an own module without breaking the spec or losing performance. txs and LieGrue, mark --- Gurkan Erdogdu gurkanerdo...@yahoo.com schrieb am Do, 26.3.2009: Von: Gurkan Erdogdu gurkanerdo...@yahoo.com Betreff: Re: setting conversation at request startup An: openwebbeans-dev@incubator.apache.org Datum: Donnerstag, 26. März 2009, 22:31 Firstly I have got compile error in the WebBeansFinder class. It uses *import org.apache.webbeans.conversation.ConversationManager;* but it seems that you have not committed this package yet, ConversationManager is still in the jsf package. I have changed the packages. I have just added the *conversation* package and added ConversationManager and ConversationImpl into it removing from the jsf package. Gurkan From: Gurkan Erdogdu gurkanerdo...@yahoo.com To: openwebbeans-dev@incubator.apache.org Sent: Thursday, March 26, 2009 10:43:12 PM Subject: Re: setting conversation at request startup Hi Mark; Firstly I have got compile error in the WebBeansFinder class. It uses *import org.apache.webbeans.conversation.ConversationManager;* but it seems that you have not committed this package yet, ConversationManager is still in the jsf package. For Conversation stuff, As I said before, specification defines the conversations at the JSF level. It does not define anything for other than JSF. Maybe we can extend it to use any technology other than JSF. I will think about it. Gurkan From: Mark Struberg strub...@yahoo.de To: openwebbeans-dev@incubator.apache.org Sent: Thursday, March 26, 2009 10:26:21 PM Subject: setting conversation at request startup Gurkan, I think I need help :) Currently we set the Converation via the ConversationComponent which gets the conversationId from the FacesContext. The FacesContext is essentially the same thing as we already have with our WebBeansContext. It's 'simply' a ThreadLocal container for session/app/request/page information. So my idea was to store the conversationId in a kind of @RequestScoped bean at start of the ServletRequest, so the ConversationComponent doesn't need to get the cid from the FacesContext but instead simply asks this 'ConversationBean'. Hmm the longer I think about it, why don't we simply create the Conversation at request startup? My basic idea was: we should move the conversationId detection out of the ConversationComponent, and make it part of the 'integration stuff'. So for ServletContainers this may work different than for PortletBridges and also different for freaky things like a standalone Swing application. txs and LieGrue, strub
