Re: OpenEJB Client incompatibility between 3.1.x and 4.x

Shading is not not going to resolve the situation, as serialization will break and 3.1 - early 4.6-SNAPSHOT had virtually no serialVersionUID's at all. Serialization between runtime 1.6- and 1.7+ was/is completely broken at many levels. The only hope we had was the byte 'version', but that needed

Re: Quartz, next

You need to enable the 'main' profile in the maven projects view, then the whole world comes in to say hello (takes a while even on a fast machine). Also enable automatic imports in the intellij maven settings. Andy. -- View this message in context: http://openejb.979440.n4.nabble.com/Quartz-n

Re: Quartz, next

I see what you mean now - As shade only works at the 'package' phase there is no way round this other than to use your approach - An external project dependency. Dammit Andy -- View this message in context: http://openejb.979440.n4.nabble.com/Quartz-next-tp4666498p4666717.html Sent from the

Re: Quartz, next

I agree. Just checked in for a build something that works for me - We can rename stuff later. Andy. -- View this message in context: http://openejb.979440.n4.nabble.com/Quartz-next-tp4666498p488.html Sent from the OpenEJB Dev mailing list archive at Nabble.com.

Re: Quartz, next

So how would we feel with 'openejb-shade-[quartz]' ? And eventually bring all shade jars in line with that naming? I'm happy to do the maven stuff either way. Andy -- View this message in context: http://openejb.979440.n4.nabble.com/Quartz-next-tp4666498p486.html Sent from the OpenEJB Dev

Re: Quartz, next

The name 'openejb-quartz-shade' just keeps it nice in a directory listing (i.e. All openejb jars together) -- View this message in context: http://openejb.979440.n4.nabble.com/Quartz-next-tp4666498p456.html Sent from the OpenEJB Dev mailing list archive at Nabble.com.

Re: Quartz, next

And renaming to openejb-quartz-shade would make sense i.e. produce openejb-quartz-shade-4.6.1-SNAPSHOT.jar -- View this message in context: http://openejb.979440.n4.nabble.com/Quartz-next-tp4666498p451.html Sent from the OpenEJB Dev mailing list archive at Nabble.com.

Re: OpenEJB Client incompatibility between 3.1.x and 4.x

So to sum up both: org.apache.openejb.client.Client#processRequest and... org.apache.openejb.server.ejbd.RequestHandler#processRequest (4 Implementations all added various levels of complexity) Introduced calls that broke backwards compatablity between 3.x / 4.5.x and early 4.6.x-SNAPSHOT versi

Re: Quartz, next

Damn, was too late checking this in. The only issue with quartz-openejb-shade was trying to use the quartz version rather than 'omitting' the version so that it resolves to the parent project version (i.e. 4.6.1-SNAPSHOT) - This is how it should be, as we really want to keep control of the shade a

Re: OpenEJB Client incompatibility between 3.1.x and 4.x

Check for usage of org.apache.openejb.client.ProtocolMetaData#isAtLeast. The chances of getting 3.x to 4.x working are slim (to none), and will require action on the byte 'version', and this is even more useless with a .eg 1.6 to 1.7 runtime communication due to the missing serial id's - You'll ju

Re: OpenEJB Client incompatibility between 3.1.x and 4.x

Woa - been away over the weekend, so missed all this. Give me a moment. I'll rush in without checking code so you get an idea, - I'll polish my comments in minute if I have it wrong. Newer clients can talk to older servers by setting the property, but not the other way round. The protocol initia

Buildbot: Too many open files

Seeing this on the buildbot: java.io.IOException: error=24, Too many open files Which is easily resolved with something like ulimit -n 5 However, this is usually a good indication that 'a' process is leaking file handles. Has anyone done work on files or sockets recently (a socket is often b

Re: Sleep 10s?

Then either close the socket in a finally or use is to test connectivity more before closing... -- View this message in context: http://openejb.979440.n4.nabble.com/Sleep-10s-tp4666479p4666487.html Sent from the OpenEJB Dev mailing list archive at Nabble.com.

Re: Sleep 10s?

Yes, I'd do something like: if(!connect(20,1234))throw FailMiserablyException(); public static boolean connect(int tries, final int port) try{ final Socket s = new Socket(); s.connect(new InetSocketAddress(addr, port), 150); } catch (IOException e) { if (tries < 1) { return fa

Re: [ANNOUNCE] Welcome Mark Struberg as a new Apache TomEE committer

Hi Mark, Most welcome . Andy. -- View this message in context: http://openejb.979440.n4.nabble.com/ANNOUNCE-Welcome-Mark-Struberg-as-a-new-Apache-TomEE-committer-tp4666391p4666426.html Sent from the OpenEJB Dev mailing list archive at Nabble.com.

Re: Hello, Tomee!

Hi Ivan, Have fun! Andy. -- View this message in context: http://openejb.979440.n4.nabble.com/Hello-Tomee-tp4666296p4666388.html Sent from the OpenEJB Dev mailing list archive at Nabble.com.

Re: Preparing 1.6.1 maintenance release

+1 Works for me Andy. -- View this message in context: http://openejb.979440.n4.nabble.com/Preparing-1-6-1-maintenance-release-tp4666324p4666384.html Sent from the OpenEJB Dev mailing list archive at Nabble.com.

Re: [VOTE] TomEE 1.6.0 / OpenEJB 4.6.0 (staging-120)

OK, I have a single test failing: testWithTransaction(org.superbiz.injection.tx.MoviesTest) Time elapsed: 0.285 sec <<< ERROR! javax.ejb.EJBException: The bean encountered a non-application exception; nested exception is: junit.framework.AssertionFailedError: List.size() expected:<3> bu

Re: [VOTE] TomEE 1.6.0 / OpenEJB 4.6.0 (staging-120)

+1 On windows 32bit and 64bit (with corresponding JVMs) -- View this message in context: http://openejb.979440.n4.nabble.com/VOTE-TomEE-1-6-0-OpenEJB-4-6-0-staging-120-tp4666097p4666103.html Sent from the OpenEJB Dev mailing list archive at Nabble.com.

Re: JIRA Spam

Just forwarded it now :-) -- View this message in context: http://openejb.979440.n4.nabble.com/JIRA-Spam-tp4665230p4665232.html Sent from the OpenEJB Dev mailing list archive at Nabble.com.

JIRA Spam

Just deleted the first ever spam I have seen on JIRA! Looks like we're in for a spate of it :-( Andy. -- View this message in context: http://openejb.979440.n4.nabble.com/JIRA-Spam-tp4665230.html Sent from the OpenEJB Dev mailing list archive at Nabble.com.

Re: Today's announcement

Well done David. You deserve every success! Andy. -- View this message in context: http://openejb.979440.n4.nabble.com/Today-s-announcement-tp4665226p4665229.html Sent from the OpenEJB Dev mailing list archive at Nabble.com.

Build 569 failure

The following is due to the server responding with an unexpected (out of sync) write and the client is unable to correctly read what it is expecting (the spec string). There is still somewhere a response that has changed the IO order. Having worked on this to get backwards compatibility back my gut

Re: Current test failures on trunk

Should be resolved (by Romain). Andy. -- View this message in context: http://openejb.979440.n4.nabble.com/Current-test-failures-on-trunk-tp4664795p4664856.html Sent from the OpenEJB Dev mailing list archive at Nabble.com.

Current test failures on trunk

Current test failures on trunk are caused by my recent conflict resolution commit. These were only passing due to maven conflict resolution using fudged versions, which is IMHO not the way to go. I am already looking into the failures and how to 'fix' the tests... [ERROR] Failed to execute goal

Re: Buildbot forced build.

Thanks Romain, started already :-) -- View this message in context: http://openejb.979440.n4.nabble.com/Buildbot-forced-build-tp4664788p4664790.html Sent from the OpenEJB Dev mailing list archive at Nabble.com.

Buildbot forced build.

How do we force a build on the bot? Seen Romain do it several times. The buildbot has not picked up my last check-in? Andy. -- View this message in context: http://openejb.979440.n4.nabble.com/Buildbot-forced-build-tp4664788.html Sent from the OpenEJB Dev mailing list archive at Nabble.com.

Re: EJBD

Added initial LegacyClientTest (which is currently a ripped RandomConnectionStrategyTest), but does the job. We can always add more to the test as new features are added. -- View this message in context: http://openejb.979440.n4.nabble.com/EJBD-tp4664447p4664574.html Sent from the OpenEJB Dev m

Re: EJBD

I've checked in a pretty comprehensive fix for this issue that should see us safe in the future. ProtocolMetaData can be propagated into Externalizable implementations. This can then be used to determine which version the client is capable of accepting - Especially, we cannot write a new entry to

Re: EJBD

Working on this now, the order of read write has become out of sync. Please don't rush to change anything before I commit. I have a real world scenario to work on here and when I have it working I will commit. I may not be ready till tomorrow, so please hang on. Andy. -- View this message in

Re: EJBD

I've been trying something similar, and a new request code is probably the best option. The only issue is as you state - Could this be a hole into the new server? A solution to that could be to add a server option, something like - AllowOldClients = false. Another option that I was looking at was

Re: EJBD

Cool, thanks Romain. The whole version concept seems to have been introduced adhoc, which has made this much harder than it should be. Newer clients will not be able to talk to older servers as they must send the current version (3), but older servers still have code that basically does 'if vers

Re: EJBD

Older means ...possibly only as little as 4 weeks old snapshot. But I guess that 4.5.2 clients should still be able to look up ejbs on a 4.6 server right? -- View this message in context: http://openejb.979440.n4.nabble.com/EJBD-tp4664447p4664455.html Sent from the OpenEJB Dev mailing list arch

Re: EJBD

A bit of a pain to debug hopping from client to remote server. -- View this message in context: http://openejb.979440.n4.nabble.com/EJBD-tp4664447p4664453.html Sent from the OpenEJB Dev mailing list archive at Nabble.com.

Re: EJBD

I've already changed the code a bit to look for the version, but just missing something still... Start a snapshot server, and lookup any ejb from an older client. In the client on a stop just before call to protocolMetaData.readExternal(in); in Client.java:251 Wrap stream with new BufferedReader

EJBD

Still have not got EJBD working for older clients. ProtocolMetaData gets a useless spec string back from the newer server. The order of write has changed on the server. Older clients seem to be getting a serialized EJBMetaDataImpl rather than the spec string. Any ideas? Andy. -- View this me

Re: Default include exclude order should be exclude-include

Thanks Romain, you're on top of everything! If I ever get to meet I'll be sure to get you a beer -- View this message in context: http://openejb.979440.n4.nabble.com/Default-include-exclude-order-should-be-exclude-include-tp4663418p4663534.html Sent from the OpenEJB Dev mailing list archive at

Re: Default include exclude order should be exclude-include

What do I need to do to get the site to update from the svn repo? Thought a commit would trigger it. Andy. -- View this message in context: http://openejb.979440.n4.nabble.com/Default-include-exclude-order-should-be-exclude-include-tp4663418p4663529.html Sent from the OpenEJB Dev mailing list

Re: Default include exclude order should be exclude-include

It is fine by me. Now I know what needs to be configured. I don't want to break any existing functionality. I will include some more relevant info in the docs that may help others facing the same issue. -- View this message in context: http://openejb.979440.n4.nabble.com/Default-include-exclud

Re: Default include exclude order should be exclude-include

We do, which is why I was expecting the one line include to override it - which IMHO it should, without having to add the explicit order property to correct it. I've committed, we'll see if it's a problem on the box - Working fine here now. -- View this message in context: http://openejb.97944

Re: Default include exclude order should be exclude-include

I think it should be explicit. No parameter = scan Include = include just this/these and no scan, just ignore exclude parameter (warn the user if set). Exclude = exclude this/these and only scan if include is empty However, to quickly resolve the issue based on the current defaults I really thi

Default include exclude order should be exclude-include

Pulled my hair out on this the other day until I realized what was missing. https://issues.apache.org/jira/browse/OPENEJB-2030 Shall I commit, or is there a reason for it to be the other way round, which doesn't make sense considering these are the defaults: openejb.deployments.classpath.include

Re: Fwd: svn commit: r1485786 - /tomee/tomee/trunk/pom.xml

I guess this only changes at runtime. To deploy to a lan repo the poms have to be physically changed before upload. Currently I add and use versions-maven-plugin 1.3.1 on an svn export, and search and replace for the left-overs. I don't do it that often (only when all tests pass and something sign

Re: Fwd: svn commit: r1485786 - /tomee/tomee/trunk/pom.xml

There are also several usages that could be replaced by ${parent.version} or ${parent.parent.version} ...if that would work. -- View this message in context: http://openejb.979440.n4.nabble.com/Fwd-svn-commit-r1485786-tomee-tomee-trunk-pom-xml-tp4663194p4663201.html Sent from the OpenEJB Dev ma

Re: Fwd: svn commit: r1485786 - /tomee/tomee/trunk/pom.xml

Is there already a maven module that can be used to search poms and change this value? -- View this message in context: http://openejb.979440.n4.nabble.com/Fwd-svn-commit-r1485786-tomee-tomee-trunk-pom-xml-tp4663194p4663199.html Sent from the OpenEJB Dev mailing list archive at Nabble.com.

Re: Fwd: svn commit: r1485786 - /tomee/tomee/trunk/pom.xml

Ouch, see what you mean. But this still seems wrong somehow to have this hard coded? It makes versioning a two step process outside the scope of current maven modules. I am still playing with the push snapshot to local repo and a new version. Maybe aligning the OpenEJB version with TomEE is worth

Re: failling tests

Just built off trunk, so working for me [INFO] Apache OpenEJB SUCCESS [7.382s] [INFO] OpenEJB :: Dependencies ... SUCCESS [0.201s] [INFO] OpenEJB :: Dependencies :: MBean Annotation API ... SUCCESS [4.583s] [INFO] OpenEJB :: iTests

Re: Fwd: svn commit: r1479854 - in /tomee/tomee/branches/tomee-owb-1.1.x: arquillian/arquillian-tomee-common/ arquillian/arquillian-tomee-tests/ container/openejb-api/ examples/polling-parent/polling-

Sure, was trying to deploy a known good snapshot to our local repo with a custom version to avoid confusion and noticed this was not working. mvn versions:set -DnewVersion=[version] If this is working with an older plugin then we should declare it in management maybe? -- View this message in c

Re: OWB 1.2?

I would only to ensure that the current trunk we have (which seems to be really stable right now) is available as a stable branch for potential bug fixing. What does OWB 1.2 bring to the party (your opinion, not that of OWB)? I am almost fanatical about updating libraries, so don't think I am aga

Re: OWB 1.2?

+1 Only if trunk passing, else create a branch until stable. -- View this message in context: http://openejb.979440.n4.nabble.com/OWB-1-2-tp4662300p4662323.html Sent from the OpenEJB Dev mailing list archive at Nabble.com.

Re: anyone to review/commit the ix in ApplicationComposers?

OK, will commit something later. -- View this message in context: http://openejb.979440.n4.nabble.com/anyone-to-review-commit-the-ix-in-ApplicationComposers-tp4662301p4662319.html Sent from the OpenEJB Dev mailing list archive at Nabble.com.

Re: anyone to review/commit the ix in ApplicationComposers?

The users test now passes but I am not sure about pulling in the deps for it if we were to integrate it into the project. Is the issue 'org.apache.deltaspike' specific, or do we have something else we can use for a test already? I'm looking, but I'm sure you have a deeper understanding of the iss

Re: anyone to review/commit the ix in ApplicationComposers?

I'll do it now. Andy. -- View this message in context: http://openejb.979440.n4.nabble.com/anyone-to-review-commit-the-ix-in-ApplicationComposers-tp4662301p4662315.html Sent from the OpenEJB Dev mailing list archive at Nabble.com.

Re: [RESULT] TomEE 1.5.2/OpenEJB 4.5.2 (staging-008)

Late I know. But +1 from me. Was on Easter break, and just built/passed on Win7 box this morning. Andy. -- View this message in context: http://openejb.979440.n4.nabble.com/VOTE-TomEE-1-5-2-OpenEJB-4-5-2-staging-008-tp4661645p4661893.html Sent from the OpenEJB Dev mailing list archive at Nabbl

Re: Case insensitive org.apache.openejb.config.AutoConfig#findResourceId

Where to put... final OpenEjbConfiguration configuration = SystemInstance.get().getComponent(OpenEjbConfiguration.class); final Iterator iterator = configuration.facilities.resources.iterator(); while (iterator.hasNext()) { final ResourceInfo info = iterator.next(); if([TheResource

Re: Case insensitive org.apache.openejb.config.AutoConfig#findResourceId

In that case it is critical that the old DataSource resource id is removed from wherever it is being cached when the resource is destroyed/removed/unbound else the org.apache.openejb.config.AutoConfig#findResourceId assumes it is still a valid id. I believe this is going to be from: SystemInstanc

Case insensitive org.apache.openejb.config.AutoConfig#findResourceId

org.apache.openejb.config.AutoConfig#findResourceId uses 'equalsIgnoreCase'. I doubt this is correct for at least DataSources as 'dsBob' is not the same as 'dsBOB' - Not sure about other resource IDs. I came across this specifically undeploying an app with say 'Bob' and then deploying a new app n

Re: Deploy snapshot build to a remote repository in local network

OK, got it in the end. So here for info Created a pom above the 'tomee' directory like so: http://maven.apache.org/POM/4.0.0"; xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd";> 4

Deploy snapshot build to a remote repository in local network

Hi All, I would like to build the snapshot and deploy it to a local network repository. Is there a way to do this without actually modifying the main pom.xml? I tried this with a parent pom, but deploy always tries to deploy to the apache.org repo. Cheers, Andy. -- View this message in context

Re: [VOTE] Release javaee-api 6.0-5

+1 -- View this message in context: http://openejb.979440.n4.nabble.com/VOTE-Release-javaee-api-6-0-5-tp4661574p4661597.html Sent from the OpenEJB Dev mailing list archive at Nabble.com.

Re: slow multicast discovery can be optimized by caching server...

So this is much easier than you think and is what I have already said. If ActiveMQ is on localhost to OpenEJB this will do: I am guessing you know how to create and access a simple stateless bean from OpenEJB: http://tomee.apache.org/examples-trunk/simple-stateless/README.html Create a simple EJ

Re: slow multicast discovery can be optimized by caching server...

In trunk (4.6 snapshot at the time of writing) there is now the option to 'ignore' hosts in the multipulse.properties. The original desire for MultiPulse was a virtually zero configuration for discovery of multi-homed systems. For example some of my server machines ship with up to 5 Ethernet camer

Sun JDK Buildbot

For your info, the Sun JDK Buildbot is now only failing due to long file name issues in the TCK. I have reported this here: https://issues.jboss.org/browse/CDITCK-297 If we were able to reduce the root directory on the bot to a minimum we might get a real pass. I would like to leave the maven -

Re: openejb multicast with activemq

For a start, ActiveMQ might not even be on the same machine if OpenEJB is configured to use a remote ActiveMQ server. The fact that we start an embedded broker is purely to provide an out of the box solution. You may even choose to use a completely different MQ. You and your application are respon

Re: slow multicast discovery can be optimized by caching server...

Up till now I was allowing the connection pool to do the caching of valid connections once a server was found. Using this in house has been working very well. You can tune the URI 'timeout' option to be as low as possible for your network - This is the amount of time the client will sift the multi

Re: slow multicast discovery can be optimized by caching server...

Try running this from the OpenEJB directory when the server is running. java -cp lib/*.jar;lib/openejb-client-4.6.0-SNAPSHOT.jar org.apache.openejb.client.MulticastPulseClient Then post a snippet of the results here, it should list all multipulse enabled servers in your LAN. You should get somet

Generics safety, class.isInstance vs instanceOf

A thought aloud. As more and more of my code and several libraries that I use slide towards generics I have found 'class.isInstance' far more useful than 'instanceOf', to the point where I literally never use it. http://docs.oracle.com/javase/1.5.0/docs/api/java/lang/Class.html#isInstance%28java.

Re: svn commit: r1442065 - in /tomee/tomee/trunk: examples/groovy-cdi/ examples/groovy-jpa/ examples/groovy-spock/ examples/groovy-spock/src/main/java/org/superbiz/groovy/ examples/groovy-spock/src/te

For your info... [INFO] Reactor Summary: [INFO] [INFO] OpenEJB :: iTests :: Failover . SUCCESS [2:48.955s] [INFO] OpenEJB :: Maven Plugins .. SUCCESS [8.552s] [INFO] OpenEJB :: Maven Plugins :: TomEE Maven Plugin SUCCESS [19.265s] [INFO] OpenEJB :: T

Re: svn commit: r1442065 - in /tomee/tomee/trunk: examples/groovy-cdi/ examples/groovy-jpa/ examples/groovy-spock/ examples/groovy-spock/src/main/java/org/superbiz/groovy/ examples/groovy-spock/src/te

TomEE is now passing everything on both my Win32/64 test boxes so I though I'd push it out there and see how it fairs for the rest of the world There are some significant 2.1.0 fixes

Re: Help!!!!one MDB deploy standalone openejb ,but lookup ConnectionFactory result is null!

I am guessing you are trying to access ActiveMQ from a remote client, so try: final Properties env = new Properties(); env.setProperty(Context.INITIAL_CONTEXT_FACTORY, org.apache.activemq.jndi.ActiveMQInitialContextFactory"); env.setProperty(Context.PROVIDER_URL, String.format("failover:(nio://%1$

Recent ManagedConnection changes have possibly broken something.

Will try and reproduce in a test case, but posting this now to give you a heads up. Not sure if ManagedConnection is responsible, but seems to be a likely candidate. Basic scenario is a test with 50 threads concurrently accessing a stateless EJB. It initially looks like that connections in an acti