David Blevins 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.
>
Did it. I added a test case even if it i'm not really satisfied with because
it looks like an itests more than a unit test case. Still opened because i
need to work on again.
David Blevins wrote:
>
>> · 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."
>
Fully agree.
David Blevins wrote:
>
>
>> · 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.
>
>
Thx
David Blevins wrote:
>
>
>
>> · 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.
>
OK
David Blevins wrote:
>
>
>> · 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.
>
>
+1
David Blevins wrote:
>
>
>
>> · 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.
>
>
Sure, i have to fix it. But for the moment i don't know how nor where ...
David Blevins wrote:
>
>
>
>> · 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.
>
>
Done.
I will read all summaries to be sure they are well worded (for me :P).
Let me know if you think i'm able to do something else.
Jean-Louis
--
View this message in context:
http://www.nabble.com/3.1.2-status-tp25389152p25491978.html
Sent from the OpenEJB Dev mailing list archive at Nabble.com.
