Hi Hamzah!
I'm registered at openejb-dev@a.o, just didn't have time to response.
In a new TomEE we should use a new MyFaces. In the newer MyFaces, the
DebugPhaseListener is not enabled by default (as it created a few side
effects). So this issue should not happen. In fact we did not do a
This is driving me crazy. I cannot for the life of me work out how to
configure 'default' logging for a simple test.
Let's pick an example - simple-singleton.
How to I override console logging for that? I just want to debug from
'org.apache.openejb' and up. How do I do it?
No matter what I try
did you try logging.level.OpenEJB=FINE?
- Romain
2012/7/5 AndyG andy.gumbre...@orprovision.com
This is driving me crazy. I cannot for the life of me work out how to
configure 'default' logging for a simple test.
Let's pick an example - simple-singleton.
How to I override console logging
In jdk/jre/lib/logging.properties - Does nothing.
This may be as simple as sucking eggs, and I assure you I feel stupid having
to resort to asking!
Using the 'simple-singleton' example as a starting point, and 'mvn clean
install' to run it - How can I get it to log debug to the console rather
@BeforeClass comments:
http://svn.apache.org/repos/asf/openejb/trunk/openejb/examples/simple-webservice/src/test/java/org/superbiz/calculator/ws/CalculatorTest.java
- Romain
2012/7/5 AndyG andy.gumbre...@orprovision.com
In jdk/jre/lib/logging.properties - Does nothing.
This may be as
Thanks dude! That does the trick :-)
--
View this message in context:
http://openejb.979440.n4.nabble.com/Logging-documentation-tp4656042p4656047.html
Sent from the OpenEJB Dev mailing list archive at Nabble.com.
Hi Andy,
any part of the spec?
@Lock is relevant only for singleton no? so why checking views?
- Romain
2012/7/5 andygumbre...@apache.org
Author: andygumbrecht
Date: Thu Jul 5 12:25:51 2012
New Revision: 1357576
URL: http://svn.apache.org/viewvc?rev=1357576view=rev
Log:
Fix hard
was wondering about the following lines,
should interfaces be taken into account or the class hierarchy?
- Romain
2012/7/5 andygumbre...@apache.org
Author: andygumbrecht
Date: Thu Jul 5 14:51:19 2012
New Revision: 1357648
URL: http://svn.apache.org/viewvc?rev=1357648view=rev
Log:
Only
I have changed BeanContext to perform the check only for a singleton.
The BeanContext is used here:
org.apache.openejb.core.singleton.SingletonContainer#_invoke
boolean read =
javax.ejb.LockType.READ.equals(beanContext.*getConcurrencyAttribute*(runMethod));
This result was wrong for a singleton
weird since it was fine for me
but i know parent methods of a singleton are by default WRITE even if the
child is READ and i guess that's the same for intrefaces so i'm not sure of
the fix
- Romain
2012/7/5 AndyG andy.gumbre...@orprovision.com
I have changed BeanContext to perform the check
I also believe this is legal right?
@Local
@Lock(LockType.READ)
public interface *Deployer *{
@Remote
public interface DeployerRemote extends *Deployer *{
@Singleton
@TransactionManagement(TransactionManagementType.BEAN)
@AccessTimeout(value = 60, unit = TimeUnit.SECONDS)
public class
i tend to think so since intrefaces are kind of parent but i didnt find
(maybe miss) sthg clear in the spec
the lock is for me linked to impl not the contract
wdyt?
- Romain
2012/7/5 AndyG andy.gumbre...@orprovision.com
I also believe this is legal right?
@Local
@Lock(LockType.READ)
@Andy: seems your changes of this morning broke this test, any idea?
- Romain
-- Forwarded message --
From: rmannibu...@apache.org
Date: 2012/7/5
Subject: svn commit: r1357670 -
Romain Manni-Bucau wrote
weird since it was fine for me
I don't see how?
beanContext.*getConcurrencyAttribute*(runMethod) /always/ propagated to the
hard coded WRITE if methods were not explicitly annotated - This has to be
wrong if the class or interface is READ?
--
View this message in
no since it was handled at method level not class level.
- Romain
2012/7/5 AndyG andy.gumbre...@orprovision.com
Romain Manni-Bucau wrote
weird since it was fine for me
I don't see how?
beanContext.*getConcurrencyAttribute*(runMethod) /always/ propagated to the
hard coded WRITE if
I think the @Lock should /always/ be visible on the *public* contract
(interfaces), so that API users understand that there is one.
The implementation is *private* nö? The implementation should be able to
override the contract is it sees fit to do so, which is why I chose the
order @Remote,
Only handled at method level if there was an 'explicitly defined @Lock' on
the method else...
org.apache.openejb.MethodContext#getLockType
public LockType getLockType() {
return lockType != null? lockType: beanContext.getLockType();
}
...beanContext.getLockType() -- Was LockType.WRITE
weird i always got the right lock and never defined it at method level
but i never put lock on the interface
- Romain
2012/7/5 AndyG andy.gumbre...@orprovision.com
Only handled at method level if there was an 'explicitly defined @Lock' on
the method else...
Yes, I hate intellij cache. Always letting things like this go through :-(
I'll fix it ASAP
--
View this message in context:
http://openejb.979440.n4.nabble.com/Fwd-svn-commit-r1357670-openejb-trunk-openejb-server-openejb-multicast-src-test-java-org-apache-opena-tp4656057p4656063.html
Sent from
thks
- Romain
2012/7/5 AndyG andy.gumbre...@orprovision.com
Yes, I hate intellij cache. Always letting things like this go through :-(
I'll fix it ASAP
--
View this message in context:
We've had a string of bad luck and hit with several intermittent test failures
in the last three days. Likely the load on the CI system increased and time
sensitive tests started failing.
I've cleared away some of these. Here's the current failure:
Test set:
21 matches
Mail list logo
