Fantastic list! Thanks for putting this together! Gee, maybe we
should have you do next release? :)
I didn't comment on the ones you say are completed and can be closed.
Your JIRA permissions were still at contributor level -- my bad! I
fixed that, so you should be able to close, assign, etc. Feel free to
clean and close what you need. Double check the summaries to make
sure they are worded well for release notes.
On Sep 10, 2009, at 12:49 PM, Jean-Louis MONTEIRO wrote:
· OPENEJB-965: webfault not correctly handled à patch is
available.
I guess it’s still usable for trunk.
Great, let's get that one in.
· OPENEJB-977: upgrade to latest CXF release à we worked with
Jean-Sébastien to do such upgrade. It solves some other issues (965
and
1020) but it has some drawbacks (upgrade JaxB to 2.1). Do you want
me to
update this patch again so we can apply it on trunk ?
· OPENEJB-1020: JAX-WS inheritance à it’s a JAX-WS 2.1
feature. So
we need to upgrade CXF and JaxB (OPENEJB-977)
It's a big upgrade and change to the CXF integration. Not sure what
other think, but I'd feel safer applying that patch immediately after
the 3.1.2 release so we have a whole release cycle to deal with any
issues. We could put something out on the user list like "WebService
users please try this snapshot."
· OPENEJB-1011: corrupted initial context à should be closed.
Actually it’s not an issue but a misunderstanding (sorry for that).
That one should be taken care of with this fix OPENEJB-1018. Closed
it for now.
· OPENEJB-1026: must be validated à easy to fix if needed
Not so sure about the recommendation for that one. I tried hacking on
this for bash just to make sure what we had there was right... I don't
think it is. Will launch that off in another thread.
· OPENEJB-1040: javaee-api à a discussion is in progress in
d...@list
I think the zip idea will take care of that. Hacking on OPENEJB-1049
now. Afterwards I'll take a shot at adding a new assemblies zip for
javaee-api if someone doesn't beat me to it.
· OPENEJB-1046: currently we can change url template
(openejb.wsAddress.format defaults to /{ejbDeploymentId}) and add the
moduleId if needed. So I need to clarify the request with Jean-
Sebastien.
Moreover, I need to check the spec to see how EJB web services must be
treated when deployed in a web module (shall we publish ws in the root
context or in the context container?)
I'm not too sure not being much of a ws expert. But with only
questions and no obvious quick solution seems like better to delay to
3.1.3.
· OPENEJB-1049 : stateful cache management à we already
discussed
that point on IRC. Behaviour is not relevant with OpenEJB 3.0. From
the
picture p74 of the spec, you concluded we are in the “method ready
in TX”
and we are allowing non-tx or different tx method invocation without
throwing an explicit error à did you fix it ?
Yeah, this is still a critical fix for 3.1.2.
· OPENEJB-1053: manage old servlet deployment descriptors à
I’ve
just enhance the existing JUnit test to be sure it fails ;-) (not
committed)
We should definitely get that updated. We could add a second test and
second web.xml if that makes sense for the element in question.
Do we know exactly which elements/attributes have been changed/removed
between the 2.2 descriptor and now? We had a similar issue with the
ejb-jar.xml which was reported and fixed OPENEJB-701. The problem was
that there other removed elements that needed to be supported and
those were not added till now: OPENEJB-1065, OPENEJB-1066. Hopefully
we can get everything in one go this time.
Is there someone who has time to work on this?
· OPENEJB-1063: Main-Class containing fails à I can submit
my patch
to warn and replace “/” by “.” Then, we can close this issue as
there is
still the OPENEJB-1054 opened.
Don't add the warn in but definitely do the / to . replacement and
close that issue. No need do the replacement as a backup for when the
first attempt to load the main class doesn't work. We know slashes
are never valid in class names so we can just do that the first time
around. I think we're good for OPENEJB-1063 but will have to take
another look to verify -- wish I would have commented on it when I
looked at it the first time.
-David
