Adding some notes as the person who made this mess :)
What we had there was very much the case of "someday we can use this", but
someday never came till Andy finished it. We've historically told users the
exact server and client version needed to match.
Didn't say it at the time, but *huge* th
I suspect what Romain is pointing out is we already have things like
openejb-derby, openejb-hsql and openejb-cxf. No way at this point to use
"openejb-cxf" to imply a shaded or patched version of CXF without it
conflicting with the existing openejb-cxf module where the CXF integration code
liv
User experience of out-of-the-box performance is better in general.
For example tweaks like org.terracotta.quartz.skipUpdateCheck=true
which was necessary for 1.5.2 are no longer necessary. And I'm sure
there's lots of more stuff to support such a statement.
--
Bjorn Danielsson
Cuspy Code AB
Da
Hi Andy,
Did you miss a commit? The build is broken. It looks like the versions are
missing.
[]s,
Thiago.
On Tue, Dec 10, 2013 at 11:54 AM, wrote:
> Author: andygumbrecht
> Date: Tue Dec 10 16:54:47 2013
> New Revision: 1549891
>
> URL: http://svn.apache.org/r1549891
> Log:
> Improve Multicast
Exactly why i would like to avoid it, ls quartz*. That's what is expected
(from me at least). This is smoother to compare with released versions IMO
Le 10 déc. 2013 17:43, "AndyG" a écrit :
> The name 'openejb-quartz-shade' just keeps it nice in a directory listing
> (i.e. All openejb jars togeth
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.
Hi Romain,
Thanks for your answer and sorry that I left this thread for a long time.
I already solved my problem by adding openejb-core to the project
org.apache.openejb
openejb-core
4.5.0
I'm not subscribed on tomee mailing list, but I hope you will find this
asnwer.
+1 to keep it in the build (in old deps)
however on the renaming I think keeping the shade starting with
"quartz" makes it more obvious.
Romain Manni-Bucau
Twitter: @rmannibucau
Blog: http://rmannibucau.wordpress.com/
LinkedIn: http://fr.linkedin.com/in/rmannibucau
Github: https://github.com/rmann
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.
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
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
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
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
13 matches
Mail list logo
