Re: OWB proxy characteristics

[Gurkan Erdogdu]

>>>Are our proxies 100% thread safe?
Answer is NO.

2009/12/22 Gurkan Erdogdu 

> As you said, proxies are just facades. It is thought as immutable. Its sole
> purpose is to get actual instance of the bean from current context. I
> remember that there is no thread-safety requirements of the scoped instances
> in the specification. If there are parallel calls to the same proxy
> instance, this means that parallel calls to same scoped instances. For
> example, Seam defines some conditions for handling multi-threaded session or
> application scoped instances.
>
> --Gurkan
>
> 2009/12/22 Mark Struberg 
>
> Hi!
>>
>> Just a short mail to ensure that we take care of a few things:
>>
>> .) Are our proxies 100% thread safe? Because we currently only create one
>> proxy instance for all instances of a specific bean. Which means that
>> parallel requests coming through a web server may result in concurrent proxy
>> invocations to the same proxy instance, even if the proxied bean instances
>> behind the facade differ.
>>
>> 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
>



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

Re: OWB proxy characteristics

[Gurkan Erdogdu]

As you said, proxies are just facades. It is thought as immutable. Its sole
purpose is to get actual instance of the bean from current context. I
remember that there is no thread-safety requirements of the scoped instances
in the specification. If there are parallel calls to the same proxy
instance, this means that parallel calls to same scoped instances. For
example, Seam defines some conditions for handling multi-threaded session or
application scoped instances.

--Gurkan

2009/12/22 Mark Struberg 

> Hi!
>
> Just a short mail to ensure that we take care of a few things:
>
> .) Are our proxies 100% thread safe? Because we currently only create one
> proxy instance for all instances of a specific bean. Which means that
> parallel requests coming through a web server may result in concurrent proxy
> invocations to the same proxy instance, even if the proxied bean instances
> behind the facade differ.
>
> 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] Updated: (OWB-206) proxies only get injected for the 1st instance of a bean

[Gurkan Erdogdu]

I added this section for some reasons that I do not remember now!

I will look at it





From: Mark Struberg (JIRA) 
To: openwebbeans-dev@incubator.apache.org
Sent: Mon, December 21, 2009 7:36:18 PM
Subject: [jira] Updated: (OWB-206) proxies only get injected for the 1st 
instance of a bean


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

Mark Struberg updated OWB-206:
--

Attachment: OWB-206-rfc.patch

> proxies only get injected for the 1st instance of a bean
> 
>
> Key: OWB-206
> URL: https://issues.apache.org/jira/browse/OWB-206
> Project: OpenWebBeans
>  Issue Type: Bug
>Affects Versions: M3
>Reporter: Mark Struberg
>Assignee: Mark Struberg
>Priority: Blocker
> Fix For: M4
>
> Attachments: OWB-206-rfc.patch
>
>
> I think I've hit a big problem!
> If I inject a bean twice, I get no interceptor for the 2nd instance!
> The problem seems caused in AbstractContext#getInstance() which puts the 
> unproxied! instance into the map!
> I'll checkin a unit test i've written to demonstrate the problem.

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


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

Re: Proxy only gets resolved for the first instance injection

[Gurkan Erdogdu]

Hi;

Bean instance is injected by the container using getReference#BeanManagerImpl 
that uses proxy every time! (creates new one or use existing one with normal 
scoped beans)

If you use Context interface directly, you must not use Context interface 
directly to get instance that is specified in the specification explicitly.

This is just a quick try, but I will look at your test class after you check in.

Thanks ;

--Gurkan





From: Mark Struberg 
To: openwebbeans-dev@incubator.apache.org
Sent: Mon, December 21, 2009 6:14:51 PM
Subject: Proxy only gets resolved for the first instance injection

Hi!

I've created OWB-206 and checked in a unit test which demonstrates the blocker!

I know that the build is currently broken therefore, but it's really important 
that we fix this issue asap!

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!

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

[Gurkan Erdogdu (JIRA)]

[ 
https://issues.apache.org/jira/browse/OWB-171?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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  with appropriate   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] Closed: (OWB-205) Update Samples for MyFaces 1.2 Latest Version

[Gurkan Erdogdu (JIRA)]

 [ 
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] Created: (OWB-205) Update Samples for MyFaces 1.2 Latest Version

[Gurkan Erdogdu (JIRA)]

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-205) Update Samples for MyFaces 1.2 Latest Version

[Gurkan Erdogdu (JIRA)]

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

Gurkan Erdogdu commented on OWB-205:


Adding 1.2.8 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] Updated: (OWB-204) Update Samples for JSF2 Usage

[Gurkan Erdogdu (JIRA)]

 [ 
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-204) Update Samples for JSF2 Usage

[Gurkan Erdogdu (JIRA)]

[ 
https://issues.apache.org/jira/browse/OWB-204?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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] Created: (OWB-204) Update Samples for JSF2 Usage

[Gurkan Erdogdu (JIRA)]

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.

OpenJPA Maven Plugin

[Gurkan Erdogdu]

Hi Mark

Seems that samples/reservation depends on openjpa-maven-plugin. But I do not 
find how to get this plugin from which repository?

Could you update pom.xml with repository info that provides 1.1-SNAPSHOT for 
this plugin;

Thanks;

--Gurkan



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

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

[Gurkan Erdogdu (JIRA)]

[ 
https://issues.apache.org/jira/browse/OWB-171?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12792983#action_12792983
 ] 

Gurkan Erdogdu commented on OWB-171:


I am working on patching. Applying WebBeansPhaseListener with hand :)

> 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
>
>
> The problem:
> GET requests in JSF2 can be handled by the full lifecycle, if the view 
> contains a  with appropriate   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.

Re: Integration of JSF2 specific API calls

[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 

> Also we have to update our poms for JSf2
>
> 2009/12/19 Gurkan Erdogdu 
>
> Just adding classes to webbeans-jsf project.
>>
>> For example you can add JSf2WebBeansListener etc.
>>
>> 2009/12/19 Sven Linstaedt 
>>
>> 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 
>>>
>>> > +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  schrieb am Fr,
>>> > 18.12.2009:
>>> >
>>> > > Von: Sven Linstaedt 
>>> > > 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 
>>> > >
>>> > > > 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 
>>> > > schrieb am Do, 17.12.2009:
>>> > > >
>>> > > > > Von: Gurkan Erdogdu 
>>> > > > > 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 
>>> > > > >
>>> > > > > > 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 w

Re: Integration of JSF2 specific API calls

[Gurkan Erdogdu]

Also we have to update our poms for JSf2

2009/12/19 Gurkan Erdogdu 

> Just adding classes to webbeans-jsf project.
>
> For example you can add JSf2WebBeansListener etc.
>
> 2009/12/19 Sven Linstaedt 
>
> 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 
>>
>> > +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  schrieb am Fr,
>> > 18.12.2009:
>> >
>> > > Von: Sven Linstaedt 
>> > > 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 
>> > >
>> > > > 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 
>> > > schrieb am Do, 17.12.2009:
>> > > >
>> > > > > Von: Gurkan Erdogdu 
>> > > > > 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 
>> > > > >
>> > > > > > 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

Re: Integration of JSF2 specific API calls

[Gurkan Erdogdu]

Just adding classes to webbeans-jsf project.

For example you can add JSf2WebBeansListener etc.

2009/12/19 Sven Linstaedt 

> 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 
>
> > +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  schrieb am Fr,
> > 18.12.2009:
> >
> > > Von: Sven Linstaedt 
> > > 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 
> > >
> > > > 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 
> > > schrieb am Do, 17.12.2009:
> > > >
> > > > > Von: Gurkan Erdogdu 
> > > > > 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 
> > > > >
> > > > > > 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 
> > > > > >
> > > > > >> Gurkan,
> > > > > >>
> > > > > >> I was not talking about special
> > > products, I also
> > > > > meant the API and I
> > > > > >> mentioned RichFaces-3.3.2 only

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

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

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

[Gurkan Erdogdu (JIRA)]

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

Gurkan Erdogdu updated OWB-201:
---

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

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

Migration after Graduation

[Gurkan Erdogdu]

Hi folks;

After graduation, our resources have to be transferred from Incubator. 
Therefore, I have created a jira issue for 
INFRA.(https://issues.apache.org/jira/browse/INFRA-2386).

After all of those issue will be done, we have to act accordingly.(Such as svn 
switch of workspace, changing mailing lists etc.)

--Gurkan



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

Progress Tracking

[Gurkan Erdogdu]

Hi folks;

I just wonder that who is working on which subject/jira issues? Just for not
doing duplicate things!

Currently I read final specification chapters and running TCK (Standalone)
for compatibility and update our code base (I am in chapter-2, Concepts). To
debug TCK code, I get weld-tck from SVN and setup it in eclipse. Actually it
is a very hard and time consuming work!

For container testing, I use TCK TomcatConnector for deploying artifacts
into embeddable EJB container. Generally I am getting OutofMemoryError in
the middle of TCK suite :) Help is welcome!

After some hard work, I think that we have to test much our Generic Types
injection handling code!

As you know we have graduated and we have to move our infrastructure to new
locations. And also WDYT about how to pass JSR-299 TCK, integration with
Geronimo etc?

Thanks;

--Gurkan

Re: Integration of JSF2 specific API calls

[Gurkan Erdogdu]

It is a good idea.

2009/12/18 Sven Linstaedt 

> 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 
>
> > 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  schrieb am Do, 17.12.2009:
> >
> > > Von: Gurkan Erdogdu 
> > > 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 
> > >
> > > > 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 
> > > >
> > > >> 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 
> > > schrieb am Do, 17.12.2009:
> > > >>
> > > >> > Von: Gurkan Erdogdu 
> > > >> > Betreff: Re: Integration of JSF2 specific API
> > > calls
> > > >> > An: openwebbeans-dev@incubator.apache.org
> > > >> > Datum: Donnerstag, 17.

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

[Gurkan Erdogdu (JIRA)]

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

Gurkan Erdogdu updated OWB-200:
---

Affects Version/s: M3

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

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

[Gurkan Erdogdu (JIRA)]

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

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

[Gurkan Erdogdu (JIRA)]

@Type annotation does not work correctly


 Key: OWB-200
 URL: https://issues.apache.org/jira/browse/OWB-200
 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.

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

[Gurkan Erdogdu (JIRA)]

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-199) Bug in ProducerMethod primitive return type resolution

[Gurkan Erdogdu (JIRA)]

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

Gurkan Erdogdu closed OWB-199.
--

Resolution: Fixed

> 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] Created: (OWB-197) If a stereotype declares any other qualifier an- notation, non-portable behavior results.

[Gurkan Erdogdu (JIRA)]

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.

[Gurkan Erdogdu (JIRA)]

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.

[Gurkan Erdogdu (JIRA)]

 [ 
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-196) If an interceptor or decorator is an alternative, non-portable behavior results.

[Gurkan Erdogdu (JIRA)]

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] Updated: (OWB-194) If an interceptor or decorator has a name, non-portable behavior results.

[Gurkan Erdogdu (JIRA)]

 [ 
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] Updated: (OWB-193) If an interceptor or decorator has any scope other than @Dependent, non-portable behavior results.

[Gurkan Erdogdu (JIRA)]

 [ 
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] Created: (OWB-195) Give warning to the developer related with non- portable operations

[Gurkan Erdogdu (JIRA)]

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] Created: (OWB-194) If an interceptor or decorator has a name, non-portable behavior results.

[Gurkan Erdogdu (JIRA)]

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: Improvement
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-193) If an interceptor or decorator has any scope other than @Dependent, non-portable behavior results.

[Gurkan Erdogdu (JIRA)]

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: Improvement
  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] Closed: (OWB-192) Bean Api Types Does not contain Object.class

[Gurkan Erdogdu (JIRA)]

 [ 
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-192) Bean Api Types Does not contain Object.class

[Gurkan Erdogdu (JIRA)]

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] Closed: (OWB-178) update Bean interface to fit the latest spec

[Gurkan Erdogdu (JIRA)]

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

Gurkan Erdogdu closed OWB-178.
--

Resolution: Fixed

> update Bean interface to fit the latest spec
> 
>
> Key: OWB-178
> URL: https://issues.apache.org/jira/browse/OWB-178
> Project: OpenWebBeans
>  Issue Type: Bug
>  Components: Core
>Affects Versions: M4
>Reporter: Mark Struberg
>Assignee: Mark Struberg
>Priority: Blocker
> Fix For: M3
>
>
> e.g. remove isSerialisable(), 
> We have to fix this in order to get the TCK running.

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

[Gurkan Erdogdu (JIRA)]

 [ 
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

[Gurkan Erdogdu (JIRA)]

 [ 
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

[Gurkan Erdogdu (JIRA)]

 [ 
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] Updated: (OWB-170) Address findbug issues in webbeans-impl

[Gurkan Erdogdu (JIRA)]

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

Gurkan Erdogdu updated OWB-170:
---

Fix Version/s: 1.0.0

> Address findbug issues in webbeans-impl
> ---
>
> Key: OWB-170
> URL: https://issues.apache.org/jira/browse/OWB-170
> Project: OpenWebBeans
>  Issue Type: Improvement
>Affects Versions: M3
>Reporter: Joe Bergmark
>Assignee: Joe Bergmark
>Priority: Minor
> Fix For: 1.0.0
>
> Attachments: findbugs.html
>
>
> Several simple performance improvements suggested by findbugs report in 
> webbeans-impl.

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

[jira] Updated: (OWB-151) @Dependent beans not interceptable

[Gurkan Erdogdu (JIRA)]

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

Gurkan Erdogdu updated OWB-151:
---

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

> @Dependent beans not interceptable
> --
>
> Key: OWB-151
> URL: https://issues.apache.org/jira/browse/OWB-151
> Project: OpenWebBeans
>  Issue Type: Bug
>  Components: Interceptor and Decorators
>Affects Versions: M3
>Reporter: Eric Covener
>Assignee: Joe Bergmark
> Fix For: M4
>
>   Original Estimate: 48h
>  Remaining Estimate: 48h
>
> @Dependent beans must be interceptable, although implementations are not 
> required to provide a client proxy for them.

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

[Gurkan Erdogdu (JIRA)]

 [ 
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-171) CID during GET requests must be set on UIViewRoot earlier than before render response

[Gurkan Erdogdu (JIRA)]

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

Gurkan Erdogdu updated OWB-171:
---

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

> 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
>
>
> The problem:
> GET requests in JSF2 can be handled by the full lifecycle, if the view 
> contains a  with appropriate   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] Closed: (OWB-191) Convert logging to use keyed, formatted strings from a ResourceBundle to allow for translation.

[Gurkan Erdogdu (JIRA)]

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

Re: what about a -M4 release?

[Gurkan Erdogdu]

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

--Gurkan





From: Matthias Wessendorf 
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  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 
> 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!

Re: Congratulations! OpenWebBeans is now a TLP

[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 
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: Integration of JSF2 specific API calls

[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 

> 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 
>
>> 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  schrieb am Do, 17.12.2009:
>>
>> > Von: Gurkan Erdogdu 
>> > 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 
>> >
>> > > > 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 
>> > schrieb am Do, 17.12.2009:
>> > >
>> > > > Von: Gurkan Erd

Re: Integration of JSF2 specific API calls

[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 

> 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  schrieb am Do, 17.12.2009:
>
> > Von: Gurkan Erdogdu 
> > 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 
> >
> > > > 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 
> > schrieb am Do, 17.12.2009:
> > >
> > > > Von: Gurkan Erdogdu 
> > > > 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 pack

Re: Integration of JSF2 specific API calls

[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 

> > 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  schrieb am Do, 17.12.2009:
>
> > Von: Gurkan Erdogdu 
> > 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 
> >
> > > 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 
> > schrieb am Do,
> > > 17.12.2009:
> > >
> > > > Von: Sven Linstaedt 
> > > > 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 fun

Re: Integration of JSF2 specific API calls

[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 

> 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  schrieb am Do,
> 17.12.2009:
>
> > Von: Sven Linstaedt 
> > 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

[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 

> 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: svn commit: r889852 - in /incubator/openwebbeans/trunk: pom.xml webbeans-ejb/ webbeans-impl/src/main/java/org/apache/webbeans/container/Boot.java webbeans-openejb/

[Gurkan Erdogdu]

Hi Eric;

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

Thanks;

--Gurkan





From: Eric Covener 
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,   wrote:
> Author: gerdogdu
> Date: Fri Dec 11 23:11:53 2009
> New Revision: 889852
>
> URL: http://svn.apache.org/viewvc?rev=889852&view=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=889852&r1=889851&r2=889852&view=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: Removing webbeans-api and atinject-api

[Gurkan Erdogdu]

Look at

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

2009/12/15 Mark Struberg 

> 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  schrieb am Di, 15.12.2009:
>
> > Von: Gurkan Erdogdu 
> > 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

Removing webbeans-api and atinject-api

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

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: what about a -M4 release?

[Gurkan Erdogdu]

>>>congratulations from me too.
Thanks a lot Sven.

--Gurkan





From: Sven Linstaedt 
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 

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

Re: what about a -M4 release?

[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:

 
  
   

/OWB/1.0.0-incubating-M4/plugins


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



  apache.openwebbeans.stage
  user name
   
   password
  664
  775


   
   
  apache.incubating
  user name
   
   password
  664
  775


   
  release
  
 
 your passphrase
  
 
apache.openwebbeans.stage::default::scp://people.apache.org/home/your
 user name/public_html/staging-repo/${siteId} 
  


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
 
   ..
  /OWB/1.0.0-incubating-M4/distribution


>> 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 
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  schrieb am Mo, 14.12.2009:

> Von: Gurkan Erdogdu 
> 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 
> 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!

__
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?

[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 
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!

[GRADUATE] Resolution to the Board

[Gurkan Erdogdu]

Hi Kevan;

Graduation as TLP VOTE has been approved by the IPMC that I have stated in 
gene...@...:)

I think that next step is to submit resolution to the board. Could you send 
Resolution Text to the board? 

Thanks;

--Gurkan



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

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

[Gurkan Erdogdu]

>
> true, I think we should really go and rename webbeans-geronimo to
> webbeans-openejb.
>

Not that way. The way is to

1*  rename webbeans-ejb to webbeans-openejb
2*  move codes from webbeans-geronimo into  webbeans-openejb
3*  remove webbeans-geronimo folder.

2009/12/11 Mark Struberg 

> true, I think we should really go and rename webbeans-geronimo to
> webbeans-openejb.
>
> In fact there is a 4th layer: the integration via bundles of 3) for the
> default packages of various containers (all with preconfigured
> openwebbeans.properties):
>
> just a few ideas
> bundles/geronimo (MyFaces + OpenEJB + OpenJPA ...)
> bundles/web_se (MyFaces + OpenJPA)
> bundles/web_wicket(wicket + OpenJPA)
> bundles/standalone
>
> LieGrue,
> strub
>
> --- Gurkan Erdogdu  schrieb am Fr, 11.12.2009:
>
> > Von: Gurkan Erdogdu 
> > Betreff: Re: [jira] Resolved: (OWB-188) remove webbeans-jpa and cleanup
>  webbeans-resource
> > An: openwebbeans-dev@incubator.apache.org
> > Datum: Freitag, 11. Dezember 2009, 12:30
> > 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 
> >
> > > > 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 
> > schrieb am Fr, 11.12.2009:
> > >
> > > > Von: Gurkan Erdogdu 
> > > > 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) 
> > > >
> > > > >
> > > > > [
> > > > >
> > >
> https://issues.apache.org/jira/browse/OWB-188?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
> > > ]
> > > > >
> > > > > Mark Struberg resolved OWB-188.
> > > > > --

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

[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 

> 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 
>
> > 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  schrieb am Fr, 11.12.2009:
>>
>> > Von: Gurkan Erdogdu 
>> > 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) 
>> >
>> > >
>> > > [
>> > >
>> 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
>



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

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

[Gurkan Erdogdu]

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 

> > 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  schrieb am Fr, 11.12.2009:
>
> > Von: Gurkan Erdogdu 
> > 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) 
> >
> > >
> > > [
> > >
> 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: [jira] Resolved: (OWB-188) remove webbeans-jpa and cleanup webbeans-resource

[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) 

>
> [
> 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: webbeans-jpa vs webbeans-resource

[Gurkan Erdogdu]

yeap. webbeans-jpa is no more usage!


2009/12/11 Mark Struberg 

> 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] Created: (OWB-185) Managed beans with non-default constructors lead to InstantiationException when creating the proxy

[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) 

> 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

About JSR-299 and JSR-330 API

[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: JSR-330

[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 

> 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

December Report

[Gurkan Erdogdu]

Hi folks;

I have written our December Report
http://wiki.apache.org/incubator/December2009.

Today is the last day for sending reports.

Thanks;

--Gurkan

[RESULT]Re: [VOTE] Graduation as TLP

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

[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 

> 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: Apache Web Profile Edition of the Java EE 6 standard ?

[Gurkan Erdogdu]

Yeah, that will be awesome.

--Gurkan

2009/12/2 Matthias Wessendorf 

> FYI
>
> http://markmail.org/message/kbnb2imqdohkra7f
>
> -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

[VOTE] Graduation as TLP

[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: Documentation: first draft

[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 

> 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 
>
> > 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 
> >
> > > 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 
> > >
> > > > 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 
> > > >
> > > > > Sorry for the spam
> > > > > it should work better with my gmail.
> > > > >
> > > > > Jean-Louis
> > > > >
> > > > > 2009/12/1 Monteiro Jean-Louis 
> > > > >
> > > > >
> > > > >>
> > > > >>
> > > > >>
> > > > >> *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

Re: Documentation: first draft

[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 

> 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 
>
> > 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 
> >
> > > Sorry for the spam
> > > it should work better with my gmail.
> > >
> > > Jean-Louis
> > >
> > > 2009/12/1 Monteiro Jean-Louis 
> > >
> > >
> > >>
> > >>
> > >>
> > >> *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

[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 

> Sorry for the spam
> it should work better with my gmail.
>
> Jean-Louis
>
> 2009/12/1 Monteiro Jean-Louis 
>
>
>>
>>
>>
>> *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

[Gurkan Erdogdu]

Hi Jean-Louis;

Do you forget to attach first draft ?

Thanks;

--Gurkan

2009/12/1 Monteiro Jean-Louis 

>  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: tons of skipped TCK tests

[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 

> > >>>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  schrieb am Di, 1.12.2009:
>
> > Von: Gurkan Erdogdu 
> > 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 
> > 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 
> > schrieb am Mo, 30.11.2009:
> >
> > > Von: Gurkan Erdogdu 
> > > 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 
> >

Re: tons of skipped TCK tests

[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 
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  schrieb am Mo, 30.11.2009:

> Von: Gurkan Erdogdu 
> 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 
> 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: [jira] Created: (OWB-182) Even if @PreDestroy is used in an Interceptor, it doesn't need an InvoicationContext parameter

[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) 
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

[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 
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: Documentation

[Gurkan Erdogdu]

Awesome!

Thanks a lot;

--Gurkan

2009/11/25 Monteiro Jean-Louis 

> 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

[Gurkan Erdogdu]

Actually this is not the correct mail topic to discuss such things. Please
always start a new mail thread like this type of questions.

Anyway, documentation is a little bit distributed over some places.

1*  after you check out all sources, go to the directory "webbeans-doc" and
run following command :
 >>mvn package
After that you will see a documentation in target/docbox/pdf. It is under
development but currently it contains a little useful startup information.
This project will be our main documentation place.
2* "Released Versions" readme files in "readme" folder.
3* Look at our wiki altough some of its part may be outdated.
http://cwiki.apache.org/OWB/

If you would like to help on documentation project(writing doc-book content
about OpenWebBeans), that is always welcome!

Thanks;

--Gurkan

2009/11/25 Chris Shayan 

> Hey,
> I check out the sources, but is there any documentation about what is each
> module for.
>
> On Wed, Nov 25, 2009 at 5:23 AM, Gurkan Erdogdu  >wrote:
>
> > 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 
> > 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
> >
> >
> >
> >
> >
>
>
>
> --
> Sincerely Yours,
> Chris Shayan
> Life creates questions. Together our world can write the answers.
> -- Josh
> www.ChrisShayan.com
>



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

Re: [DISCUSSION] Draft Resolution Document

[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 
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: RE : RE : Documentation Project

[Gurkan Erdogdu]

Awesome! Thanks a lot!


--Gurkan




From: Monteiro Jean-Louis 
To: "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 

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


  

Re: [DISCUSSION] Draft Resolution Document

[Gurkan Erdogdu]

Hi Joe;

>>>1) In most examples the apache e-mail addresses of the PMC were provided
>>>>beside the names.
I will add emails if we agree on this draft.

>>>>2) Several of them provided a resol
We can add it if everybody is ok

--Gurkan





From: Joseph Bergmark 
To: openwebbeans-dev@incubator.apache.org
Sent: Mon, November 23, 2009 6:04:40 PM
Subject: Re: [DISCUSSION] Draft Resolution Document

This looks very good to me.  Two things I noticed when comparing it to some
of the other examples:

1) In most examples the apache e-mail addresses of the PMC were provided
beside the names.

2) Several of them provided a resolved paragraph that detailed the goals of
the project, similar to the text at the end of the WHEREAS paragraph.
Something along the lines of:

   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

Sincerely,

Joe

On Sun, Nov 22, 2009 at 1:04 PM, Gurkan Erdogdu wrote:

> Hi folks;
>
> Below is the draft resolution document for Apache Board?
>
> WDYT?
>
> All comments are lovely welcome!
>
> --Gurkan
>
> ---
> 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 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
> * Kevan Miller
> * Mark Struberg
> * Joe Bergmark
> * Eric Covener
> * David Blevins
>
> 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: Review of WebBeansPhaseListener

[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 

> Imho it should.
>
> And it must also work for AJAX requests and partial submits.
>
> LieGrue,
> strub
>
> --- Gurkan Erdogdu  schrieb am Mo, 23.11.2009:
>
> > Von: Gurkan Erdogdu 
> > 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 
> >
> > > 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 
> > >
> > > > 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 
> > > > 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 ThreadLocal
> > fromRedirect = new
> > > > ThreadLocal()
> > > > {
> > > >  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

[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 

> Imho it should.
>
> And it must also work for AJAX requests and partial submits.
>
> LieGrue,
> strub
>
> --- Gurkan Erdogdu  schrieb am Mo, 23.11.2009:
>
> > Von: Gurkan Erdogdu 
> > 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 
> >
> > > 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 
> > >
> > > > 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 
> > > > 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 ThreadLocal
> > fromRedirect = new
> > > > ThreadLocal()
> > > > {
> > > >  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

[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 

> 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 
>
> > 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 
> > 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 ThreadLocal fromRedirect = new
> > ThreadLocal()
> > {
> >  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

Re: RE : Documentation Project

[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 

> 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

[DISCUSSION] Draft Resolution Document

[Gurkan Erdogdu]

Hi folks;

Below is the draft resolution document for Apache Board?

WDYT?

All comments are lovely welcome!

--Gurkan
---
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 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 
* Kevan Miller 
* Mark Struberg 
* Joe Bergmark 
* Eric Covener
* David Blevins

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: Inheritance of class local interception and lifecyle invocation?

[Gurkan Erdogdu]

Hi;

Check it again, it must work now. Those interceptors are configured in the 
EJBInterceptorConfig class.

Thanks;

--Gurkan





From: Sven Linstaedt 
To: openwebbeans-dev@incubator.apache.org
Sent: Sat, November 21, 2009 5:24:10 PM
Subject: Re: Inheritance of class local interception and lifecyle invocation?

According to the EJB 3.0 specs, there is and hierarchical model classlocal,
methodlocal and global interception, which takes inheritance on all this
levels into account. Unfortunately in JSR 299 it is not exactly stated,
wether there can be multiple lifecycle/interception methods due to
inheritance.

In 4.2 injection of inherated fields is required. In the next sentence the
same phrases are used for @PostConstruct/@PreDestroy lifecycle methods, so
IMHO inheritance must be taken into account for them too.

wdyt?

br, Sven



2009/11/20 Sven Linstaedt 

> As far as I remember, exactly this is stated in 4.2. I am about of
> finishing work for today, but I will have a look at the spec later this
> evening.
>
> br, Sven
>
>
>
> 2009/11/20 Mark Struberg 
>
> gnah sorry forget it, I misread the example Sven gave us :/
>>
>> the CreationalContext is for
>>
>> class A {
>>  @inject B b;
>> }
>>
>> class B {
>>  @inject A a
>> }
>>
>>
>> but your sample is a derivation problem.
>> Have to look at it, but as far as I remember most EE containers, for an
>> instance of B only initB() must be called. It's up to initB() to
>> subsequently call initA() itself (initA() must not be called at all for B
>> instances).
>>
>> LieGrue,
>> strub
>>
>> --- Mark Struberg  schrieb am Fr, 20.11.2009:
>>
>> > Von: Mark Struberg 
>> > Betreff: Re: Inheritance of class local interception and lifecyle
>> invocation?
>> > An: openwebbeans-dev@incubator.apache.org
>> > Datum: Freitag, 20. November 2009, 18:24
>> > Hi folks!
>> >
>> > This should be working. At least that was exactly the
>> > reason why we have a 'CreationalContext' in our interfaces
>> > ;) It's only purpose is to make cyclic bean references
>> > work.
>> >
>> > LieGrue,
>> > strub
>> >
>> > --- Eric Covener 
>> > schrieb am Fr, 20.11.2009:
>> >
>> > > Von: Eric Covener 
>> > > Betreff: Re: Inheritance of class local interception
>> > and lifecyle invocation?
>> > > An: openwebbeans-dev@incubator.apache.org
>> > > Datum: Freitag, 20. November 2009, 17:32
>> > > On Fri, Nov 20, 2009 at 11:15 AM,
>> > > Sven Linstaedt
>> > > 
>> > > wrote:
>> > > > Hi,
>> > > >
>> > > > has someone tested the correct order of class
>> > local
>> > > interception and
>> > > > lifecycle invocation in the case of inherited
>> > beans,
>> > > like it is specified in
>> > > > 4.2.?
>> > > >
>> > > > Like:
>> > > >
>> > > > class A {
>> > > > @PostConstruct
>> > > > void initA() {}
>> > > > }
>> > > >
>> > > > class B extends A {
>> > > > @PostConstruct
>> > > > void initB() {}
>> > > > }
>> > >
>> > > Haven't here, but would be interested in your
>> > findings.
>> > >
>> > > I believe even basic interceptor ordering via
>> > beans.xml is
>> > > currently
>> > > non-deterministic so cross your fingers!
>> > >
>> > > --
>> > > Eric Covener
>> > > cove...@gmail.com
>> > >
>> >
>> > __
>> > 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
>>
>
>



  

[IMPORTANT]Writing Tests

[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


  

Documentation Project

[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

[Gurkan Erdogdu]

could you look at OpenWebBeansTestLifecycle in test package?




From: Sven Linstaedt 
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) 

>
>[
> https://issues.apache.org/jira/browse/OWB-174?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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.
>
>



  

[jira] Closed: (OWB-175) SingletonContext not available in in multithreaded SE environments, which use the StandaloneLifeCycle

[Gurkan Erdogdu (JIRA)]

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

Gurkan Erdogdu closed OWB-175.
--

   Resolution: Fixed
Fix Version/s: M4

> SingletonContext not available in in multithreaded SE environments, which use 
> the StandaloneLifeCycle
> -
>
> Key: OWB-175
> URL: https://issues.apache.org/jira/browse/OWB-175
> Project: OpenWebBeans
>  Issue Type: Bug
>Reporter: Sven Linstaedt
>    Assignee: Gurkan Erdogdu
> Fix For: M4
>
>
> Due to missing reinitialization of ThreadLocals.

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

[jira] Closed: (OWB-173) Singleton context is not set as ThreadLocal on every request

[Gurkan Erdogdu (JIRA)]

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

Gurkan Erdogdu closed OWB-173.
--

   Resolution: Fixed
Fix Version/s: M4

Actually JSR-299 does not define how to use Singleton scoped because it is not 
defined as Normal scoped type. But I have updated implementation that each 
servlet context owns its singleton context as you indicated.

> Singleton context is not set as ThreadLocal on every request
> 
>
> Key: OWB-173
> URL: https://issues.apache.org/jira/browse/OWB-173
> Project: OpenWebBeans
>  Issue Type: Bug
>Reporter: Sven Linstaedt
>        Assignee: Gurkan Erdogdu
> Fix For: M4
>
>
> THe Singleton context exists similar to the ApplicationContext as a 
> ThreadLocal. But unlike the last, it is not set on the ThreadLocal on every 
> request, resulting in Singleton beans not being available.
> Solution:
> reinitialize singleton context like it is done with the application context 
> in ContextFactory.initRequestContext():112

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

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

[Gurkan Erdogdu (JIRA)]

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

Gurkan Erdogdu closed OWB-174.
--

   Resolution: Won't Fix
Fix Version/s: M4

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

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

[Gurkan Erdogdu (JIRA)]

[ 
https://issues.apache.org/jira/browse/OWB-174?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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.

Re: Time to move atinject-api over to geronimo?

[Gurkan Erdogdu]

+1.

How could we integrate this into geronimo-specs?

Kevan, David?

Thanks;

--Gurkan

2009/11/20 Mark Struberg 

> Hi!
>
> I think our atinject-api is pretty stable now.
>
> Wdyt about adding a bit more documentation and finally moving it over to
> geronimo-specs?
>
> 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