[jira] [Updated] (OWB-701) Support ASM for Bean Proxies

2012-09-15 Thread David Blevins (JIRA)

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

David Blevins updated OWB-701:
--

Component/s: Core
Summary: Support ASM for Bean Proxies  (was: Remove Javassist)

 Support ASM for Bean Proxies
 

 Key: OWB-701
 URL: https://issues.apache.org/jira/browse/OWB-701
 Project: OpenWebBeans
  Issue Type: Improvement
  Components: Core
Reporter: David Blevins
Assignee: David Blevins
 Fix For: 1.1.6




--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


[jira] [Resolved] (OWB-701) Support ASM for Bean Proxies

2012-09-15 Thread David Blevins (JIRA)

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

David Blevins resolved OWB-701.
---

Resolution: Fixed

 Support ASM for Bean Proxies
 

 Key: OWB-701
 URL: https://issues.apache.org/jira/browse/OWB-701
 Project: OpenWebBeans
  Issue Type: Improvement
  Components: Core
Reporter: David Blevins
Assignee: David Blevins
 Fix For: 1.1.6




--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


Re: [DISCUSS] release OWB-1.1.6 end of this week?

2012-09-15 Thread David Blevins
Got the ASM support finished.  OWB-701 officially closed.

We still use Javassist by default, but we have the ability to use ASM.

Mark, do you need help with the release?  (I know you have a *very* busy week 
coming up :)


-David

On Sep 12, 2012, at 11:03 AM, Mark Struberg wrote:

 2nd try as my previous got eaten by the spam filter :/
 
 
 
 
 
 - Forwarded Message -
 From: Mark Struberg strub...@yahoo.de
 To: openwebbeans-dev dev@openwebbeans.apache.org 
 Sent: Wednesday, September 12, 2012 7:49 PM
 Subject: [DISCUSS] releaese OWB-1.1.6 end of this week?
 
 
 Hi folks!
 
 I would like to start with a hot-fix release of OWB (version 1.1.6) end of 
 this week.
 Thomas, is this an ok timeframe in which you can fix the issues you needed 
 for your production?
 
 LIeGrue,
 strub
 
 
 
 
 
 



Re: [DISCUSS] release OWB-1.1.6 end of this week?

2012-09-15 Thread Mark Struberg
Hi David!

I can roll the release tonight or tomorrow morning. 
Udo still likes to get a few things done afaik. UnitTests and stuff...


Thomas, did you commit all your changes which you have Jiras created for?

LieGrue,
strub



- Original Message -
 From: David Blevins david.blev...@gmail.com
 To: dev@openwebbeans.apache.org; Mark Struberg strub...@yahoo.de
 Cc: 
 Sent: Saturday, September 15, 2012 10:56 AM
 Subject: Re: [DISCUSS] release OWB-1.1.6 end of this week?
 
G ot the ASM support finished.  OWB-701 officially closed.
 
 We still use Javassist by default, but we have the ability to use ASM.
 
 Mark, do you need help with the release?  (I know you have a *very* busy week 
 coming up :)
 
 
 -David
 
 On Sep 12, 2012, at 11:03 AM, Mark Struberg wrote:
 
  2nd try as my previous got eaten by the spam filter :/
 
 
 
 
 
  - Forwarded Message -
  From: Mark Struberg strub...@yahoo.de
  To: openwebbeans-dev dev@openwebbeans.apache.org 
  Sent: Wednesday, September 12, 2012 7:49 PM
  Subject: [DISCUSS] releaese OWB-1.1.6 end of this week?
 
 
  Hi folks!
 
  I would like to start with a hot-fix release of OWB (version 1.1.6) end 
 of this week.
  Thomas, is this an ok timeframe in which you can fix the issues you 
 needed for your production?
 
  LIeGrue,
  strub
 
 
 
 
 
 



Re: [DISCUSS] release OWB-1.1.6 end of this week?

2012-09-15 Thread Thomas Andraschko
Hi,

i will commit today :)

Regards,
Thomas

2012/9/15 Mark Struberg strub...@yahoo.de

 Hi David!

 I can roll the release tonight or tomorrow morning.
 Udo still likes to get a few things done afaik. UnitTests and stuff...


 Thomas, did you commit all your changes which you have Jiras created for?

 LieGrue,
 strub



 - Original Message -
  From: David Blevins david.blev...@gmail.com
  To: dev@openwebbeans.apache.org; Mark Struberg strub...@yahoo.de
  Cc:
  Sent: Saturday, September 15, 2012 10:56 AM
  Subject: Re: [DISCUSS] release OWB-1.1.6 end of this week?
 
 G ot the ASM support finished.  OWB-701 officially closed.
 
  We still use Javassist by default, but we have the ability to use ASM.
 
  Mark, do you need help with the release?  (I know you have a *very* busy
 week
  coming up :)
 
 
  -David
 
  On Sep 12, 2012, at 11:03 AM, Mark Struberg wrote:
 
   2nd try as my previous got eaten by the spam filter :/
 
 
 
 
 
   - Forwarded Message -
   From: Mark Struberg strub...@yahoo.de
   To: openwebbeans-dev dev@openwebbeans.apache.org
   Sent: Wednesday, September 12, 2012 7:49 PM
   Subject: [DISCUSS] releaese OWB-1.1.6 end of this week?
 
 
   Hi folks!
 
   I would like to start with a hot-fix release of OWB (version 1.1.6)
 end
  of this week.
   Thomas, is this an ok timeframe in which you can fix the issues you
  needed for your production?
 
   LIeGrue,
   strub
 
 
 
 
 
 
 



JIRA permissions

2012-09-15 Thread Thomas Andraschko
Hi,

how can i change the assignee of a ticket to myself or mark the issue as
fixed? I can't find any button/view for this :)
Do i need special permissions?

Regards,
Thomas


Re: JIRA permissions

2012-09-15 Thread Mark Struberg
I've added you to the OWB committers group in Jira. Could you please try again 
now?

LieGrue,
strub




- Original Message -
 From: Thomas Andraschko zoi...@gmail.com
 To: dev@openwebbeans.apache.org
 Cc: 
 Sent: Saturday, September 15, 2012 2:38 PM
 Subject: JIRA permissions
 
 Hi,
 
 how can i change the assignee of a ticket to myself or mark the issue as
 fixed? I can't find any button/view for this :)
 Do i need special permissions?
 
 Regards,
 Thomas
 


Re: [DISCUSS] release OWB-1.1.6 end of this week?

2012-09-15 Thread Udo Schnurpfeil
Hi!

Yes, I've put the stuff as a diff+comment in OWB-703. It would be nice
if somebody can check and commit it.

Regards,

Udo


Am 15.09.12 11:32, schrieb Mark Struberg:
 Hi David!
 
 I can roll the release tonight or tomorrow morning. 
 Udo still likes to get a few things done afaik. UnitTests and stuff...
 
 
 Thomas, did you commit all your changes which you have Jiras created for?
 
 LieGrue,
 strub
 
 
 
 - Original Message -
 From: David Blevins david.blev...@gmail.com
 To: dev@openwebbeans.apache.org; Mark Struberg strub...@yahoo.de
 Cc: 
 Sent: Saturday, September 15, 2012 10:56 AM
 Subject: Re: [DISCUSS] release OWB-1.1.6 end of this week?

 G ot the ASM support finished.  OWB-701 officially closed.

 We still use Javassist by default, but we have the ability to use ASM.

 Mark, do you need help with the release?  (I know you have a *very* busy 
 week 
 coming up :)


 -David

 On Sep 12, 2012, at 11:03 AM, Mark Struberg wrote:

  2nd try as my previous got eaten by the spam filter :/





  - Forwarded Message -
  From: Mark Struberg strub...@yahoo.de
  To: openwebbeans-dev dev@openwebbeans.apache.org 
  Sent: Wednesday, September 12, 2012 7:49 PM
  Subject: [DISCUSS] releaese OWB-1.1.6 end of this week?


  Hi folks!

  I would like to start with a hot-fix release of OWB (version 1.1.6) end 
 of this week.
  Thomas, is this an ok timeframe in which you can fix the issues you 
 needed for your production?

  LIeGrue,
  strub







 


[jira] [Updated] (OWB-702) Add serialization unit tests to openwebbeans-web to catch future regressions

2012-09-15 Thread Thomas Andraschko (JIRA)

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

Thomas Andraschko updated OWB-702:
--

Assignee: Thomas Andraschko  (was: Joe Bergmark)

 Add serialization unit tests to openwebbeans-web to catch future regressions
 

 Key: OWB-702
 URL: https://issues.apache.org/jira/browse/OWB-702
 Project: OpenWebBeans
  Issue Type: Improvement
Reporter: Joe Bergmark
Assignee: Thomas Andraschko
Priority: Minor
 Fix For: 1.1.6

 Attachments: failover.patch


 Add unit tests to webbeans-web for at least the two following scenarios:
 1) Ensure bean injected with the BeanManager is serializable
 2) Ensure FailOverBag can be serialized and then restored

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


[jira] [Resolved] (OWB-702) Add serialization unit tests to openwebbeans-web to catch future regressions

2012-09-15 Thread Thomas Andraschko (JIRA)

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

Thomas Andraschko resolved OWB-702.
---

Resolution: Fixed

 Add serialization unit tests to openwebbeans-web to catch future regressions
 

 Key: OWB-702
 URL: https://issues.apache.org/jira/browse/OWB-702
 Project: OpenWebBeans
  Issue Type: Improvement
Reporter: Joe Bergmark
Assignee: Thomas Andraschko
Priority: Minor
 Fix For: 1.1.6

 Attachments: failover.patch


 Add unit tests to webbeans-web for at least the two following scenarios:
 1) Ensure bean injected with the BeanManager is serializable
 2) Ensure FailOverBag can be serialized and then restored

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


[jira] [Commented] (OWB-703) getBeans cache key algorithm must be unique

2012-09-15 Thread Udo Schnurpfeil (JIRA)

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

Udo Schnurpfeil commented on OWB-703:
-

Hmmm, the BeanCacheKeyUnitTest is in the wrong directory: 
org/apache/webbeans/test/annotation/binding
but the package is 
org.apache.webbeans.container;

The package and directory should be the same.

Changing the package makes it not longer compilable, thats the reason why I've 
put it in the other package. The BeanCacheKey, is not public.

Solution 1: make BeanCacheKEy public
Solution 2: move the BeanCacheKeyUnitTest back to its original package

I don't know what OWB usually do in this case, but seems solution 1.

 getBeans cache key algorithm must be unique
 ---

 Key: OWB-703
 URL: https://issues.apache.org/jira/browse/OWB-703
 Project: OpenWebBeans
  Issue Type: Bug
Affects Versions: 1.1.4, 1.1.5
 Environment: OWB 1.1.4, Codi 1.0.5, MyFaces 2.0.13, Tobago 1.5.7
Reporter: Udo Schnurpfeil
Assignee: Mark Struberg
Priority: Critical
 Fix For: 1.1.6

 Attachments: OWB-703-2nd-shoot.patch, 
 OWB-703-hash-cache-as-integer.patch, OWB-703-ordering-and-other-fixes.patch, 
 owb-703.patch, OWB-703-refactored.diff


 Our application was tested in a Pre-Production environment, and it turns out 
 a problem which occurs sometime after 2 weeks but sometimes after a short 
 time:
 [9/11/12 10:46:27:288 CEST] 009e ServletWrappe E   SRVE0068E: Uncaught 
 exception thrown in one of the service methods of the servlet:
 FacesServlet. Exception thrown : java.lang.IllegalArgumentException: Given 
 bean type : class 
 org.apache.myfaces.extensions.cdi.jsf.impl.scope.conversation.ViewAccessConversationExpirationEvaluatorRegistry
  is not applicable for the bean instance : BereitstellungModelLoaderImpl, 
 Name:BereitstellungModelLoader, WebBeans Type:MANAGED, API 
 Types:[java.lang.Object,de.nordlbit.iopc.optionen.jsf.model.BereitstellungModelLoader,de.nordlbit.iopc.optionen.jsf.model.BereitstellungModelLoaderImpl,java.io.Serializable],
  
 Qualifiers:[javax.inject.Named,javax.enterprise.inject.Any,javax.enterprise.inject.Default]
   at 
 org.apache.webbeans.container.BeanManagerImpl.getReference(BeanManagerImpl.java:923)
   at 
 org.apache.webbeans.container.InjectableBeanManager.getReference(InjectableBeanManager.java:133)
   at 
 org.apache.myfaces.extensions.cdi.core.impl.util.CodiUtils.getContextualReference(CodiUtils.java:215)
   at 
 org.apache.myfaces.extensions.cdi.core.impl.util.CodiUtils.getContextualReferenceByClass(CodiUtils.java:179)
   at 
 org.apache.myfaces.extensions.cdi.core.impl.util.CodiUtils.getContextualReferenceByClass(CodiUtils.java:139)
   at 
 org.apache.myfaces.extensions.cdi.jsf.impl.util.ConversationUtils.postRenderCleanup(ConversationUtils.java:668)
   at 
 org.apache.myfaces.extensions.cdi.jsf2.impl.listener.phase.CodiLifecycleWrapper.render(CodiLifecycleWrapper.java:128)
   at javax.faces.webapp.FacesServlet.service(FacesServlet.java:191)
   at 
 com.ibm.ws.webcontainer.servlet.ServletWrapper.service(ServletWrapper.java:1213)
 [...]
 I think the reason is, that two objects got the same key in the map.
 So we got wrong objects.
 After this exception the application must be restarted, no request works 
 anymore.
 How can this happen?
 Problem number 1:
 Looking in the implementation:
 There will be computed a key of type Long from all given parameters.
 Parameters: injectionPointType, bdaBeansXMLPath, qualifiers
 In practice we have one injectionPointType (say t) and one qualifiers 
 (say q) and the computed hash code will be:
 key = hash(t) + 29 * hash(q)
 assume: hash(t)=1000 and hash(q)=100
 we got a key of 1000 + 29 * 100 = 3900
 but that's the same like
 1029 + 29 * 99 = 3900
 1058 + 29 * 98 = 3900
 1087 + 29 * 97 = 3900
 and so on.
 If we got parameter with hash(t)=1029 and hash(q)=99 we have found 2 beans 
 with the same key.
 With that our map is broken, because the 2nd bean will remove the 1st bean 
 while adding (with the same key).
 Problem number 2:
 Hash codes are generally not suitable to be used as keys because there are 
 not unique.
 The JavaDoc of the Object.hashCode() method says:
 It is not required that if two objects are unequal according to the 
 equals(Object) method,
 then calling the hashCode method on each of the two objects must produce 
 distinct integer results.
 The strings org.apache.kcmdjx and java.lang.Object have the same hash 
 code (at least in my Apple java VM).
 Solution:
 I see 3 solutions here:
 Solution 1:
 Do the same like in 1.1.3: Build a String with all information inside.
 Disadvantage: slow
 Solution 2:
 Create an helper object, which contains the unconverted information analog to 
 e.g.: 

[jira] [Commented] (OWB-703) getBeans cache key algorithm must be unique

2012-09-15 Thread Joe Bergmark (JIRA)

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

Joe Bergmark commented on OWB-703:
--

For some reason when I applied your patch it dropped all the new test files in 
the root, and I blindly moved them all together without double checking the 
packages.  I assumed that if I made a mistake a command line mvn compile would 
fail.  Obviously I was wrong.

I've committed a new change that makes the package match the directory, as 
personally I'd rather keep the tests separate.  As you suggested I also made 
BeanCacheKey public.

 getBeans cache key algorithm must be unique
 ---

 Key: OWB-703
 URL: https://issues.apache.org/jira/browse/OWB-703
 Project: OpenWebBeans
  Issue Type: Bug
Affects Versions: 1.1.4, 1.1.5
 Environment: OWB 1.1.4, Codi 1.0.5, MyFaces 2.0.13, Tobago 1.5.7
Reporter: Udo Schnurpfeil
Assignee: Mark Struberg
Priority: Critical
 Fix For: 1.1.6

 Attachments: OWB-703-2nd-shoot.patch, 
 OWB-703-hash-cache-as-integer.patch, OWB-703-ordering-and-other-fixes.patch, 
 owb-703.patch, OWB-703-refactored.diff


 Our application was tested in a Pre-Production environment, and it turns out 
 a problem which occurs sometime after 2 weeks but sometimes after a short 
 time:
 [9/11/12 10:46:27:288 CEST] 009e ServletWrappe E   SRVE0068E: Uncaught 
 exception thrown in one of the service methods of the servlet:
 FacesServlet. Exception thrown : java.lang.IllegalArgumentException: Given 
 bean type : class 
 org.apache.myfaces.extensions.cdi.jsf.impl.scope.conversation.ViewAccessConversationExpirationEvaluatorRegistry
  is not applicable for the bean instance : BereitstellungModelLoaderImpl, 
 Name:BereitstellungModelLoader, WebBeans Type:MANAGED, API 
 Types:[java.lang.Object,de.nordlbit.iopc.optionen.jsf.model.BereitstellungModelLoader,de.nordlbit.iopc.optionen.jsf.model.BereitstellungModelLoaderImpl,java.io.Serializable],
  
 Qualifiers:[javax.inject.Named,javax.enterprise.inject.Any,javax.enterprise.inject.Default]
   at 
 org.apache.webbeans.container.BeanManagerImpl.getReference(BeanManagerImpl.java:923)
   at 
 org.apache.webbeans.container.InjectableBeanManager.getReference(InjectableBeanManager.java:133)
   at 
 org.apache.myfaces.extensions.cdi.core.impl.util.CodiUtils.getContextualReference(CodiUtils.java:215)
   at 
 org.apache.myfaces.extensions.cdi.core.impl.util.CodiUtils.getContextualReferenceByClass(CodiUtils.java:179)
   at 
 org.apache.myfaces.extensions.cdi.core.impl.util.CodiUtils.getContextualReferenceByClass(CodiUtils.java:139)
   at 
 org.apache.myfaces.extensions.cdi.jsf.impl.util.ConversationUtils.postRenderCleanup(ConversationUtils.java:668)
   at 
 org.apache.myfaces.extensions.cdi.jsf2.impl.listener.phase.CodiLifecycleWrapper.render(CodiLifecycleWrapper.java:128)
   at javax.faces.webapp.FacesServlet.service(FacesServlet.java:191)
   at 
 com.ibm.ws.webcontainer.servlet.ServletWrapper.service(ServletWrapper.java:1213)
 [...]
 I think the reason is, that two objects got the same key in the map.
 So we got wrong objects.
 After this exception the application must be restarted, no request works 
 anymore.
 How can this happen?
 Problem number 1:
 Looking in the implementation:
 There will be computed a key of type Long from all given parameters.
 Parameters: injectionPointType, bdaBeansXMLPath, qualifiers
 In practice we have one injectionPointType (say t) and one qualifiers 
 (say q) and the computed hash code will be:
 key = hash(t) + 29 * hash(q)
 assume: hash(t)=1000 and hash(q)=100
 we got a key of 1000 + 29 * 100 = 3900
 but that's the same like
 1029 + 29 * 99 = 3900
 1058 + 29 * 98 = 3900
 1087 + 29 * 97 = 3900
 and so on.
 If we got parameter with hash(t)=1029 and hash(q)=99 we have found 2 beans 
 with the same key.
 With that our map is broken, because the 2nd bean will remove the 1st bean 
 while adding (with the same key).
 Problem number 2:
 Hash codes are generally not suitable to be used as keys because there are 
 not unique.
 The JavaDoc of the Object.hashCode() method says:
 It is not required that if two objects are unequal according to the 
 equals(Object) method,
 then calling the hashCode method on each of the two objects must produce 
 distinct integer results.
 The strings org.apache.kcmdjx and java.lang.Object have the same hash 
 code (at least in my Apple java VM).
 Solution:
 I see 3 solutions here:
 Solution 1:
 Do the same like in 1.1.3: Build a String with all information inside.
 Disadvantage: slow
 Solution 2:
 Create an helper object, which contains the unconverted information analog to 
 e.g.: org.apache.myfaces.tobago.internal.context.ClientPropertiesKey
 This will be faster than 

Re: Eclipse/Checkstyle errors

2012-09-15 Thread Joseph Bergmark
Which test classes are you getting check style errors in?  When I
build on the command line I don't see any check style errors:

[INFO] --- maven-checkstyle-plugin:2.7:check (verify-style) @
openwebbeans-web ---
[INFO]
[INFO]


[INFO] --- maven-checkstyle-plugin:2.7:check (verify-style) @
openwebbeans-impl ---
[INFO]
[INFO]

etc..

Sincerely,

Joe

On Sat, Sep 15, 2012 at 12:26 PM, Thomas Andraschko zoi...@gmail.com wrote:
 Hi,

 we have many checkstyle errors (not warnings) in the test classes.
 Can i fix them or should i exclude (don't know if possible in Eclipse) the
 test classes from checkstyle?
 The most errors are { should be on a new line and naming errors of
 constants and variables.

 Also i have many eclipse errors that @PostConstruct, @PreDestory,
 @WebServiceRef etc are not accessible.
 Can we add this APIs with provided scope or is there any better solution?

 Regards,
 Thomas


Re: Eclipse/Checkstyle errors

2012-09-15 Thread Thomas Andraschko
It's only in test-classes because the won't be checked by maven.
For example - AbstractUnitTest#addExtension

2012/9/15 Joseph Bergmark bergm...@apache.org

 Which test classes are you getting check style errors in?  When I
 build on the command line I don't see any check style errors:

 [INFO] --- maven-checkstyle-plugin:2.7:check (verify-style) @
 openwebbeans-web ---
 [INFO]
 [INFO]


 [INFO] --- maven-checkstyle-plugin:2.7:check (verify-style) @
 openwebbeans-impl ---
 [INFO]
 [INFO]

 etc..

 Sincerely,

 Joe

 On Sat, Sep 15, 2012 at 12:26 PM, Thomas Andraschko zoi...@gmail.com
 wrote:
  Hi,
 
  we have many checkstyle errors (not warnings) in the test classes.
  Can i fix them or should i exclude (don't know if possible in Eclipse)
 the
  test classes from checkstyle?
  The most errors are { should be on a new line and naming errors of
  constants and variables.
 
  Also i have many eclipse errors that @PostConstruct, @PreDestory,
  @WebServiceRef etc are not accessible.
  Can we add this APIs with provided scope or is there any better solution?
 
  Regards,
  Thomas



Re: Eclipse/Checkstyle errors

2012-09-15 Thread Joseph Bergmark
I haven't used the checkstyle plugin for Eclipse, so afraid I can't
provide much advice here.  Its too bad it doesn't appear to follow the
same rules as the maven plugin.

Sincerely,

Joe

On Sat, Sep 15, 2012 at 1:15 PM, Thomas Andraschko zoi...@gmail.com wrote:
 It's only in test-classes because the won't be checked by maven.
 For example - AbstractUnitTest#addExtension

 2012/9/15 Joseph Bergmark bergm...@apache.org

 Which test classes are you getting check style errors in?  When I
 build on the command line I don't see any check style errors:

 [INFO] --- maven-checkstyle-plugin:2.7:check (verify-style) @
 openwebbeans-web ---
 [INFO]
 [INFO]


 [INFO] --- maven-checkstyle-plugin:2.7:check (verify-style) @
 openwebbeans-impl ---
 [INFO]
 [INFO]

 etc..

 Sincerely,

 Joe

 On Sat, Sep 15, 2012 at 12:26 PM, Thomas Andraschko zoi...@gmail.com
 wrote:
  Hi,
 
  we have many checkstyle errors (not warnings) in the test classes.
  Can i fix them or should i exclude (don't know if possible in Eclipse)
 the
  test classes from checkstyle?
  The most errors are { should be on a new line and naming errors of
  constants and variables.
 
  Also i have many eclipse errors that @PostConstruct, @PreDestory,
  @WebServiceRef etc are not accessible.
  Can we add this APIs with provided scope or is there any better solution?
 
  Regards,
  Thomas



Re: Eclipse/Checkstyle errors

2012-09-15 Thread Thomas Andraschko
I use the same rules as the maven plugin, you must just import the settings.
The problem is that maven-checkstyle-plugin does not check the test-src but
eclipse does (per default).

So what do you think? should we fix this errors or should the developers
exclude test classes?

2012/9/15 Joseph Bergmark bergm...@apache.org

 I haven't used the checkstyle plugin for Eclipse, so afraid I can't
 provide much advice here.  Its too bad it doesn't appear to follow the
 same rules as the maven plugin.

 Sincerely,

 Joe

 On Sat, Sep 15, 2012 at 1:15 PM, Thomas Andraschko zoi...@gmail.com
 wrote:
  It's only in test-classes because the won't be checked by maven.
  For example - AbstractUnitTest#addExtension
 
  2012/9/15 Joseph Bergmark bergm...@apache.org
 
  Which test classes are you getting check style errors in?  When I
  build on the command line I don't see any check style errors:
 
  [INFO] --- maven-checkstyle-plugin:2.7:check (verify-style) @
  openwebbeans-web ---
  [INFO]
  [INFO]
 
 
  [INFO] --- maven-checkstyle-plugin:2.7:check (verify-style) @
  openwebbeans-impl ---
  [INFO]
  [INFO]
 
  etc..
 
  Sincerely,
 
  Joe
 
  On Sat, Sep 15, 2012 at 12:26 PM, Thomas Andraschko zoi...@gmail.com
  wrote:
   Hi,
  
   we have many checkstyle errors (not warnings) in the test classes.
   Can i fix them or should i exclude (don't know if possible in Eclipse)
  the
   test classes from checkstyle?
   The most errors are { should be on a new line and naming errors of
   constants and variables.
  
   Also i have many eclipse errors that @PostConstruct, @PreDestory,
   @WebServiceRef etc are not accessible.
   Can we add this APIs with provided scope or is there any better
 solution?
  
   Regards,
   Thomas
 



Re: Eclipse/Checkstyle errors

2012-09-15 Thread Romain Manni-Bucau
We can filter them http://checkstyle.sourceforge.net/config.html#Filters
Le 15 sept. 2012 20:09, Thomas Andraschko zoi...@gmail.com a écrit :

 I use the same rules as the maven plugin, you must just import the
 settings.
 The problem is that maven-checkstyle-plugin does not check the test-src but
 eclipse does (per default).

 So what do you think? should we fix this errors or should the developers
 exclude test classes?

 2012/9/15 Joseph Bergmark bergm...@apache.org

  I haven't used the checkstyle plugin for Eclipse, so afraid I can't
  provide much advice here.  Its too bad it doesn't appear to follow the
  same rules as the maven plugin.
 
  Sincerely,
 
  Joe
 
  On Sat, Sep 15, 2012 at 1:15 PM, Thomas Andraschko zoi...@gmail.com
  wrote:
   It's only in test-classes because the won't be checked by maven.
   For example - AbstractUnitTest#addExtension
  
   2012/9/15 Joseph Bergmark bergm...@apache.org
  
   Which test classes are you getting check style errors in?  When I
   build on the command line I don't see any check style errors:
  
   [INFO] --- maven-checkstyle-plugin:2.7:check (verify-style) @
   openwebbeans-web ---
   [INFO]
   [INFO]
  
  
   [INFO] --- maven-checkstyle-plugin:2.7:check (verify-style) @
   openwebbeans-impl ---
   [INFO]
   [INFO]
  
   etc..
  
   Sincerely,
  
   Joe
  
   On Sat, Sep 15, 2012 at 12:26 PM, Thomas Andraschko zoi...@gmail.com
 
   wrote:
Hi,
   
we have many checkstyle errors (not warnings) in the test classes.
Can i fix them or should i exclude (don't know if possible in
 Eclipse)
   the
test classes from checkstyle?
The most errors are { should be on a new line and naming errors of
constants and variables.
   
Also i have many eclipse errors that @PostConstruct, @PreDestory,
@WebServiceRef etc are not accessible.
Can we add this APIs with provided scope or is there any better
  solution?
   
Regards,
Thomas
  
 



Re: [ANN] Welcome Thomas Andraschko as OpenWebBeans committer!

2012-09-15 Thread Gerhard Petracek
welcome!

regards,
gerhard



2012/9/12 Mark Struberg strub...@yahoo.de



 Hi community!

 I'm happy to announce that Thomas will help us with making OWB even better.
 He is an expert on passivation and clustering and uses OWB in production
 for a few projects.

 Welcome Thomas!


 The Apache OpenWebBeans PMC



Re: Eclipse/Checkstyle errors

2012-09-15 Thread David Jencks
My opinion as a pretty much completely inactive contributor to OWB is that it 
would be better to have the test classes follow the same style rules as the 
main code, but I'm not prepared to help fix it.

thanks
david jencks

On Sep 15, 2012, at 11:09 AM, Thomas Andraschko wrote:

 I use the same rules as the maven plugin, you must just import the settings.
 The problem is that maven-checkstyle-plugin does not check the test-src but
 eclipse does (per default).
 
 So what do you think? should we fix this errors or should the developers
 exclude test classes?
 
 2012/9/15 Joseph Bergmark bergm...@apache.org
 
 I haven't used the checkstyle plugin for Eclipse, so afraid I can't
 provide much advice here.  Its too bad it doesn't appear to follow the
 same rules as the maven plugin.
 
 Sincerely,
 
 Joe
 
 On Sat, Sep 15, 2012 at 1:15 PM, Thomas Andraschko zoi...@gmail.com
 wrote:
 It's only in test-classes because the won't be checked by maven.
 For example - AbstractUnitTest#addExtension
 
 2012/9/15 Joseph Bergmark bergm...@apache.org
 
 Which test classes are you getting check style errors in?  When I
 build on the command line I don't see any check style errors:
 
 [INFO] --- maven-checkstyle-plugin:2.7:check (verify-style) @
 openwebbeans-web ---
 [INFO]
 [INFO]
 
 
 [INFO] --- maven-checkstyle-plugin:2.7:check (verify-style) @
 openwebbeans-impl ---
 [INFO]
 [INFO]
 
 etc..
 
 Sincerely,
 
 Joe
 
 On Sat, Sep 15, 2012 at 12:26 PM, Thomas Andraschko zoi...@gmail.com
 wrote:
 Hi,
 
 we have many checkstyle errors (not warnings) in the test classes.
 Can i fix them or should i exclude (don't know if possible in Eclipse)
 the
 test classes from checkstyle?
 The most errors are { should be on a new line and naming errors of
 constants and variables.
 
 Also i have many eclipse errors that @PostConstruct, @PreDestory,
 @WebServiceRef etc are not accessible.
 Can we add this APIs with provided scope or is there any better
 solution?
 
 Regards,
 Thomas