Skip to main content

Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

Difference between revisions of "EclipseLink/Development/DevMeetings"

m (SDO / MOXy)
m
Line 27: Line 27:
  
 
=== Ad Hoc ===
 
=== Ad Hoc ===
# ASM <br/> Each DBWS web service <tt>.war</tt> file contains an ASM-generated class that implements the JAX-WS <code>javax.xml.ws.Provider</code> API
 
<source lang="java5">
 
public interface Provider<T> {
 
 
    T invoke(T request) {
 
        return ...
 
    }
 
}
 
</source>
 
For DBWS, the generic <code><T></code> is bound to <code>javax.xml.soap.SOAPMessage</code>. In addition, the generated class requires a number annotations to indicate information about WSDL, target XML namespace, resource injection and lifecycle methods:
 
<source lang="java5">
 
//Java extension libraries
 
import javax.annotation.PostConstruct;
 
import javax.annotation.PreDestroy;
 
import javax.annotation.Resource;
 
import javax.servlet.ServletContext;
 
import javax.xml.soap.SOAPMessage;
 
import javax.xml.ws.BindingType;
 
import javax.xml.ws.Provider;
 
import javax.xml.ws.ServiceMode;
 
import javax.xml.ws.WebServiceContext;
 
import javax.xml.ws.WebServiceProvider;
 
import static javax.xml.ws.Service.Mode.MESSAGE;
 
 
//EclipseLink imports
 
import org.eclipse.persistence.internal.dbws.ProviderHelper;
 
 
@WebServiceProvider(
 
    wsdlLocation = "WEB-INF/wsdl/eclipselink-dbws.wsdl",
 
    serviceName = {SERVICE NAME},
 
    portName = {SERVICE NAME + "Port"},
 
    targetNamespace = {SERVICE NAMESPACE}
 
)
 
@ServiceMode(MESSAGE)
 
public class DBWSProvider extends ProviderHelper implements Provider<SOAPMessage> {
 
    public  DBWSProvider() {
 
        super();
 
    }
 
    @Resource
 
    protected WebServiceContext wsContext;
 
    @PostConstruct
 
    public void init() {
 
        ...
 
    }
 
    @Override
 
    public SOAPMessage invoke(SOAPMessage request) {
 
        if (wsContext != null) {
 
            setMessageContext(wsContext.getMessageContext());
 
        }
 
        return super.invoke(request);
 
    }
 
    @PreDestroy
 
    public void destroy() {
 
        ...
 
    }
 
</source>
 
A <tt>.war</tt> file containing <code>_dbws.DBWSProvider</code> will deploy to a WebLogic server fine, but when the <code>invoke(request)</code> method is hit, a <tt>.dump</tt> file is generated for JRockit JVMs; the same <tt>.war</tt> file, deployed to the same WebLogic server running on the Sun JDK, works fine.
 
 
The underlying problem is the old version of ASM in <code>o.e.p.internal.libraries.asm</code> - it is based on ASM 1.5.3 (circa late 2004/early 2005) plus a custom patch (we called it 1.5.4, but the patch was never accepted by the ASM community). When I re-implemented the one class <code>o.e.p.tools.dbws.ProviderPackager</code> that does all the ASM work for the <code>DBWSBuilder</code>, the <tt>.war</tt> file works for both JRockit <b>and</b> Sun JVMs.
 
 
There are no runtime-dependencies to ASM (1.5 or 3.n, internal or external) for generated <code>DBWSProvider</code>'s - this is solely a design-time requirement.
 
 
The proposal is to include in the TopLink standalone installer a copy of ASM 3.1 in ...\eclipse\utils\dbws (org.objectweb.asm_3.1.0.v200803061910.jar from Orbit) and generate a new jar file (eclipselink-dbwsutils-asm3.jar) that, if the user requires, can be placed <b>ahead</b> of the 'real' eclipselink-dbwsutils.jar file so that the new functionality can be used to generate a <tt>.war</tt> file that works with JRockit JVMs.
 
 
For the EclipseLink installer, the issue is whether or not we can get a CQ thru the system in time for Helios/2.1
 
 
=== Release Planning ===
 
 
=== QA  ===
 
 
=== Build ===
 
 
=== JPA  ===
 
 
==== Foundation and JPA  ====
 
 
=== DBWS  ===
 
 
=== SDO / MOXy  ===
 
 
=== Dynamic Persistence ===
 
 
=== EclipseLink Incubator  ===
 
 
=== Documentation ===
 
 
=== Bug Status  ===
 
[http://wiki.eclipse.org/EclipseLink/Bugs Bug reports]
 
 
== Agenda Mar 25, 2010  ==
 
 
[http://www.timeanddate.com/worldclock/fixedtime.html?month=11&day=27&year=2009&hour=11&min=0&sec=0&p1=188 11 am EST, Thurs Mar 25, 2009]
 
  
== Ad Hoc  ==
 
  
 
== Release Planning ==
 
== Release Planning ==
Line 222: Line 129:
 
* Scoping out potential EclipseLink feature work
 
* Scoping out potential EclipseLink feature work
 
** Improved Sparse Merge support (an 'Update' operation currently requires the instance to be fully specified in the SOAP message)
 
** Improved Sparse Merge support (an 'Update' operation currently requires the instance to be fully specified in the SOAP message)
 +
 +
* Bug - Using DBWS in JRockit environment due to ASM generated class incompatibility
 +
# ASM <br/> Each DBWS web service <tt>.war</tt> file contains an ASM-generated class that implements the JAX-WS <code>javax.xml.ws.Provider</code> API
 +
<source lang="java5">
 +
public interface Provider<T> {
 +
 +
    T invoke(T request) {
 +
        return ...
 +
    }
 +
}
 +
</source>
 +
For DBWS, the generic <code><T></code> is bound to <code>javax.xml.soap.SOAPMessage</code>. In addition, the generated class requires a number annotations to indicate information about WSDL, target XML namespace, resource injection and lifecycle methods:
 +
<source lang="java5">
 +
//Java extension libraries
 +
import javax.annotation.PostConstruct;
 +
import javax.annotation.PreDestroy;
 +
import javax.annotation.Resource;
 +
import javax.servlet.ServletContext;
 +
import javax.xml.soap.SOAPMessage;
 +
import javax.xml.ws.BindingType;
 +
import javax.xml.ws.Provider;
 +
import javax.xml.ws.ServiceMode;
 +
import javax.xml.ws.WebServiceContext;
 +
import javax.xml.ws.WebServiceProvider;
 +
import static javax.xml.ws.Service.Mode.MESSAGE;
 +
 +
//EclipseLink imports
 +
import org.eclipse.persistence.internal.dbws.ProviderHelper;
 +
 +
@WebServiceProvider(
 +
    wsdlLocation = "WEB-INF/wsdl/eclipselink-dbws.wsdl",
 +
    serviceName = {SERVICE NAME},
 +
    portName = {SERVICE NAME + "Port"},
 +
    targetNamespace = {SERVICE NAMESPACE}
 +
)
 +
@ServiceMode(MESSAGE)
 +
public class DBWSProvider extends ProviderHelper implements Provider<SOAPMessage> {
 +
    public  DBWSProvider() {
 +
        super();
 +
    }
 +
    @Resource
 +
    protected WebServiceContext wsContext;
 +
    @PostConstruct
 +
    public void init() {
 +
        ...
 +
    }
 +
    @Override
 +
    public SOAPMessage invoke(SOAPMessage request) {
 +
        if (wsContext != null) {
 +
            setMessageContext(wsContext.getMessageContext());
 +
        }
 +
        return super.invoke(request);
 +
    }
 +
    @PreDestroy
 +
    public void destroy() {
 +
        ...
 +
    }
 +
</source>
 +
A <tt>.war</tt> file containing <code>_dbws.DBWSProvider</code> will deploy to a WebLogic server fine, but when the <code>invoke(request)</code> method is hit, a <tt>.dump</tt> file is generated for JRockit JVMs; the same <tt>.war</tt> file, deployed to the same WebLogic server running on the Sun JDK, works fine.
 +
 +
The underlying problem is the old version of ASM in <code>o.e.p.internal.libraries.asm</code> - it is based on ASM 1.5.3 (circa late 2004/early 2005) plus a custom patch (we called it 1.5.4, but the patch was never accepted by the ASM community). When I re-implemented the one class <code>o.e.p.tools.dbws.ProviderPackager</code> that does all the ASM work for the <code>DBWSBuilder</code>, the <tt>.war</tt> file works for both JRockit <b>and</b> Sun JVMs.
 +
 +
There are no runtime-dependencies to ASM (1.5 or 3.n, internal or external) for generated <code>DBWSProvider</code>'s - this is solely a design-time requirement.
 +
 +
The proposal is to include in the TopLink standalone installer a copy of ASM 3.1 in ...\eclipse\utils\dbws (org.objectweb.asm_3.1.0.v200803061910.jar from Orbit) and generate a new jar file (eclipselink-dbwsutils-asm3.jar) that, if the user requires, can be placed <b>ahead</b> of the 'real' eclipselink-dbwsutils.jar file so that the new functionality can be used to generate a <tt>.war</tt> file that works with JRockit JVMs.
 +
 +
For the EclipseLink installer, the issue is whether or not we can get a CQ thru the system in time for Helios/2.1
  
 
== SDO / MOXy  ==
 
== SDO / MOXy  ==

Revision as of 16:14, 31 March 2010



Dial In Info:

  • please contact Peter Krogh for dial in information.


The EclipseLink committers have a regular meeting (currently weekly) to discuss ongoing development issues and projects. All interested parties are welcome to attend. If you have any additional items you wished discussed please add them at the bottom of the agenda including a brief description and any relevant links. Alternatively development issues can be discussed on the EclipseLink Dev mailing list.

* When adding agenda items please send an email to the eclipselink-dev@eclipse.org list notifying attendees. This will ensure attendees are aware of agenda items prior to the meeting.

Call Schedule

The calendar is available in the following formats:
Ical.gifiCal,Xml.gifATOM News Feed,Html.gifHTML



Agenda Apr 1, 2010

11 am EST, Thurs Apr 1st, 2010

Ad Hoc

Release Planning

Mar 19 - 25, 2010:

  • Nightly Results
    • 1.1.4 - JPA/Glassfish 2.0 jpql test failires
    • 2.0.2 - clean
    • 1.2.0 - no recent builds
    • trunk - JPA/J2SE no weave 5 tests failed - investigating
  • Last week
    • Fixed Bugs
      • 296279 - jpql.JUnitJPQLComplexTestSuite.complexConstructorCaseTest failed with Derby
      • 290069 - testOrderCustomerMapping within jpa.xml.merge.relationships.EntityMappingsMergeRelationshipsJUnitTestCase failed on JBoss
      • 274584 - testUpdateUsingTempStorageWithParameter and testUpdateUsingTempStorage failed on SQL Server 2k5
      • 305865 - jpa.fieldaccess.advanced.AdvancedJPAJunitTest.testPessimisticLockingNamedQuery failed on Derby
      • 305330 - EclipseLink JPA tests failed On JBOSS EAP 5.0.0 GA JNDI lookup failure of EJB Proxy Factory
      • 305331 - Unsigned eclipselink.jar doesn't work with signed ejb3-persistence.jar for JPA testing on JBOSS EAP 5.0.0 GA
    • JPA 2.0 TCK enable nightly - completed
    • EL 2.1 Advanced Query - FUNC support test spec 90%; Downcast - reviewing dev documentation
    • EL 2.1 Advanced JPA Config - reviewing dev documentation
    • JAXB 2.2 TCK - automation work completed
    • Changed test scripts to fix issues with running JPA/JBoss EAP (JBoss Community has always run)
    • Triage - 7 bugs filed
  • This week
    • Continue with EL 2.1 test dev work - Advanced querying, Advanced JPA config
    • Enable SDO/Websphere
    • Fix Bugs

Build

  • Milestone Releases
    • M6 EclipseLink
    • M6 Helios contribution (nightly build)
      • Due to an uncaught bug found by the Helios build system.
      • We need to modify our milestone strategy. Milestones should be promoted *after* the Helios contribution is made.
  • "target platform" work for Helios (bug 306188)
    • RT is requesting we simplify how we are included in RT - siingle SDK
      • the one feature can and should simply include our other already existing features.
  • As of M6 EclipseLink is no longer shipped with the Java EE Package
    • As a team we need to decide:
      • What we should offer regarding IDE tooling that helps the developer use EclipseLink
      • If we should help another team provide it (Dali ?)
  • Helios build integration (293034) (Blocked until Post M6)
    • Need to do p2 consolidation work to manage multiple versions in a single update location.
      • investigation composite repositories
        • Have working prototype.
        • Working on creating a Composite of all our releases - (completed locally).
          • Cannot generate on Download machine due to bug 303802 fix will be available in M6 helios release.
        • Still need to finalize automation.
          • Automation for Composite work still pending. Looks like a separate script will be necessary.
      • Migration from p2.metadata.generator to p2.publisher (Blocked by bug 303802).
        • Prototype complete.
          • Awaiting confirmation of a bugfix before commit (Blocked by bug 303802).
          • Still need to finalize automation (Blocked by bug 303802).
  • Test component build cleanup (Holding)
    • Restructure to allow testing to *not* rebuild product jars (293032)
      • Will use "static targets" as discussed in meeting last week (297217).
      • Tests will not compile when run target called.
        • merged partial work to update standards.
        • migration work for test projects, currently priority 2
    • Need shippable testing artifacts (R2).
  • jpa.test10 Suite (Holding)
    • Explore possibility of using eclipselink.jpa.test from 1.1.3 as a way to certify javax.persistence 1.0 backward compatability in EclipseLink 2.0.x
      • All tests now compiling with trunk, 83% success rate on Test run.
      • Awaiting review by Tom or Peter of test results (still).
    • Need "project name" assuming this gets running 100%

Fixed Bugs:

JPA

Mar 25

2.1.0

  • Bugs with Votes

DBWS

DBWS Development

2.0.2

  • No remaining bugs

2.1.0

  • 290156 Validate SOAP message elements
  • Scoping out potential EclipseLink feature work
    • Improved Sparse Merge support (an 'Update' operation currently requires the instance to be fully specified in the SOAP message)
  • Bug - Using DBWS in JRockit environment due to ASM generated class incompatibility
  1. ASM
    Each DBWS web service .war file contains an ASM-generated class that implements the JAX-WS javax.xml.ws.Provider API
public interface Provider<T> {
 
     T invoke(T request) {
         return ...
     }
}

For DBWS, the generic <T> is bound to javax.xml.soap.SOAPMessage. In addition, the generated class requires a number annotations to indicate information about WSDL, target XML namespace, resource injection and lifecycle methods:

//Java extension libraries
import javax.annotation.PostConstruct;
import javax.annotation.PreDestroy;
import javax.annotation.Resource;
import javax.servlet.ServletContext;
import javax.xml.soap.SOAPMessage;
import javax.xml.ws.BindingType;
import javax.xml.ws.Provider;
import javax.xml.ws.ServiceMode;
import javax.xml.ws.WebServiceContext;
import javax.xml.ws.WebServiceProvider;
import static javax.xml.ws.Service.Mode.MESSAGE;
 
//EclipseLink imports
import org.eclipse.persistence.internal.dbws.ProviderHelper;
 
@WebServiceProvider(
    wsdlLocation = "WEB-INF/wsdl/eclipselink-dbws.wsdl",
    serviceName = {SERVICE NAME},
    portName = {SERVICE NAME + "Port"},
    targetNamespace = {SERVICE NAMESPACE}
)
@ServiceMode(MESSAGE)
public class DBWSProvider extends ProviderHelper implements Provider<SOAPMessage> {
    public  DBWSProvider() {
        super();
    }
    @Resource
    protected WebServiceContext wsContext;
    @PostConstruct
    public void init() {
        ...
    }
    @Override
    public SOAPMessage invoke(SOAPMessage request) {
        if (wsContext != null) {
            setMessageContext(wsContext.getMessageContext());
        }
        return super.invoke(request);
    }
    @PreDestroy
    public void destroy() {
        ...
    }

A .war file containing _dbws.DBWSProvider will deploy to a WebLogic server fine, but when the invoke(request) method is hit, a .dump file is generated for JRockit JVMs; the same .war file, deployed to the same WebLogic server running on the Sun JDK, works fine.

The underlying problem is the old version of ASM in o.e.p.internal.libraries.asm - it is based on ASM 1.5.3 (circa late 2004/early 2005) plus a custom patch (we called it 1.5.4, but the patch was never accepted by the ASM community). When I re-implemented the one class o.e.p.tools.dbws.ProviderPackager that does all the ASM work for the DBWSBuilder, the .war file works for both JRockit and Sun JVMs.

There are no runtime-dependencies to ASM (1.5 or 3.n, internal or external) for generated DBWSProvider's - this is solely a design-time requirement.

The proposal is to include in the TopLink standalone installer a copy of ASM 3.1 in ...\eclipse\utils\dbws (org.objectweb.asm_3.1.0.v200803061910.jar from Orbit) and generate a new jar file (eclipselink-dbwsutils-asm3.jar) that, if the user requires, can be placed ahead of the 'real' eclipselink-dbwsutils.jar file so that the new functionality can be used to generate a .war file that works with JRockit JVMs.

For the EclipseLink installer, the issue is whether or not we can get a CQ thru the system in time for Helios/2.1

SDO / MOXy

2.0.2

  • All 2.0.2 bugs resolved

2.1.0

  • Representation of JAXB Annotations and enhanced MOXy metadata in externalized 'eclipselink-oxm.xml' metadata format Design
  • MOXY Dynamic Persistence Design
  • JAXB2.2 Compliance
    • JAXB 2.1.12, 2.2 API, Impl jars submitted to Orbit
    • Need to determine whether new CQ is required for XJC, based on new Dynamic Persistence runtime dependency
  • OSGi, Server testing
    • Discussion with Dev, QA teams to improve the level of server and OSGi testing we have for MOXy and SDO components.

Dynamic Persistence

Dynamic Persistence

EclipseLink Incubator

EclipseLink/Development/Incubation

Documentation

  • Working on automated doc build process (Rick & Eric)
    If not possible, Rick is working on an automated localized doc build process, and would simply post the daily doc builds
  • Updated Documentation Requirements and Build Proposal
  • Several "chapters" currently stored in XML. More to come once the production/build process is finalized.
  • Need discussion about how the strategy we are using for User Documentation compares to the wiki-based strategy we are using for developer documentation and whether there is merit to changing the way we do developer documentation. This discussion should wait until we have used found all the issues with our User Documentation Strategy.

Bug Status

Bug reports

Foundation and JPA

Bugs By Target and Priority

Resolved Bugs

Created Bugs


EclipseLink/Development/DevMeetings/ArchiveBugReports

Back to the top