from:"Mark Struberg"


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

Mark Struberg resolved OWB-191.
---

Resolution: Fixed

i18n bundle moved from
* META-INF/Messages_en.properties 
to
* openwebbeans/Messages.properties

to ensure 2 things
1.) the Messages also get picked up if  the langage is not 'en' e.g for a 
Locale='de_AT'
2.) the resource doesn't interfere with other Messages.properties files this way

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

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

 Attachments: ResourceBundlePort.patch


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

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

[jira] Created: (OWB-202) move all JSF specific code from webbeans-impl to webbeans-jsf and upgrade to JSF-2

move all JSF specific code from webbeans-impl to webbeans-jsf and upgrade to 
JSF-2
--

 Key: OWB-202
 URL: https://issues.apache.org/jira/browse/OWB-202
 Project: OpenWebBeans
  Issue Type: Improvement
Affects Versions: M3
Reporter: Mark Struberg
Assignee: Mark Struberg
 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-202) upgrade webbeans-jsf to JSF-2


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

Mark Struberg updated OWB-202:
--

Component/s: Context and Scopes
Description: 
*edit* saw that webbeans-impl already has been cleaned up!

Summary: upgrade webbeans-jsf to JSF-2  (was: move all JSF specific 
code from webbeans-impl to webbeans-jsf and upgrade to JSF-2)

 upgrade webbeans-jsf to JSF-2
 -

 Key: OWB-202
 URL: https://issues.apache.org/jira/browse/OWB-202
 Project: OpenWebBeans
  Issue Type: Improvement
  Components: Context and Scopes
Affects Versions: M3
Reporter: Mark Struberg
Assignee: Mark Struberg
 Fix For: M4


 *edit* saw that webbeans-impl already has been cleaned up!

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

[jira] Resolved: (OWB-190) Make the TestLifeCycles available in webbeans-impl


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

Mark Struberg resolved OWB-190.
---

Resolution: Fixed

Moved the TestLifeCycle to a visible package.

A unittest in a project using OpenWebBeans could be using

META-INF/openwebbeans/openwebbeans.properties:
{noformat}
# the service section:
# The key is the Interface, the value the implementation of the service

# use the static HashMap instead of storing objects in JNDI as default  
org.apache.webbeans.spi.JNDIService=org.apache.webbeans.spi.se.JNDIServiceStaticImpl

# lookup the javax.transaction.TransactionManager via JNDI as default 
org.apache.webbeans.spi.TransactionService=org.apache.webbeans.spi.se.TransactionServiceNonJTA

#use the web metadata as default
org.apache.webbeans.spi.deployer.MetaDataDiscoveryService=org.apache.webbeans.spi.se.deployer.MetaDataDiscoveryStandard

#Lifecycle to start container
org.apache.webbeans.spi.Lifecycle=org.apache.webbeans.lifecycle.test.EnterpriseTestLifeCycle
{noformat}


And utilise it from the unit tests by using the following class to bootstrap 
OWB in a @BeforeClass or similar:
{noformat}
import java.util.Set;

import javax.enterprise.inject.spi.Bean;
import javax.enterprise.inject.spi.BeanManager;

import org.apache.webbeans.lifecycle.LifecycleFactory;
import org.apache.webbeans.spi.Lifecycle;
import org.testng.Assert;

public class ContainerStarter {

private Lifecycle lifecycle = null;

public  void boot(Object startupObject) throws Exception {
lifecycle = LifecycleFactory.getInstance().getLifecycle();
lifecycle.applicationStarted(startupObject);
}

public void shutdown(Object endObject) throws Exception {
lifecycle = LifecycleFactory.getInstance().getLifecycle();
if (lifecycle != null) {
lifecycle.applicationEnded(endObject);
}
}

public  BeanManager getBeanManager() {
return lifecycle.getBeanManager();
}

public T T getInstance(ClassT clazz) {
SetBean? beans = getBeanManager().getBeans(clazz);
Assert.assertNotNull(beans, cannot find beans for class  + 
clazz.getCanonicalName());
Assert.assertTrue(!beans.isEmpty(), cannot find beans for class  + 
clazz.getCanonicalName());

@SuppressWarnings(unchecked)
BeanT bean = (BeanT)beans.iterator().next();

@SuppressWarnings(unchecked)
T instance = (T) getBeanManager().getReference(bean, clazz, 
getBeanManager().createCreationalContext(bean));
return instance;
}

}
{noformat}

 Make the TestLifeCycles available in webbeans-impl
 --

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


 Currently the OpenWebBeansTestLifecycle is only available internally for the 
 tests and via the tests.jar.
 This is not usable for running automated function tests in projects which use 
 OWB.
 I'd like to move over the OpenWebBeansTestLifeCycle (where one has to 
 manually select all classes which should get scanned) to a new lifecycle.test 
 package and also add a new EnterpriseTestLifeCycle which scanns all classes 
 on the classpaths according to the spec.

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

[jira] Resolved: (OWB-203) Improve logging of webbeans-resource if a PersistenceUnit cannot be found


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

Mark Struberg resolved OWB-203.
---

Resolution: Fixed

 Improve logging of webbeans-resource if a PersistenceUnit cannot be found
 -

 Key: OWB-203
 URL: https://issues.apache.org/jira/browse/OWB-203
 Project: OpenWebBeans
  Issue Type: Improvement
  Components: Java EE Integration
Affects Versions: M3
Reporter: Mark Struberg
Assignee: Mark Struberg
 Fix For: M4


 currently if someone tries to inject a @PersistenceUnit(myUnitName) we 
 inject null without logging something.
 We shall log at least a INFO in this case!

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

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

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

Mark Struberg commented on OWB-171:
---

sven, can you please merge again and attach the patch?
I have problems with applying the WebBeansPhaseListener :(
you can also join us in IRC tomorrow and then we can do it together.

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

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

[jira] Resolved: (OWB-176) InterceptionType.AROUND_TIMEOUT is missing

2009-12-18 Thread Mark Struberg (JIRA)


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

Mark Struberg resolved OWB-176.
---

Resolution: Fixed

 InterceptionType.AROUND_TIMEOUT is missing
 --

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


 AROUND_TIMEOUT must be added

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

[jira] Resolved: (OWB-144) upgrade OWB TCK from webbeans to weld

2009-12-18 Thread Mark Struberg (JIRA)


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

Mark Struberg resolved OWB-144.
---

Resolution: Fixed

 upgrade OWB TCK from webbeans to weld
 -

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


 JBoss has renamed the name of JSR-299 from WebBeans to weld. Thus we have to 
 reflect the changes we need for the TCK in our webbeans-tck module.

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

Re: Integration of JSF2 specific API calls

2009-12-17 Thread 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 cgurkanerdo...@gmail.com schrieb am Do, 17.12.2009:

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

Re: Integration of JSF2 specific API calls

2009-12-17 Thread 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 cgurkanerdo...@gmail.com schrieb am Do, 17.12.2009:

 Von: Gurkan Erdogdu cgurkanerdo...@gmail.com
 Betreff: Re: Integration of JSF2 specific API calls
 An: openwebbeans-dev@incubator.apache.org
 Datum: Donnerstag, 17. Dezember 2009, 10:49
 I think we will start
 hacking on the feature and if we hit the point of
 no return we should create an own module.
 We could definitely create a new package for unique JSF2
 features if we will
 have under webbeans-jsf project. So management and
 configuration are much
 more easy with having one JSF module.
 
 
 2009/12/17 Gurkan Erdogdu cgurkanerdo...@gmail.com
 
  What I mean is that,
 
  Our code base has nothing regarding to JSF 1.2 like
 other JSF
  Frameworks/Tools etc. do.
 
  We have just implemented 2 class for conversation
 service
 
  1* WebBeansPhase Listener -- For restore
 conversations
  2* Custom View Handler   
    -- For adding cid to view handler
 
  Both of them work on any JSF1.2 or JSF2
 implementation.
 
  Therefore it is not rational to define new jsf2
 project from my point of
  view. If we were implementing lots of code unique to
 JSF 1.2 then it will be
  reasonable to define new JSF2 project but we did not.
 Actually it is
  meaningless for me to separate JSF 1.2 and JSF 2.
 
  We must not think of such a backward compatibility
 with JSF 1.2 etc because
  we have been implementing Java EE 6 defined JSR-299
 specification.
 
 
  --Gurkan
 
  2009/12/17 Mark Struberg strub...@yahoo.de
 
  Gurkan,
 
  I was not talking about special products, I also
 meant the API and I
  mentioned RichFaces-3.3.2 only as an example. You
 can google for the
  incompatibility problems.
 
  Matter of fact:
  .) EE6 WebProfile defines JSF-2, so from this
 point I'm with you
 
  But:
  .) there is no full stack for JSF-2 on the market
 currently (the component
  libraries are missing, since they are mostly
 incompatible)
  Plus, there will be lot old projects which still
 use JSF-1.2 but may like
  to use OWB for new extensions.
 
  and as such:
  .) providing an easy migration path to EE6 by
 allowing to use JSF-1.2 +
  OWB would imho be a pretty nice goodie.
 
  I don't think it will confuse users if they have a
 choice between a
  JSF-1.2 and a JSF-2 plugin if we explain the
 differences in the
  documentation.
  I think we will start hacking on the feature and
 if we hit the point of no
  return we should create an own module.
 
 
  wdyt?
 
  LieGrue,
  strub
 
  --- Gurkan Erdogdu cgurkanerdo...@gmail.com
 schrieb am Do, 17.12.2009:
 
   Von: Gurkan Erdogdu cgurkanerdo...@gmail.com
   Betreff: Re: Integration of JSF2 specific API
 calls
   An: openwebbeans-dev@incubator.apache.org
   Datum: Donnerstag, 17. Dezember 2009, 10:03
   Hey Mark,
  
   E.g. try running RichFaces-3.3.2 on a
 JSF-2
   container ;)
   Java EE standards do not depend on any
 special product!
   Standards talk about
   API.
  
   In JSF-1.2 there was no standardised
 ajax handling,
   so we would have no
   chance to use those features in a portable
 fashion.
   JSR-299 is contained in Java EE 6. Java EE 6
 defines JSF2
   and when we talk
   about JSF functionality, it means JSF2 not
 JSF1.2 or
   earlier.
   We wrote a little JSF code for conversations
 and at that
   time there was no
   offical MyFaces JSF2 API to use. Now there is
 one and we
   will update our pom
   to use MyFaces JSF2 and we will go ahead with
 it. In fact,
   our codes in
   webbeans-jsf must work within JSF2. Moreover,
 JSF2 is
   compatible with JSF1.2
   as written in Java EE 6 specification.
  
   So all functionality must go into package
 webbeans-jsf.
   There is no need to
   create extra project modules that confuses
 developers
   minds.
  
   Thnks;
  
   --Gurkan
  
   2009/12/17 Mark Struberg strub...@yahoo.de
  
 JSF2 is backward compatible
   
Not when it comes to the details!
E.g. try running RichFaces-3.3.2 on a
 JSF-2 container
   ;)
   
There have been a few changes which
 allows us to
   create better support for
JSF2, mostly in the AJAX area. In
 JSF-1.2 there was no
   standardised ajax
handling, so we would have no chance to
 use those
   features in a portable
fashion.
   
LieGrue,
strub
   
--- Gurkan Erdogdu cgurkanerdo...@gmail.com
   schrieb am Do, 17.12.2009:
   
 Von: Gurkan Erdogdu cgurkanerdo...@gmail.com
 Betreff: Re: Integration of JSF2
 specific API
   calls
 An: openwebbeans-dev@incubator.apache.org
 Datum: Donnerstag, 17. Dezember
 2009, 9:50
 Id favour a
 webbeans-jsf2, I think that's more
 future proof.
 I think that there is no need to
 define extra
   jsf
 module/project. There is
 no such a thing that You could use
 it in JSF
   1.2  but
 not JSF2 or vice
 versa

Congratulations! OpenWebBeans is now a TLP

2009-12-17 Thread Mark Struberg

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

[jira] Created: (OWB-190) Make the TestLifeCycles available in webbeans-impl

2009-12-15 Thread Mark Struberg (JIRA)

Make the TestLifeCycles available in webbeans-impl
--

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


Currently the OpenWebBeansTestLifecycle is only available internally for the 
tests and via the tests.jar.

This is not usable for running automated function tests in projects which use 
OWB.
I'd like to move over the OpenWebBeansTestLifeCycle (where one has to manually 
select all classes which should get scanned) to a new lifecycle.test package 
and also add a new EnterpriseTestLifeCycle which scanns all classes on the 
classpaths according to the spec.

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

AW: Removing webbeans-api and atinject-api

2009-12-14 Thread 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 cgurkanerdo...@gmail.com schrieb am Di, 15.12.2009:

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

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

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

2009-12-11 Thread 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 cgurkanerdo...@gmail.com schrieb am Fr, 11.12.2009:

 Von: Gurkan Erdogdu cgurkanerdo...@gmail.com
 Betreff: Re: [jira] Resolved: (OWB-188) remove webbeans-jpa and cleanup  
 webbeans-resource
 An: openwebbeans-dev@incubator.apache.org
 Datum: Freitag, 11. Dezember 2009, 10:51
 Awesome thanks! Good idea to throw
 out trashed code.
 
 We sure that all examples still work :)
 
 --Gurkan
 
 2009/12/11 Mark Struberg (JIRA) j...@apache.org
 
 
      [
  https://issues.apache.org/jira/browse/OWB-188?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel]
 
  Mark Struberg resolved OWB-188.
  ---
 
     Resolution: Fixed
 
   remove webbeans-jpa and cleanup
 webbeans-resource
  
 -
  
               
    Key: OWB-188
               
    URL: https://issues.apache.org/jira/browse/OWB-188
           
    Project: OpenWebBeans
            Issue Type:
 Improvement
      Affects Versions: M3
             
 Reporter: Mark Struberg
             
 Assignee: Mark Struberg
           
    Fix For: M4
  
  
   Most of the code from webbeans-jpa has been
 dupped over to
  webbeans-resource. The whole plugin is now essentially
 obsolete and shall be
  removed.
   We also have to cleanup webbeans-resource and
 webbeans-geronimo and
  remove unused code.
 
  --
  This message is automatically generated by JIRA.
  -
  You can reply to this email to add a comment to the
 issue online.
 
 
 
 
 -- 
 Gurkan Erdogdu
 http://gurkanerdogdu.blogspot.com
 

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

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

2009-12-11 Thread 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 cgurkanerdo...@gmail.com schrieb am Fr, 11.12.2009:

 Von: Gurkan Erdogdu cgurkanerdo...@gmail.com
 Betreff: Re: [jira] Resolved: (OWB-188) remove webbeans-jpa and cleanup  
 webbeans-resource
 An: openwebbeans-dev@incubator.apache.org
 Datum: Freitag, 11. Dezember 2009, 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 strub...@yahoo.de
 
   We sure that all examples still work :)
  Heh, I hope so, I at least tried out samples/guess and
 samples/reservation
  before checking in ;)
 
  I hope I can sum up the magic behind this (maybe even
 in the new xdoc) this
  weekend.
 
  In general it seems like we have a 3-staged mechanism
 (even if this is not
  so visible from the first glance)
 
  1st layer:
  webbeans-core
 
  2nd layer:
  the general plugin on a specific specification area
 (e.g. JMS, JPA, EJB)
 
  3rd layer:
  the 2) bound to a specific product or technique: e.g.
 the JPA
  Implementation for SE (provided originally with
 webbeans-jpa, now moved over
  to webbeans-resource) will give you a
 @PersistenceContext EntityManager with
  PersitenceType.EXTENDED whereas if you switch over to
 the SPI Implementation
  from webbeans-geronimo you will get a TRANSACTIONAL
 PersistenceContext
  (which we get from OpenEJB + it's JTA layer).
  It's really important to know these differences and to
 understand the
  fundamentally different way those 2 EntityManagers
 work internally. But I
  think David or the other geronimo and OpenEJB folks
 here can explain this
  much better than I can, so I'll focus on the OWB
 part.
 
  LieGrue,
  strub
 
 
  --- Gurkan Erdogdu cgurkanerdo...@gmail.com
 schrieb am Fr, 11.12.2009:
 
   Von: Gurkan Erdogdu cgurkanerdo...@gmail.com
   Betreff: Re: [jira] Resolved: (OWB-188) remove
 webbeans-jpa and cleanup
   webbeans-resource
   An: openwebbeans-dev@incubator.apache.org
   Datum: Freitag, 11. Dezember 2009, 10:51
   Awesome thanks! Good idea to throw
   out trashed code.
  
   We sure that all examples still work :)
  
   --Gurkan
  
   2009/12/11 Mark Struberg (JIRA) j...@apache.org
  
   
        [
   
  https://issues.apache.org/jira/browse/OWB-188?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
  ]
   
Mark Struberg resolved OWB-188.
---
   
       Resolution: Fixed
   
 remove webbeans-jpa and cleanup
   webbeans-resource

  
 -


      Key: OWB-188

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

      Project: OpenWebBeans
          Issue
 Type:
   Improvement
    Affects Versions: M3

   Reporter: Mark Struberg

   Assignee: Mark Struberg

      Fix For: M4


 Most of the code from webbeans-jpa has
 been
   dupped over to
webbeans-resource. The whole plugin is now
 essentially
   obsolete and shall be
removed.
 We also have to cleanup
 webbeans-resource and
   webbeans-geronimo and
remove unused code.
   
--
This message is automatically generated by
 JIRA.
-
You can reply to this email to add a comment
 to the
   issue online.
   
   
  
  
   --
   Gurkan Erdogdu
   http://gurkanerdogdu.blogspot.com
  
 
  __
  Do You Yahoo!?
  Sie sind Spam leid? Yahoo! Mail verfügt über einen
 herausragenden Schutz
  gegen Massenmails.
  http://mail.yahoo.com
 
 
 
 
 -- 
 Gurkan Erdogdu
 http://gurkanerdogdu.blogspot.com
 

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

Upgrade to JPA2?

2009-12-10 Thread Mark Struberg

Hi!

I'm currently preparing the upgrade to JPA-2 since this is the version which is 
defined in the EE6 Web profile.

I write this mail because there is a bit of confusion about the spec versions. 
JPA1 was part of EJB3 and thus the artifact was called geronimo-jpa_3.0_spec. 
So the '3.0' meant EJB-3.0!

Now, JPA became an own JSR and geronimo folks decided to name it 
geronimo-jpa_2.0_spec. Here the '2.0' means JPA-2.0! 
The current version is 1.0-PFD2.

So geronimo-jpa_2.0_spec is NEWER than geronimo-jpa_3.0_spec :)
I was also a bit confused, but Michael Dick told me that my assumptions were 
right.

I will also upgrade all out tests to OpenJPA-2.0.0-M3 which got released a 
short time ago.


LieGrue,
strub

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

[jira] Created: (OWB-186) Upgrade OWB to the JPA-2 spec

2009-12-10 Thread Mark Struberg (JIRA)

Upgrade OWB to the JPA-2 spec
-

 Key: OWB-186
 URL: https://issues.apache.org/jira/browse/OWB-186
 Project: OpenWebBeans
  Issue Type: Improvement
  Components: Enterprise Web Beans
Affects Versions: M3
Reporter: Mark Struberg
Assignee: Mark Struberg
 Fix For: M4


The EE6 Web profile defines JPA2 as persistence provider technologie. Thus we 
shall upgrade to the jpa2-api and OpenJPA-2.0.

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

[jira] Resolved: (OWB-186) Upgrade OWB to the JPA-2 spec

2009-12-10 Thread Mark Struberg (JIRA)


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

Mark Struberg resolved OWB-186.
---

Resolution: Fixed

implemented in Revision 889274

 Upgrade OWB to the JPA-2 spec
 -

 Key: OWB-186
 URL: https://issues.apache.org/jira/browse/OWB-186
 Project: OpenWebBeans
  Issue Type: Improvement
  Components: Enterprise Web Beans
Affects Versions: M3
Reporter: Mark Struberg
Assignee: Mark Struberg
 Fix For: M4


 The EE6 Web profile defines JPA2 as persistence provider technologie. Thus we 
 shall upgrade to the jpa2-api and OpenJPA-2.0.

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

webbeans-jpa vs webbeans-resource

2009-12-10 Thread 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

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

2009-12-10 Thread Mark Struberg (JIRA)

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.

Re: December Report

2009-12-09 Thread Mark Struberg

+1, looks fine :)

btw, I hope that the bugs in the TCK get fixed soon ;)

LieGrue,
strub

--- Matthias Wessendorf mat...@apache.org schrieb am Mi, 9.12.2009:

 Von: Matthias Wessendorf mat...@apache.org
 Betreff: Re: December Report
 An: openwebbeans-dev@incubator.apache.org
 Datum: Mittwoch, 9. Dezember 2009, 11:10
 looks good so far...
 
 On Wed, Dec 9, 2009 at 10:35 AM, Gurkan Erdogdu
 cgurkanerdo...@gmail.com
 wrote:
  Hi folks;
 
  I have written our December Report
  http://wiki.apache.org/incubator/December2009.
 
  Today is the last day for sending reports.
 
  Thanks;
 
  --Gurkan
 
 
 
 
 -- 
 Matthias Wessendorf
 
 blog: http://matthiaswessendorf.wordpress.com/
 sessions: http://www.slideshare.net/mwessendorf
 twitter: http://twitter.com/mwessendorf
 

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

Re: About JSR-299 and JSR-330 API

2009-12-09 Thread Mark Struberg

Just 2 make sure we all speak about the same:

We'd like to move over the atinject-api which only contains the annotations of 
JSR-330. (This is similar to commons-annotations)

OpenWebBeans implements processing functionality for those annotations as part 
of the JSR-299 implementation and passes the JSR-330 TCK. There is no separate 
JSR-330-container or something.

So assumed we speak about only the api, then I'm d'accord we should release it 
as 1.0.0

LieGrue,
strub


--- Matthias Wessendorf mat...@apache.org schrieb am Mi, 9.12.2009:

 Von: Matthias Wessendorf mat...@apache.org
 Betreff: Re: About JSR-299 and JSR-330 API
 An: d...@geronimo.apache.org
 CC: openwebbeans-dev@incubator.apache.org
 Datum: Mittwoch, 9. Dezember 2009, 14:16
 IMO would be cool if there is a
 standalone release of that soon.
 As this passed the TCK, we even do not need to say alpha
 or so, on that...
 
 -Matthias
 
 On Wed, Dec 9, 2009 at 12:28 PM, Gurkan Erdogdu
 cgurkanerdo...@gmail.com
 wrote:
  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
 
 
 
 
 -- 
 Matthias Wessendorf
 
 blog: http://matthiaswessendorf.wordpress.com/
 sessions: http://www.slideshare.net/mwessendorf
 twitter: http://twitter.com/mwessendorf
 

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

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


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

Mark Struberg commented on OWB-182:
---

oki, command return ;)

After a long discussion on the JSR-299 list it turns out that CDI will not 
support this 'new oldschool' type of @PreDestroy on Interceptors.
Instead each JSR-299 container must act in an EJB specification compatible way:
@PreDestroy, @PostConstruct et al on an Interceptor must have an 
InvoicationContext parameter as our original implementation did force.

The weld team will fix the corresponding TCK test.

 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.

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


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

Mark Struberg closed OWB-182.
-


 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.

[jira] Reopened: (OWB-127) @Stateful EJBs have to be handled as being passivation capable


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

Mark Struberg reopened OWB-127:
---


WebBeansUtil#checkPassivationScope still fails with a 
WebBeansPassivationException while handling @Stateful session beans.

 @Stateful EJBs have to be handled as being passivation capable
 --

 Key: OWB-127
 URL: https://issues.apache.org/jira/browse/OWB-127
 Project: OpenWebBeans
  Issue Type: Bug
Reporter: Mark Struberg
Assignee: Gurkan Erdogdu
 Fix For: M4


 Currently the container complains about @Stateful session beans do not have 
 the Interface Serializable.
 This check must not be performed for stateful session beans, since they are 
 per se passivation capable.

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

Re: Apache Web Profile Edition of the Java EE 6 standard ?

2009-12-02 Thread Mark Struberg

Txs Matthias!

I just wonder about the @ManagedBean, because I still couldn't find anything in 
the official JSF-2 spec (and also nothing about the JSF scopes! 
Gerhard Petracek pointed me to the Mojarra where this is also implemented, but 
it this 'official' now?

I'd like to implement a JSR-299 extension which basically provides an alias 
between javax.faces.scopes.SessionScoped and 
javax.enterprise.context.SessionScoped and others. As well as a JSR-299 
implementation of the FlashScoped and support for @ManagedBean of course. The 
goal is to be able to disable the whole DI part of MyFaces/Mojarra somehow 
(haven't looked at it) and use OWB instead if it is available.

txs and LieGrue,
strub

--- Gurkan Erdogdu cgurkanerdo...@gmail.com schrieb am Mi, 2.12.2009:

 Von: Gurkan Erdogdu cgurkanerdo...@gmail.com
 Betreff: Re: Apache Web Profile Edition of the Java EE 6 standard ?
 An: openwebbeans-dev@incubator.apache.org
 Datum: Mittwoch, 2. Dezember 2009, 12:29
 Yeah, that will be awesome.
 
 --Gurkan
 
 2009/12/2 Matthias Wessendorf mat...@apache.org
 
  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
 

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

TCK bugfixes

2009-12-02 Thread Mark Struberg

Hi folks!

I have tweaked the JSR-299 TCK and now a bit more tests pass.

I also found (and reported) a few bugs in the TCK, so for now, you should 
checkout the TCK from

http://anonsvn.jboss.org/repos/weld/cdi-tck/trunk

and update the dependencyin openwebbeans-tck to 1.1.0-SNAPSHOT again.

Pete will fix the TCK on the weekend, but for now you need to apply the patch I 
added.

LieGrue,
strub

__
Do You Yahoo!?
Sie sind Spam leid? Yahoo! Mail verfügt über einen herausragenden Schutz gegen 
Massenmails. 
http://mail.yahoo.com Index: impl/src/main/java/org/jboss/jsr299/tck/tests/context/passivating/KokkolaInterceptor.java
===
--- impl/src/main/java/org/jboss/jsr299/tck/tests/context/passivating/KokkolaInterceptor.java	(Revision 5190)
+++ impl/src/main/java/org/jboss/jsr299/tck/tests/context/passivating/KokkolaInterceptor.java	(Arbeitskopie)
@@ -9,7 +9,7 @@
 public class KokkolaInterceptor implements Serializable
 {
@AroundInvoke
-   public Object intercept(InvocationContext context)
+   public Object intercept(InvocationContext context) throws Exception
{
   // do nothing
   return null;
Index: impl/src/main/java/org/jboss/jsr299/tck/tests/context/dependent/TransactionalInterceptor.java
===
--- impl/src/main/java/org/jboss/jsr299/tck/tests/context/dependent/TransactionalInterceptor.java	(Revision 5190)
+++ impl/src/main/java/org/jboss/jsr299/tck/tests/context/dependent/TransactionalInterceptor.java	(Arbeitskopie)
@@ -18,7 +18,7 @@
   return ctx.proceed();
}
 
-   @PreDestroy public void destroy()
+   @PreDestroy public void destroy(InvocationContext ctx)
{
   destroyed = true;
}

[jira] Created: (OWB-184) BeanManager itself needs to be added as managed bean

BeanManager itself needs to be added as managed bean


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


The BeanManager itself needs to be added as manages bean at the time we 
bootstrap the lifecycle.
This needs to be done to be able to @Inject BeanManager bm; which a lot TCK 
tests rely on.

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

[jira] Commented: (OWB-184) BeanManager itself needs to be added as managed bean


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

Mark Struberg commented on OWB-184:
---

after further debugging it turned out that we already deploy the 
BeanManagerBean in
BeansDeployer#configureDefaultBeans()

My problem seems to be a undeploy issue:

{noformat}
ObserverMethodImplT.getMethodArguments(Object) line: 271  
ObserverMethodImplT.notify(T) line: 188   
NotificationManager.fireEvent(Object, Annotation...) line: 239  
BeanManagerImpl.fireEvent(Object, Annotation...) line: 302  
EnterpriseLifeCycle.applicationEnded(Object) line: 218  
StandaloneContainersImpl.undeploy() line: 144   
{noformat}

just a gut feeling:
Bean? bean = InjectionResolver.getInstance().implResolveByType(type, 
bindingTypes).iterator().next(); 
doesn't find the BeanManagerBean anymore, because it seems to be be terminated 
already...



 BeanManager itself needs to be added as managed bean
 

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


 The BeanManager itself needs to be added as manages bean at the time we 
 bootstrap the lifecycle.
 This needs to be done to be able to @Inject BeanManager bm; which a lot TCK 
 tests rely on.

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

RE: Documentation: first draft

2009-12-01 Thread Mark Struberg

it seems that our list drops the attachment.

LieGrue,
strub

--- Monteiro Jean-Louis jean-louis.monte...@atosorigin.com schrieb am Di, 
1.12.2009:

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

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

Re: Documentation: first draft

2009-12-01 Thread Mark Struberg

looks pretty fine!

LieGrue,
strub

--- Jean-Louis MONTEIRO jeano...@gmail.com schrieb am Di, 1.12.2009:

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

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

AW: [VOTE] Graduation as TLP

2009-12-01 Thread Mark Struberg

+1 

LieGrue,
strub

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

 Von: Gurkan Erdogdu gurkanerdo...@yahoo.com
 Betreff: [VOTE] Graduation as TLP
 An: openwebbeans-dev@incubator.apache.org
 Datum: Dienstag, 1. Dezember 2009, 20:13
 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.
 
 
 
       

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

Re: tons of skipped TCK tests

2009-11-30 Thread Mark Struberg

Thanks Gurkan!

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

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

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

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


LieGrue,
strub

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

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

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

Re: tons of skipped TCK tests

2009-11-30 Thread 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 gurkanerdo...@yahoo.com schrieb am Di, 1.12.2009:

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

[jira] Resolved: (OWB-179) PluginLoader need to actually startUp each plugin at load time


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

Mark Struberg resolved OWB-179.
---

Resolution: Fixed

 PluginLoader need to actually startUp each plugin at load time
 --

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


 PluginLoader need to call startUp() on each plugin while starting up

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

[jira] Created: (OWB-180) remove e.printStackTrace() and use proper logging

remove e.printStackTrace() and use proper logging
-

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


Found in BeansDeployer

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

[jira] Created: (OWB-181) TCK requires to create newInstance of hidden constructors

TCK requires to create newInstance of hidden constructors
-

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


The JSR-299 TCK defines a interceptors (e.g. MissileInterceptor) which have 
only package scope.
This means we have to manually set the constructor to be accessible before we 
construct the interceptor.
The same problem might happen in other areas too...

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

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

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


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

Mark Struberg resolved OWB-182.
---

Resolution: Fixed

 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: Review of WebBeansPhaseListener

2009-11-23 Thread Mark Struberg

Imho it should.

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

LieGrue,
strub

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

 Von: Gurkan Erdogdu cgurkanerdo...@gmail.com
 Betreff: Re: Review of WebBeansPhaseListener
 An: openwebbeans-dev@incubator.apache.org
 Datum: Montag, 23. November 2009, 8:04
 Hi Sven;
 
 AFAIK, conversation is defined for using it in pure JSF in
 the
 specification. I do not know whether it supports tag
 handlers or not.
 
 --Gurkan
 
 2009/11/23 Sven Linstaedt sven.linsta...@googlemail.com
 
  I have found a issue, that makes the second point
 necessary to implement:
 
  If one uses a conversation scoped bean in an
 expression, which is evaluated
  during restore view as part of a tag handler (e.g. in
 c:forEach), we need
  the conversation already to be restored, because
 otherwise two
  conversations
  will be in action during one request: one from the
 beginning the request
  till after restore view phase, and another one (the
 right one actually)
  in
  the other phases.
 
  Because before restore view no view and therefore no
 cid is available
  (well,
  sound reasonable ;) our only chance is to retrieve the
 cid from something
  else. The current implementation attaches the cid to
 every form's action
  url
  due to ConversationAwareViewHandler, so we could use
 this information for
  restoring the conversation. Does anybody has
 objections or a better
  solution
  regarding this point in mind?
 
  br, Sven
 
 
 
  2009/11/15 Gurkan Erdogdu gurkanerdo...@yahoo.com
 
   Hi Sven;
  
   Very good points :) I will try to correct those
 issues.
  
   PS: If you would like to patch, you are always
 welcome :)
  
   Thanks again for helping us!
  
   --Gurkan
  
  
  
  
   
   From: Sven Linstaedt sven.linsta...@googlemail.com
   To: openwebbeans-dev@incubator.apache.org
   Sent: Sun, November 15, 2009 4:02:57 PM
   Subject: Review of WebBeansPhaseListener
  
   Hi,
  
   I have some questions about the JSF integration
 of OWB, which come to my
   mind when dealing with the source code:
  
   _ JSF PhaseListener have to be threadsafe (see
 JSF 2.0 spec, chapter
   12.3.),
   but WebBeansPhaseListener references a obvious
 context dependent
   conversation. A quick look at mojarra indicates
 there is a singleton
   instantiated for each PhaseListener, so I supose
  WebBeansPhaseListenerwill
   get into troubles when serving multiple requests.
 - Use a ThreadLocal
   instead?
  
   _ Conversation scoped beans might be accessed
 *during* restore view
  during
   a
   FaceletHandler evaluation. But the
 ConversationContext is restored
  *after*
   restore view. - Are there any limitations or
 drawbacks restoring the
   ConversationContext *before* restore view? Weld
 is also doing this as far
   as
   I remember.
  
   _ Make sure the ViewRoot's initial state is
 marked *before* modifying
  it's
   attributes, because otherwise the stored
 information may be lost.
  
   _ WebBeansPhaseListener.fromRedirect ThreadLocal
 seems not to be resetted
   anywhere. Furthermore the initializer of this
 ThreadLocal is done once
  (?)
   in a static block, and not per created Thread
 using something like
  
   public static ThreadLocalBoolean
 fromRedirect = new
   ThreadLocalBoolean()
   {
    protected Boolean initialValue() {
          return false;
      }
   }
  
   In addition, if this static field is public, it
 should at least be final.
  
  
   br, Sven
  
  
  
  
  
 
 
 
 
 -- 
 Gurkan Erdogdu
 http://gurkanerdogdu.blogspot.com
 

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

[jira] Created: (OWB-177) Handling of InterceptionType#POST_ACTIVATE, PRE_PASSIVATE and AROUND_TIMEOUT is missing

Handling of InterceptionType#POST_ACTIVATE, PRE_PASSIVATE and AROUND_TIMEOUT is 
missing
---

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


those interceptor types allow handling of the new ones defined in EJB-3.1.

Where do we handle them? 
This turns out to be a very basic decision whether to pull in the EE api or not.

If we handle them in the in openwebbeans-geronimo or openwebbeans-ejb only, 
then we'd loose this functionality if we are running in e.g. a pure 
ServletContainer. But although it's defined in the EJB spec, I personally think 
this functionality might be interesting for SE applications too.

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

[jira] Assigned: (OWB-178) update Bean interface to fit the latest spec


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

Mark Struberg reassigned OWB-178:
-

Assignee: Mark Struberg  (was: Gurkan Erdogdu)

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

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: Gurkan Erdogdu
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] Resolved: (OWB-154) remove Bean#getDeploymentType()


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

Mark Struberg resolved OWB-154.
---

Resolution: Fixed

 remove Bean#getDeploymentType()
 ---

 Key: OWB-154
 URL: https://issues.apache.org/jira/browse/OWB-154
 Project: OpenWebBeans
  Issue Type: Bug
  Components: Simple Web Beans
Affects Versions: M3
Reporter: Mark Struberg
Assignee: Gurkan Erdogdu
 Fix For: M4


 this function is not in the interface of the spec anymore, thus causing the 
 TCK to fail.

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

Time to move atinject-api over to geronimo?

2009-11-20 Thread 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

sporadic test failures

2009-11-20 Thread Mark Struberg

any1 seen this before?

testGenericBeanInjection(org.apache.webbeans.test.unittests.inject.generic.GenericBeanTest)
  Time elapsed: 0.004 sec   ERROR!
javax.enterprise.context.ContextNotActiveException: WebBeans context with scope 
type annotation @ApplicationScoped does not exist within current thread
at 
org.apache.webbeans.container.BeanManagerImpl.getContext(BeanManagerImpl.java:249)
at 
org.apache.webbeans.event.ObserverMethodImpl.notify(ObserverMethodImpl.java:166)
at 
org.apache.webbeans.event.NotificationManager.fireEvent(NotificationManager.java:240)
at 
org.apache.webbeans.container.BeanManagerImpl.fireEvent(BeanManagerImpl.java:302)
at 
org.apache.webbeans.test.mock.MockManager.fireEvent(MockManager.java:105)
at 
org.apache.webbeans.test.TestContext.defineManagedBean(TestContext.java:327)
at 
org.apache.webbeans.test.unittests.inject.generic.GenericBeanTest.testGenericBeanInjection(GenericBeanTest.java:41)


LieGrue,
strub

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

[jira] Resolved: (OWB-150) remove ActivityManager from OWB

2009-11-20 Thread Mark Struberg (JIRA)


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

Mark Struberg resolved OWB-150.
---

Resolution: Fixed

 remove ActivityManager from OWB
 ---

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


 The ActivityManager has been dropped from the spec a while ago.
 We should reflect this within OWB too.
 We should also remove the BeanManager#getParent and #setParent functions 
 which belong to this area. 

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

AW: [VOTE] Gradutation

2009-11-16 Thread Mark Struberg

+1

LieGrue,
strub

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

 Von: Gurkan Erdogdu gurkanerdo...@yahoo.com
 Betreff: [VOTE] Gradutation
 An: openwebbeans-dev@incubator.apache.org
 Datum: Montag, 16. November 2009, 21:50
 Hi folks,
 
 There were some discussions related with graduation of the
 OpenWebBeans podling from incubator. Last time we discussed
 graduation, main barrier is the lack of community around
 it.  Over couple of weeks, we have diverted and
 increased our community around the project. 
 
 Generally,  it seems that community would like to
 graduate as a TLP.   To do formal process, I
 would like to start a VOTE for graduating OWB as TLP.
 
 Please cast your VOTEs here. VOTE is open for 72 hours.
 
 [-1] Do not graduate as TLP
 [0 ] Do not care TLP or not
 [+1] Graduate as TLP
 
 This is my +1;
 
 Thanks;
 
 --Gurkan

[jira] Created: (OWB-169) PrimitiveProducerTest creates a NullPointerException

2009-11-16 Thread Mark Struberg (JIRA)

PrimitiveProducerTest creates a NullPointerException


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


testPrimitiveProducer(org.apache.webbeans.test.unittests.producer.primitive.PrimitiveProducerTest)
  Time elapsed: 0.007 sec   ERROR!
java.lang.NullPointerException
at 
org.apache.webbeans.util.AnnotationUtil.isResourceAnnotation(AnnotationUtil.java:869)
at 
org.apache.webbeans.util.AnnotationUtil.hasResourceAnnotation(AnnotationUtil.java:832)
at 
org.apache.webbeans.util.AnnotationUtil.hasResourceAnnotation(AnnotationUtil.java:91)
at 
org.apache.webbeans.config.DefinitionUtil.defineInternalInjectedMethods(DefinitionUtil.java:943)


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

CDI final draft released

2009-11-11 Thread Mark Struberg

Hi!

Gavin today released the final draft of the CDI specification:

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


LieGrue,
strub

AW: graduation

2009-11-11 Thread Mark Struberg

What do we have to do in order to get OWB graduated?

LieGrue,
strub



- Ursprüngliche Mail 
 Von: Kevan Miller kevan.mil...@gmail.com
 An: openwebbeans-dev@incubator.apache.org
 Gesendet: Mittwoch, den 11. November 2009, 18:00:50 Uhr
 Betreff: graduation
 
 It's been a while since the community has discussed graduation. What are your 
 current thoughts?
 
 I've mentored about all that I can mentor... ; -)
 
 From the last time I kicked off the discussion:
 
 On Sep 8, 2009, at 11:00 AM, Kevan Miller wrote:
 
  IMO, this community displays nearly all of the characteristics that I would 
 look for from a successful Incubator project: you've successfully created 
 several releases while operating in a clear, open, and welcoming manner. All 
 of 
 this while facing some significant challenges as the JSR 299 spec has been an 
 ever shifting target.
  
  I'd like to see us moving towards graduation. To start things off, is the 
 community interested in becoming a top-level project? Or would you rather 
 graduate as a sub-project of an existing TLP?
 
 I think we're ready. Graduation is going to take a concerted effort by the 
 community. I'm certainly willing to help, but the community is going to need 
 to 
 help drive this.
 
 --kevan

[jira] Created: (OWB-152) @New needs a value parameter for the Class it should create

@New needs a value parameter for the Class it should create
---

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


from a sample of the spec:

{noformat}
 Produces @ConversationScoped
 @Special Order getSpecialOrder(@New(Order.class) Order order) 
{noformat}



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

[jira] Updated: (OWB-153) javax.enterprise.inject.spi.Decorator#getDelegateBindings() must be renamed to getDelegateQualifiers();


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

Mark Struberg updated OWB-153:
--

Affects Version/s: M3
Fix Version/s: M4
 Assignee: Mark Struberg  (was: Gurkan Erdogdu)

 javax.enterprise.inject.spi.Decorator#getDelegateBindings() must be renamed 
 to getDelegateQualifiers();
 ---

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


 the interface from the spec:
 {noformat}
 public interface DecoratorT extends BeanT {
 public SetType getDecoratedTypes();
 public Type getDelegateType();
 public SetAnnotation getDelegateQualifiers();
 }
 {noformat}

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

[jira] Commented: (OWB-154) remove Bean#getDeploymentType()


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

Mark Struberg commented on OWB-154:
---

Gurkan, I saw this is still pretty often used in our implementation.

We must not rely on it, because this would render the whole SPI idea senseless!

So I strongly vote for finally switching over all this stuff to the 
'Alternatives' as written in the spec.

 remove Bean#getDeploymentType()
 ---

 Key: OWB-154
 URL: https://issues.apache.org/jira/browse/OWB-154
 Project: OpenWebBeans
  Issue Type: Bug
  Components: Simple Web Beans
Affects Versions: M3
Reporter: Mark Struberg
Assignee: Gurkan Erdogdu
 Fix For: M4


 this function is not in the interface of the spec anymore, thus causing the 
 TCK to fail.

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

[jira] Created: (OWB-155) Conversation#isLongRunning() logic must be converted to isTransient();

Conversation#isLongRunning() logic must be converted to isTransient();
--

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


from the latest spec:

bq. Conversation#isTransient() returns true if the conversation is marked 
transient, or false if it is marked long-running.

so the logic got inverted.

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

[jira] Resolved: (OWB-155) Conversation#isLongRunning() logic must be converted to isTransient();


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

Mark Struberg resolved OWB-155.
---

Resolution: Fixed

 Conversation#isLongRunning() logic must be converted to isTransient();
 --

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


 from the latest spec:
 bq. Conversation#isTransient() returns true if the conversation is marked 
 transient, or false if it is marked long-running.
 so the logic got inverted.

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

[jira] Created: (OWB-156) ProcessSessionBean SPI interface needs to be updated to the latest spec

ProcessSessionBean SPI interface needs to be updated to the latest spec
---

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


currently is:
{noformat}
public interface ProcessSessionBeanX extends ProcessBeanObject
{
public AnnotatedTypeX getAnnotatedBeanClass();
...
{noformat}

and spec defines:
{noformat}
public interface ProcessSessionBeanX  extends ProcessManagedBeanObject {
public AnnotatedTypeX getAnnotatedSessionBeanClass();
...
}
{noformat}


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

[jira] Resolved: (OWB-156) ProcessSessionBean SPI interface needs to be updated to the latest spec