from:"Gurkan Erdogdu"

Update Samples for JSF2 Usage
-

 Key: OWB-204
 URL: https://issues.apache.org/jira/browse/OWB-204
 Project: OpenWebBeans
  Issue Type: Task
  Components: Core
Affects Versions: M3
Reporter: Gurkan Erdogdu
Assignee: Gurkan Erdogdu
 Fix For: M4


We have updated our JSF version to 2.0. Samples must be updated to use JSF 2 
libraries. Task includes updating faces-config.xml files to remove 
facelet-handler, update faces-config schema version to 2.0, update libs.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (OWB-204) Update Samples for JSF2 Usage


[ 
https://issues.apache.org/jira/browse/OWB-204?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12792991#action_12792991
 ] 

Gurkan Erdogdu commented on OWB-204:


While trying to convert our samples to MyFaces 2.0, there were problems with 
MyFaces. So, until GA release of myfaces, it reasonable to keep MyFaces 1.2. 
Therefore I will update samples for using MyFaces 1.2.8.

 Update Samples for JSF2 Usage
 -

 Key: OWB-204
 URL: https://issues.apache.org/jira/browse/OWB-204
 Project: OpenWebBeans
  Issue Type: Task
  Components: Core
Affects Versions: M3
Reporter: Gurkan Erdogdu
Assignee: Gurkan Erdogdu
 Fix For: M4


 We have updated our JSF version to 2.0. Samples must be updated to use JSF 2 
 libraries. Task includes updating faces-config.xml files to remove 
 facelet-handler, update faces-config schema version to 2.0, update libs.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (OWB-204) Update Samples for JSF2 Usage


 [ 
https://issues.apache.org/jira/browse/OWB-204?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gurkan Erdogdu updated OWB-204:
---

Fix Version/s: (was: M4)
   1.0.0

 Update Samples for JSF2 Usage
 -

 Key: OWB-204
 URL: https://issues.apache.org/jira/browse/OWB-204
 Project: OpenWebBeans
  Issue Type: Task
  Components: Core
Affects Versions: M3
Reporter: Gurkan Erdogdu
Assignee: Gurkan Erdogdu
 Fix For: 1.0.0


 We have updated our JSF version to 2.0. Samples must be updated to use JSF 2 
 libraries. Task includes updating faces-config.xml files to remove 
 facelet-handler, update faces-config schema version to 2.0, update libs.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (OWB-205) Update Samples for MyFaces 1.2 Latest Version


[ 
https://issues.apache.org/jira/browse/OWB-205?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12792992#action_12792992
 ] 

Gurkan Erdogdu commented on OWB-205:


Adding version1.2.8/version to poms.

 Update Samples for MyFaces 1.2 Latest Version
 -

 Key: OWB-205
 URL: https://issues.apache.org/jira/browse/OWB-205
 Project: OpenWebBeans
  Issue Type: Task
Affects Versions: M3
Reporter: Gurkan Erdogdu
Assignee: Gurkan Erdogdu
 Fix For: M4




-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Closed: (OWB-205) Update Samples for MyFaces 1.2 Latest Version


 [ 
https://issues.apache.org/jira/browse/OWB-205?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gurkan Erdogdu closed OWB-205.
--

Resolution: Fixed

 Update Samples for MyFaces 1.2 Latest Version
 -

 Key: OWB-205
 URL: https://issues.apache.org/jira/browse/OWB-205
 Project: OpenWebBeans
  Issue Type: Task
Affects Versions: M3
Reporter: Gurkan Erdogdu
Assignee: Gurkan Erdogdu
 Fix For: M4




-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (OWB-171) CID during GET requests must be set on UIViewRoot earlier than before render response

[
https://issues.apache.org/jira/browse/OWB-171?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12792993#action_12792993
]

Gurkan Erdogdu commented on OWB-171:

I have applied and committed patch, thanks Svan!

CID during GET requests must be set on UIViewRoot earlier than before render
response
-

Key: OWB-171
URL: https://issues.apache.org/jira/browse/OWB-171
Project: OpenWebBeans
Issue Type: Bug
Components: Context and Scopes
Affects Versions: M3
Reporter: Sven Linstaedt
Assignee: Gurkan Erdogdu
Fix For: M4

Attachments: owb-171.diff, owb-171.diff, owb-171.diff, owb-171.diff

The problem:
GET requests in JSF2 can be handled by the full lifecycle, if the view
contains a f:metadata/ with appropriate f:viewParam/ components. Because
no UIViewRoot is restored, but instead a new one is created, no cid can be
restored from the view root until WebBeansPhaseListener handles before render
rensponse.
If one requests the Conversation for injection during the lifecycle
ConversationBean.createInstance() is called, which should lookup the
conversation on the ConversationManager using the current sessionid and cid.
Both string based parameters are again looked up from the
ConversationService. Unfortunately ConversationService.getConversationId()
uses the ViewRoot's attributes map of current FacesContext to retrieve the
cid, which will be first set in the render phase. This results in a new
conversation being created.
A possible solution would consists of setting the cid as early as the view
root is created in restore view.

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Created: (OWB-201) @New must use its value field while creating New bean

2009-12-18 Thread Gurkan Erdogdu (JIRA)

@New must use its value field while creating New bean
-

 Key: OWB-201
 URL: https://issues.apache.org/jira/browse/OWB-201
 Project: OpenWebBeans
  Issue Type: Bug
Reporter: Gurkan Erdogdu
Assignee: Gurkan Erdogdu




-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: Integration of JSF2 specific API calls

2009-12-18 Thread Gurkan Erdogdu

Also we have to update our poms for JSf2

2009/12/19 Gurkan Erdogdu cgurkanerdo...@gmail.com

 Just adding classes to webbeans-jsf project.

 For example you can add JSf2WebBeansListener etc.

 2009/12/19 Sven Linstaedt sven.linsta...@googlemail.com

 Was there any agreement on the JSF2 topic? As far as I remember two
 solutions were mentioned:

 1. Move completely to JSF2, JSF1 is not supported any more
 2. Create an additional project for JSF2 integration

 br, Sven



 2009/12/18 Mark Struberg strub...@yahoo.de

  +1  big one :)
 
  webbeans-impl should finally need no other dependencies than SE (maybe +
  the servlet_spec because that would be much work to sort it out)
 
  LieGrue,
  strub
 
  --- Sven Linstaedt sven.linsta...@googlemail.com schrieb am Fr,
  18.12.2009:
 
   Von: Sven Linstaedt sven.linsta...@googlemail.com
   Betreff: Re: Integration of JSF2 specific API calls
   An: openwebbeans-dev@incubator.apache.org
   Datum: Freitag, 18. Dezember 2009, 13:38
   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

Re: Integration of JSF2 specific API calls

2009-12-18 Thread Gurkan Erdogdu

MyFaces 2 Alpha Release Maven

http://repo1.maven.org/maven2/org/apache/myfaces/core/myfaces-api/2.0.0-alpha/

2009/12/19 Gurkan Erdogdu cgurkanerdo...@gmail.com

 Also we have to update our poms for JSf2

 2009/12/19 Gurkan Erdogdu cgurkanerdo...@gmail.com

 Just adding classes to webbeans-jsf project.

 For example you can add JSf2WebBeansListener etc.

 2009/12/19 Sven Linstaedt sven.linsta...@googlemail.com

 Was there any agreement on the JSF2 topic? As far as I remember two
 solutions were mentioned:

 1. Move completely to JSF2, JSF1 is not supported any more
 2. Create an additional project for JSF2 integration

 br, Sven



 2009/12/18 Mark Struberg strub...@yahoo.de

  +1  big one :)
 
  webbeans-impl should finally need no other dependencies than SE (maybe
 +
  the servlet_spec because that would be much work to sort it out)
 
  LieGrue,
  strub
 
  --- Sven Linstaedt sven.linsta...@googlemail.com schrieb am Fr,
  18.12.2009:
 
   Von: Sven Linstaedt sven.linsta...@googlemail.com
   Betreff: Re: Integration of JSF2 specific API calls
   An: openwebbeans-dev@incubator.apache.org
   Datum: Freitag, 18. Dezember 2009, 13:38
   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

Re: Integration of JSF2 specific API calls

2009-12-17 Thread Gurkan Erdogdu

Id favour a webbeans-jsf2, I think that's more future proof.
I think that there is no need to define extra jsf module/project. There is
no such a thing that You could use it in JSF 1.2  but not JSF2 or vice
versa. We support JSF2 and JSF2 is backward compatible. But, if we really
emphasize that the code is related with JSF2, we can create a package with
named jsf2 in webbeans-jsf project.

Thanks;

--Gurkan

2009/12/17 Mark Struberg strub...@yahoo.de

 cool!

 Id favour a webbeans-jsf2, I think that's more future proof.

 And as Gurkan already said: please attach the patch as owb-171-patch.rfc in
 Jira.

 txs and LieGrue,
 strub

 --- Sven Linstaedt sven.linsta...@googlemail.com schrieb am Do,
 17.12.2009:

  Von: Sven Linstaedt sven.linsta...@googlemail.com
  Betreff: Integration of JSF2 specific API calls
  An: openwebbeans-dev@incubator.apache.org
  Datum: Donnerstag, 17. Dezember 2009, 2:24
  Back in business.
 
  I am currently working on a patch for OWB-171. Besides some
  cleanups I have refactored the code:
 
  Conversation is request scoped and solely created or
  restored by ConversationBean which delegates the later one
  to the ConversationManager. WebBeansPhaseListener is only
  responsible for retrieving and handling the
  ConversationContext. Conversation is only restored using the
  cid request parameter and not the
  UIViewRoot's attributes, because the view is only
  accessible after restore view phase. The restored
  conversation (and it's context of course) must actually
  exist for restoring the view. This chicken or egg problem
  was the reason not to store the the cid in the view's
  attributes, because restoring these attributes actually
  needs restoring the conversation beforehand.
 
 
  There is still an issue with the jsf2-example: In case of
  ajax requests which start a long running conversation, all
  form's action attributes needs to be updated to reflect
  the current active conversation for following request. This
  could be done using JSF2 specific API features. At the
  moment webbeans-impl is purely compiled against the JSF 1.2
  API. Without the necessary abstraction there is no chance to
  get the JSF2 specific ajax functionality working again.
 
 
  I have attached the patch to this mail and not to the
  issue, because the patch is not meant for inclusion yet, but
  for testing purposes. Integration it and rerunning the
  jsf2-example points out my problem. If you disable ajax by
  disabling javascript in your browser e.g. the conversation
  example is working, because in this case the full page with
  updated form's action urls is rendered during each
  action invocation.
 
 
  Last but not least: Do you guys have a glue how JSF2
  specific extension for conversation handling should be
  integrated? I supose either adding another project
  (webbeans-jsf2 e.g.) or updating the JSF API (not impl)
  version to 2.x and making sure, we are loading JSF2 specific
  classes only for this ajax purpose.
 
 
  good night, Sven
 
 

 __
 Do You Yahoo!?
 Sie sind Spam leid? Yahoo! Mail verfügt über einen herausragenden Schutz
 gegen Massenmails.
 http://mail.yahoo.com




-- 
Gurkan Erdogdu
http://gurkanerdogdu.blogspot.com

Re: Integration of JSF2 specific API calls

2009-12-17 Thread Gurkan Erdogdu

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 JSF-1.2 there was no standardised ajax
 handling, so we would have no chance to use those features in a portable
 fashion.

 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, 9:50
  Id favour a
  webbeans-jsf2, I think that's more future proof.
  I think that there is no need to define extra jsf
  module/project. There is
  no such a thing that You could use it in JSF 1.2  but
  not JSF2 or vice
  versa. We support JSF2 and JSF2 is backward compatible.
  But, if we really
  emphasize that the code is related with JSF2, we can
  create a package with
  named jsf2 in webbeans-jsf project.
 
  Thanks;
 
  --Gurkan
 
  2009/12/17 Mark Struberg strub...@yahoo.de
 
   cool!
  
   Id favour a webbeans-jsf2, I think that's more future
  proof.
  
   And as Gurkan already said: please attach the patch as
  owb-171-patch.rfc in
   Jira.
  
   txs and LieGrue,
   strub
  
   --- Sven Linstaedt sven.linsta...@googlemail.com
  schrieb am Do,
   17.12.2009:
  
Von: Sven Linstaedt sven.linsta...@googlemail.com
Betreff: Integration of JSF2 specific API calls
An: openwebbeans-dev@incubator.apache.org
Datum: Donnerstag, 17. Dezember 2009, 2:24
Back in business.
   
I am currently working on a patch for OWB-171.
  Besides some
cleanups I have refactored the code:
   
Conversation is request scoped and solely created
  or
restored by ConversationBean which delegates the
  later one
to the ConversationManager. WebBeansPhaseListener
  is only
responsible for retrieving and handling the
ConversationContext. Conversation is only
  restored using the
cid request parameter and not the
UIViewRoot's attributes, because the view is
  only
accessible after restore view phase. The
  restored
conversation (and it's context of course) must
  actually
exist for restoring the view. This chicken or egg
  problem
was the reason not to store the the cid in the
  view's
attributes, because restoring these attributes
  actually
needs restoring the conversation beforehand.
   
   
There is still an issue with the jsf2-example: In
  case of
ajax requests which start a long running
  conversation, all
form's action attributes needs to be updated to
  reflect
the current active conversation for following
  request. This
could be done using JSF2 specific API features.
  At the
moment webbeans-impl is purely compiled against
  the JSF 1.2
API. Without the necessary abstraction there is
  no chance to
get the JSF2 specific ajax functionality working
  again.
   
   
I have attached the patch to this mail and not to
  the
issue, because the patch is not meant for
  inclusion yet, but
for testing purposes. Integration it and
  rerunning the
jsf2-example points out my problem. If you
  disable ajax by
disabling javascript in your browser e.g. the
  conversation
example is working, because in this case the full
  page with
updated form's action urls is rendered during
  each
action invocation.
   
   
Last but not least: Do you guys have a glue how
  JSF2
specific extension for conversation handling
  should be
integrated? I supose either adding another
  project
(webbeans-jsf2 e.g.) or updating the JSF API (not
  impl)
version to 2.x and making sure, we are loading
  JSF2 specific
classes only for this ajax purpose.
   
   
good night, Sven
   
   
  
   __
   Do You Yahoo!?
   Sie sind Spam leid? Yahoo! Mail verfügt über einen
  herausragenden Schutz

Re: Integration of JSF2 specific API calls

2009-12-17 Thread Gurkan Erdogdu

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 JSF-1.2 there was no
  standardised ajax
   handling, so we would have no chance to use those
  features in a portable
   fashion.
  
   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, 9:50
Id favour a
webbeans-jsf2, I think that's more future proof.
I think that there is no need to define extra
  jsf
module/project. There is
no such a thing that You could use it in JSF
  1.2  but
not JSF2 or vice
versa. We support JSF2 and JSF2 is backward
  compatible.
But, if we really
emphasize that the code is related with JSF2,
  we can
create a package with
named jsf2 in webbeans-jsf project.
   
Thanks;
   
--Gurkan
   
2009/12/17 Mark Struberg strub...@yahoo.de
   
 cool!

 Id favour a webbeans-jsf2, I think that's
  more future
proof.

 And as Gurkan already said: please attach
  the patch as
owb-171-patch.rfc in
 Jira.

 txs and LieGrue,
 strub

 --- Sven Linstaedt sven.linsta...@googlemail.com
schrieb am Do,
 17.12.2009:

  Von: Sven Linstaedt sven.linsta...@googlemail.com
  Betreff: Integration of JSF2 specific
  API calls
  An: openwebbeans-dev@incubator.apache.org
  Datum: Donnerstag, 17. Dezember 2009,
  2:24
  Back in business.
 
  I am currently working on a patch for
  OWB-171.
Besides some
  cleanups I have refactored the code:
 
  Conversation is request scoped and
  solely

Re: Integration of JSF2 specific API calls

2009-12-17 Thread Gurkan Erdogdu

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 JSF-1.2 there was no
  standardised ajax
   handling, so we would have no chance to use those
  features in a portable
   fashion.
  
   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, 9:50
Id favour a
webbeans-jsf2, I think that's more future proof.
I think that there is no need to define extra
  jsf
module/project. There is
no such a thing that You could use it in JSF
  1.2  but
not JSF2 or vice
versa. We support JSF2 and JSF2 is backward
  compatible.
But, if we really
emphasize that the code is related with JSF2,
  we can
create a package with
named jsf2 in webbeans-jsf project.
   
Thanks;
   
--Gurkan
   
2009/12/17 Mark Struberg strub...@yahoo.de
   
 cool!

 Id favour a webbeans-jsf2, I think that's
  more future
proof.

 And as Gurkan already said: please attach
  the patch as
owb-171-patch.rfc in
 Jira.

 txs and LieGrue,
 strub

 --- Sven Linstaedt sven.linsta...@googlemail.com
schrieb am Do,
 17.12.2009:

  Von: Sven Linstaedt sven.linsta

Re: Congratulations! OpenWebBeans is now a TLP

2009-12-17 Thread Gurkan Erdogdu

Hey,

I am very happy for hearing such a great news! It takes a more than one year 
work with unbelievable support from our mentors and community. Thanks to all 
members of the OWB community and our mentors. Especially I want to special 
thank our mentor Kevan Miller for his sincere support.

I think that our responsibility for OWB will be increased after becoming TLP of 
Apache Foundation. But I believe that we will run over all of hard things that 
we will face with while living as TLP.

Kevan, what will be next? How could we start to relocate our resources/mailing 
lists etc?

Thanks;

--Gurkan





From: Mark Struberg strub...@yahoo.de
To: openwebbeans-dev@incubator.apache.org; 
openwebbeans-us...@incubator.apache.org
Sent: Thu, December 17, 2009 4:37:31 PM
Subject: Congratulations! OpenWebBeans is now a TLP

Hi!

From the ASF board meeting report:

 The following resolutions were passed unaminously:
 ...
   B. Establish the Apache OpenWebBeans Project (Gurkan Erdogdu, VP)

Congratulations all for the hard and successful work!

I'd like to specially thank our Mentors Kevan and Matthias for their support 
and of course Gurkan for doing most of the actual hacking :)

LieGrue,
strub

__
Do You Yahoo!?
Sie sind Spam leid? Yahoo! Mail verfügt über einen herausragenden Schutz gegen 
Massenmails. 
http://mail.yahoo.com



  ___
Yahoo! Türkiye açıldı!  http://yahoo.com.tr
İnternet üzerindeki en iyi içeriği Yahoo! Türkiye sizlere sunuyor!

Re: what about a -M4 release?

2009-12-17 Thread Gurkan Erdogdu

congrats! I recently did the same. Feels good!
Good luck for your wife and you!
Thanks a lot :)

--Gurkan





From: Matthias Wessendorf mat...@apache.org
To: openwebbeans-dev@incubator.apache.org
Sent: Thu, December 17, 2009 6:43:52 PM
Subject: Re: what about a -M4 release?

On Mon, Dec 14, 2009 at 8:40 PM, Gurkan Erdogdu gurkanerdo...@yahoo.com wrote:
 Hi Mark;

 WDYT about the content for M4 release? I think that documentation and web 
 site needs more work. If we release M4 , we have to also focus on those 2 
 subjects.


 Besides, would you like to be release guy for M4 :)?

 In the mean time, I will be marrying at next week, all of you are welcome to 
 my wedding ceremony :)

congrats! I recently did the same. Feels good!
Good luck for your wife and you!

-M


 Thnks;

 --Gurkan



 
 From: Mark Struberg strub...@yahoo.de
 To: openwebbeans-dev@incubator.apache.org
 Sent: Mon, December 14, 2009 5:57:09 PM
 Subject: what about a -M4 release?

 Hi!

 Wdyt about releaseing a milestone M4 now?

 I think OWB has become pretty stable and since the spec is not moving 
 anymore, it would be a good idea to get more users on board right now.

 txs and LieGrue,
 strub

 __
 Do You Yahoo!?
 Sie sind Spam leid? Yahoo! Mail verfügt über einen herausragenden Schutz 
 gegen Massenmails.
 http://mail.yahoo.com



  ___
 Yahoo! Türkiye açıldı!  http://yahoo.com.tr
 İnternet üzerindeki en iyi içeriği Yahoo! Türkiye sizlere sunuyor!



-- 
Matthias Wessendorf

blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf



  ___
Yahoo! Türkiye açıldı!  http://yahoo.com.tr
İnternet üzerindeki en iyi içeriği Yahoo! Türkiye sizlere sunuyor!

[jira] Closed: (OWB-191) Convert logging to use keyed, formatted strings from a ResourceBundle to allow for translation.


 [ 
https://issues.apache.org/jira/browse/OWB-191?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gurkan Erdogdu closed OWB-191.
--

   Resolution: Fixed
Fix Version/s: M4

Committed, thanks Paul J. Reder

 Convert logging to use keyed, formatted strings from a ResourceBundle to 
 allow for translation.
 ---

 Key: OWB-191
 URL: https://issues.apache.org/jira/browse/OWB-191
 Project: OpenWebBeans
  Issue Type: Improvement
  Components: Core
 Environment: All.
Reporter: Paul J. Reder
Assignee: Gurkan Erdogdu
 Fix For: M4

 Attachments: ResourceBundlePort.patch


 Currently all logs and exceptions use hard coded strings that are embedded 
 throughout the source. The attached patch converts the code to use key-based 
 strings from a ResourceBundle so that all strings are collected in one place 
 to enable translation.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Closed: (OWB-148) create a test case for the BeforeShutDown event


 [ 
https://issues.apache.org/jira/browse/OWB-148?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gurkan Erdogdu closed OWB-148.
--

   Resolution: Fixed
Fix Version/s: M4

 create a test case for the BeforeShutDown event
 ---

 Key: OWB-148
 URL: https://issues.apache.org/jira/browse/OWB-148
 Project: OpenWebBeans
  Issue Type: Bug
  Components: Events
Affects Versions: M3
Reporter: Mark Struberg
Assignee: Mark Struberg
 Fix For: M4


 It seems that the BeforeShutDown event doesn't get received, so we first have 
 to create a proper JUnit test case for it.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (OWB-187) Interceptors with lifecycle and @AroundInvoke permitted to have bindingtypes containing method-level annotations


 [ 
https://issues.apache.org/jira/browse/OWB-187?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gurkan Erdogdu updated OWB-187:
---

Fix Version/s: M4

 Interceptors with lifecycle and @AroundInvoke permitted to have bindingtypes 
 containing method-level annotations
 

 Key: OWB-187
 URL: https://issues.apache.org/jira/browse/OWB-187
 Project: OpenWebBeans
  Issue Type: Bug
  Components: Interceptor and Decorators
Affects Versions: M3
Reporter: Eric Covener
Assignee: Eric Covener
Priority: Minor
 Fix For: M4

   Original Estimate: 1h
  Remaining Estimate: 1h

 An interceptor for lifecycle callbacks may only declare interceptor binding 
 types that are defined as @Target(TYPE). If an interceptor for lifecycle 
 callbacks declares an interceptor binding type that is defined @Target({TYPE, 
 METHOD}), the container automatically detects the problem and treats it as a 
 definition error.
 our InterceptorUtil.checkLifecycleConditions() does not perform the METHOD 
 check when the Interceptor also contains business method interceptors

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (OWB-167) Buildin Bean types should be decoratable


 [ 
https://issues.apache.org/jira/browse/OWB-167?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gurkan Erdogdu updated OWB-167:
---

Affects Version/s: M3
Fix Version/s: M4

 Buildin Bean types should be decoratable
 

 Key: OWB-167
 URL: https://issues.apache.org/jira/browse/OWB-167
 Project: OpenWebBeans
  Issue Type: Bug
  Components: Interceptor and Decorators
Affects Versions: M3
Reporter: Sven Linstaedt
Assignee: Gurkan Erdogdu
 Fix For: M4


 According to the weld list buildin Bean types like Conversations should be 
 decoratable like application specific Beans. 
 I haved tested this not working for javax.enterprise.context.Conversation, 
 but I believe other buildin Beans are not decoratable too.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Closed: (OWB-185) Managed beans with non-default constructors lead to InstantiationException when creating the proxy


 [ 
https://issues.apache.org/jira/browse/OWB-185?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gurkan Erdogdu closed OWB-185.
--

   Resolution: Fixed
Fix Version/s: M4

Look at chapter 5.4.1. Normal scoped beans must have default public constructor.

 Managed beans with non-default constructors lead to InstantiationException 
 when creating the proxy
 --

 Key: OWB-185
 URL: https://issues.apache.org/jira/browse/OWB-185
 Project: OpenWebBeans
  Issue Type: Bug
  Components: Injection and Lookup
Affects Versions: M3
Reporter: Joe Bergmark
Assignee: Gurkan Erdogdu
 Fix For: M4


 While working on OWB-151 I ran into a problem with the way proxies are 
 created for beans with non-default injected constructors.  For example, you 
 could look at 
 org.apache.webbeans.newtests.interceptors.lifecycle.LifecycleBean and give it 
 a normal scope:
 @RequestScoped
 @LifecycleBinding
 @Named(org.apache.webbeans.newtests.interceptors.lifecycle.LifecycleBean)
 public class LifecycleBean
 {
 public static String CONSTRUCTOR_INJECTED = null; 
 
 @Inject
 public LifecycleBean(@New String string)
 {
 CONSTRUCTOR_INJECTED = string;
 }
 
 public void touch(){}
 }
 Leads to the following exception (the stack trace is off slightly due to some 
 refactoring I have done but the error should be the same):
 org.apache.webbeans.exception.WebBeansException: 
 java.lang.InstantiationException: 
 org.apache.webbeans.newtests.interceptors.lifecycle.LifecycleBean_$$_javassist_1
   at 
 org.apache.webbeans.proxy.JavassistProxyFactory.createNewProxyWithHandler(JavassistProxyFactory.java:53)
   at 
 org.apache.webbeans.proxy.JavassistProxyFactory.createNewProxyInstance(JavassistProxyFactory.java:78)
   at 
 org.apache.webbeans.container.BeanManagerImpl.getReference(BeanManagerImpl.java:702)
   at 
 org.apache.webbeans.newtests.interceptors.lifecycle.LifecycleTest.testLifecycle(LifecycleTest.java:57)
   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
   at 
 sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
   at 
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37)
   at java.lang.reflect.Method.invoke(Method.java:599)
   at 
 org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:44)
   at 
 org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
   at 
 org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:41)
   at 
 org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20)
   at 
 org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28)
   at 
 org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:31)
   at 
 org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:73)
   at 
 org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:46)
   at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:180)
   at org.junit.runners.ParentRunner.access$000(ParentRunner.java:41)
   at org.junit.runners.ParentRunner$1.evaluate(ParentRunner.java:173)
   at 
 org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28)
   at 
 org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:31)
   at org.junit.runners.ParentRunner.run(ParentRunner.java:220)
   at 
 org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:45)
   at 
 org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
   at 
 org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:460)
   at 
 org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:673)
   at 
 org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:386)
   at 
 org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:196)
 Caused by: java.lang.InstantiationException: 
 org.apache.webbeans.newtests.interceptors.lifecycle.LifecycleBean_$$_javassist_1
   at java.lang.J9VMInternals.newInstanceImpl(Native Method)
   at java.lang.Class.newInstance(Class.java:1325)
   at 
 org.apache.webbeans.proxy.JavassistProxyFactory.createNewProxyWithHandler(JavassistProxyFactory.java:48)
   ... 27 more

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Closed: (OWB-192) Bean Api Types Does not contain Object.class


 [ 
https://issues.apache.org/jira/browse/OWB-192?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gurkan Erdogdu closed OWB-192.
--

Resolution: Fixed

Done.

 Bean Api Types Does not contain Object.class
 

 Key: OWB-192
 URL: https://issues.apache.org/jira/browse/OWB-192
 Project: OpenWebBeans
  Issue Type: Bug
  Components: Core
Affects Versions: M3
Reporter: Gurkan Erdogdu
Assignee: Gurkan Erdogdu
 Fix For: M4


 Currently, bean Api Types Does not contain Object.class.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Created: (OWB-195) Give warning to the developer related with non- portable operations

Give warning to the developer related with non- portable operations
---

 Key: OWB-195
 URL: https://issues.apache.org/jira/browse/OWB-195
 Project: OpenWebBeans
  Issue Type: Improvement
  Components: Core
Affects Versions: M3
Reporter: Gurkan Erdogdu
Assignee: Gurkan Erdogdu
Priority: Minor
 Fix For: 1.0.0




-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (OWB-193) If an interceptor or decorator has any scope other than @Dependent, non-portable behavior results.


 [ 
https://issues.apache.org/jira/browse/OWB-193?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gurkan Erdogdu updated OWB-193:
---

Issue Type: Sub-task  (was: Improvement)
Parent: OWB-195

 If an interceptor or decorator has any scope other than @Dependent, 
 non-portable behavior results.
 --

 Key: OWB-193
 URL: https://issues.apache.org/jira/browse/OWB-193
 Project: OpenWebBeans
  Issue Type: Sub-task
  Components: Context and Scopes
Affects Versions: M3
Reporter: Gurkan Erdogdu
Assignee: Gurkan Erdogdu
Priority: Minor
 Fix For: 1.0.0


 Give a warning message to the user

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (OWB-194) If an interceptor or decorator has a name, non-portable behavior results.


 [ 
https://issues.apache.org/jira/browse/OWB-194?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gurkan Erdogdu updated OWB-194:
---

Issue Type: Sub-task  (was: Improvement)
Parent: OWB-195

 If an interceptor or decorator has a name, non-portable behavior results.
 -

 Key: OWB-194
 URL: https://issues.apache.org/jira/browse/OWB-194
 Project: OpenWebBeans
  Issue Type: Sub-task
Affects Versions: M3
Reporter: Gurkan Erdogdu
Assignee: Gurkan Erdogdu
Priority: Minor
 Fix For: 1.0.0


 Give a warning to the user

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Created: (OWB-196) If an interceptor or decorator is an alternative, non-portable behavior results.

If an interceptor or decorator is an alternative, non-portable behavior results.


 Key: OWB-196
 URL: https://issues.apache.org/jira/browse/OWB-196
 Project: OpenWebBeans
  Issue Type: Sub-task
  Components: Core
Affects Versions: 1.0.0
Reporter: Gurkan Erdogdu
Assignee: Gurkan Erdogdu
Priority: Minor
 Fix For: M3




-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Created: (OWB-197) If a stereotype declares any other qualifier an- notation, non-portable behavior results.

If a stereotype declares any other qualifier an- notation, non-portable 
behavior results.
-

 Key: OWB-197
 URL: https://issues.apache.org/jira/browse/OWB-197
 Project: OpenWebBeans
  Issue Type: Sub-task
  Components: Core
Reporter: Gurkan Erdogdu
Assignee: Gurkan Erdogdu




-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Created: (OWB-198) If a stereotype is annotated @Typed, non-portable behavior results.

If a stereotype is annotated @Typed, non-portable behavior results.
---

 Key: OWB-198
 URL: https://issues.apache.org/jira/browse/OWB-198
 Project: OpenWebBeans
  Issue Type: Sub-task
  Components: Core
Affects Versions: M3
Reporter: Gurkan Erdogdu
Assignee: Gurkan Erdogdu
Priority: Minor
 Fix For: 1.0.0




-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (OWB-197) If a stereotype declares any other qualifier an- notation, non-portable behavior results.


 [ 
https://issues.apache.org/jira/browse/OWB-197?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gurkan Erdogdu updated OWB-197:
---

  Component/s: Core
 Priority: Minor  (was: Major)
Affects Version/s: M3
Fix Version/s: 1.0.0

 If a stereotype declares any other qualifier an- notation, non-portable 
 behavior results.
 -

 Key: OWB-197
 URL: https://issues.apache.org/jira/browse/OWB-197
 Project: OpenWebBeans
  Issue Type: Sub-task
  Components: Core
Affects Versions: M3
Reporter: Gurkan Erdogdu
Assignee: Gurkan Erdogdu
Priority: Minor
 Fix For: 1.0.0




-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Created: (OWB-199) Bug in ProducerMethod primitive return type resolution

Bug in ProducerMethod primitive return type resolution
--

 Key: OWB-199
 URL: https://issues.apache.org/jira/browse/OWB-199
 Project: OpenWebBeans
  Issue Type: Bug
  Components: Core
Affects Versions: M3
Reporter: Gurkan Erdogdu
Assignee: Gurkan Erdogdu
 Fix For: M4




-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Closed: (OWB-200) @Type annotation does not work correctly


 [ 
https://issues.apache.org/jira/browse/OWB-200?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gurkan Erdogdu closed OWB-200.
--

   Resolution: Fixed
Fix Version/s: M4

 @Type annotation does not work correctly
 

 Key: OWB-200
 URL: https://issues.apache.org/jira/browse/OWB-200
 Project: OpenWebBeans
  Issue Type: Bug
Affects Versions: M3
Reporter: Gurkan Erdogdu
Assignee: Gurkan Erdogdu
 Fix For: M4




-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: Integration of JSF2 specific API calls

2009-12-16 Thread Gurkan Erdogdu

Thanks for working and commenting Sven!
At the moment webbeans-impl is purely compiled against the JSF 1.2 API.
We have to definitely change our JSF dependency to JSF2 API. We will use
MyFaces JSF2. (Currently MyFaces Core 2.0.0-alpha ). You could change pom
file(https://svn.apache.org/repos/asf/incubator/openwebbeans/trunk/pom.xml)
to use MyFaces JSF2 Alpha.

I think patch is dropped because of attachment policy of mailing lists.
Please attach your patch to jira.

--Gurkan

2009/12/17 Sven Linstaedt sven.linsta...@googlemail.com

 Back in business.

 I am currently working on a patch for OWB-171. Besides some cleanups I have
 refactored the code:

 Conversation is request scoped and solely created or restored by
 ConversationBean which delegates the later one to the ConversationManager.
 WebBeansPhaseListener is only responsible for retrieving and handling the
 ConversationContext. Conversation is only restored using the cid request
 parameter and not the UIViewRoot's attributes, because the view is only
 accessible after restore view phase. The restored conversation (and it's
 context of course) must actually exist for restoring the view. This chicken
 or egg problem was the reason not to store the the cid in the view's
 attributes, because restoring these attributes actually needs restoring the
 conversation beforehand.

 There is still an issue with the jsf2-example: In case of ajax requests
 which start a long running conversation, all form's action attributes needs
 to be updated to reflect the current active conversation for following
 request. This could be done using JSF2 specific API features. At the moment
 webbeans-impl is purely compiled against the JSF 1.2 API. Without the
 necessary abstraction there is no chance to get the JSF2 specific ajax
 functionality working again.

 I have attached the patch to this mail and not to the issue, because the
 patch is not meant for inclusion yet, but for testing purposes. Integration
 it and rerunning the jsf2-example points out my problem. If you disable ajax
 by disabling javascript in your browser e.g. the conversation example is
 working, because in this case the full page with updated form's action urls
 is rendered during each action invocation.

 Last but not least: Do you guys have a glue how JSF2 specific extension for
 conversation handling should be integrated? I supose either adding another
 project (webbeans-jsf2 e.g.) or updating the JSF API (not impl) version to
 2.x and making sure, we are loading JSF2 specific classes only for this ajax
 purpose.

 good night, Sven




-- 
Gurkan Erdogdu
http://gurkanerdogdu.blogspot.com

Re: Removing webbeans-api and atinject-api

2009-12-15 Thread Gurkan Erdogdu

Look at

https://issues.apache.org/jira/browse/GERONIMO-4985?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12789874#action_12789874

2009/12/15 Mark Struberg strub...@yahoo.de

 cool!
 +1

 How does the Release process and patching work?
 Do we have commit rights for e.g. improving the JavaDoc in geronimo-specs?

 How is the release process working? Are we obliged to release those 2
 modules or do we have to send a request to geronimo-dev?

 txs and LieGrue,
 strub

 --- Gurkan Erdogdu cgurkanerdo...@gmail.com schrieb am Di, 15.12.2009:

  Von: Gurkan Erdogdu cgurkanerdo...@gmail.com
  Betreff: Removing webbeans-api and atinject-api
  An: openwebbeans-dev@incubator.apache.org
  Datum: Dienstag, 15. Dezember 2009, 7:59
  Hi folks;
 
  We have pushed those projects into 
  https://svn.apache.org/repos/asf/geronimo/specs/trunk/;
  with
 
  JSR-299 API -- geronimo-cdi_1.0_spec/
  JSR-330 API -- geronimo-atinject_1.0_spec/
 
  And snapshots are located at
  http://repository.apache.org/snapshots/org/apache/geronimo/specs/.
 http://repository.apache.org/snapshots/org/apache/geronimo/specs/
 
  I will remove those projects from our svn if there is no
  objection? After
  that we patch geronimo-spec project for updating
 
  Thanks;
 
  --Gurkan
 

 __
 Do You Yahoo!?
 Sie sind Spam leid? Yahoo! Mail verfügt über einen herausragenden Schutz
 gegen Massenmails.
 http://mail.yahoo.com




-- 
Gurkan Erdogdu
http://gurkanerdogdu.blogspot.com

Re: svn commit: r889852 - in /incubator/openwebbeans/trunk: pom.xml webbeans-ejb/ webbeans-impl/src/main/java/org/apache/webbeans/container/Boot.java webbeans-openejb/

2009-12-15 Thread Gurkan Erdogdu

Hi Eric;

Actually it is not intended to commit. I will remove Boot.java.

Thanks;

--Gurkan





From: Eric Covener cove...@gmail.com
To: openwebbeans-dev@incubator.apache.org
Sent: Tue, December 15, 2009 8:04:21 PM
Subject: Re: svn commit: r889852 - in /incubator/openwebbeans/trunk: pom.xml  
webbeans-ejb/ 
webbeans-impl/src/main/java/org/apache/webbeans/container/Boot.java  
webbeans-openejb/

On Fri, Dec 11, 2009 at 6:11 PM,  gerdo...@apache.org wrote:
 Author: gerdogdu
 Date: Fri Dec 11 23:11:53 2009
 New Revision: 889852

 URL: http://svn.apache.org/viewvc?rev=889852view=rev
 Log:
 Rename webbeans-ejb to openejb

Is the Boot.java change below intended?  Did you mean to add Main.java
in this pkg?

 Modified: 
 incubator/openwebbeans/trunk/webbeans-impl/src/main/java/org/apache/webbeans/container/Boot.java
 URL: 
 http://svn.apache.org/viewvc/incubator/openwebbeans/trunk/webbeans-impl/src/main/java/org/apache/webbeans/container/Boot.java?rev=889852r1=889851r2=889852view=diff
 ==
 --- 
 incubator/openwebbeans/trunk/webbeans-impl/src/main/java/org/apache/webbeans/container/Boot.java
  (original)
 +++ 
 incubator/openwebbeans/trunk/webbeans-impl/src/main/java/org/apache/webbeans/container/Boot.java
  Fri Dec 11 23:11:53 2009
 @@ -21,10 +21,19 @@
  * @version $Rev$ $Date$
  *
  */
 -public class Boot
 +public class Boot implements Main
  {
 /**BeanManager instance unique to deployment*/
 private BeanManager beanManager;

 +/**
 + * {...@inheritdoc}
 + */
 +@Override
 +public void main(String[] args)
 +{
 +
 +}
 +

  }






-- 
Eric Covener
cove...@gmail.com



  ___
Yahoo! Türkiye açıldı!  http://yahoo.com.tr
İnternet üzerindeki en iyi içeriği Yahoo! Türkiye sizlere sunuyor!

Re: what about a -M4 release?

2009-12-14 Thread Gurkan Erdogdu

Hi Mark;

WDYT about the content for M4 release? I think that documentation and web site 
needs more work. If we release M4 , we have to also focus on those 2 subjects.


Besides, would you like to be release guy for M4 :)? 

In the mean time, I will be marrying at next week, all of you are welcome to my 
wedding ceremony :)

Thnks;

--Gurkan




From: Mark Struberg strub...@yahoo.de
To: openwebbeans-dev@incubator.apache.org
Sent: Mon, December 14, 2009 5:57:09 PM
Subject: what about a -M4 release?

Hi!

Wdyt about releaseing a milestone M4 now? 

I think OWB has become pretty stable and since the spec is not moving anymore, 
it would be a good idea to get more users on board right now.

txs and LieGrue,
strub

__
Do You Yahoo!?
Sie sind Spam leid? Yahoo! Mail verfügt über einen herausragenden Schutz gegen 
Massenmails. 
http://mail.yahoo.com



  ___
Yahoo! Türkiye açıldı!  http://yahoo.com.tr
İnternet üzerindeki en iyi içeriği Yahoo! Türkiye sizlere sunuyor!

Re: what about a -M4 release?

2009-12-14 Thread Gurkan Erdogdu

Hey, congratulations and all the best for you and your wife ;)
I fear I cannot make it to the Ankara next week but I hope you will have a 
wonderful marriage!

Thanks a lot!

I will try to be the release guy for M4 - I'm only hoping not to trash 
something ;)
Actually creating a release is easy :). Followings are tasks in order :

* Update trunk/KEYS file. It must include your apache account related with 
public-key uid.
* Write ReadMe file that contains what is new! It must be put under 
trunk/readme folder, such as trunk/readme/README_M4.txt.
* Update trunk/pom.xml for updating maven plugins staged location:

 !-- Puts maven generated artifacts into siteId location--
  properties
   
!-- Staging folder for maven plugins--
siteId/OWB/1.0.0-incubating-M4/plugins/siteId
/properties

* Update local maven settings.xml for password, alt.deployRepository, profile 
etc.

!-- For staging--
server
  idapache.openwebbeans.stage/id
  usernameuser name/username
   !-- If you use password--
  password password/password
  filePermissions664/filePermissions
  directoryPermissions775/directoryPermissions
/server

   !-- For m2  snapshot repository--
   server
  idapache.incubating/id
  usernameuser name/username
   !-- If you use password--
  password password/password
  filePermissions664/filePermissions
  directoryPermissions775/directoryPermissions
/server

   profile
  idrelease/id
  properties
 !--  Passphrase for fingerprints of artifacts--
 gpg.passphraseyour passphrase/gpg.passphrase
  !-- Local staging repo--
 
deploy.altRepositoryapache.openwebbeans.stage::default::scp://people.apache.org/home/your
 user name/public_html/staging-repo/${siteId} /deploy.altRepository
  /properties
/profile

After that, run maven-release-plugin
 mvn release:prepare
 mvn release:perform -Prelease

Release plugin tags source code as 1.0.0-M4

After that checkout tagged branch into your local folder;

 svn co https://svn.apache.org/repos/asf/incubator/openwebbeans/tags/1.0.0-M4 
 1.0.0-M4
 cd 1.0.0-M4
 cd distribution
 update pom.xml for distribution artifacts folder
 properties
   ..
  siteId/OWB/1.0.0-incubating-M4/distribution/siteId
/properties

 Update distribution/src/main/assembly/*.xml
 Update README location
 Update configuration (For example, remove old JPA module, add new samples 
etc.)
 mvn deploy -Prelease;
 This will create binary and source version in 
/OWB/1.0.0-incubating-M4/distribution

* If everything is ok;
  - Send an email to openwebbe...@... for VOTE
  - If VOTE is ok, send an email to gene...@ for VOTE
  - If VOTE is ok, add binary and source to  
www.apache.org/dist/incubator/openwebbeans
  - Post announcement to general@, dev@ and user@ lists

I think that is all !

--Gurkan





From: Mark Struberg strub...@yahoo.de
To: openwebbeans-dev@incubator.apache.org
Sent: Mon, December 14, 2009 10:14:31 PM
Subject: Re: what about a -M4 release?

Hey, congratulations and all the best for you and your wife ;)
I fear I cannot make it to the Ankara next week but I hope you will have a 
wonderful marriage!

As for the release: Sure we should improve docs and the website, but most 
important is that people can finally use OWB without having to build it 
themselfs. You know, M3 is now a bit outdated from the spec point.

I will try to be the release guy for M4 - I'm only hoping not to trash 
something ;)

LieGrue,
strub


--- Gurkan Erdogdu gurkanerdo...@yahoo.com schrieb am Mo, 14.12.2009:

 Von: Gurkan Erdogdu gurkanerdo...@yahoo.com
 Betreff: Re: what about a -M4 release?
 An: openwebbeans-dev@incubator.apache.org
 Datum: Montag, 14. Dezember 2009, 20:40
 Hi Mark;
 
 WDYT about the content for M4 release? I think that
 documentation and web site needs more work. If we release M4
 , we have to also focus on those 2 subjects.
 
 
 Besides, would you like to be release guy for M4 :)? 
 
 In the mean time, I will be marrying at next week, all of
 you are welcome to my wedding ceremony :)
 
 Thnks;
 
 --Gurkan
 
 
 
 
 From: Mark Struberg strub...@yahoo.de
 To: openwebbeans-dev@incubator.apache.org
 Sent: Mon, December 14, 2009 5:57:09 PM
 Subject: what about a -M4 release?
 
 Hi!
 
 Wdyt about releaseing a milestone M4 now? 
 
 I think OWB has become pretty stable and since the spec is
 not moving anymore, it would be a good idea to get more
 users on board right now.
 
 txs and LieGrue,
 strub
 
 __
 Do You Yahoo!?
 Sie sind Spam leid? Yahoo! Mail verfügt über einen
 herausragenden Schutz gegen Massenmails. 
 http://mail.yahoo.com
 
 
 
  
 ___
 Yahoo! Türkiye açıldı!  http://yahoo.com.tr
 İnternet üzerindeki en iyi içeriği

Re: what about a -M4 release?

2009-12-14 Thread Gurkan Erdogdu

congratulations from me too.
Thanks a lot Sven.

--Gurkan





From: Sven Linstaedt sven.linsta...@googlemail.com
To: openwebbeans-dev@incubator.apache.org
Sent: Mon, December 14, 2009 11:34:09 PM
Subject: Re: what about a -M4 release?

Hi Gurkan,

congratulations from me too. I hope you have some days left for vacation
this year ;)

br, Sven



2009/12/14 Gurkan Erdogdu gurkanerdo...@yahoo.com

 Hi Mark;

 WDYT about the content for M4 release? I think that documentation and web
 site needs more work. If we release M4 , we have to also focus on those 2
 subjects.


 Besides, would you like to be release guy for M4 :)?

 In the mean time, I will be marrying at next week, all of you are welcome
 to my wedding ceremony :)

 Thnks;

 --Gurkan



 
 From: Mark Struberg strub...@yahoo.de
 To: openwebbeans-dev@incubator.apache.org
 Sent: Mon, December 14, 2009 5:57:09 PM
 Subject: what about a -M4 release?

 Hi!

 Wdyt about releaseing a milestone M4 now?

 I think OWB has become pretty stable and since the spec is not moving
 anymore, it would be a good idea to get more users on board right now.

 txs and LieGrue,
 strub

 __
 Do You Yahoo!?
 Sie sind Spam leid? Yahoo! Mail verfügt über einen herausragenden Schutz
 gegen Massenmails.
 http://mail.yahoo.com



  ___
 Yahoo! Türkiye açıldı!  http://yahoo.com.tr
 İnternet üzerindeki en iyi içeriği Yahoo! Türkiye sizlere sunuyor!




  ___
Yahoo! Türkiye açıldı!  http://yahoo.com.tr
İnternet üzerindeki en iyi içeriği Yahoo! Türkiye sizlere sunuyor!

Removing webbeans-api and atinject-api

2009-12-14 Thread Gurkan Erdogdu

Hi folks;

We have pushed those projects into 
https://svn.apache.org/repos/asf/geronimo/specs/trunk/; with

JSR-299 API -- geronimo-cdi_1.0_spec/
JSR-330 API -- geronimo-atinject_1.0_spec/

And snapshots are located at
http://repository.apache.org/snapshots/org/apache/geronimo/specs/.http://repository.apache.org/snapshots/org/apache/geronimo/specs/

I will remove those projects from our svn if there is no objection? After
that we patch geronimo-spec project for updating

Thanks;

--Gurkan

Re: webbeans-jpa vs webbeans-resource

2009-12-11 Thread Gurkan Erdogdu

yeap. webbeans-jpa is no more usage!


2009/12/11 Mark Struberg strub...@yahoo.de

 Gurkan!

 It seems you duplicated the jpa part to the resource plugin.
 It seems there are a bunch of cleanup tasks left open.

 I think we can drop the webbeans-jpa, and I will cleanup webbeans-resource
 and webbeans-geronimo accordingly, ok?

 LieGrue,
 strub



 __
 Do You Yahoo!?
 Sie sind Spam leid? Yahoo! Mail verfügt über einen herausragenden Schutz
 gegen Massenmails.
 http://mail.yahoo.com




-- 
Gurkan Erdogdu
http://gurkanerdogdu.blogspot.com

Re: [jira] Resolved: (OWB-188) remove webbeans-jpa and cleanup webbeans-resource

2009-12-11 Thread Gurkan Erdogdu

Awesome thanks! Good idea to throw out trashed code.

We sure that all examples still work :)

--Gurkan

2009/12/11 Mark Struberg (JIRA) j...@apache.org


 [
 https://issues.apache.org/jira/browse/OWB-188?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel]

 Mark Struberg resolved OWB-188.
 ---

Resolution: Fixed

  remove webbeans-jpa and cleanup webbeans-resource
  -
 
  Key: OWB-188
  URL: https://issues.apache.org/jira/browse/OWB-188
  Project: OpenWebBeans
   Issue Type: Improvement
 Affects Versions: M3
 Reporter: Mark Struberg
 Assignee: Mark Struberg
  Fix For: M4
 
 
  Most of the code from webbeans-jpa has been dupped over to
 webbeans-resource. The whole plugin is now essentially obsolete and shall be
 removed.
  We also have to cleanup webbeans-resource and webbeans-geronimo and
 remove unused code.

 --
 This message is automatically generated by JIRA.
 -
 You can reply to this email to add a comment to the issue online.




-- 
Gurkan Erdogdu
http://gurkanerdogdu.blogspot.com

Re: [jira] Resolved: (OWB-188) remove webbeans-jpa and cleanup webbeans-resource

2009-12-11 Thread Gurkan Erdogdu

We will update those projects to integrate with geronimo

https://svn.apache.org/repos/asf/geronimo/server/trunk/plugins/openwebbeans/.https://svn.apache.org/repos/asf/geronimo/server/trunk/plugins/openwebbeans/

This is a very good candidate that needs contribution!

Thanks;

--Gurkan

2009/12/11 Gurkan Erdogdu cgurkanerdo...@gmail.com

Good seperation Mark!

Actually webbeans-geronimo will be leading to some confusion. The main
motivation behind this project was that it will include integration code for
geronimo .But currently it includes OpenEJB code. I think that we have to
separate those things and some refactoring.

My advice is that

1* Change project name of webbeans-ejb -- webbeans-openejb as Mark stated
earlier
2* Move OpenEJB related code from webbeans-geronimo to webbeans-ejb
3* Remove webbeans-geronimo
In reality Geronimo integration code will be implemented in the
Geronimo code base using its plugin architecture. This will use the same
technique for what happened to MyFaces and OpenJPA, OpenEJB etc.
integration.

--Gurkan

2009/12/11 Mark Struberg strub...@yahoo.de

We sure that all examples still work :)
Heh, I hope so, I at least tried out samples/guess and samples/reservation
before checking in ;)

I hope I can sum up the magic behind this (maybe even in the new xdoc)
this weekend.

In general it seems like we have a 3-staged mechanism (even if this is not
so visible from the first glance)

1st layer:
webbeans-core

2nd layer:
the general plugin on a specific specification area (e.g. JMS, JPA, EJB)

3rd layer:
the 2) bound to a specific product or technique: e.g. the JPA
Implementation for SE (provided originally with webbeans-jpa, now moved over
to webbeans-resource) will give you a @PersistenceContext EntityManager with
PersitenceType.EXTENDED whereas if you switch over to the SPI Implementation
from webbeans-geronimo you will get a TRANSACTIONAL PersistenceContext
(which we get from OpenEJB + it's JTA layer).
It's really important to know these differences and to understand the
fundamentally different way those 2 EntityManagers work internally. But I
think David or the other geronimo and OpenEJB folks here can explain this
much better than I can, so I'll focus on the OWB part.

LieGrue,
strub

--- Gurkan Erdogdu cgurkanerdo...@gmail.com schrieb am Fr, 11.12.2009:

Von: Gurkan Erdogdu cgurkanerdo...@gmail.com
Betreff: Re: [jira] Resolved: (OWB-188) remove webbeans-jpa and cleanup
webbeans-resource
An: openwebbeans-dev@incubator.apache.org
Datum: Freitag, 11. Dezember 2009, 10:51
Awesome thanks! Good idea to throw
out trashed code.

We sure that all examples still work :)

--Gurkan

2009/12/11 Mark Struberg (JIRA) j...@apache.org

[

https://issues.apache.org/jira/browse/OWB-188?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Mark Struberg resolved OWB-188.
---

Resolution: Fixed

remove webbeans-jpa and cleanup
webbeans-resource

Key: OWB-188

URL: https://issues.apache.org/jira/browse/OWB-188

Project: OpenWebBeans
Issue Type:
Improvement
Affects Versions: M3

Reporter: Mark Struberg

Assignee: Mark Struberg

Fix For: M4

Most of the code from webbeans-jpa has been
dupped over to
webbeans-resource. The whole plugin is now essentially
obsolete and shall be
removed.
We also have to cleanup webbeans-resource and
webbeans-geronimo and
remove unused code.

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the
issue online.

--
Gurkan Erdogdu
http://gurkanerdogdu.blogspot.com

__
Do You Yahoo!?
Sie sind Spam leid? Yahoo! Mail verfügt über einen herausragenden Schutz
gegen Massenmails.
http://mail.yahoo.com

--
Gurkan Erdogdu
http://gurkanerdogdu.blogspot.com

Re: JSR-330

2009-12-09 Thread Gurkan Erdogdu

Yes, we have discussed it some time ago. We will import JSR330 related API
into the geronimo spec section.

2009/12/9 Matthias Wessendorf mat...@apache.org

 Hi,

 is there a plan to release these bit separately as well ?

 (sorry if I am ignorant and this has already been discussed :-) )

 -Matthias

 --
 Matthias Wessendorf

 blog: http://matthiaswessendorf.wordpress.com/
 sessions: http://www.slideshare.net/mwessendorf
 twitter: http://twitter.com/mwessendorf




-- 
Gurkan Erdogdu
http://gurkanerdogdu.blogspot.com

About JSR-299 and JSR-330 API

2009-12-09 Thread Gurkan Erdogdu

Hi folks;

We would like to port our JSR-299 and JSR-330 related API projects into
Geronimo spec. project. How could we start ?

Thanks;

--Gurkan

Re: [jira] Created: (OWB-185) Managed beans with non-default constructors lead to InstantiationException when creating the proxy

2009-12-09 Thread Gurkan Erdogdu

If a bean is normal scoped, it must satisfy conditions at  5.4.1. Mean that
it has to default constructor.

I think that I was checked this situation in our impl. in
WebBeansUtil#checkUnproxiableApiType.

We have to look where this method is called.

2009/12/9 Joe Bergmark (JIRA) j...@apache.org

 Managed beans with non-default constructors lead to InstantiationException
 when creating the proxy

 --

 Key: OWB-185
 URL: https://issues.apache.org/jira/browse/OWB-185
 Project: OpenWebBeans
  Issue Type: Bug
  Components: Injection and Lookup
Affects Versions: M3
Reporter: Joe Bergmark
Assignee: Gurkan Erdogdu


 While working on OWB-151 I ran into a problem with the way proxies are
 created for beans with non-default injected constructors.  For example, you
 could look at

 org.apache.webbeans.newtests.interceptors.lifecycle.LifecycleBean and give
 it a normal scope:

 @RequestScoped
 @LifecycleBinding
 @Named(org.apache.webbeans.newtests.interceptors.lifecycle.LifecycleBean)
 public class LifecycleBean
 {
public static String CONSTRUCTOR_INJECTED = null;

@Inject
public LifecycleBean(@New String string)
{
CONSTRUCTOR_INJECTED = string;
}


public void touch(){}
 }

 Leads to the following exception (the stack trace is off slightly due to
 some refactoring I have done but the error should be the same):
 org.apache.webbeans.exception.WebBeansException:
 java.lang.InstantiationException:
 org.apache.webbeans.newtests.interceptors.lifecycle.LifecycleBean_$$_javassist_1
at
 org.apache.webbeans.proxy.JavassistProxyFactory.createNewProxyWithHandler(JavassistProxyFactory.java:53)
at
 org.apache.webbeans.proxy.JavassistProxyFactory.createNewProxyInstance(JavassistProxyFactory.java:78)
at
 org.apache.webbeans.container.BeanManagerImpl.getReference(BeanManagerImpl.java:702)
at
 org.apache.webbeans.newtests.interceptors.lifecycle.LifecycleTest.testLifecycle(LifecycleTest.java:57)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
 sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37)
at java.lang.reflect.Method.invoke(Method.java:599)
at
 org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:44)
at
 org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
at
 org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:41)
at
 org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20)
at
 org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28)
at
 org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:31)
at
 org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:73)
at
 org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:46)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:180)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:41)
at org.junit.runners.ParentRunner$1.evaluate(ParentRunner.java:173)
at
 org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28)
at
 org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:31)
at org.junit.runners.ParentRunner.run(ParentRunner.java:220)
at
 org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:45)
at
 org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
at
 org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:460)
at
 org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:673)
at
 org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:386)
at
 org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:196)
 Caused by: java.lang.InstantiationException:
 org.apache.webbeans.newtests.interceptors.lifecycle.LifecycleBean_$$_javassist_1
at java.lang.J9VMInternals.newInstanceImpl(Native Method)
at java.lang.Class.newInstance(Class.java:1325)
at
 org.apache.webbeans.proxy.JavassistProxyFactory.createNewProxyWithHandler(JavassistProxyFactory.java:48)
... 27 more



 --
 This message is automatically generated by JIRA.
 -
 You can reply to this email to add a comment to the issue online.




-- 
Gurkan Erdogdu
http://gurkanerdogdu.blogspot.com

[RESULT]Re: [VOTE] Graduation as TLP

2009-12-07 Thread Gurkan Erdogdu

Hi;

The VOTE is closed after more than 72 hours. VOTE is passed with six +1 no 0 or 
-1 from PPMC

+1 Votes from PPMC
---
Gurkan Erdogdu
Kevan Miller
Matthias Wessendorf
Mark Struberg
Eric Covener
Joseph Bergmark

Thanks to everyone;

--Gurkan






From: Gurkan Erdogdu gurkanerdo...@yahoo.com
To: openwebbeans-dev@incubator.apache.org
Sent: Tue, December 1, 2009 9:13:16 PM
Subject: [VOTE] Graduation as TLP

Hi;

I would like to start a VOTE for graduating OWB as TLP.

Please cast your VOTEs here. VOTE is open for 72 hours.

[-1] Do not graduate as TLP
[0 ] Do not care TLP or not
[+1] Graduate as TLP

Here's my +1.

Incubator Status Page
---
http://incubator.apache.org/projects/openwebbeans.html (I have updated 
checklists, it will appear in a couple of hours)

Board Resolution Report
---

WHEREAS, the Board of Directors deems it to be in the best interests of the
Foundation and consistent with the Foundation's purpose to establish a Project,
to be known as Apache OpenWebBeans, related to the implementation of the
JSR-299,i.e Contexts and Dependency Injection for the Java EE platform, for
distribution at no charge to the public.

NOW, THEREFORE, BE IT RESOLVED, that a Project Management Committee (PMC) is
hereby established pursuant to Bylaws of the Foundation; and be it further

RESOLVED, that the Apache OpenWebBeans Project be and hereby is
responsible for the creation and maintenance of a software
project related to JSR299, Context and Dependency Injection for the
Java EE Platform; and be it further

RESOLVED, that the Apache OpenWebBeans PMC be and hereby is charged with the
creation and maintenance of Apache OpenWebBeans; and be it further

RESOLVED, that the office of Vice President, Apache OpenWebBeans be and hereby
is created, the person holding such office to serve at the direction of the
Board of Directors as the chair of Apache OpenWebBeans, and to have primary
responsibility for management of the projects within the scope of responsibility
of the Apache OpenWebBeans PMC; and be it further

RESOLVED, that the persons listed immediately below be and hereby are appointed
to serve as the initial members of the Apache OpenWebBeans PMC:

* Gurkan Erdogdu (gurkanerdogdu at yahoo dot com)
* Kevan Miller  (kevan dot miller at gmail dot com)
* Mark Struberg  (struberg at yahoo dot com)
* Joe Bergmark  (bergmark at gmail dot com)
* Eric Covener (covener at gmail dot com)
* David Blevins (david dot blevins at visi dot com)

NOW, THEREFORE, BE IT FURTHER RESOLVED, that Gurkan Erdogdu be appointed to the
office of Vice President, Apache OpenWebBeans, to serve in accordance with and
subject to the direction of the Board of Directors and the Bylaws of the
Foundation until death, resignation, retirement, removal or disqualification, or
until a successor is appointed; and be it further

RESOLVED, that Apache OpenWebBeans be and hereby is tasked with the migration
and rationalization of the Apache Incubator OpenWebBeans podling; and be it
further

RESOLVED, that all responsibilities pertaining to the Apache Incubator
OpenWebBeans podling encumbered upon the Apache Incubator PMC are hereafter
discharged.



  ___
Yahoo! Türkiye açıldı!  http://yahoo.com.tr
İnternet üzerindeki en iyi içeriği Yahoo! Türkiye sizlere sunuyor!

Re: JSF2 scope annotation mapping extension

2009-12-02 Thread Gurkan Erdogdu

Hi Sven;

because Mark mentioned this one before and I already have an implentation...
 The basic idea to deal with (at least some of) the JSF2 scope annotations is
 to map some of them to the existing scopes in CDI. The delegation of context
 retrieval was necessary, because the contexts are not active during
 application startup time, so direct retrieval of them from the BeanManager
 had resulted in an exception. JSF specific scopes like flash- or viewscope
 are still todo.

You could help us to implement this extension. JSF related codes go into the
webbeans-jsf module.

And just because I had read about this in the weld list: Are there any
 existing plans how to deal with (portable / nonportable) CDI extension in
 the OWB project?

We also would like to create extensions for OWB.

2009/12/3 Sven Linstaedt sven.linsta...@googlemail.com

 Hi,

 because Mark mentioned this one before and I already have an
 implentation... The basic idea to deal with (at least some of) the JSF2
 scope annotations is to map some of them to the existing scopes in CDI. The
 delegation of context retrieval was necessary, because the contexts are not
 active during application startup time, so direct retrieval of them from the
 BeanManager had resulted in an exception. JSF specific scopes like flash- or
 viewscope are still todo.

 And just because I had read about this in the weld list: Are there any
 existing plans how to deal with (portable / nonportable) CDI extension in
 the OWB project?

 br, Sven




-- 
Gurkan Erdogdu
http://gurkanerdogdu.blogspot.com

Re: tons of skipped TCK tests

2009-12-01 Thread Gurkan Erdogdu

EJB is enabled via openwebbeans.properties,  and it is false as default. In
standalone mode, it must be false

#use embedded openejb metadata discovery
org.apache.webbeans.spi.deployer.UseEjbMetaDataDiscoveryService=false


2009/12/1 Mark Struberg strub...@yahoo.de

  ad 1) I moved the
  OpenEJB.init() to StandaloneContainersImpl#setup() so this
  initialisation will only be performed if
  It is not necessary to call OpenEJB.init in standalone
  mode. We do not provide EJB functionality in standalone
  mode. It works only in container mode.

 The effect I had: IF the webbeans-ejb module is on the classpath, the
 EjbPlugin gets picked up and tries to ask the EJB Container for information.
 Since we don't change the dependencies (or currently: the unpacking) if we
 run as StandaloneContainers, it's the same as running in tomcat. And
 therefore OpenEJB must be started up even in this mode.

 LieGrue,
 strub


 --- Gurkan Erdogdu gurkanerdo...@yahoo.com schrieb am Di, 1.12.2009:

  Von: Gurkan Erdogdu gurkanerdo...@yahoo.com
  Betreff: Re: tons of skipped TCK tests
  An: openwebbeans-dev@incubator.apache.org
  Datum: Dienstag, 1. Dezember 2009, 6:18
  ad 1) I moved the
  OpenEJB.init() to StandaloneContainersImpl#setup() so this
  initialisation will only be performed if
  It is not necessary to call OpenEJB.init in standalone
  mode. We do not provide EJB functionality in standalone
  mode. It works only in container mode.
 
 
  ad 2)Still it is not really clear to me how the
  TCK suite works on your computer.
  Will look at again.
 
  For the unpacking vs dependency: the only thing
  which matters is if the jars are on the classpath
  Ok, then,  current way for doing that is fine.
 
 
 
  
  From: Mark Struberg strub...@yahoo.de
  To: openwebbeans-dev@incubator.apache.org
  Sent: Tue, December 1, 2009 12:13:57 AM
  Subject: Re: tons of skipped TCK tests
 
  Thanks Gurkan!
 
  It's still not really clear to me, so maybe I should try to
  sum it up again:
 
  ad 1) I moved the OpenEJB.init() to
  StandaloneContainersImpl#setup() so this initialisation will
  only be performed if we dont test against tomcat. It simply
  doesn't work here after a clean checkout. Do you have
  JBossAS in your classpath? Maybe I oversee something...
 
  ad 2)
  Still it is not really clear to me how the TCK suite works
  on your computer. With a standard tomcat-6.0.18 I
  experienced exactly the same DeploymentException (and thus
  skipped tests) as when running in a standalone mode. The few
  Exceptions I fixed yesterday (package scope constructor)
  have nothing to do with EJB at all. And they aborted almost
  all the TCK tests.
  Can you please try to clean your .m2/repository? Maybe we
  face some artifact clash?
 
  For the unpacking vs dependency: the only thing which
  matters is if the jars are on the classpath. This is the
  case in both ways. The only subtle difference is if we would
  like to apply some kind of byte code enhancement (which we
  don't do).
 
 
  LieGrue,
  strub
 
  --- Gurkan Erdogdu gurkanerdo...@yahoo.com
  schrieb am Mo, 30.11.2009:
 
   Von: Gurkan Erdogdu gurkanerdo...@yahoo.com
   Betreff: Re: tons of skipped TCK tests
   An: openwebbeans-dev@incubator.apache.org
   Datum: Montag, 30. November 2009, 18:22
   For question 1 :
   OpenEJB is used with Apache Tomcat as an embeddable.
  It is
   not enabled as default. If you deploy WAR archive
  that
   contains EJB classes, EJBs are deployed by the
  OpenEJB
   before contextInitialized() is called.  We
  configure
   OWB in contextInitialized so we can get that which
  class
   is EJB or not. There is no start-up logic beyon this.
  
   For question 2 :
   We must run TCK in embeddable OpenEJB in Tomcat. So
   dependency:copy adds all necessary jar into each test
  WAR
   archive lib folder. I do not see any skipped test in
  my
   environment. Maybe your Tomcat configuration is wrong.
 
  
   --Gurkan
  
  
  
  
   
   From: Mark Struberg strub...@yahoo.de
   To: openwebbeans-dev@incubator.apache.org
   Sent: Sat, November 28, 2009 11:27:02 AM
   Subject: tons of skipped TCK tests
  
   Hi!
  
   I'm playing around with the TCK suite for a few days
  and
   almost all tests got skipped. I tried this with tomcat
  and
   also as standalone, and both give similar results.
  
   Let's stick with the standalone container for now:
  
   1.) The webbeans-ejb plugin (which we should rename
  to
   webbeans-openejb imho, because it uses a lot internal
   OpenEJB functionality) doesn't get startet up
  correctly. I
   fixed that part in the PluginLoader and added a starup
  logic
   to the EJBPlugin. I'm not sure about this part since
  OpenEJB
   should already be started up, isn't? In the TCK it
  isn't so
   I got a NullPointerException because
  
  SystemInstance.get().getComponent(ContainerSystem.class);
   returned null.
  
   We should sum up in which scenarios OpenEJB gets
  started

Re: Documentation: first draft

2009-12-01 Thread Gurkan Erdogdu

Hi Jean-Louis;

Do you forget to attach first draft ?

Thanks;

--Gurkan

2009/12/1 Monteiro Jean-Louis jean-louis.monte...@atosorigin.com

  Hi all,



 I’ve been working on the documentation.

 I refactored a lot of things to make all more sexy and professional.



 Before submitting a patch, I’d like to have your opinion.

 I’m ready to change whatever you want.



 Any feedback is welcome.



 * *

 *Jean-Louis*

 --

 Ce message et les pièces jointes sont confidentiels et réservés à l'usage
 exclusif de ses destinataires. Il peut également être protégé par le secret
 professionnel. Si vous recevez ce message par erreur, merci d'en avertir
 immédiatement l'expéditeur et de le détruire. L'intégrité du message ne
 pouvant être assurée sur Internet, la responsabilité du groupe Atos Origin
 ne pourra être recherchée quant au contenu de ce message. Bien que les
 meilleurs efforts soient faits pour maintenir cette transmission exempte de
 tout virus, l'expéditeur ne donne aucune garantie à cet égard et sa
 responsabilité ne saurait être recherchée pour tout dommage résultant d'un
 virus transmis.

 This e-mail and the documents attached are confidential and intended solely
 for the addressee; it may also be privileged. If you receive this e-mail in
 error, please notify the sender immediately and destroy it. As its integrity
 cannot be secured on the Internet, the Atos Origin group liability cannot be
 triggered for the message content. Although the sender endeavours to
 maintain a computer virus-free network, the sender does not warrant that
 this transmission is virus-free and will not be liable for any damages
 resulting from any virus transmitted.




-- 
Gurkan Erdogdu
http://gurkanerdogdu.blogspot.com

Re: Documentation: first draft

2009-12-01 Thread Gurkan Erdogdu

Better is to create a JIRA issue and attach artifacts to it.

You could create a issue here : http://issues.apache.org/jira/browse/OWB

Thanks;

--Gurkan

2009/12/1 Jean-Louis MONTEIRO jeano...@gmail.com

 Sorry for the spam
 it should work better with my gmail.

 Jean-Louis

 2009/12/1 Monteiro Jean-Louis jean-louis.monte...@atosorigin.com





 *De :* Monteiro Jean-Louis
 *Envoyé :* mardi 1 décembre 2009 10:28

 *À :* openwebbeans-dev@incubator.apache.org
 *Objet :* Documentation: first draft



 Hi all,



 I’ve been working on the documentation.

 I refactored a lot of things to make all more sexy and professional.



 Before submitting a patch, I’d like to have your opinion.

 I’m ready to change whatever you want.



 Any feedback is welcome.



 * *

 *Jean-Louis*

 --

 Ce message et les pièces jointes sont confidentiels et réservés à l'usage
 exclusif de ses destinataires. Il peut également être protégé par le secret
 professionnel. Si vous recevez ce message par erreur, merci d'en avertir
 immédiatement l'expéditeur et de le détruire. L'intégrité du message ne
 pouvant être assurée sur Internet, la responsabilité du groupe Atos Origin
 ne pourra être recherchée quant au contenu de ce message. Bien que les
 meilleurs efforts soient faits pour maintenir cette transmission exempte de
 tout virus, l'expéditeur ne donne aucune garantie à cet égard et sa
 responsabilité ne saurait être recherchée pour tout dommage résultant d'un
 virus transmis.

 This e-mail and the documents attached are confidential and intended
 solely for the addressee; it may also be privileged. If you receive this
 e-mail in error, please notify the sender immediately and destroy it. As its
 integrity cannot be secured on the Internet, the Atos Origin group liability
 cannot be triggered for the message content. Although the sender endeavours
 to maintain a computer virus-free network, the sender does not warrant that
 this transmission is virus-free and will not be liable for any damages
 resulting from any virus transmitted.






-- 
Gurkan Erdogdu
http://gurkanerdogdu.blogspot.com

Re: Documentation: first draft

2009-12-01 Thread Gurkan Erdogdu

Pretty cool. You are not able to assign it yourself because of not being
committer currently.

I think that we agree on the current format/template.

Could you also add other patch/diff files ? Therefore, I can commit those
into the webbeans-doc project.

--Gurkan

2009/12/1 Jean-Louis MONTEIRO jeano...@gmail.com

 Done https://issues.apache.org/jira/browse/OWB-183
 Gurkan, I was not able to assign it to me, so feel free to do it if you
 want.

 Jean-Louis


 2009/12/1 Gurkan Erdogdu cgurkanerdo...@gmail.com

  Better is to create a JIRA issue and attach artifacts to it.
 
  You could create a issue here : http://issues.apache.org/jira/browse/OWB
 
  Thanks;
 
  --Gurkan
 
  2009/12/1 Jean-Louis MONTEIRO jeano...@gmail.com
 
   Sorry for the spam
   it should work better with my gmail.
  
   Jean-Louis
  
   2009/12/1 Monteiro Jean-Louis jean-louis.monte...@atosorigin.com
  
  
  
  
  
   *De :* Monteiro Jean-Louis
   *Envoyé :* mardi 1 décembre 2009 10:28
  
   *À :* openwebbeans-dev@incubator.apache.org
   *Objet :* Documentation: first draft
  
  
  
   Hi all,
  
  
  
   I’ve been working on the documentation.
  
   I refactored a lot of things to make all more sexy and professional.
  
  
  
   Before submitting a patch, I’d like to have your opinion.
  
   I’m ready to change whatever you want.
  
  
  
   Any feedback is welcome.
  
  
  
   * *
  
   *Jean-Louis*
  
   --
  
   Ce message et les pièces jointes sont confidentiels et réservés à
  l'usage
   exclusif de ses destinataires. Il peut également être protégé par le
  secret
   professionnel. Si vous recevez ce message par erreur, merci d'en
 avertir
   immédiatement l'expéditeur et de le détruire. L'intégrité du message
 ne
   pouvant être assurée sur Internet, la responsabilité du groupe Atos
  Origin
   ne pourra être recherchée quant au contenu de ce message. Bien que les
   meilleurs efforts soient faits pour maintenir cette transmission
 exempte
  de
   tout virus, l'expéditeur ne donne aucune garantie à cet égard et sa
   responsabilité ne saurait être recherchée pour tout dommage résultant
  d'un
   virus transmis.
  
   This e-mail and the documents attached are confidential and intended
   solely for the addressee; it may also be privileged. If you receive
 this
   e-mail in error, please notify the sender immediately and destroy it.
 As
  its
   integrity cannot be secured on the Internet, the Atos Origin group
  liability
   cannot be triggered for the message content. Although the sender
  endeavours
   to maintain a computer virus-free network, the sender does not warrant
  that
   this transmission is virus-free and will not be liable for any damages
   resulting from any virus transmitted.
  
  
  
  
 
 
  --
  Gurkan Erdogdu
  http://gurkanerdogdu.blogspot.com
 




-- 
Gurkan Erdogdu
http://gurkanerdogdu.blogspot.com

Re: Documentation: first draft

2009-12-01 Thread Gurkan Erdogdu

I gonna add Apache headers to my XSL files and clean the whole.
I guess i'll can submit a patch file by the end of this week.
Cool, thanks.

Do we also need to generate HTML (single and multi/chunk)?
Yes, so we can attach HTMLs(single is enough I think) to our website.

2009/12/1 Jean-Louis MONTEIRO jeano...@gmail.com

 OK, no problem.
 I gonna add Apache headers to my XSL files and clean the whole.
 I guess i'll can submit a patch file by the end of this week.

 Do we also need to generate HTML (single and multi/chunk)?

 Jean-Louis




 2009/12/1 Gurkan Erdogdu cgurkanerdo...@gmail.com

  Pretty cool. You are not able to assign it yourself because of not being
  committer currently.
 
  I think that we agree on the current format/template.
 
  Could you also add other patch/diff files ? Therefore, I can commit those
  into the webbeans-doc project.
 
  --Gurkan
 
  2009/12/1 Jean-Louis MONTEIRO jeano...@gmail.com
 
   Done https://issues.apache.org/jira/browse/OWB-183
   Gurkan, I was not able to assign it to me, so feel free to do it if you
   want.
  
   Jean-Louis
  
  
   2009/12/1 Gurkan Erdogdu cgurkanerdo...@gmail.com
  
Better is to create a JIRA issue and attach artifacts to it.
   
You could create a issue here :
  http://issues.apache.org/jira/browse/OWB
   
Thanks;
   
--Gurkan
   
2009/12/1 Jean-Louis MONTEIRO jeano...@gmail.com
   
 Sorry for the spam
 it should work better with my gmail.

 Jean-Louis

 2009/12/1 Monteiro Jean-Louis jean-louis.monte...@atosorigin.com





 *De :* Monteiro Jean-Louis
 *Envoyé :* mardi 1 décembre 2009 10:28

 *À :* openwebbeans-dev@incubator.apache.org
 *Objet :* Documentation: first draft



 Hi all,



 I’ve been working on the documentation.

 I refactored a lot of things to make all more sexy and
 professional.



 Before submitting a patch, I’d like to have your opinion.

 I’m ready to change whatever you want.



 Any feedback is welcome.



 * *

 *Jean-Louis*

 --

 Ce message et les pièces jointes sont confidentiels et réservés à
l'usage
 exclusif de ses destinataires. Il peut également être protégé par
 le
secret
 professionnel. Si vous recevez ce message par erreur, merci d'en
   avertir
 immédiatement l'expéditeur et de le détruire. L'intégrité du
 message
   ne
 pouvant être assurée sur Internet, la responsabilité du groupe
 Atos
Origin
 ne pourra être recherchée quant au contenu de ce message. Bien que
  les
 meilleurs efforts soient faits pour maintenir cette transmission
   exempte
de
 tout virus, l'expéditeur ne donne aucune garantie à cet égard et
 sa
 responsabilité ne saurait être recherchée pour tout dommage
  résultant
d'un
 virus transmis.

 This e-mail and the documents attached are confidential and
 intended
 solely for the addressee; it may also be privileged. If you
 receive
   this
 e-mail in error, please notify the sender immediately and destroy
  it.
   As
its
 integrity cannot be secured on the Internet, the Atos Origin group
liability
 cannot be triggered for the message content. Although the sender
endeavours
 to maintain a computer virus-free network, the sender does not
  warrant
that
 this transmission is virus-free and will not be liable for any
  damages
 resulting from any virus transmitted.




   
   
--
Gurkan Erdogdu
http://gurkanerdogdu.blogspot.com
   
  
 
 
 
  --
  Gurkan Erdogdu
  http://gurkanerdogdu.blogspot.com
 




-- 
Gurkan Erdogdu
http://gurkanerdogdu.blogspot.com

[VOTE] Graduation as TLP

2009-12-01 Thread Gurkan Erdogdu

Hi;

I would like to start a VOTE for graduating OWB as TLP.

Please cast your VOTEs here. VOTE is open for 72 hours.
 
 [-1] Do not graduate as TLP
 [0 ] Do not care TLP or not
 [+1] Graduate as TLP
 
Here's my +1.

Incubator Status Page
---
http://incubator.apache.org/projects/openwebbeans.html (I have updated 
checklists, it will appear in a couple of hours)

Board Resolution Report
---

WHEREAS, the Board of Directors deems it to be in the best interests of the
Foundation and consistent with the Foundation's purpose to establish a Project,
to be known as Apache OpenWebBeans, related to the implementation of the
JSR-299,i.e Contexts and Dependency Injection for the Java EE platform, for
distribution at no charge to the public.

NOW, THEREFORE, BE IT RESOLVED, that a Project Management Committee (PMC) is
hereby established pursuant to Bylaws of the Foundation; and be it further

RESOLVED, that the Apache OpenWebBeans Project be and hereby is
responsible for the creation and maintenance of a software
project related to JSR299, Context and Dependency Injection for the
Java EE Platform; and be it further

RESOLVED, that the Apache OpenWebBeans PMC be and hereby is charged with the
creation and maintenance of Apache OpenWebBeans; and be it further

RESOLVED, that the office of Vice President, Apache OpenWebBeans be and hereby
is created, the person holding such office to serve at the direction of the
Board of Directors as the chair of Apache OpenWebBeans, and to have primary
responsibility for management of the projects within the scope of responsibility
of the Apache OpenWebBeans PMC; and be it further

RESOLVED, that the persons listed immediately below be and hereby are appointed
to serve as the initial members of the Apache OpenWebBeans PMC:

* Gurkan Erdogdu (gurkanerdogdu at yahoo dot com)
* Kevan Miller  (kevan dot miller at gmail dot com)
* Mark Struberg  (struberg at yahoo dot com)
* Joe Bergmark  (bergmark at gmail dot com)
* Eric Covener (covener at gmail dot com)
* David Blevins (david dot blevins at visi dot com)

NOW, THEREFORE, BE IT FURTHER RESOLVED, that Gurkan Erdogdu be appointed to the
office of Vice President, Apache OpenWebBeans, to serve in accordance with and
subject to the direction of the Board of Directors and the Bylaws of the
Foundation until death, resignation, retirement, removal or disqualification, or
until a successor is appointed; and be it further

RESOLVED, that Apache OpenWebBeans be and hereby is tasked with the migration
and rationalization of the Apache Incubator OpenWebBeans podling; and be it
further

RESOLVED, that all responsibilities pertaining to the Apache Incubator
OpenWebBeans podling encumbered upon the Apache Incubator PMC are hereafter
discharged.

Re: tons of skipped TCK tests

2009-11-30 Thread Gurkan Erdogdu

For question 1 :
OpenEJB is used with Apache Tomcat as an embeddable. It is not enabled as 
default. If you deploy WAR archive that contains EJB classes, EJBs are deployed 
by the OpenEJB before contextInitialized() is called.  We configure OWB in 
contextInitialized so we can get that which class is EJB or not. There is no 
start-up logic beyon this.

For question 2 :
We must run TCK in embeddable OpenEJB in Tomcat. So dependency:copy adds all 
necessary jar into each test WAR archive lib folder. I do not see any skipped 
test in my environment. Maybe your Tomcat configuration is wrong. 

--Gurkan





From: Mark Struberg strub...@yahoo.de
To: openwebbeans-dev@incubator.apache.org
Sent: Sat, November 28, 2009 11:27:02 AM
Subject: tons of skipped TCK tests

Hi!

I'm playing around with the TCK suite for a few days and almost all tests got 
skipped. I tried this with tomcat and also as standalone, and both give similar 
results.

Let's stick with the standalone container for now:

1.) The webbeans-ejb plugin (which we should rename to webbeans-openejb imho, 
because it uses a lot internal OpenEJB functionality) doesn't get startet up 
correctly. I fixed that part in the PluginLoader and added a starup logic to 
the EJBPlugin. I'm not sure about this part since OpenEJB should already be 
started up, isn't? In the TCK it isn't so I got a NullPointerException because 
SystemInstance.get().getComponent(ContainerSystem.class);
returned null.

We should sum up in which scenarios OpenEJB gets started up at which point in 
time/bootstrapped from which component.

2.) I'm not sure why all the dependencies got copied over with dependency:copy 
instead of simply setting the test dependencies? Imho the only thing we have to 
dependency:copy are those parts which are accessed via a file path instead of 
getting it via the classloader (afaik only the testng-suite.xml)

Oki, that should be it for now ;)

I'll continue to figure out why most of the TCK tests get skipped.

LieGrue,
strub

__
Do You Yahoo!?
Sie sind Spam leid? Yahoo! Mail verfügt über einen herausragenden Schutz gegen 
Massenmails. 
http://mail.yahoo.com

Re: [jira] Created: (OWB-182) Even if @PreDestroy is used in an Interceptor, it doesn't need an InvoicationContext parameter

2009-11-30 Thread Gurkan Erdogdu

If you look at Interceptors specification, you can see that if you have 
@PreDestroy in interceptor class, it must take InvocationContext as a 
parameter. I think that our old impl. was correct. Seems that TCK tests are 
wrong!


--Gurkan




From: Mark Struberg (JIRA) j...@apache.org
To: openwebbeans-dev@incubator.apache.org
Sent: Mon, November 30, 2009 1:33:20 AM
Subject: [jira] Created: (OWB-182) Even if @PreDestroy is used in an 
Interceptor, it doesn't need an InvoicationContext parameter

Even if @PreDestroy is used in an Interceptor, it doesn't need an 
InvoicationContext parameter
--

 Key: OWB-182
 URL: https://issues.apache.org/jira/browse/OWB-182
 Project: OpenWebBeans
  Issue Type: Bug
Affects Versions: M3
Reporter: Mark Struberg
Assignee: Mark Struberg
 Fix For: M4


thus we must disable the check in WebBeansUtils#configureInterceptorMethods

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: tons of skipped TCK tests

2009-11-30 Thread Gurkan Erdogdu

ad 1) I moved the OpenEJB.init() to StandaloneContainersImpl#setup() so this 
initialisation will only be performed if
It is not necessary to call OpenEJB.init in standalone mode. We do not provide 
EJB functionality in standalone mode. It works only in container mode.


ad 2)Still it is not really clear to me how the TCK suite works on your 
computer.
Will look at again.

For the unpacking vs dependency: the only thing which matters is if the jars 
are on the classpath
Ok, then,  current way for doing that is fine.




From: Mark Struberg strub...@yahoo.de
To: openwebbeans-dev@incubator.apache.org
Sent: Tue, December 1, 2009 12:13:57 AM
Subject: Re: tons of skipped TCK tests

Thanks Gurkan!

It's still not really clear to me, so maybe I should try to sum it up again:

ad 1) I moved the OpenEJB.init() to StandaloneContainersImpl#setup() so this 
initialisation will only be performed if we dont test against tomcat. It simply 
doesn't work here after a clean checkout. Do you have JBossAS in your 
classpath? Maybe I oversee something...

ad 2)
Still it is not really clear to me how the TCK suite works on your computer. 
With a standard tomcat-6.0.18 I experienced exactly the same 
DeploymentException (and thus skipped tests) as when running in a standalone 
mode. The few Exceptions I fixed yesterday (package scope constructor) have 
nothing to do with EJB at all. And they aborted almost all the TCK tests.
Can you please try to clean your .m2/repository? Maybe we face some artifact 
clash?

For the unpacking vs dependency: the only thing which matters is if the jars 
are on the classpath. This is the case in both ways. The only subtle difference 
is if we would like to apply some kind of byte code enhancement (which we don't 
do).


LieGrue,
strub

--- Gurkan Erdogdu gurkanerdo...@yahoo.com schrieb am Mo, 30.11.2009:

 Von: Gurkan Erdogdu gurkanerdo...@yahoo.com
 Betreff: Re: tons of skipped TCK tests
 An: openwebbeans-dev@incubator.apache.org
 Datum: Montag, 30. November 2009, 18:22
 For question 1 :
 OpenEJB is used with Apache Tomcat as an embeddable. It is
 not enabled as default. If you deploy WAR archive that
 contains EJB classes, EJBs are deployed by the OpenEJB
 before contextInitialized() is called.  We configure
 OWB in contextInitialized so we can get that which class
 is EJB or not. There is no start-up logic beyon this.
 
 For question 2 :
 We must run TCK in embeddable OpenEJB in Tomcat. So
 dependency:copy adds all necessary jar into each test WAR
 archive lib folder. I do not see any skipped test in my
 environment. Maybe your Tomcat configuration is wrong. 
 
 --Gurkan
 
 
 
 
 
 From: Mark Struberg strub...@yahoo.de
 To: openwebbeans-dev@incubator.apache.org
 Sent: Sat, November 28, 2009 11:27:02 AM
 Subject: tons of skipped TCK tests
 
 Hi!
 
 I'm playing around with the TCK suite for a few days and
 almost all tests got skipped. I tried this with tomcat and
 also as standalone, and both give similar results.
 
 Let's stick with the standalone container for now:
 
 1.) The webbeans-ejb plugin (which we should rename to
 webbeans-openejb imho, because it uses a lot internal
 OpenEJB functionality) doesn't get startet up correctly. I
 fixed that part in the PluginLoader and added a starup logic
 to the EJBPlugin. I'm not sure about this part since OpenEJB
 should already be started up, isn't? In the TCK it isn't so
 I got a NullPointerException because 
 SystemInstance.get().getComponent(ContainerSystem.class);
 returned null.
 
 We should sum up in which scenarios OpenEJB gets started up
 at which point in time/bootstrapped from which component.
 
 2.) I'm not sure why all the dependencies got copied over
 with dependency:copy instead of simply setting the test
 dependencies? Imho the only thing we have to dependency:copy
 are those parts which are accessed via a file path instead
 of getting it via the classloader (afaik only the
 testng-suite.xml)
 
 Oki, that should be it for now ;)
 
 I'll continue to figure out why most of the TCK tests get
 skipped.
 
 LieGrue,
 strub
 
 __
 Do You Yahoo!?
 Sie sind Spam leid? Yahoo! Mail verfügt über einen
 herausragenden Schutz gegen Massenmails. 
 http://mail.yahoo.com
 
 
 
   

__
Do You Yahoo!?
Sie sind Spam leid? Yahoo! Mail verfügt über einen herausragenden Schutz gegen 
Massenmails. 
http://mail.yahoo.com

Re: Documentation

2009-11-25 Thread Gurkan Erdogdu

Awesome!

Thanks a lot;

--Gurkan

2009/11/25 Monteiro Jean-Louis jean-louis.monte...@atosorigin.com

 Hi,

 i worked a bit on the documentation yesturday.
 I guess i gonna have a draft version by the end of the day.

 If anybody have some content to add, feel free to send it here.

 Jean-Louis


 Ce message et les pi?ces jointes sont confidentiels et r?serv?s ? l'usage
 exclusif de ses destinataires. Il peut ?galement ?tre prot?g? par le secret
 professionnel. Si vous recevez ce message par erreur, merci d'en avertir
 imm?diatement l'exp?diteur et de le d?truire. L'int?grit? du message ne
 pouvant ?tre assur?e sur Internet, la responsabilit? du groupe Atos Origin
 ne pourra ?tre recherch?e quant au contenu de ce message. Bien que les
 meilleurs efforts soient faits pour maintenir cette transmission exempte de
 tout virus, l'exp?diteur ne donne aucune garantie ? cet ?gard et sa
 responsabilit? ne saurait ?tre recherch?e pour tout dommage r?sultant d'un
 virus transmis.

 This e-mail and the documents attached are confidential and intended solely
 for the addressee; it may also be privileged. If you receive this e-mail in
 error, please notify the sender immediately and destroy it. As its integrity
 cannot be secured on the Internet, the Atos Origin group liability cannot be
 triggered for the message content. Although the sender endeavours to
 maintain a computer virus-free network, the sender does not warrant that
 this transmission is virus-free and will not be liable for any damages
 resulting from any virus transmitted.




-- 
Gurkan Erdogdu
http://gurkanerdogdu.blogspot.com

Re: [DISCUSSION] Draft Resolution Document

2009-11-24 Thread Gurkan Erdogdu

Hi Chris;

We are happy to work with more committers in the project :)  You can look at 
our current issues in https://issues.apache.org/jira/browse/OWB, and select one 
that you would like to work on. After that, you can attach your patch. If 
anything you want to ask, just drop mail here for discussion.

We discuss all development related activities here! Also you can join us on 
iirc#freenode  within channel #openwebbeans

Thanks;


--Gurkan




From: Chris Shayan hamedsha...@gmail.com
To: openwebbeans-dev@incubator.apache.org
Sent: Tue, November 24, 2009 11:16:44 PM
Subject: Re: [DISCUSSION] Draft Resolution Document

Dear all,
I'd like to join to this project, according to my abilities would you mind
to guide me what can I do?
-- 
Sincerely Yours,
Chris Shayan
Life creates questions. Together our world can write the answers.
-- Josh
www.ChrisShayan.com

Re: Review of WebBeansPhaseListener

2009-11-23 Thread Gurkan Erdogdu

I think that JSP and Tag Handlers are old tech. Java EE may remove those
parts from the specification in the next revision of the spec. Pure JSF is
always be in favor.

2009/11/23 Mark Struberg strub...@yahoo.de

 Imho it should.

 And it must also work for AJAX requests and partial submits.

 LieGrue,
 strub

 --- Gurkan Erdogdu cgurkanerdo...@gmail.com schrieb am Mo, 23.11.2009:

  Von: Gurkan Erdogdu cgurkanerdo...@gmail.com
  Betreff: Re: Review of WebBeansPhaseListener
  An: openwebbeans-dev@incubator.apache.org
  Datum: Montag, 23. November 2009, 8:04
  Hi Sven;
 
  AFAIK, conversation is defined for using it in pure JSF in
  the
  specification. I do not know whether it supports tag
  handlers or not.
 
  --Gurkan
 
  2009/11/23 Sven Linstaedt sven.linsta...@googlemail.com
 
   I have found a issue, that makes the second point
  necessary to implement:
  
   If one uses a conversation scoped bean in an
  expression, which is evaluated
   during restore view as part of a tag handler (e.g. in
  c:forEach), we need
   the conversation already to be restored, because
  otherwise two
   conversations
   will be in action during one request: one from the
  beginning the request
   till after restore view phase, and another one (the
  right one actually)
   in
   the other phases.
  
   Because before restore view no view and therefore no
  cid is available
   (well,
   sound reasonable ;) our only chance is to retrieve the
  cid from something
   else. The current implementation attaches the cid to
  every form's action
   url
   due to ConversationAwareViewHandler, so we could use
  this information for
   restoring the conversation. Does anybody has
  objections or a better
   solution
   regarding this point in mind?
  
   br, Sven
  
  
  
   2009/11/15 Gurkan Erdogdu gurkanerdo...@yahoo.com
  
Hi Sven;
   
Very good points :) I will try to correct those
  issues.
   
PS: If you would like to patch, you are always
  welcome :)
   
Thanks again for helping us!
   
--Gurkan
   
   
   
   

From: Sven Linstaedt sven.linsta...@googlemail.com
To: openwebbeans-dev@incubator.apache.org
Sent: Sun, November 15, 2009 4:02:57 PM
Subject: Review of WebBeansPhaseListener
   
Hi,
   
I have some questions about the JSF integration
  of OWB, which come to my
mind when dealing with the source code:
   
_ JSF PhaseListener have to be threadsafe (see
  JSF 2.0 spec, chapter
12.3.),
but WebBeansPhaseListener references a obvious
  context dependent
conversation. A quick look at mojarra indicates
  there is a singleton
instantiated for each PhaseListener, so I supose
   WebBeansPhaseListenerwill
get into troubles when serving multiple requests.
  - Use a ThreadLocal
instead?
   
_ Conversation scoped beans might be accessed
  *during* restore view
   during
a
FaceletHandler evaluation. But the
  ConversationContext is restored
   *after*
restore view. - Are there any limitations or
  drawbacks restoring the
ConversationContext *before* restore view? Weld
  is also doing this as far
as
I remember.
   
_ Make sure the ViewRoot's initial state is
  marked *before* modifying
   it's
attributes, because otherwise the stored
  information may be lost.
   
_ WebBeansPhaseListener.fromRedirect ThreadLocal
  seems not to be resetted
anywhere. Furthermore the initializer of this
  ThreadLocal is done once
   (?)
in a static block, and not per created Thread
  using something like
   
public static ThreadLocalBoolean
  fromRedirect = new
ThreadLocalBoolean()
{
 protected Boolean initialValue() {
   return false;
   }
}
   
In addition, if this static field is public, it
  should at least be final.
   
   
br, Sven
   
   
   
   
   
  
 
 
 
  --
  Gurkan Erdogdu
  http://gurkanerdogdu.blogspot.com
 

 __
 Do You Yahoo!?
 Sie sind Spam leid? Yahoo! Mail verfügt über einen herausragenden Schutz
 gegen Massenmails.
 http://mail.yahoo.com




-- 
Gurkan Erdogdu
http://gurkanerdogdu.blogspot.com

Re: Review of WebBeansPhaseListener

2009-11-23 Thread Gurkan Erdogdu

And it must also work for AJAX requests and partial submits.
Those are handled by JSF2. So OWB supports this.

2009/11/23 Mark Struberg strub...@yahoo.de

 Imho it should.

 And it must also work for AJAX requests and partial submits.

 LieGrue,
 strub

 --- Gurkan Erdogdu cgurkanerdo...@gmail.com schrieb am Mo, 23.11.2009:

  Von: Gurkan Erdogdu cgurkanerdo...@gmail.com
  Betreff: Re: Review of WebBeansPhaseListener
  An: openwebbeans-dev@incubator.apache.org
  Datum: Montag, 23. November 2009, 8:04
  Hi Sven;
 
  AFAIK, conversation is defined for using it in pure JSF in
  the
  specification. I do not know whether it supports tag
  handlers or not.
 
  --Gurkan
 
  2009/11/23 Sven Linstaedt sven.linsta...@googlemail.com
 
   I have found a issue, that makes the second point
  necessary to implement:
  
   If one uses a conversation scoped bean in an
  expression, which is evaluated
   during restore view as part of a tag handler (e.g. in
  c:forEach), we need
   the conversation already to be restored, because
  otherwise two
   conversations
   will be in action during one request: one from the
  beginning the request
   till after restore view phase, and another one (the
  right one actually)
   in
   the other phases.
  
   Because before restore view no view and therefore no
  cid is available
   (well,
   sound reasonable ;) our only chance is to retrieve the
  cid from something
   else. The current implementation attaches the cid to
  every form's action
   url
   due to ConversationAwareViewHandler, so we could use
  this information for
   restoring the conversation. Does anybody has
  objections or a better
   solution
   regarding this point in mind?
  
   br, Sven
  
  
  
   2009/11/15 Gurkan Erdogdu gurkanerdo...@yahoo.com
  
Hi Sven;
   
Very good points :) I will try to correct those
  issues.
   
PS: If you would like to patch, you are always
  welcome :)
   
Thanks again for helping us!
   
--Gurkan
   
   
   
   

From: Sven Linstaedt sven.linsta...@googlemail.com
To: openwebbeans-dev@incubator.apache.org
Sent: Sun, November 15, 2009 4:02:57 PM
Subject: Review of WebBeansPhaseListener
   
Hi,
   
I have some questions about the JSF integration
  of OWB, which come to my
mind when dealing with the source code:
   
_ JSF PhaseListener have to be threadsafe (see
  JSF 2.0 spec, chapter
12.3.),
but WebBeansPhaseListener references a obvious
  context dependent
conversation. A quick look at mojarra indicates
  there is a singleton
instantiated for each PhaseListener, so I supose
   WebBeansPhaseListenerwill
get into troubles when serving multiple requests.
  - Use a ThreadLocal
instead?
   
_ Conversation scoped beans might be accessed
  *during* restore view
   during
a
FaceletHandler evaluation. But the
  ConversationContext is restored
   *after*
restore view. - Are there any limitations or
  drawbacks restoring the
ConversationContext *before* restore view? Weld
  is also doing this as far
as
I remember.
   
_ Make sure the ViewRoot's initial state is
  marked *before* modifying
   it's
attributes, because otherwise the stored
  information may be lost.
   
_ WebBeansPhaseListener.fromRedirect ThreadLocal
  seems not to be resetted
anywhere. Furthermore the initializer of this
  ThreadLocal is done once
   (?)
in a static block, and not per created Thread
  using something like
   
public static ThreadLocalBoolean
  fromRedirect = new
ThreadLocalBoolean()
{
 protected Boolean initialValue() {
   return false;
   }
}
   
In addition, if this static field is public, it
  should at least be final.
   
   
br, Sven
   
   
   
   
   
  
 
 
 
  --
  Gurkan Erdogdu
  http://gurkanerdogdu.blogspot.com
 

 __
 Do You Yahoo!?
 Sie sind Spam leid? Yahoo! Mail verfügt über einen herausragenden Schutz
 gegen Massenmails.
 http://mail.yahoo.com




-- 
Gurkan Erdogdu
http://gurkanerdogdu.blogspot.com

Re: RE : RE : Documentation Project

2009-11-23 Thread Gurkan Erdogdu

Awesome! Thanks a lot!

--Gurkan

From: Monteiro Jean-Louis jean-louis.monte...@atosorigin.com
To: openwebbeans-dev@incubator.apache.org 
openwebbeans-dev@incubator.apache.org
Sent: Mon, November 23, 2009 10:35:12 PM
Subject: RE : RE : Documentation Project

Hi Gurkan,

I gonna checkout the doc tomorrow and try to give it a try.
As soon as i have a pretty better version, i'll give you back the new version.

After that, i guess i'll be able to work on OEJB+Tomcat+OWB

Jean-Louis

De : Gurkan Erdogdu [cgurkanerdo...@gmail.com]
Date d'envoi : lundi 23 novembre 2009 08:01
À : openwebbeans-dev@incubator.apache.org
Objet : Re: RE : Documentation Project

Hi Jean-Louis,

Our PDF and HTML documents does not look good after generating. How can we
change color of titles, size of fonts, adding images to warning messages
etc..?

What are your opinions?

Moreover, it is very nice if you update documentation related with how to
develop EJB using OpenEJB+Tomcat+OpenWebBeans. Some materials are located in
my blog and in the
https://svn.apache.org/repos/asf/incubator/openwebbeans/trunk/readme/README_M3.txt
.

Thanks a lot;

--Gurkan

2009/11/22 Monteiro Jean-Louis jean-louis.monte...@atosorigin.com

 Hi Gurkan,

 I already use this plugin (at the office) and i'm familiar with XSL and
 DocBook
 How can I help?
 What do you want/need?

 Jean-Louis MONTEIRO

 De : Gurkan Erdogdu [gurkanerdo...@yahoo.com]
 Date d'envoi : samedi 21 novembre 2009 23:59
 À : openwebbeans-dev@incubator.apache.org
 Objet : Documentation Project

 Hi folks;

 I have created a new maven project(webbeans-doc) responsible for generating
  documents(html, pdf etc.) based on the DocBook format. I have used a maven
 plugin from http://code.google.com/p/docbkx-tools/.

 Generating documents
 -
 mvn compile;
 cd target/html or pdf

 Produced documentation needs some stylesheet updating for looking good but
 I have not so much experienced with DocBook. Any helps are welcome!

 Besides,  I have added some documentation namely chapter1.xml. But we need
 to write some more documentation.

 Thanks;

 --Gurkan

 Ce message et les pièces jointes sont confidentiels et réservés à l'usage
 exclusif de ses destinataires. Il peut également être protégé par le secret
 professionnel. Si vous recevez ce message par erreur, merci d'en avertir
 immédiatement l'expéditeur et de le détruire. L'intégrité du message ne
 pouvant être assurée sur Internet, la responsabilité du groupe Atos Origin
 ne pourra être recherchée quant au contenu de ce message. Bien que les
 meilleurs efforts soient faits pour maintenir cette transmission exempte de
 tout virus, l'expéditeur ne donne aucune garantie à cet égard et sa
 responsabilité ne saurait être recherchée pour tout dommage résultant d'un
 virus transmis.

 This e-mail and the documents attached are confidential and intended solely
 for the addressee; it may also be privileged. If you receive this e-mail in
 error, please notify the sender immediately and destroy it. As its integrity
 cannot be secured on the Internet, the Atos Origin group liability cannot be
 triggered for the message content. Although the sender endeavours to
 maintain a computer virus-free network, the sender does not warrant that
 this transmission is virus-free and will not be liable for any damages
 resulting from any virus transmitted.

--
Gurkan Erdogdu
http://gurkanerdogdu.blogspot.com

Ce message et les pièces jointes sont confidentiels et réservés à l'usage 
exclusif de ses destinataires. Il peut également être protégé par le secret 
professionnel. Si vous recevez ce message par erreur, merci d'en avertir 
immédiatement l'expéditeur et de le détruire. L'intégrité du message ne pouvant 
être assurée sur Internet, la responsabilité du groupe Atos Origin ne pourra 
être recherchée quant au contenu de ce message. Bien que les meilleurs efforts 
soient faits pour maintenir cette transmission exempte de tout virus, 
l'expéditeur ne donne aucune garantie à cet égard et sa responsabilité ne 
saurait être recherchée pour tout dommage résultant d'un virus transmis.

This e-mail and the documents attached are confidential and intended solely for 
the addressee; it may also be privileged. If you receive this e-mail in error, 
please notify the sender immediately and destroy it. As its integrity cannot be 
secured on the Internet, the Atos Origin group liability cannot be triggered 
for the message content. Although the sender endeavours to maintain a computer 
virus-free network, the sender does not warrant that this transmission is 
virus-free and will not be liable for any damages resulting from any virus 
transmitted.

[IMPORTANT]Writing Tests

2009-11-22 Thread Gurkan Erdogdu

Hi folks,

As you know, I have implemented new test framework. Please do not use old test 
framework for writing new tests,i .e do not use TestContext class and its 
methods anymore.

Moreover, do not put new tests into the org/apache/webbeans/test folder. Put 
new tests into org/apache/webbeans/newtests folder. One more thing is that 
please ensure that you have check-out all committed code before adding/updating 
something.

Thanks;

--Gurkan

Re: RE : Documentation Project

2009-11-22 Thread Gurkan Erdogdu

Hi Jean-Louis,

Our PDF and HTML documents does not look good after generating. How can we
change color of titles, size of fonts, adding images to warning messages
etc..?

What are your opinions?

Moreover, it is very nice if you update documentation related with how to
develop EJB using OpenEJB+Tomcat+OpenWebBeans. Some materials are located in
my blog and in the
https://svn.apache.org/repos/asf/incubator/openwebbeans/trunk/readme/README_M3.txt
.

Thanks a lot;

--Gurkan

2009/11/22 Monteiro Jean-Louis jean-louis.monte...@atosorigin.com

 Hi Gurkan,

 I already use this plugin (at the office) and i'm familiar with XSL and
 DocBook
 How can I help?
 What do you want/need?

 Jean-Louis MONTEIRO

 
 De : Gurkan Erdogdu [gurkanerdo...@yahoo.com]
 Date d'envoi : samedi 21 novembre 2009 23:59
 À : openwebbeans-dev@incubator.apache.org
 Objet : Documentation Project

 Hi folks;

 I have created a new maven project(webbeans-doc) responsible for generating
  documents(html, pdf etc.) based on the DocBook format. I have used a maven
 plugin from http://code.google.com/p/docbkx-tools/.

 Generating documents
 -
 mvn compile;
 cd target/html or pdf

 Produced documentation needs some stylesheet updating for looking good but
 I have not so much experienced with DocBook. Any helps are welcome!

 Besides,  I have added some documentation namely chapter1.xml. But we need
 to write some more documentation.

 Thanks;

 --Gurkan





 Ce message et les pièces jointes sont confidentiels et réservés à l'usage
 exclusif de ses destinataires. Il peut également être protégé par le secret
 professionnel. Si vous recevez ce message par erreur, merci d'en avertir
 immédiatement l'expéditeur et de le détruire. L'intégrité du message ne
 pouvant être assurée sur Internet, la responsabilité du groupe Atos Origin
 ne pourra être recherchée quant au contenu de ce message. Bien que les
 meilleurs efforts soient faits pour maintenir cette transmission exempte de
 tout virus, l'expéditeur ne donne aucune garantie à cet égard et sa
 responsabilité ne saurait être recherchée pour tout dommage résultant d'un
 virus transmis.

 This e-mail and the documents attached are confidential and intended solely
 for the addressee; it may also be privileged. If you receive this e-mail in
 error, please notify the sender immediately and destroy it. As its integrity
 cannot be secured on the Internet, the Atos Origin group liability cannot be
 triggered for the message content. Although the sender endeavours to
 maintain a computer virus-free network, the sender does not warrant that
 this transmission is virus-free and will not be liable for any damages
 resulting from any virus transmitted.




-- 
Gurkan Erdogdu
http://gurkanerdogdu.blogspot.com

Re: Review of WebBeansPhaseListener

2009-11-22 Thread Gurkan Erdogdu

Hi Sven;

AFAIK, conversation is defined for using it in pure JSF in the
specification. I do not know whether it supports tag handlers or not.

--Gurkan

2009/11/23 Sven Linstaedt sven.linsta...@googlemail.com

 I have found a issue, that makes the second point necessary to implement:

 If one uses a conversation scoped bean in an expression, which is evaluated
 during restore view as part of a tag handler (e.g. in c:forEach), we need
 the conversation already to be restored, because otherwise two
 conversations
 will be in action during one request: one from the beginning the request
 till after restore view phase, and another one (the right one actually)
 in
 the other phases.

 Because before restore view no view and therefore no cid is available
 (well,
 sound reasonable ;) our only chance is to retrieve the cid from something
 else. The current implementation attaches the cid to every form's action
 url
 due to ConversationAwareViewHandler, so we could use this information for
 restoring the conversation. Does anybody has objections or a better
 solution
 regarding this point in mind?

 br, Sven



 2009/11/15 Gurkan Erdogdu gurkanerdo...@yahoo.com

  Hi Sven;
 
  Very good points :) I will try to correct those issues.
 
  PS: If you would like to patch, you are always welcome :)
 
  Thanks again for helping us!
 
  --Gurkan
 
 
 
 
  
  From: Sven Linstaedt sven.linsta...@googlemail.com
  To: openwebbeans-dev@incubator.apache.org
  Sent: Sun, November 15, 2009 4:02:57 PM
  Subject: Review of WebBeansPhaseListener
 
  Hi,
 
  I have some questions about the JSF integration of OWB, which come to my
  mind when dealing with the source code:
 
  _ JSF PhaseListener have to be threadsafe (see JSF 2.0 spec, chapter
  12.3.),
  but WebBeansPhaseListener references a obvious context dependent
  conversation. A quick look at mojarra indicates there is a singleton
  instantiated for each PhaseListener, so I supose
 WebBeansPhaseListenerwill
  get into troubles when serving multiple requests. - Use a ThreadLocal
  instead?
 
  _ Conversation scoped beans might be accessed *during* restore view
 during
  a
  FaceletHandler evaluation. But the ConversationContext is restored
 *after*
  restore view. - Are there any limitations or drawbacks restoring the
  ConversationContext *before* restore view? Weld is also doing this as far
  as
  I remember.
 
  _ Make sure the ViewRoot's initial state is marked *before* modifying
 it's
  attributes, because otherwise the stored information may be lost.
 
  _ WebBeansPhaseListener.fromRedirect ThreadLocal seems not to be resetted
  anywhere. Furthermore the initializer of this ThreadLocal is done once
 (?)
  in a static block, and not per created Thread using something like
 
  public static ThreadLocalBoolean fromRedirect = new
  ThreadLocalBoolean()
  {
   protected Boolean initialValue() {
 return false;
 }
  }
 
  In addition, if this static field is public, it should at least be final.
 
 
  br, Sven
 
 
 
 
 




-- 
Gurkan Erdogdu
http://gurkanerdogdu.blogspot.com

Documentation Project

2009-11-21 Thread Gurkan Erdogdu

Hi folks;

I have created a new maven project(webbeans-doc) responsible for generating  
documents(html, pdf etc.) based on the DocBook format. I have used a maven 
plugin from http://code.google.com/p/docbkx-tools/.

Generating documents
-
mvn compile;
cd target/html or pdf

Produced documentation needs some stylesheet updating for looking good but I 
have not so much experienced with DocBook. Any helps are welcome!

Besides,  I have added some documentation namely chapter1.xml. But we need to 
write some more documentation.

Thanks;

--Gurkan

Re: [jira] Commented: (OWB-174) ApplicationContext available in StandaloneLifeCycle

2009-11-20 Thread Gurkan Erdogdu

could you look at OpenWebBeansTestLifecycle in test package?




From: Sven Linstaedt sven.linsta...@googlemail.com
To: openwebbeans-dev@incubator.apache.org
Sent: Fri, November 20, 2009 7:52:09 PM
Subject: Re: [jira] Commented: (OWB-174) ApplicationContext available in  
StandaloneLifeCycle

It would be nice to be able to test one's services with unit tests using the
StandaloneLifecycle.

wdyt?



2009/11/20 Gurkan Erdogdu (JIRA) j...@apache.org


[
 https://issues.apache.org/jira/browse/OWB-174?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12780674#action_12780674]

 Gurkan Erdogdu commented on OWB-174:
 

 Actually in standalone there is no difference between usage of singleton or
 application context. Also JSR-299 does not define this scope usage in Java
 SE.

  ApplicationContext available in StandaloneLifeCycle
  ---
 
  Key: OWB-174
  URL: https://issues.apache.org/jira/browse/OWB-174
  Project: OpenWebBeans
   Issue Type: Improvement
   Components: Context and Scopes
 Reporter: Sven Linstaedt
 Assignee: Gurkan Erdogdu
 Priority: Minor
  Fix For: M4
 
 
  Just to make @ApplicationScoped beans usable in SE environments.

 --
 This message is automatically generated by JIRA.
 -
 You can reply to this email to add a comment to the issue online.

[RESULT]Re: [VOTE] Gradutation

2009-11-19 Thread Gurkan Erdogdu

Hi folks;

VOTE is now closed after more than 72 hours. OWB community would like to 
graduate as TLP.

It is passed with the following +1's and no 0 or -1. 

Kevan Miller(PPMC)
Gurkan Erdogdu(PPMC)
Mark Struberg(PPMC)
David Blevins(PPMC)
Joe Bergmark
Monteiro Jean-Louis 

I will prepare a draft resolution document and post it here for discussion. 
After that we can start a new VOTE for it.

Thanks;

--Gurkan







From: Kevan Miller kevan.mil...@gmail.com
To: openwebbeans-dev@incubator.apache.org
Sent: Thu, November 19, 2009 12:59:34 AM
Subject: Re: [VOTE] Gradutation


On Nov 16, 2009, at 3:50 PM, Gurkan Erdogdu wrote:

 Hi folks,
 
 There were some discussions related with graduation of the OpenWebBeans 
 podling from incubator. Last time we discussed graduation, main barrier is 
 the lack of community around it.  Over couple of weeks, we have diverted and 
 increased our community around the project. 
 
 Generally,  it seems that community would like to graduate as a TLP.   To do 
 formal process, I would like to start a VOTE for graduating OWB as TLP.
 
 Please cast your VOTEs here. VOTE is open for 72 hours.
 
 [-1] Do not graduate as TLP
 [0 ] Do not care TLP or not
 [+1] Graduate as TLP
 
 This is my +1;

Here's my +1. 

IIUC, this vote is intended to set the direction for graduation. The community 
will then prepare the community for graduation, determine who will be community 
members, PMC chair, and draft a resolution. We will then approve that via a 
vote. That resolution will then be taken to the Incubator PMC. Is that what 
we're working towards?

--kevan

Re: [jira] Created: (OWB-171) CID during GET requests must be set on UIViewRoot earlier than before render response

2009-11-18 Thread Gurkan Erdogdu

Understood the problem.

WDYT to update  JSFConversationServiceImpl#getConversationId as follows

//Look for UIViewRoot for postback requests
if(JSFUtil.getConversationId == null)
{
  //Look for get requests
 return
JSFUtil.getExternalContext().getRequestParameterMap().get(cid);}
}


2009/11/18 Sven Linstaedt sven.linsta...@googlemail.com

 Hi Gurkan,

 actually two instances needs to be restores: Conversation (request scoped
 bean) and ConversationContext (hold as ThreadLocal). WebBeansPhaseListener
 restores the last one. The Conversation is actually not set as a
 ThreadLocal, but instead retrieved from the ConversationBean every time it
 is requested, which itself relies on the ConversationService, which
 implementation in turn relies on the cid being set on the ViewRoot.

 The problem with GET requests is, the ViewRoot is created for the requests
 (without a cid being set of course), so the cid needs to be set on the
 ViewRoot in order to be able to have the correct Conversation being looked
 up during the request.

 br, Sven


 2009/11/18 Gurkan Erdogdu cgurkanerdo...@gmail.com

  Hi;
 
  For GET requests, specification defines two ways
 
  1* Redirect via JSF -- OWB handles -- Adding cid parameter to the URL.
  2* Ordinary GET requests  -- You have to manage this scenario -- Adding
  cid manually to URL
 
  In second case, if URL contains cid then conversation is restored in
  WebBeansPhaseListener#AfterPhase#RESTORE_VIEW via
 
  String cid =
  JSFUtil.getExternalContext().getRequestParameterMap().get(cid);
 
 
  --Gurkan
 
  2009/11/18 Sven Linstaedt (JIRA) j...@apache.org
 
   CID during GET requests must be set on UIViewRoot earlier than before
   render response
  
  
 
 -
  
   Key: OWB-171
   URL: https://issues.apache.org/jira/browse/OWB-171
   Project: OpenWebBeans
Issue Type: Bug
Components: Context and Scopes
  Reporter: Sven Linstaedt
  Assignee: Gurkan Erdogdu
  
  
   The problem:
  
   GET requests in JSF2 can be handled by the full lifecycle, if the view
   contains a f:metadata/ with appropriate  f:viewParam/ components.
   Because no UIViewRoot is restored, but instead a new one is created, no
  cid
   can be restored from the view root until WebBeansPhaseListener handles
   before render rensponse.
  
   If one  requests the Conversation for injection during the lifecycle
   ConversationBean.createInstance() is called, which should lookup the
   conversation on the ConversationManager using the current sessionid and
  cid.
   Both string based parameters are again looked up from the
   ConversationService. Unfortunately
  ConversationService.getConversationId()
   uses the ViewRoot's attributes map of current FacesContext to retrieve
  the
   cid, which will be first set in the render phase. This results in a new
   conversation being created.
  
   A possible solution would consists of setting the cid as early as the
  view
   root is created in restore view.
  
   --
   This message is automatically generated by JIRA.
   -
   You can reply to this email to add a comment to the issue online.
  
  
 
 
  --
  Gurkan Erdogdu
  http://gurkanerdogdu.blogspot.com
 




-- 
Gurkan Erdogdu
http://gurkanerdogdu.blogspot.com

[jira] Closed: (OWB-168) cid parameter is not propagated for redirects caused by ajax requests and on h:link/

2009-11-17 Thread Gurkan Erdogdu (JIRA)


 [ 
https://issues.apache.org/jira/browse/OWB-168?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gurkan Erdogdu closed OWB-168.
--

   Resolution: Fixed
Fix Version/s: M4

I have added implementation to module jsf. Nonetheless, I have not added it 
into faces-config.xml so it needs manual configuration for the time being.

 cid parameter is not propagated for redirects caused by ajax requests and on 
 h:link/
 --

 Key: OWB-168
 URL: https://issues.apache.org/jira/browse/OWB-168
 Project: OpenWebBeans
  Issue Type: Bug
  Components: Context and Scopes
Reporter: Sven Linstaedt
Assignee: Gurkan Erdogdu
 Fix For: M4

 Attachments: ConversationAwareViewHandler.java


 Instead of using a servlet filter I suggest using a ViewHandler delegate, 
 which oberrides getActionURL and getRedirectURL and attaches the cid, because 
 Filter.sendRedirect() is not called reliable.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: [jira] Created: (OWB-171) CID during GET requests must be set on UIViewRoot earlier than before render response

2009-11-17 Thread Gurkan Erdogdu

Hi;

For GET requests, specification defines two ways

1* Redirect via JSF -- OWB handles -- Adding cid parameter to the URL.
2* Ordinary GET requests  -- You have to manage this scenario -- Adding
cid manually to URL

In second case, if URL contains cid then conversation is restored in
WebBeansPhaseListener#AfterPhase#RESTORE_VIEW via

String cid = JSFUtil.getExternalContext().getRequestParameterMap().get(cid);


--Gurkan

2009/11/18 Sven Linstaedt (JIRA) j...@apache.org

 CID during GET requests must be set on UIViewRoot earlier than before
 render response

 -

 Key: OWB-171
 URL: https://issues.apache.org/jira/browse/OWB-171
 Project: OpenWebBeans
  Issue Type: Bug
  Components: Context and Scopes
Reporter: Sven Linstaedt
Assignee: Gurkan Erdogdu


 The problem:

 GET requests in JSF2 can be handled by the full lifecycle, if the view
 contains a f:metadata/ with appropriate  f:viewParam/ components.
 Because no UIViewRoot is restored, but instead a new one is created, no cid
 can be restored from the view root until WebBeansPhaseListener handles
 before render rensponse.

 If one  requests the Conversation for injection during the lifecycle
 ConversationBean.createInstance() is called, which should lookup the
 conversation on the ConversationManager using the current sessionid and cid.
 Both string based parameters are again looked up from the
 ConversationService. Unfortunately ConversationService.getConversationId()
 uses the ViewRoot's attributes map of current FacesContext to retrieve the
 cid, which will be first set in the render phase. This results in a new
 conversation being created.

 A possible solution would consists of setting the cid as early as the view
 root is created in restore view.

 --
 This message is automatically generated by JIRA.
 -
 You can reply to this email to add a comment to the issue online.




-- 
Gurkan Erdogdu
http://gurkanerdogdu.blogspot.com

[jira] Commented: (OWB-168) cid parameter is not propagated for redirects caused by ajax requests and on h:link/

2009-11-16 Thread Gurkan Erdogdu (JIRA)


[ 
https://issues.apache.org/jira/browse/OWB-168?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12778428#action_12778428
 ] 

Gurkan Erdogdu commented on OWB-168:


Currently we are wrapping response object. 

There is an example for how to use redirect with JSF. Could you look at the 
sample, 
https://svn.apache.org/repos/asf/incubator/openwebbeans/trunk/samples/jsf2sample
 ? It includes conversation.xhtml.

Also could you attach your test case?

Thanks;

 cid parameter is not propagated for redirects caused by ajax requests and on 
 h:link/
 --

 Key: OWB-168
 URL: https://issues.apache.org/jira/browse/OWB-168
 Project: OpenWebBeans
  Issue Type: Bug
  Components: Context and Scopes
Reporter: Sven Linstaedt
Assignee: Gurkan Erdogdu

 Instead of using a servlet filter I suggest using a ViewHandler delegate, 
 which oberrides getActionURL and getRedirectURL and attaches the cid, because 
 Filter.sendRedirect() is not called reliable.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (OWB-167) Buildin Bean types should be decoratable

2009-11-16 Thread Gurkan Erdogdu (JIRA)


[ 
https://issues.apache.org/jira/browse/OWB-167?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12778646#action_12778646
 ] 

Gurkan Erdogdu commented on OWB-167:


Added support for Conversation becuase it is RequestScoped. Dependent scoped 
interceptor/decorator is TODO

 Buildin Bean types should be decoratable
 

 Key: OWB-167
 URL: https://issues.apache.org/jira/browse/OWB-167
 Project: OpenWebBeans
  Issue Type: Bug
  Components: Interceptor and Decorators
Reporter: Sven Linstaedt
Assignee: Gurkan Erdogdu

 According to the weld list buildin Bean types like Conversations should be 
 decoratable like application specific Beans. 
 I haved tested this not working for javax.enterprise.context.Conversation, 
 but I believe other buildin Beans are not decoratable too.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Resolved: (OWB-165) Missing bean interception stack during TagHandler expression evaluation

[
https://issues.apache.org/jira/browse/OWB-165?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Gurkan Erdogdu resolved OWB-165.

Resolution: Fixed

Sven,

Looks like problem is related with getting instance from context. To run
interceptors, we have always return to proxy instead of actual instance.

Could you verify ?

Thanks again for helping us!

Missing bean interception stack during TagHandler expression evaluation
---

Key: OWB-165
URL: https://issues.apache.org/jira/browse/OWB-165
Project: OpenWebBeans
Issue Type: Bug
Components: Interceptor and Decorators
Affects Versions: M3
Reporter: Sven Linstaedt
Assignee: Gurkan Erdogdu
Fix For: M4

Attachments: webapp-sources.jar, webapp.war

Given a JSF controller bean, which should be intercepted by in simple
interceptor. If one of it's methods is invoked via EL using a
MethodExpression bound to a commandButton, the controller bean is called
without interception stack (meaning: the interceptor is not called). If I
invoke the same method from within another controller bean programmatically,
the interception stack is in place and the interceptor is called.
As far as I figured this issue out, the problem is due to the phase, when the
bean is created. If you remove the c:if test=#{testController.show} in
the example, the interceptor is called.
http://localhost:8080/interceptor.xhtml

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Resolved: (OWB-162) WebBeansJSFFilter is cutting off included ViewParams


 [ 
https://issues.apache.org/jira/browse/OWB-162?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gurkan Erdogdu resolved OWB-162.


   Resolution: Fixed
Fix Version/s: M4

 WebBeansJSFFilter is cutting off included ViewParams
 

 Key: OWB-162
 URL: https://issues.apache.org/jira/browse/OWB-162
 Project: OpenWebBeans
  Issue Type: Bug
  Components: Core
Affects Versions: 1.0.0
Reporter: Sven Linstaedt
Assignee: Gurkan Erdogdu
 Fix For: M4


 I am using a nightly build.
 If a navigation result in a redirect that has a query string containing view 
 encoded parameters using f:viewParam /, these parameters will get cut off 
 in WebBeansJSFFilter:68. The filter uses ViewHandler.getActionURL(), which in 
 turn only returns the viewId with cut off parameters.
 I was not able to figure out why ViewHandler.getActionURL() is used at this 
 point. In the reference implementation ViewHandler.getActionURL() is already 
 called in ViewHandler.getRedirectURL().

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Closed: (OWB-162) WebBeansJSFFilter is cutting off included ViewParams


 [ 
https://issues.apache.org/jira/browse/OWB-162?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gurkan Erdogdu closed OWB-162.
--


 WebBeansJSFFilter is cutting off included ViewParams
 

 Key: OWB-162
 URL: https://issues.apache.org/jira/browse/OWB-162
 Project: OpenWebBeans
  Issue Type: Bug
  Components: Core
Affects Versions: 1.0.0
Reporter: Sven Linstaedt
Assignee: Gurkan Erdogdu
 Fix For: M4


 I am using a nightly build.
 If a navigation result in a redirect that has a query string containing view 
 encoded parameters using f:viewParam /, these parameters will get cut off 
 in WebBeansJSFFilter:68. The filter uses ViewHandler.getActionURL(), which in 
 turn only returns the viewId with cut off parameters.
 I was not able to figure out why ViewHandler.getActionURL() is used at this 
 point. In the reference implementation ViewHandler.getActionURL() is already 
 called in ViewHandler.getRedirectURL().

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Closed: (OWB-165) Missing bean interception stack during TagHandler expression evaluation


 [ 
https://issues.apache.org/jira/browse/OWB-165?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gurkan Erdogdu closed OWB-165.
--

Resolution: Fixed

 Missing bean interception stack during TagHandler expression evaluation
 ---

 Key: OWB-165
 URL: https://issues.apache.org/jira/browse/OWB-165
 Project: OpenWebBeans
  Issue Type: Bug
  Components: Interceptor and Decorators
Affects Versions: M3
Reporter: Sven Linstaedt
Assignee: Gurkan Erdogdu
 Fix For: M4

 Attachments: webapp-sources.jar, webapp.war


 Given a JSF controller bean, which should be intercepted by in simple 
 interceptor. If one of it's methods is invoked via EL using a 
 MethodExpression bound to a commandButton, the controller bean is called 
 without interception stack (meaning: the interceptor is not called). If I 
 invoke the same method from within another controller bean programmatically, 
 the interception stack is in place and the interceptor is called.
 As far as I figured this issue out, the problem is due to the phase, when the 
 bean is created. If you remove the c:if test=#{testController.show} in 
 the example, the interceptor is called.
 http://localhost:8080/interceptor.xhtml

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: [jira] Created: (OWB-163) Conversations are not scoped to a particular session

2009-11-14 Thread Gurkan Erdogdu

Sorry, I did catch multiple browser scenario :)

I will look at it. Conversations must be on the same session 

Conversation = cid + session id 

Thanks;





From: Gurkan Erdogdu gurkanerdo...@yahoo.com
To: openwebbeans-dev@incubator.apache.org
Sent: Sat, November 14, 2009 9:14:01 PM
Subject: Re: [jira] Created: (OWB-163) Conversations are not scoped to a 
particular session

Hi;

I think that this is the normal. 

When you delete cookie, your session is still valid on the server side until 
session times out/invalidated. If you send a get request via cid parameter, 
conversation is restored again using that cid. Conversations are deleted when 
session times out or is invalidated. I do not see any security hole on this.

This is similar to session management without cookies. If you do not use 
cookies, then JSESSIONID is used on every url that server sends.  Browser sends 
every request with JSESSIONID parameter. If somebody steals your session id, 
then he can simulate fake requests but security must be managed by the 
application in somehow.

Thanks;

--Gurkan





From: Sven Linstaedt (JIRA) j...@apache.org
To: openwebbeans-dev@incubator.apache.org
Sent: Sat, November 14, 2009 3:40:39 PM
Subject: [jira] Created: (OWB-163) Conversations are not scoped to a particular 
session

Conversations are not scoped to a particular session


 Key: OWB-163
 URL: https://issues.apache.org/jira/browse/OWB-163
 Project: OpenWebBeans
  Issue Type: Bug
  Components: Context and Scopes
Affects Versions: 1.0.0
Reporter: Sven Linstaedt
Assignee: Gurkan Erdogdu
Priority: Blocker


According to the spec 6.7.4: All long-running conversations are scoped to a 
particular HTTP servlet session and may not cross session boundaries.

If I create a long running conversation and delete my browser cookies (or 
switch to another browser vendor) the conversation is still available by 
attaching the CID to the request URL. IMHO this is a high security risk, 
therefore I created this issue as a blocker.

I stumbled upon this while trying to provide incremental instead of random CIDs 
to long running conversations. I am using a nightly build of the trunk.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (OWB-163) Conversations are not scoped to a particular session


[ 
https://issues.apache.org/jira/browse/OWB-163?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12777988#action_12777988
 ] 

Gurkan Erdogdu commented on OWB-163:


conversation = cid + session id

Means, two different session with same cid must not be restored.

 Conversations are not scoped to a particular session
 

 Key: OWB-163
 URL: https://issues.apache.org/jira/browse/OWB-163
 Project: OpenWebBeans
  Issue Type: Bug
  Components: Context and Scopes
Affects Versions: 1.0.0
Reporter: Sven Linstaedt
Assignee: Gurkan Erdogdu
Priority: Blocker

 According to the spec 6.7.4: All long-running conversations are scoped to a 
 particular HTTP servlet session and may not cross session boundaries.
 If I create a long running conversation and delete my browser cookies (or 
 switch to another browser vendor) the conversation is still available by 
 attaching the CID to the request URL. IMHO this is a high security risk, 
 therefore I created this issue as a blocker.
 I stumbled upon this while trying to provide incremental instead of random 
 CIDs to long running conversations. I am using a nightly build of the trunk.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (OWB-163) Conversations are not scoped to a particular session


[ 
https://issues.apache.org/jira/browse/OWB-163?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12777992#action_12777992
 ] 

Gurkan Erdogdu commented on OWB-163:


ConversationManager uses Mapconversation, context . As I said, conversation = 
cid + session_id. So if cid is same but different session_id, then different 
contexts exist. 

 Conversations are not scoped to a particular session
 

 Key: OWB-163
 URL: https://issues.apache.org/jira/browse/OWB-163
 Project: OpenWebBeans
  Issue Type: Bug
  Components: Context and Scopes
Affects Versions: 1.0.0
Reporter: Sven Linstaedt
Assignee: Gurkan Erdogdu
Priority: Blocker

 According to the spec 6.7.4: All long-running conversations are scoped to a 
 particular HTTP servlet session and may not cross session boundaries.
 If I create a long running conversation and delete my browser cookies (or 
 switch to another browser vendor) the conversation is still available by 
 attaching the CID to the request URL. IMHO this is a high security risk, 
 therefore I created this issue as a blocker.
 I stumbled upon this while trying to provide incremental instead of random 
 CIDs to long running conversations. I am using a nightly build of the trunk.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: Interception stack during MethodExpression evaluation?

2009-11-14 Thread Gurkan Erdogdu

could you also attach your sample?

Thanks;

From: Sven Linstaedt sven.linsta...@googlemail.com
To: openwebbeans-dev@incubator.apache.org
Sent: Sat, November 14, 2009 9:47:44 PM
Subject: Re: Interception stack during MethodExpression evaluation?

Well, actually I tried this only using @NormalScope beans like
ConversationScoped and RequestScoped. Haven't tested @Dependent yet.

I will file a bug for this.

br, Sven

2009/11/14 Gurkan Erdogdu gurkanerdo...@yahoo.com

 FYI : Currently, we do not provide interceptions for @Dependent scoped
 beans. So, if your controller is a dependent scoped bean, OWB does not
 intercept.(https://issues.apache.org/jira/browse/OWB-151)

 Did you try to configure controller with other scopes than @Dependent? If
 you tried, then it is weird and definitely a bug!

 Thanks;

 --Gurkan

 From: Sven Linstaedt sven.linsta...@googlemail.com
 To: openwebbeans-dev@incubator.apache.org
 Sent: Sat, November 14, 2009 9:21:50 PM
 Subject: Interception stack during MethodExpression evaluation?

 Good evening,

 I am totally puzzled in this case: I have a JSF controller bean, which
 should be intercepted by in simple interceptor. If I invoke a method of
 this
 controller via EL using a MethodExpression bound to a commandButton, the
 controller bean is called without interception stack (meaning: the
 interceptor is not called). If I invoke the same method from within another
 controller bean programmatically, the interception stack is in place and
 the
 interceptor is called.

 I have verified this using multiple different scoped controller beans and
 it's every time the same. Feels like a bug. Can someone verify this?

 I am using a nightly build and spec conform beans.xml notation like:

 http://www.w3.org/2001/XMLSchema-instance;
xsi:schemaLocation=http://java.sun.com/xml/ns/javaee
 http://java.sun.com/xml/ns/javaee/beans_1_0.xsd;
interceptors
classxxx.InterceptorType/class
/interceptors
 /beans

 br, Sven

[jira] Commented: (OWB-163) Conversations are not scoped to a particular session


[ 
https://issues.apache.org/jira/browse/OWB-163?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12777998#action_12777998
 ] 

Gurkan Erdogdu commented on OWB-163:


Yeah, this is a bug :)

 Conversations are not scoped to a particular session
 

 Key: OWB-163
 URL: https://issues.apache.org/jira/browse/OWB-163
 Project: OpenWebBeans
  Issue Type: Bug
  Components: Context and Scopes
Affects Versions: 1.0.0
Reporter: Sven Linstaedt
Assignee: Gurkan Erdogdu
Priority: Blocker

 According to the spec 6.7.4: All long-running conversations are scoped to a 
 particular HTTP servlet session and may not cross session boundaries.
 If I create a long running conversation and delete my browser cookies (or 
 switch to another browser vendor) the conversation is still available by 
 attaching the CID to the request URL. IMHO this is a high security risk, 
 therefore I created this issue as a blocker.
 I stumbled upon this while trying to provide incremental instead of random 
 CIDs to long running conversations. I am using a nightly build of the trunk.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Resolved: (OWB-163) Conversations are not scoped to a particular session


 [ 
https://issues.apache.org/jira/browse/OWB-163?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gurkan Erdogdu resolved OWB-163.


   Resolution: Fixed
Fix Version/s: M4

Please check trunk. 

 Conversations are not scoped to a particular session
 

 Key: OWB-163
 URL: https://issues.apache.org/jira/browse/OWB-163
 Project: OpenWebBeans
  Issue Type: Bug
  Components: Context and Scopes
Affects Versions: 1.0.0
Reporter: Sven Linstaedt
Assignee: Gurkan Erdogdu
Priority: Blocker
 Fix For: M4


 According to the spec 6.7.4: All long-running conversations are scoped to a 
 particular HTTP servlet session and may not cross session boundaries.
 If I create a long running conversation and delete my browser cookies (or 
 switch to another browser vendor) the conversation is still available by 
 attaching the CID to the request URL. IMHO this is a high security risk, 
 therefore I created this issue as a blocker.
 I stumbled upon this while trying to provide incremental instead of random 
 CIDs to long running conversations. I am using a nightly build of the trunk.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Closed: (OWB-164) Consistent logging in WebBeansInterceptorConfig


 [ 
https://issues.apache.org/jira/browse/OWB-164?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gurkan Erdogdu closed OWB-164.
--


 Consistent logging in WebBeansInterceptorConfig
 ---

 Key: OWB-164
 URL: https://issues.apache.org/jira/browse/OWB-164
 Project: OpenWebBeans
  Issue Type: Improvement
  Components: XML Configuration
Affects Versions: 1.0.0
Reporter: Sven Linstaedt
Assignee: Gurkan Erdogdu
Priority: Trivial
 Fix For: M4


 WebBeansInterceptorConfig.configureInterceptorClass:64
 Method entry is logged with delegate.getReturnType().getName(), but method 
 leaving with delegate.getReturnType(), resulting in different log outputs. 
 I would expect both log of them log in a similar way.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (OWB-163) Conversations are not scoped to a particular session


 [ 
https://issues.apache.org/jira/browse/OWB-163?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gurkan Erdogdu updated OWB-163:
---

Affects Version/s: (was: 1.0.0)
   M3

 Conversations are not scoped to a particular session
 

 Key: OWB-163
 URL: https://issues.apache.org/jira/browse/OWB-163
 Project: OpenWebBeans
  Issue Type: Bug
  Components: Context and Scopes
Affects Versions: M3
Reporter: Sven Linstaedt
Assignee: Gurkan Erdogdu
Priority: Blocker
 Fix For: M4


 According to the spec 6.7.4: All long-running conversations are scoped to a 
 particular HTTP servlet session and may not cross session boundaries.
 If I create a long running conversation and delete my browser cookies (or 
 switch to another browser vendor) the conversation is still available by 
 attaching the CID to the request URL. IMHO this is a high security risk, 
 therefore I created this issue as a blocker.
 I stumbled upon this while trying to provide incremental instead of random 
 CIDs to long running conversations. I am using a nightly build of the trunk.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (OWB-165) Missing bean interception stack during TagHandler expression evaluation


 [ 
https://issues.apache.org/jira/browse/OWB-165?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gurkan Erdogdu updated OWB-165:
---

Affects Version/s: (was: M4)
   M3
Fix Version/s: M4

 Missing bean interception stack during TagHandler expression evaluation
 ---

 Key: OWB-165
 URL: https://issues.apache.org/jira/browse/OWB-165
 Project: OpenWebBeans
  Issue Type: Bug
  Components: Interceptor and Decorators
Affects Versions: M3
Reporter: Sven Linstaedt
Assignee: Gurkan Erdogdu
 Fix For: M4

 Attachments: webapp-sources.jar, webapp.war


 Given a JSF controller bean, which should be intercepted by in simple 
 interceptor. If one of it's methods is invoked via EL using a 
 MethodExpression bound to a commandButton, the controller bean is called 
 without interception stack (meaning: the interceptor is not called). If I 
 invoke the same method from within another controller bean programmatically, 
 the interception stack is in place and the interceptor is called.
 As far as I figured this issue out, the problem is due to the phase, when the 
 bean is created. If you remove the c:if test=#{testController.show} in 
 the example, the interceptor is called.
 http://localhost:8080/interceptor.xhtml

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (OWB-165) Missing bean interception stack during TagHandler expression evaluation


 [ 
https://issues.apache.org/jira/browse/OWB-165?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gurkan Erdogdu updated OWB-165:
---

Affects Version/s: (was: 1.0.0)
   M4

 Missing bean interception stack during TagHandler expression evaluation
 ---

 Key: OWB-165
 URL: https://issues.apache.org/jira/browse/OWB-165
 Project: OpenWebBeans
  Issue Type: Bug
  Components: Interceptor and Decorators
Affects Versions: M3
Reporter: Sven Linstaedt
Assignee: Gurkan Erdogdu
 Fix For: M4

 Attachments: webapp-sources.jar, webapp.war


 Given a JSF controller bean, which should be intercepted by in simple 
 interceptor. If one of it's methods is invoked via EL using a 
 MethodExpression bound to a commandButton, the controller bean is called 
 without interception stack (meaning: the interceptor is not called). If I 
 invoke the same method from within another controller bean programmatically, 
 the interception stack is in place and the interceptor is called.
 As far as I figured this issue out, the problem is due to the phase, when the 
 bean is created. If you remove the c:if test=#{testController.show} in 
 the example, the interceptor is called.
 http://localhost:8080/interceptor.xhtml

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (OWB-164) Consistent logging in WebBeansInterceptorConfig