1) I use this batch to build fully:
set MAVEN_OPTS=-Xmx768m -XX:MaxPermSize=256M -XX:ReservedCodeCacheSize=64m
-Xss2048k
rem mvn dependency:purge-local-repository
mvn -e -ff -Dejbd.port=9988 -DuniqueVersion=false -Dassemble clean install
And add the following for a quick build if I know the
Added StatefulBeanManagedTest.java (openejb-core), but not sure if this is
the right way to process the 'release' call in
org.apache.openejb.core.stateful.StatefulContainer#releaseInstance - This
previously threw an IllegalStateException (which was 'fixed' or rather
exposed on my last commit).
It
Do we know why, is it a bug in surefire or our configuration?
--
View this message in context:
http://openejb.979440.n4.nabble.com/Fwd-svn-commit-r1427716-in-openejb-trunk-openejb-tck-bval-embedded-pom-xml-bval-tomee-pom-xml-cdi-eml-tp4660010p4660011.html
Sent from the OpenEJB Dev mailing list
Two birds with one stone. May be a bug though?
The following error can be seen on the
http://ci.apache.org/builders/openejb-trunk-win-sunjdk build. It is caused
by a temp file issue, that may be more common on win platforms, which leads
to an undeploy / destroy call.
INFO - Deployed
I have been checking stuff in lately specifically to get this build working.
It's getting close.
The jdk1.6.0_16 should really be updated, but I'd be happy to help.
Andy.
--
View this message in context:
We don't need to uninstall the existing jdk, just install the new one. As
long as system variables are not changed there should be no issue.
--
View this message in context:
Sure, in general.
But 1. This is in trunk, and 2. org.jboss.arquillian.spock is an Alpha. So
really only trying to get this to build and test on the bots for groovy 2.x
for now. Which I think it now does.
I think I even removed a snapshot already. Which snapshot are you not
liking?
--
View
Do you know if we have any public access to surefire-reports directories such
as?:
C:\slave4\openejb-trunk-win-sunjdk\build\container\openejb-core\target\surefire-reports
I'd like to get to the traces if possible.
--
View this message in context:
+1
I do remember finding OpenEJB years ago on a specific google for 'open
source ejb', it's still way up there so let's be sure not lose it.
--
View this message in context:
http://openejb.979440.n4.nabble.com/VOTE-Name-change-resolution-tp4659611p4659746.html
Sent from the OpenEJB Dev
My sentiments exactly. I'd just like to have a loosely defined default. Not
something in concrete . I don't think anyone has ever really worried about
it and we shouldn't start now.
Andy.
--
View this message in context:
preRegister org.apache.jasper.servlet.JspServlet@789e4b55
Tomcat:type=JspMonitor,name=jsp,WebModule=//localhost/red/\green,J2EEApplication=none,J2EEServer=none
https://issues.apache.org/jira/browse/TOMEE-663
The WebModule=//localhost/red/\green URL was invalid due to only checking
for / and not
+0
Still some minor Win platform test failures. We should disable the tests.
Other than that everything looks good to go.
--
View this message in context:
http://openejb.979440.n4.nabble.com/VOTE-OpenEJB-4-5-1-TomEE-1-5-1-staging-132-tp4659354p4659401.html
Sent from the OpenEJB Dev mailing
Here is a really good write up that I subscribe to that in addition to the
'Final fields' section has some really good links to other 'field' related
resources.
http://www.ibm.com/developerworks/java/library/j-jtp1029/index.html
I have also based my use of final fields on the exposure of
Oops, sorry completely misread your question - The answer is almost the same
the though. I have avoided subtle bugs by using 'this'
I guess that 'this' is more for readability. I'll stop doing it on OpenEJB
code if it is considered overkill.
Andy.
--
View this message in context:
I guess the most obvious subtle bug avoided by 'this' that I can think of is
the use of same named method and field variables, often in abstract classes.
I have seen the the 'super' being set where the 'this' was intended, and
vice versa.
--
View this message in context:
https://issues.apache.org/jira/browse/OPENEJB-1964
The EarUnpackTest fails on win platforms due to file locking on the
'orange.jar'.
I understand the test to be.
1. Deploy colors.ear which extracts to [apps]/colors/orange.jar
2. Deploy colors.ear which extracts to [apps]/colors/yellow.jar -
https://issues.apache.org/jira/browse/OPENEJB-1962
https://issues.apache.org/jira/browse/OPENEJB-1963
Andy.
--
View this message in context:
Just closed it:
https://issues.apache.org/jira/browse/OPENEJB-1265
--
View this message in context:
http://openejb.979440.n4.nabble.com/Fwd-svn-commit-r1417802-in-openejb-trunk-openejb-container-openejb-core-src-main-java-org-apache-opea-tp4659135p4659136.html
Sent from the OpenEJB Dev
Pretty obvious what's going on here due to changes in DeploymentLoader.java
on revision 1416096:
UnknownModuleTypeException: Unable to determine module type for jar:
file:/[path]/apps/*.svn*
I have added some code to filter directory names, but not sure it's the best
way to filter. Shouldn't we
Hi Romain,
I use RMIIO extensively for large binary transfer that I modified with an
almost identical fix to your flushable gzip implementation. I have tested
this to death with and without buffering/gzip in the past.
I have found that gzip works substantially better with buffered streams over
a
Breaks my app.
2012-11-15 16:54:45,078 WARN
[org.hibernate.engine.jdbc.spi.SqlExceptionHelper] (ejbd 5) SQL Error: 0,
SQLState: null
2012-11-15 16:54:45,078 ERROR
[org.hibernate.engine.jdbc.spi.SqlExceptionHelper] (ejbd 5) Connection does
not have a registered XAResource jdbc:postgresql://[url
Done.
https://issues.apache.org/jira/browse/OPENEJB-1938
Andy.
--
View this message in context:
http://openejb.979440.n4.nabble.com/Re-svn-commit-r1409700-openejb-trunk-openejb-container-openejb-core-src-main-java-org-apache-openejba-tp4658619p4658638.html
Sent from the OpenEJB Dev mailing
Concurrency config is parallel='none', perCoreThreadCount=true,
threadCount=1, useUnlimitedThreads=false
org.apache.maven.surefire.util.SurefireReflectionException:
java.lang.reflect.InvocationTargetException; nested exception is
java.lang.reflect.InvocationTargetException: null
Found the issue but not sure of a resolution. Why is the test running when
-Dmaven.test.skip=true is specified? It can't find the class because it
shouldn't be running!
[INFO] --- maven-compiler-plugin:2.4:testCompile (default-testCompile) @
multiple-arquillian-adapters ---
[INFO] *Not compiling
Thanks
--
View this message in context:
http://openejb.979440.n4.nabble.com/Fwd-svn-commit-r1367976-in-openejb-trunk-openejb-examples-multiple-arquillian-adapters-src-test-java-tp4656615p4656632.html
Sent from the OpenEJB Dev mailing list archive at Nabble.com.
Failed on a Windows machine. Not had time to look mayself, but maybe it will
ring someone's bell.
---
Test set: org.apache.openejb.arquillian.TomEEContainerTest
0
Andy.
--
View this message in context:
http://openejb.979440.n4.nabble.com/VOTE-Bulk-close-old-issues-tp4656172p4656200.html
Sent from the OpenEJB Dev mailing list archive at Nabble.com.
+1 Derby
Using it for a long time in production.
--
View this message in context:
http://openejb.979440.n4.nabble.com/why-do-we-use-hsqldb-tp4656087p4656098.html
Sent from the OpenEJB Dev mailing list archive at Nabble.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 for that? I just want to debug from
'org.apache.openejb' and up. How do I do it?
No matter what I try
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
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.
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
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
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
, @Local then Class.
Romain Manni-Bucau wrote
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 lt;andy.gumbrecht@gt;
I also believe
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
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
Is this implemented at the class level or does this need to be set on
methods?
--
View this message in context:
http://openejb.979440.n4.nabble.com/BeanContext-getLockType-is-always-LockType-WRITE-tp4655669.html
Sent from the OpenEJB Dev mailing list archive at Nabble.com.
Hi Romain,
I am still trying to understand if the BeanContext#getLockType() should
return a variable and not a constant?
If a method has no lock annotation then as far as I can follow the default
is to call BeanContext#getLockType(), so the default is always
LockType.WRITE - Shouldn't this be
Is there a way of getting the current lock context from the method call? I'd
like to write a test for this.
--
View this message in context:
http://openejb.979440.n4.nabble.com/BeanContext-getLockType-is-always-LockType-WRITE-tp4655669p4655674.html
Sent from the OpenEJB Dev mailing list archive
David Blevins-2 wrote
No worries. Was more looking for some discussion starting descriptions :)
It might make for good docs, but we don't need to be that formal that
fast.
The jira https://issues.apache.org/jira/browse/OPENEJB-1838 is quite
extensive, I will try out some docs later.
As
David Blevins-2 wrote
Don't forget to create the applicable jiras.
Socket timeout:
https://issues.apache.org/jira/browse/OPENEJB-1839
and...
MultiPulse:
https://issues.apache.org/jira/browse/OPENEJB-1838
I know I should be able to work it out myself, but just haven't had the time
to
Thanks, I think I have it now
Romain Manni-Bucau wrote
Btw, im interested in a way to know all servers of a cluster in tomee, any
ideas?
I think 'org.apache.catalina.tribes.membership.McastService' will get you
what you need?
--
View this message in context:
Added new 'multipulse' discovery, and a few fixes.
Fixes:
ServiceDaemon.java - Must close the server socket even if it does not get a
lock.
ServiceManager.java - Revert 'conf.d' in path. If this is a 'tomee'
requirement then it needs to be checked?
EjbDaemon.java - Ensure streams are closed on
I will do a fresh check-out and try again.
--
View this message in context:
http://openejb.979440.n4.nabble.com/VOTE-OpenEJB-4-0-0-TomEE-1-0-0-staging-109-tp4589077p4591922.html
Sent from the OpenEJB Dev mailing list archive at Nabble.com.
+1
[INFO] BUILD SUCCESS
[INFO]
[INFO] Total time: 1:06:08.825s
[INFO] Finished at: Fri Apr 27 12:25:12 CEST 2012
[INFO] Final Memory: 138M/740M
[INFO]
+1
[INFO] BUILD SUCCESS
[INFO]
[INFO] Total time: 1:06:08.825s
[INFO] Finished at: Fri Apr 27 12:25:12 CEST 2012
[INFO] Final Memory: 138M/740M
[INFO]
Getting exactly the same here.
Added some debug logging and path fixes already to try and track arquillian
errors down.
--
View this message in context:
http://openejb.979440.n4.nabble.com/webapp-arquillian-adapter-issue-under-win-tp4584407p4585682.html
Sent from the OpenEJB Dev mailing list
I use Stateful for RMIIO streaming of large binary (anything over 10mb).
Theoretically it is possible that each client (up to 15-20 per application,
with an application count unlikely to go above 5-10) may hold one or more
statefuls at any one time, and that may last for a considerable amount of
I'll revisit the client retry, and I know where I went wrong. What I am after
is breaking out of the 'retryConditions' retry, not the 'uri' retry.
Here's my scenario, shoot me if I am barking up the wrong tree with this.
I add 'ConcurrentAccessTimeoutException.class' via addRetryCondition. The
Well near enough, about 50km south in Hameln and CeBit has become tedious
and Hannover is crap.
+1 for the EU though.
--
View this message in context:
http://openejb.979440.n4.nabble.com/Apache-OpenEJB-TomEE-Get-Together-2012-tp4313559p4551470.html
Sent from the OpenEJB Dev mailing list
+1 on OpenEJB 4.0
Cannot really comment on TomEE as I have barely used it.
David Blevins-2 wrote
We're overdue for a release.
--
View this message in context:
http://openejb.979440.n4.nabble.com/Final-release-tp4529975p4534198.html
Sent from the OpenEJB Dev mailing list archive at
Done. With a small tweak
--
View this message in context:
http://openejb.979440.n4.nabble.com/Fail-testSweeps-tp4495869p4514659.html
Sent from the OpenEJB Dev mailing list archive at Nabble.com.
So before we 'sweep' this under the carpet what would you suggest is the best
course of action?
--
View this message in context:
http://openejb.979440.n4.nabble.com/Fail-testSweeps-tp4495869p4509066.html
Sent from the OpenEJB Dev mailing list archive at Nabble.com.
Ok, so I know this is me - but I think the test needs the fix? Opinions.
Changed the timer to fire a sweep after defined period. I just don't see why
a sweep should occur immediately when the pool is created as it is unlikely
to need one?
--
View this message in context:
If I remove @Asynchronous from the method then the apps 'A.jar' loads just
fine (which is internally using 'many' classes from lib 'B.jar'), so I am
not sure if this is exclude/include related.
I will dig deeper on this tomorrow, going to call it a day for now. Just
wanted to put this out to see
Probably just easy to link to:
http://ci.apache.org/builders/openejb-trunk-ubuntu
--
View this message in context:
http://openejb.979440.n4.nabble.com/build-dashboard-tp4383927p4384047.html
Sent from the OpenEJB Dev mailing list archive at Nabble.com.
As our company nears the official release (scheduled for May) I want to start
nudging the boss to donate. Where is the best place to donate so that it
directly benefits the OpenEJB project?
Andy.
--
View this message in context:
Seen, beat me to it
--
View this message in context:
http://openejb.979440.n4.nabble.com/Fwd-svn-commit-r1239550-in-openejb-trunk-openejb-openejb-arquillian-tomee-arquillian-tomcat-openejb-n-tp4351264p4351536.html
Sent from the OpenEJB Dev mailing list archive at Nabble.com.
In the process of checking this out I have put the following back into
NewLoaderLogic.
public static final String ADDITIONAL_EXCLUDES =
System.getProperty(openejb.additional.exclude);
public static final String ADDITIONAL_INCLUDE =
System.getProperty(openejb.additional.include);
I know it was
David Blevins-2 wrote
That definitely seems to be the case.
I would focus debugging efforts at line 87 of
org.apache.openejb.cli.Bootstrap
OK, this is more than likely due to the windows service (Commons Daemon)
already having jars on the classpath. From the get go
My problem is there is no such thing as 'only' two beers... two leads to
three leads to ...say ten on a good night
--
View this message in context:
http://openejb.979440.n4.nabble.com/Apache-OpenEJB-TomEE-Get-Together-2012-tp4313559p4343882.html
Sent from the OpenEJB Dev mailing list archive at
OpenEJB :: OSGi :: Tests
org.apache.karaf.tooling.exam:exam:pom:3.0.0-SNAPSHOT
Is there a maven repository from which the above dependency can be resolved?
I have had to download and build karaf tooling to get this dep, but that is
probably not a good solution.
--
View this message in
Case sensitive jar paths are being assumed.
Found EjbModule in classpath:
d:\OrproVisionServer\openejb\lib\openejb-core-4.0.0-beta-3-SNAPSHOT.jar
Found EjbModule in classpath:
D:\OrproVisionServer\openejb\lib\openejb-core-4.0.0-beta-3-SNAPSHOT.jar
SLF4J: Class path contains multiple SLF4J
This has something to do with DeploymentsResolver.loadFromClasspath
The xbean UrlSet contains duplicate urls for every jar on the classpath and
these are not filtered out.
--
View this message in context:
I am getting pretty close to the cause in
DeploymentsResolver.loadFromClasspath
UrlSet urlSet = new UrlSet(classLoader); -- Contains duplicate urls.
...filter etc.
Still contains duplicate urls with different drive letters after all filters
have been applied.
[62] =
Just had a look at that myself and the duplicates are added from the get go.
Collections.list(classLoader.getResources(META-INF)) = Returns duplicates
Collections.list(classLoader.getResources()) = empty
--
View this message in context:
The iteration just trims off 'META-INF' from the url
--
View this message in context:
http://openejb.979440.n4.nabble.com/Trunk-classloading-is-broken-with-case-sensitive-paths-tp4344116p4345024.html
Sent from the OpenEJB Dev mailing list archive at Nabble.com.
It is the issue as that list is used for scanning, but not sure why it has
just cropped up over the weekend.
Have seen your changes to the exclude and cannot see anything that would
cause this. The duplicates need to be weeded out though as every jar is
basically scanned twice.
--
View this
I also think this is something that maybe just been highlighted by a
classloader issue somewhere else. Has anything been changed with class
loading over the weekend? Also can't see anything specific but gut tells me
this is not as simple as it looks.
The following log entries are of concern:
I have already posted the results of debugging both getResources calls - the
whole list is irrelevant , there are duplicates for 'every' url in the list,
one with an upper case drive letter and the other lower case.
--
View this message in context:
Also +1. Thanks David.
As mentioned before, in production adding something like
-Dopenejb.log.factory=log4j is not as easy as it sounds. Especially if has
to be done by a 'user' over the wire.
I don't just drop trunk into production on a whim, but if all my tests pass
and the changes are
So how about some info about how to configure the 'new' logging - I don't
really care what logging is used as long as when it changes there is a
little info for those using the 'old' logging.
I just built and dropped in the jars onto my standalone test server (which I
do at least once a week to
I am now getting the following, is there a missing or modified default port
configuration somewhere?:
Running org.apache.openejb.arquillian.session.SessionScopeTest
[] START SERVER
OPENEJB_HOME =
D:\tmp\arquillian-apache-tomee\apache-tomee-plus-1.0.0-beta-2-SNAPSHOT
SYSTEM_INFO = Java 1.6.0_30;
Still the same, something has changed since yesterday morning that is causing
the test tomee to try and bind to port 0 - Trying to figure out what.
--
View this message in context:
http://openejb.979440.n4.nabble.com/VOTE-OpenEJB-4-0-0-beta-2-TomEE-1-0-0-beta-2-tp4274468p4292230.html
Sent from
Had a similar fix in the pipes here, was just not quick enough on the
check-in. However, just for info, I have had to bump up a few build
environment options on Windows to get a full build to complete:
set MAVEN_OPTS=-Xmx768m -XX:MaxPermSize=256M -XX:ReservedCodeCacheSize=64m
-Xss4096k
The
I would say most definitely related to the classloading issue. Only one
TestRunner is allowed per classloader.
The
D:/tmp/arquillian-apache-tomee/apache-tomee-plus-1.0.0-beta-2/temp/arquillian-junit-4211441189472437588.jar
is going to be on the application root classloader and all child
I guess you mean the addIfNotExist method?
--
View this message in context:
http://openejb.979440.n4.nabble.com/VOTE-OpenEJB-4-0-0-beta-2-TomEE-1-0-0-beta-2-tp4274468p4285334.html
Sent from the OpenEJB Dev mailing list archive at Nabble.com.
The whole temp file thing seems to have arisen from JDK inconsistency issues
related to the ClassLoaderUtil.clearSunJarFileFactoryCache method.
This method was for a period failing to actually release the file handle on
jar files due to some real spaghetti in the
Andy +0
Two test failures. Not dug in to the cause, so if anyone can see something
in the traces that may have something to do with my setup then let me know.
Using Win7 Pro 64bit
---
Test set:
I contributed the original OpenEJB standalone service installation scripts
(trunk/openejb/assembly/openejb-standalone/src/main/resources) and
openejb-daemon project (org.apache.openejb.daemon.NTService).
I use the standalone server daily on 32 and 64 bit systems, but have not
really looked into
Does anyone know what has changed on the logging front to break logging -
Using standalone server. Does not even create the 'openejb.log' anymore?
--
View this message in context:
http://openejb.979440.n4.nabble.com/Logging-broken-tp4164685p4164685.html
Sent from the OpenEJB Dev mailing list
Checked in a fix. Please have a look and make sure I have not broken
something you intended.
I think that the order of the day is:
1. Check for and use a user specified factory,
2. Else, check for log4j and configure if not overridden,
3. Else, check for JUL and configure if not overridden,
4.
+1
Andy
--
View this message in context:
http://openejb.979440.n4.nabble.com/VOTE-Vishwanath-Krishnamurthi-as-committer-tp4122496p4123101.html
Sent from the OpenEJB Dev mailing list archive at Nabble.com.
+0
Not in a position to check out tag.
--
View this message in context:
http://openejb.979440.n4.nabble.com/VOTE-Apache-OpenEJB-3-0-4-3rd-Try-tp3928492p3932235.html
Sent from the OpenEJB Dev mailing list archive at Nabble.com.
Thanks for the suggestion Romain. I will look into it.
--
View this message in context:
http://openejb.979440.n4.nabble.com/DataSourceFactory-BasicManagedDataSource-plan-of-action-tp3878426p3881115.html
Sent from the OpenEJB Dev mailing list archive at Nabble.com.
I know DataSourceFactory is currently in progress, so this just an enquiry as
to the plan of action based upon my very specific issue.
I am currently using a modified DataSourceFactory and BasicManagedDataSource
due to changes in the latest version. I'll explain why further down.
Basically just
You did it David. Without your co-ordination and control I doubt the ball
would have been rolling quite as much.
I wish I could have more time to focus on this truly great project, and can
only hope that the limited input and fixes I have been able to apply have
helped you along the way.
A big
set MAVEN_OPTS=-Xmx768m -XX:MaxPermSize=256M -XX:ReservedCodeCacheSize=64m
Using above maven options and ActiveMQ 5.6-SNAPSHOT:
+1
Andy.
--
View this message in context:
http://openejb.979440.n4.nabble.com/VOTE-Apache-OpenEJB-TomEE-4-0-0-beta-1-tp3859551p3860239.html
Sent from the OpenEJB
Just reverted, but shouldn't we really have a DescriptionType[] for this?
--
View this message in context:
http://openejb.979440.n4.nabble.com/Re-svn-commit-r1176770-openejb-trunk-openejb3-container-openejb-jee-src-main-java-org-apache-openejba-tp3850280p3850508.html
Sent from the OpenEJB Dev
Changed serialVersionUIDs in 'org.apache.openejb.math' that conflict with
identical commons.math classes (from which they are copied). Not serious,
but intellij, netbeans and possibly other IDEs see these classes as the same
and can lead to incorrect imports.
Would it maybe be better to remove
Sure, I guess openejb.math is unlikely to change a lot. Just one of our other
devs here pulled in openejb.math by mistake (SecondMoment.class) which broke
a unit test here. Was easy to fix and is why I changed the id's to avoid it
happening again.
--
View this message in context:
That is actually what I did in the reverted changes.
Not saying all the changes you made were completely wrong? the revert was
simply back to the way it was before (working) until a more stable solution
was found - which is what we are doing right? If I put your changes back 'as
is' in then
The test for this can only really be tested on Win machines. I have a test on
my dev box that does the following:
1. Start
2. Deploy app
3. Undeploy app
4. Check that app files can be or are deleted
5. Repeat steps 2 through 4 several times
6. Stop
I am using a custom deployer (based loosely on
The code is far from optimal and does require a clean up and a second look
for sure. I am on it already. The revert was back to something that was
known to be working until a better solution is implemented. The changes you
made broke redeployment on my dev box - Files were back to being locked,
Revision: 1135936
Author: genspring
Date: 08:49:36, Mittwoch, 15. Juni 2011
Message:
if there's a valid id.getName, the user can't use setModuleId to update the
moduleId because the simple bug here.
Correct the logic to update moduleId.
Modified :
+1
--
View this message in context:
http://openejb.979440.n4.nabble.com/VOTE-Shawn-Jiang-as-committer-tp3543011p3543381.html
Sent from the OpenEJB Dev mailing list archive at Nabble.com.
+1
Andy
--
View this message in context:
http://openejb.979440.n4.nabble.com/VOTE-Romain-Manni-Bucau-as-committer-tp3543015p3543383.html
Sent from the OpenEJB Dev mailing list archive at Nabble.com.
The close is safe as long as the key entry is removed at the same time - and
that the removal is synchronized on the factory.
I have seen several implementations that close the jar but then leave the
closed jar in the map, and that is very 'game over'.
I have looked at the Java source to try and
I like TomEE - With capitals ;-)
--
View this message in context:
http://openejb.979440.n4.nabble.com/Renaming-the-OpenEJB-Tomcat-bundle-tp3027804p3028451.html
Sent from the OpenEJB Dev mailing list archive at Nabble.com.
100 matches
Mail list logo
