<< Back to previous view

[JAVA-1] Accessing SCA Services from non-SCA component code
Created: 03/Oct/07  Updated: 16/Feb/10

Status: Closed
Project: OASIS SCA Java TC
Component/s: Java Common Annotations and APIs specification
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Critical
Reporter: Ron Barack Assigned To: Unassigned
Resolution: Fixed Votes: 0


 Description   
 

TARGET: Java Common Annotations and APIs specification,

        Section titled "ComponentContext" (currently 1.4.2.1)

 

DESCRIPTION:

Code that is completely external to an SCA domain can communicate to SCA services through the externally advertised service bindings.

 

However, there is sometimes code that is deployed that shares much in common with the SCA domain. In increasing levels of coupling, the code might:

1. Have SCA APIs on the classpath, implemented to work with the target domain

2. The client code is running on one of the JVM runtimes that is associated with the target domain.

3. The client code was deployed as part of an SCA deployment, but the code is not within an SCA component.

 

In some or all of these cases, we should provide a simple way for the client to access the target component.

 

The current specification implies that the client would accomplish this by accessing some ComponentContext that has references injected on it, although it does not describe what component to use for this purpose (after all, the client is not associated with a component). Here is the current text of that section:

 

Non-SCA client code can use the ComponentContext API to perform operations against a component in an SCA domain. How client code obtains a reference to a ComponentContext is runtime specific. The following example demonstrates the use of the component Context API by non-SCA code:

ComponentContext context = // obtained through host environment-specific means

HelloService helloService = context.getService(HelloService.class,"HelloService");

String result = helloService.hello("Hello World!");

 

 

 

PROPOSAL:

 

Nothing yet.

 


 Comments   
Comment by Dave Booz [ 05/Dec/08 10:39 AM ]
awaiting proposal
Comment by Dave Booz [ 27/Mar/09 10:39 AM ]
latest proposal: http://lists.oasis-open.org/archives/sca-j/200903/msg00160.html
Comment by Dave Booz [ 29/Jun/09 09:48 AM ]
latest proposal: http://www.oasis-open.org/apps/org/workgroup/sca-j/download.php/33076/sca-javacaa-1.1-spec-cd02-rev3%20Issue1%20rev%207.doc
Comment by Dave Booz [ 29/Jun/09 10:06 AM ]
latest proposal: http://www.oasis-open.org/apps/org/workgroup/sca-j/download.php/33155/sca-javacaa-1.1-spec-cd02-rev3%20Issue1%20rev%208.pdf
Comment by Dave Booz [ 29/Jun/09 10:09 AM ]
latest proposal: http://www.oasis-open.org/apps/org/workgroup/sca-j/download.php/33156/sca-javacaa-1.1-spec-cd02-rev3%20Issue1%20rev%208.doc
Comment by Dave Booz [ 06/Jul/09 09:46 AM ]
latest proposal: http://www.oasis-open.org/apps/org/workgroup/sca-j/download.php/33169/sca-javacaa-1.1-spec-cd02-rev3%20Issue1%20rev%209.pdf
Comment by Dave Booz [ 06/Jul/09 10:23 AM ]
resolved July 6: with proposal above plus two additions as shown in minutes
Comment by Dave Booz [ 16/Sep/09 02:09 PM ]
applied in CAA cd03-rev1: http://www.oasis-open.org/committees/download.php/34240/sca-javacaa-1.1-spec-cd03-rev1.pdf
Comment by Dave Booz [ 16/Feb/10 11:17 AM ]
Closed as a result of CD vote on Feb 15,2010.




[JAVA-2] Determining the data binding to use (e.g. JAXB or SDO)
Created: 03/Oct/07  Updated: 09/Mar/09

Status: Closed
Project: OASIS SCA Java TC
Component/s: Java Common Annotations and APIs specification
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Minor
Reporter: Ron Barack Assigned To: Unassigned
Resolution: Won't Fix Votes: 0


 Description   
TARGET: Java Common Annotations and APIs specification,

        Section titled "WSDL to Java and Java to WSDL"

 

DESCRIPTION:

This section states the following:

For the mapping from Java types to XML schema types SCA supports both the SDO 2.0 [2] mapping and the JAXB [3] mapping.

 

Metadata should be defined which describes which of the two data bindings is used (or perhaps some other).


 Comments   
Comment by Dave Booz [ 05/Dec/08 10:39 AM ]
awaiting proposal
Comment by Dave Booz [ 09/Mar/09 10:37 AM ]
resolved Mar 9 telecon - CNA




[JAVA-3] Local services expose implementation classes as their type
Created: 03/Oct/07  Updated: 12/Nov/08

Status: Closed
Project: OASIS SCA Java TC
Component/s: Java Component Implementation Specification
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Ron Barack Assigned To: Unassigned
Resolution: Fixed Votes: 0
Environment: Also effects the Java Common Annotations and APIs Specification


 Description   
TARGET: Java Common Annotations and APIs specification

        Java Component Implementation Specification

            Section titled: "Local and Remotable Services"

 

DESCRIPTION:

 

Currently, this section states the following:

 

If an implementation class has implemented interfaces that are not decorated with an @Remotable annotation, the class is considered to implement a single local service whose type is defined by the class.

 

This is unfortunate, since the extremely common pattern of:

 

   class FooImpl implements Foo {}

 

Will result in a component that offers a service whose type is FooImpl (assuming that Foo hasn't been marked as @Remotable).

 

It should be possible for this pattern to result in a service whose type is the Foo interface.

 

PROPOSAL:

 

Introduce a new interface annotation called @Local. If a component implementation implements an interface that has been marked as @Local, then the component type will include a service whose type is that interface.

 


 Comments   
Comment by Dave Booz [ 12/Nov/08 03:10 AM ]
Closed No Action at Nov 11 F2F




[JAVA-4] Dependency reinjection
Created: 03/Oct/07  Updated: 06/Oct/08

Status: Closed
Project: OASIS SCA Java TC
Component/s: Java Common Annotations and APIs specification
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Ron Barack Assigned To: Unassigned
Resolution: Fixed Votes: 0


 Description   
TARGET: Java Common Annotations and APIs specification

        section "@Reference"

 

DESCRIPTION:

 

The description of the @Reference annotation does not specify what happens if the wire changes after the component has been instantiated. One example of a place where this could occur is for a composite-scoped component that exists at the domain level. The target of its reference could start off unwired (and thus would be null). A later deployment could deploy a <wire source="" target=""> element which provides a target for this component.

AMENDMENT:
This issue covers not only @Reference, but also (reinjection of) @Callback and @Property.
 

PROPOSAL:

 

In the above scenario, when constructor-based injection is not being used, the target MAY be reinjected.

 

This would be marked as "MAY" behavior, since it would not be required of all runtimes. However, the developer who is creating portable code needs to know that this reinjection may occur.

 

Other scenarios where such reinjection may occur is TBD. Note that reinjection should never occur for a conversational-scoped component that is in middle of its conversation.



 Comments   
Comment by Michael Rowley [ 28/Nov/07 09:23 AM ]
In the Java TC Meeting of 2007-11-08 we resolved the following things that affect reinjection of callbacks:
- The editors should be directed to add wording to the specification: Dependency injection for callbacks cannot be used for composite scoped components.
- The setcallback method can not be called while a conversation is in progress. The spec should say that @Callbacks will never be reinjected.
Comment by Michael Rowley [ 02/Jan/08 01:00 PM ]
In the SCA-J meeting of 2007-12-20 we resolved the following:

The ServiceReference corresponds to the (logical) target service of the reference. If that service is undeployed after the service reference is created then attempts to call business methods through that ServiceReference SHOULD throw InvalidServiceException. If the target service is modified, then the service reference MAY continue to work, depending on the runtime and the type of change that was made. If it doesn't work, the exception thrown will depend on the runtime and the cause of the failure.

Comment by Michael Rowley [ 17/Jan/08 01:07 PM ]
On 2007-01-17 we finalized this chart of dynamic behaviors:

http://www.oasis-open.org/apps/org/workgroup/sca-j/download.php/26845/Issue%204%20-%20Dynamic%20Modification%20Behavior%20v5.xls
Comment by Michael Rowley [ 07/Feb/08 01:20 PM ]
From meeting of 2007-01-31:

Resolved: Reinjection can occur anytime after the original injection, subject to restrictions that are already in the spec (such as those regards to conversation).
Comment by Michael Rowley [ 07/Feb/08 01:22 PM ]
On 2008-02-07 we RESOLVED this issue according to the proposal text at:

http://www.oasis-open.org/apps/org/workgroup/sca-j/download.php/27104/Issue_4_Resolution_01.doc

and the table in the spreadsheet at:

http://www.oasis-open.org/apps/org/workgroup/sca-j/download.php/27105/Dynamic%20Modification%20Behavior%20v6.xls

Comment by Anish Karmarkar [ 28/Feb/08 03:46 AM ]
Issue resolution applied in http://www.oasis-open.org/apps/org/workgroup/sca-j/download.php/27397/sca-javacaa-draft-20080228.doc
Comment by Dave Booz [ 06/Oct/08 11:59 AM ]
Incorporated into earlier drafts

Oct 6 - WD05 accepted as CD01
http://www.oasis-open.org/committees/download.php/29558/sca-javacaa-1.1-spec-WD05.pdf




[JAVA-5] EJB remove method on EJBHome
Created: 03/Oct/07  Updated: 16/Feb/10

Status: Closed
Project: OASIS SCA Java TC
Component/s: EJB Session Binding Specification
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Ron Barack Assigned To: Unassigned
Resolution: Fixed Votes: 0


 Description   
TARGET: EJB Session Binding Specification section 2.3.1 (section number from 1.0 version of the spec)

 

DESCRIPTION:

 

In the discussion of the Ejb 2.x client view in section 2.3.1 it says:

 

"When the SCA conversation with a stateful session bean ends, for example as a result of a call to ServiceReference.endSession(), the associated session object will be removed by calling the EJB Home remove() method."

 

Shouldn't this really be a call to the remove method on the EJBObject instead of the EJBHome? The EJBHome interface has the following two remove methods:

 

Public void remove(javax.ejb.Handle handle);

Public void remove(Object primaryKey);

 

The second remove method would be illegal to invoke on a session bean home. The first remove method implies a prior call to EJBObject.getHandle(). Further, the EJBLocalHome interface only has the remove method that takes the primary key.

 

PROPOSAL:

 

The remove method on the EJBObject or EJBLocalObject interface should be used to remove the EJB.

 



 Comments   
Comment by Ron Barack [ 04/Oct/07 12:51 PM ]
Proposed solution accepted in call on 4. Oct. 2007
Comment by Dave Booz [ 04/Oct/07 02:03 PM ]
Updated Draft document uploaded: http://www.oasis-open.org/committees/download.php/25551/sca-ejbbinding-draft-20071004.doc
Comment by Dave Booz [ 16/Feb/10 11:17 AM ]
Closed as a result of CD vote on Feb 15,2010.




[JAVA-6] @AllowsPassByReference requires more detailed description
Created: 04/Oct/07  Updated: 11/May/09

Status: Closed
Project: OASIS SCA Java TC
Component/s: Java Common Annotations and APIs specification
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Critical
Reporter: Ron Barack Assigned To: Anish Karmarkar
Resolution: Fixed Votes: 0


 Description   
TARGET:

Java Common Annotations and APIs specification, section "Java Annotations" / "@AllowsPassByReference"

DESCRIPTION:

That section currently states the requirement that the callee must adhere to by-value semantics when indicating that a method of a remotable interface allows the optimization of by-reference parameter passing.

It lacks a descriptions of requirements on the caller to not modify a passed by-reference parameter during the execution of an @AllowsPassByReference method. Such concurrency situations may occur for example when

a) the caller is inherently multi-threaded and holds-on to parameters in concurrently executed threads
b) the caller is called back during an invocation of an @AllowsPassByReference method (which can happen in the same thread)

c) the @AllowsPassByReference method is in addition a @OneWay method (i.e. the caller will not wait for the completion of the actual service method)

PROPOSAL:

Discussions have not come to a conclusion so far. Here are some partial solutions and further proposals:

- allow @AllowsPassByReference for synchronous methods only (rules out problem c)
- put housekeeping responsibilities on the caller (i.e. simply be aware of of a)+b) ): promise to not change parameters between invocation and return of the method.




 Comments   
Comment by Dave Booz [ 05/Dec/08 10:40 AM ]
awaiting proposal
Comment by Mark Combellack [ 12/Jan/09 03:29 AM ]
Also raised in the assembly TC as ASSEMBLY-97
Comment by Mark Combellack [ 03/Feb/09 11:59 AM ]
Proposed direction at:
http://lists.oasis-open.org/archives/sca-j/200902/msg00027.html
Comment by Dave Booz [ 13/Feb/09 10:04 AM ]
reoslved Feb 13 - There is a heading correction noted in the minutes - rest of resolution text is here
http://lists.oasis-open.org/archives/sca-j/200902/msg00112.html
Comment by Mike Edwards [ 23/Mar/09 09:22 AM ]
Applied in

sca-javacaa-1.1-spec-cd02-rev4.doc




[JAVA-7] Support for JAX-WS style async methods
Created: 04/Oct/07  Updated: 05/Dec/08

Status: Closed
Project: OASIS SCA Java TC
Component/s: Java Common Annotations and APIs specification
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Ron Barack Assigned To: Unassigned
Resolution: Won't Fix Votes: 0


 Description   
TARGET:

Java Common Annotations and APIs specification, section "WSDL to Java and Java to WSDL"

DESCRIPTION:

The current version of that section points to the JAX-WS specification to describe interface compatibility between interface representation in Java and WSDL. JAX-WS supports an optional asynchronous client invocation model via

a) a mapping of methods marked with an "Async" suffix
b) a specific API for call back handlers and return value Futures.

The working group should decide whether SCA should explicitly require support for this functionality, stay silent about it, mention it as optional, or point to its own async. invocation model as an alternative.

PROPOSAL:

none


 Comments   
Comment by Dave Booz [ 05/Dec/08 09:27 AM ]
Dec 5 Telecon - CNA
Comment by Dave Booz [ 05/Dec/08 10:11 AM ]
CNA on Dec 5 telecon




[JAVA-8] Concurrency model for Service Reference instances
Created: 04/Oct/07  Updated: 26/Jan/09

Status: Closed
Project: OASIS SCA Java TC
Component/s: Java Common Annotations and APIs specification
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Ron Barack Assigned To: Unassigned
Resolution: Won't Fix Votes: 0

Issue Links:
Depends on
depends on JAVA-25 Callback Simplification Closed
depends on JAVA-95 Simplified stateful implementation me... Closed
depends on JAVA-19 Redirecting callbacks Closed

 Description   
TARGET:

Java Common Annotations and APIs specification, section "Java API" / {"ComponentContext", "ServiceReference"} and section "Asynchronous and Conversational Programming".

DESCRIPTION:

While the current text says that a service reference represents a single conversation, it is not clear how a multi-threaded client should protect a non-conversational service reference's configuration (conversation id, callback, etc) so that it stays unmodified by other threads until an actual invocation is executed.

Consider the following code snippet for example:

class AComponent {
  @Reference ItemCheckerService srv;

  void goCheckItem(long ticket, String itemId) {
        ServiceReference sr = (ServiceReference) srv;
        sr.setConversationID(ticket);
        srv.check(itemId);
  }
}

A simple synchronization may lead to strict serialization of remote calls which is generally undesirable.

PROPOSAL:

Several proposals have been discussed in the past:

a) A service reference instance is actually a thread local proxy to the reference target.
b) A single service reference represents exactly one actual or potential conversation. Each call to ComponentContext.getService (and similar methods) returns a new instance of ServiceReference.




 Comments   
Comment by Dave Booz [ 13/Nov/08 05:47 AM ]
Nov 11 F2F -
Issue 95 - if it removes conversational interfaces, as we expect at this point, then service references become immutable, making this issue much easier to resolve.
Issue 19 - suggests to remove setCallback(Object), which also makes references immutable.
Issue 25 - might remove setCallbackID in moving to a stateless callback model.

Removal of all those APIs would make this issue easy to resolve.
Comment by Dave Booz [ 13/Nov/08 06:12 AM ]
Nov 11 F2F
Comment by Dave Booz [ 26/Jan/09 10:43 AM ]
resolved Jan 26 telecon - CNA




[JAVA-9] Representation of references with multiplicity > 1 on Component Context API
Created: 04/Oct/07  Updated: 06/Oct/08

Status: Closed
Project: OASIS SCA Java TC
Component/s: Java Common Annotations and APIs specification
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Ron Barack Assigned To: Unassigned
Resolution: Fixed Votes: 0


 Description   
TARGET:

Java Common Annotations and APIs specification, section "Java API" / "Component Context"

DESCRIPTION:

Service Component references may be of multiplicity greater 1. While the @Reference annotation considers that case and supports injection of a collection of service references, the ComponentContext API does not support retrieval of a collection of service references.

PROPOSAL:

Add the following methods to the ComponentContext API:

<B> List<B> getServices(Class<B> businessInterface, String referenceName);
(returns a list of typed service proxies for a business interface type and a reference name)

<B> List<ServiceReference<B>> getServiceReferences(Class<B> businessInterface, String referenceName);
(returns a list typed service reference for a business interface type and a reference name)


 Comments   
Comment by Ron Barack [ 18/Oct/07 03:16 AM ]
Resolved in TC call on 11.Oct.2007
http://www.oasis-open.org/apps/org/workgroup/sca-j/download.php/25758/Minutes%20from%20SCA-J%20TC%20Call%2010-11-07.doc


<B> Collection<B> getServices(Class<B> businessInterface, String referenceName);
(returns a list of typed service proxies for a business interface type and a reference name)

<B> Collection<ServiceReference<B>> getServiceReferences(Class<B> businessInterface, String referenceName);
(returns a list typed service reference for a business interface type and a reference name)


Calling getService(...) or getServiceReference(...) on a reference of multiplicity > 1 raises an IllegalArgumentException
Comment by Anish Karmarkar [ 16/Aug/08 03:18 AM ]
Applied the issue resolution in WD04 located at:
http://www.oasis-open.org/apps/org/workgroup/sca-j/download.php/29077/sca-javacaa-1.1-spec-WD04.doc
Comment by Dave Booz [ 06/Oct/08 11:52 AM ]
Oct 6 - WD05 accepted as CD01
http://www.oasis-open.org/committees/download.php/29558/sca-javacaa-1.1-spec-WD05.pdf




[JAVA-10] State sharing between ServiceReference and type-safereference
Created: 04/Oct/07  Updated: 26/Jan/09

Status: Closed
Project: OASIS SCA Java TC
Component/s: Java Common Annotations and APIs specification
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Ron Barack Assigned To: Unassigned
Resolution: Won't Fix Votes: 0

Issue Links:
Depends on
depends on JAVA-25 Callback Simplification Closed
depends on JAVA-95 Simplified stateful implementation me... Closed
depends on JAVA-19 Redirecting callbacks Closed

 Description   
TARGET:

Java Common Annotations and APIs specification, section "Java API" /
{"ComponentContext", "CallableReference"}

DESCRIPTION:
 
When a ServiceReference has been created from a type-safe reference
(proxy) using ComponentContext.cast(), or when a type-safe reference
(proxy) has been created from a ServiceReference using
CalllableReference.getService(), it is not clear whether actions that
change the state of the ServiceReference also affect calls through the
type-safe reference (proxy).

For example, in the following code snippet, where OrderService and
DeliveryService are both conversational,

class MyClient {
    @Context ComponentContext context;
    @Reference OrderService orders;

    void createOrder(String orderID, String customerID) {
        ServiceReference<OrderService> serviceRef = context.cast(orders);
        serviceRef.setConversationID(orderID);
        orders.create(customerID);
    }

    void scheduleDelivery(String orderID, String customerID) {
        ServiceReference<DeliveryService> serviceRef =
context.getServiceReference(DeliveryService.class, "Deliveries");
        DeliveryService deliveries = serviceRef.getService();
        serviceRef.setConversationID(orderID);
        deliveries.schedule(customerID);
    }
}

it is not clear whether either or both of the conversationID values passed
on the setConversationID() calls will be used for the conversations that
are started by the orders,create() and deliveries.schedule() calls.

PROPOSAL:

For the createOrder case, the cast() method should result in state that is
shared between the ServiceReference and the type-safe reference (proxy).
This shared state comprises the conversationID for the next conversation,
the callback ID for the next call, and the callback object for the next
call.

For the scheduleDelivery case, the getService() method should result in
state that is shared between the ServiceReference and the type-safe
reference (proxy). This shared state comprises the conversationID for the
next conversation, the callback ID for the next call, and the callback
object for the next call.



 Comments   
Comment by Dave Booz [ 13/Nov/08 06:11 AM ]
Nov 11 F2F -
Issue 95 - if it removes conversational interfaces, as we expect at this point, then service references become immutable, making this issue much easier to resolve.
Issue 19 - suggests to remove setCallback(Object), which also makes references immutable.
Issue 25 - might remove setCallbackID in moving to a stateless callback model.

Removal of all those APIs would make this issue easy to resolve.

Need to also nail down the APIs for serviceReferences and callableReferences, possibly we could also then require proxies to be serializable and it might then get rid of Callable reference.
Comment by Dave Booz [ 13/Nov/08 06:12 AM ]
Nov 11 F2F
Comment by Dave Booz [ 26/Jan/09 10:41 AM ]
resolved Jan 26 - telecon - CNA




[JAVA-11] Semantics of getCallbackID() are underspecified
Created: 04/Oct/07  Updated: 06/Oct/08

Status: Closed
Project: OASIS SCA Java TC
Component/s: Java Common Annotations and APIs specification
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Ron Barack Assigned To: Anish Karmarkar
Resolution: Fixed Votes: 0


 Description   
TARGET:

Java Common Annotations and APIs specification, section "Java API" /
{"CallableReference"}

DESCRIPTION:
 
The getCallbackID() method description doesn't specify the initial state
of the returned value and the events that cause this value to change.

Consider the following sequence of events:
1) A ServiceReference is created, either by injection or by
ComponentContext.getServiceReference().
2) getCallbackID() is called on the ServiceReference.
3) A type-safe reference (proxy) is created from the ServiceReference by
CallableReference.getService().
4) getCallbackID() is called on the ServiceReference.
5) A service call is made through the type-safe reference.
6) getCallbackID() is called on the ServiceReference.

It seems reasonably intuitive that call 2) will return null and call 6)
will return the system-generated callback ID that was used for the service
call. It's less clear what call 4) will return. Does the
system-generated callback ID get created and set into the ServiceReference
as part of event 3) or as part of event 5)?

The description of the getCallbackID() method should describe a "state
model" for how the value returned would change based on other actions.

PROPOSAL:

At point 2) the value returned will be null. At point 4, it will still be
null, At point 6), it will be the system-generated callback ID that was
used for the service call 5). This information should be stated
explicitly in the description of getCallbackID().





 Comments   
Comment by Michael Rowley [ 07/Feb/08 01:17 PM ]
Resolved at meeting of 2008-02-07 with:

Section 6.7.6 (draft 20070926) is changed from:

   "The identity that is used to identify a callback request is, by default, generated by the system."

to:

   "The identity that is used to identify a callback request is initially generated by the system."



Comment by Anish Karmarkar [ 28/Feb/08 03:47 AM ]
Applied issue resolution in this version http://www.oasis-open.org/apps/org/workgroup/sca-j/download.php/27397/sca-javacaa-draft-20080228.doc
Comment by Dave Booz [ 06/Oct/08 12:00 PM ]
Applied in earlier drafts
Oct 6 - WD05 accepted as CD01
http://www.oasis-open.org/committees/download.php/29558/sca-javacaa-1.1-spec-WD05.pdf




[JAVA-12] Relation between conversational annotation and scope conversation
Created: 04/Oct/07  Updated: 06/Oct/08

Status: Closed
Project: OASIS SCA Java TC
Component/s: Java Common Annotations and APIs specification
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Ron Barack Assigned To: Unassigned
Resolution: Fixed Votes: 0


 Description   
TARGET:

Java Common Annotations and APIs specification

DESCRIPTION:
 
The specification mentions @Conversational and @Scope(Conversation) but
there is no clarification how these interfere together and what should
happen in all the possible combinations.



PROPOSAL:

Two new paragraphs should be added in section (3.2 @Conversational) that
have the following wording :

In case an interface is marked as conversational but the scope of the
target implementation is different than @Scope(Conversation), than the
SCA runtime would invoke an instance as defined by the scope. In case
the scope is the default one (stateless) than the container may dispatch
to a new instance each time or alternatively pull one from a pool. In
this case, it is assumed that the implementation itself will manage
state. The implementation would be responsible for using the
conversation id associated with the request (obtaining it through
injection or via the SCA API) to obtain state stored somewhere (cache ,
database , etc.).

In case the target implementation has @Scope(Conversation) and the
interface is NOT marked as conversational than there will be no
conversation, attempts to retrieve conversationId will result in null,
and the SCA runtime may behave as if for that particular invocation the
scope has been defined as stateless.



 Comments   
Comment by Michael Rowley [ 07/Feb/08 01:34 PM ]
On today's call, we resolved the first part of this issue as follows:

Resolved: Add these words to section 2.4.4: "A conversational scoped class MUST NOT expose a service using a non-conversational interface."
Comment by Michael Rowley [ 13/Mar/08 01:47 PM ]
RESOLUTION from F2F of 2008-03-06:
http://www.oasis-open.org/apps/org/workgroup/sca-j/download.php/27571/SCA%20Java%20Minutes%20F2F%20of%202008-03-06%20and%202008-03-07.doc

Where a service has a conversational interface it MUST be implemented as by a conversation-scoped component. If no scope is specified on the implementation, then conversation scope is implied.
Comment by Anish Karmarkar [ 16/Aug/08 03:19 AM ]
Applied the issue resolution in WD04 located at:
http://www.oasis-open.org/apps/org/workgroup/sca-j/download.php/29077/sca-javacaa-1.1-spec-WD04.doc
Comment by Dave Booz [ 06/Oct/08 11:53 AM ]
Oct 6 - WD05 accepted as CD01
http://www.oasis-open.org/committees/download.php/29558/sca-javacaa-1.1-spec-WD05.pdf




[JAVA-13] ComponentContext.getProperty(...) ill defined
Created: 18/Oct/07  Updated: 16/Feb/10

Status: Closed
Project: OASIS SCA Java TC
Component/s: Java Common Annotations and APIs specification
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Minor
Reporter: Ron Barack Assigned To: Unassigned
Resolution: Fixed Votes: 0

Issue Links:
Depends on
depends on JAVA-139 Default value for SCA property is not... Closed

 Description   
RAISER: Mike Edwards

TARGET: Description of ComponentContext.getProperty() method in Java Common Annotations & APIs, Section 1.7.1

DESCRIPTION: ComponentContext.getProperty(...) does not describe what should be returned in the following
circumstances:

Java class has a property identified with a @Property annotation on a setter method, with a private field having a
default value:

private String location ="RTP";

@Property
public void setLocation(String location) {
    this.location = location;
}



...and there is no corresponding getter method for this property.

What value can/should getProperty(...) return in these circumstances? There is no getter method so how does it
know what the actual value is? It may be the default (which cannot be seen externally) or it may be a value
supplied by SCA configuration.

PROPOSAL: None

 Comments   
Comment by Mark Combellack [ 23/Feb/09 07:28 AM ]
Proposed resolution at http://lists.oasis-open.org/archives/sca-j/200902/msg00179.html
Comment by Mark Combellack [ 06/Mar/09 10:25 AM ]
Making this issue dependant on JAVA-139 as discussed in the call on 2009-03-06
Comment by Dave Booz [ 20/Jul/09 10:36 AM ]
resolved July 20 telecon, proposal linked to above
Comment by Dave Booz [ 16/Sep/09 02:09 PM ]
applied in CAA cd03-rev1: http://www.oasis-open.org/committees/download.php/34240/sca-javacaa-1.1-spec-cd03-rev1.pdf
Comment by Dave Booz [ 16/Feb/10 11:17 AM ]
Closed as a result of CD vote on Feb 15,2010.




[JAVA-14] Conversation Attributes are not in Java Schema
Created: 18/Oct/07  Updated: 26/Jan/09

Status: Closed
Project: OASIS SCA Java TC
Component/s: Java Common Annotations and APIs specification
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Ron Barack Assigned To: Unassigned
Resolution: Won't Fix Votes: 0

Issue Links:
Depends on
depends on JAVA-95 Simplified stateful implementation me... Closed

 Description   
Sumitter: Bryan Aupperle, Master Inventor

Title: Conversation Attributes are not in Java Schema

Target: Java Schema in Assembly Model Specification

Description: The conversation attributes defined by @Conversation Attributes in the initial working draft of the Java Common Annotations and APIs Specification do not exist in the initial working draft of the Assembly Model Specification. While this may not be a problem it is an inconsistency in so far as the other annotations all impact SCDL. It should also be noted that Java typically sets the pattern for other language bindings.

Proposal: No specific proposal at this time.

 Comments   
Comment by Dave Booz [ 26/Jan/09 10:39 AM ]
resolved Jan 26 - telecon - CNA




[JAVA-15] Java Implementations should be able to be Fully Configured with SCA Metadata
Created: 18/Oct/07  Updated: 13/Mar/08

Status: Closed
Project: OASIS SCA Java TC
Component/s: Java Common Annotations and APIs specification
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Ron Barack Assigned To: Michael Rowley
Resolution: Fixed Votes: 0

File Attachments: Microsoft Word Proposal_Additional_Annotations.doc    

 Description   
RAISER: Mike Edwards

TARGET: SCA Java Annotations and APIs specification

(but possibly also the SCA Assembly specification - TBD)

DESCRIPTION:

It should be possible, although not mandatory, for a Java Implementation to be fully configured with SCA-related metadata so that
such an implementation can be deployed to the SCA Domain without the need for any further configuration.

In the simplest case, the implication is that it should be possible to have a single Java class, marked with appropriate annotations,
which identifies its services, its references and its properties, but which also provides complete "default" values for all of these
aspects of its SCA component type:

- for a service, this would include its Binding and any binding parameters required to enable the SCA runtime to instantiate the
service with an appropriate endpoint address

- for a reference, this would include its Binding and any parameters required to identify a target service using that binding.
The target service could either be identified by SCA means (eg "componentName/serviceName") or by binding specific means
(eg HTTP URL for a Web service).

- for a property, this would imply a default value for the property

The services, references and the implementation itself may all be decorated with appropriate Intents and/or PolicySets.

With this approach, a specific type of "simple deployment" runtime is enabled. The sort of runtime that would be possible
with this approach is one where the runtime watches a directory (and its subdirectories, if required) and looks for new
implementations being placed into the directory. When a new implementation is placed in the directory, the runtime
spots its arrival, introspects the implementation and deploys the implementation to the SCA Domain, effectively
generating a new component at the Domain level, without needing any extra metadata, since the implementation
contains all that is required.



Note that these defaulted features of a Java implementation would be subject to the usual overriding rules of SCA and so when the
implementation artifact is used as the implementation of a component (at any level in the composition hierarchy) then the
configuration of the component can override any and all of the default configuration of the implementation, except for
absolute requirements stated via Intents (note that there is nothing new to SCA in this).


PROPOSAL:

The implications of this issue:

a) Add a section near the start of the specification that state the capability described above and its goals

b) Add a set of annotations and APIs that permit a Java implementation to specify any SCA metadata that is relevant
to deploying the implementation as a component in the SCA Domain without the need for any further metadata.
Examples of the metadata that cannot be specified today relates to Bindings and parameters of Bindings.
Separate Issue(s) should be brought forward to deal with the additional annotations and APIs that are required.



 Comments   
Comment by Ron Barack [ 08/Nov/07 09:10 AM ]
Attached the the proposal from JAVA-16, since that issue was closed as a duplicate of this.
Comment by Michael Rowley [ 13/Mar/08 01:49 PM ]
Closed at F2F of 2008-03-06:
http://www.oasis-open.org/apps/org/workgroup/sca-j/download.php/27571/SCA%20Java%20Minutes%20F2F%20of%202008-03-06%20and%202008-03-07.doc

Close with no action.




[JAVA-16] Require Additional Java Annotations to enable a Java Implementation to be "Fully Configured"
Created: 18/Oct/07  Updated: 08/Nov/07

Status: Closed
Project: OASIS SCA Java TC
Component/s: Java Common Annotations and APIs specification
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Ron Barack Assigned To: Michael Rowley
Resolution: Duplicate Votes: 0

File Attachments: Microsoft Word Proposal_Additional_Annotations.doc    

 Description   
RAISER: Mike Edwards

TARGET: SCA Java Annotations and APIs specification


DESCRIPTION:

It is currently not possible to specify some SCA metadata which can apply to a Java implementation within the Java implementation.

This includes, for example, the ability of a Java implementation with a reference to indicate a default value for the Binding of
the reference and a default target service for the reference.

It should be possible, but not mandatory, for a Java implementation to be able to supply default values for all SCA metadata
relevant to an implementation, so that the implementation can be deployed without further configuration.

PROPOSAL:

The attached document contains a proposal for extra annotations to deal with references and bindings:


 Comments   
Comment by Ron Barack [ 08/Nov/07 09:08 AM ]
Closing as duplicate of SDO-15. Decided on 1 November 2007. See meeting minutes: http://www.oasis-open.org/apps/org/workgroup/sca-j/download.php/26015/SCA%20Java%20Minutes%202007-10-01.doc




[JAVA-17] A hole in the algorithm of introspecting property/referencefrom an unannotated impl class
Created: 25/Oct/07  Updated: 27/Feb/09

Status: Closed
Project: OASIS SCA Java TC
Component/s: Java Component Implementation Specification
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Ron Barack Assigned To: Unassigned
Resolution: Duplicate Votes: 0

Issue Links:
Depends on
depends on JAVA-55 SCA Java Specifications do not Adequa... Closed

 Description   
Raised By: Raymond Feng

TARGET: Java Component Implementation Specification

DESCRIPTION :

The spec says:

358 1.2.7. Semantics of an Unannotated Implementation
359 The section defines the rules for determining properties and references for a Java component
360 implementation that does not explicitly declare them using @Reference or @Property.
361 In the absence of @Property and @Reference annotations, the properties and references of a class are
362 defined according to the following rules:
363 1. Public setter methods that are not included in any interface specified by an @Service annotation.
364 2. Protected setter methods
365 3. Public or protected fields unless there is a public or protected setter method for the same name

To apply the rule to the following case:

public class MyServiceImpl implements MyService {
        public void setX(String x) {
                ...
        }
}

@Remotable
public interface MyService {
        void setX(String x);
}

"x" will be taken as a property as it's NOT in any interface specified by @Service which is not present at all. But "setX()" is also an operation for the service "MyService ".

It's also tricky for the following case:
public class MyServiceImpl {
        public void setX(String x) {
                ...
        }
}

The service type will be MyServiceImpl.class. Would "x" be treated as a property or "setX()" as a business operation?

Another question would be: Is it valid to have a setter method denote both a property/reference and business operation?

PROPOSAL:

Change the text to:

363 1. Public setter methods that are not included in any interfaces from services introspected from this implementation class

 Comments   
Comment by Mark Combellack [ 23/Feb/09 07:28 AM ]
Proposed resolution at http://lists.oasis-open.org/archives/sca-j/200902/msg00180.html
Comment by Dave Booz [ 27/Feb/09 09:46 AM ]
closed Feb 27 telecon - As DUP of 55




[JAVA-18] Define Conformance Targets
Created: 08/Nov/07  Updated: 17/Jan/08

Status: Closed
Project: OASIS SCA Java TC
Component/s: Java Component Implementation Specification
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Ron Barack Assigned To: Michael Rowley
Resolution: Fixed Votes: 0


 Description   
TARGET: SCA Java C+I Specifications

Raised By Martin Chapman

DESCRIPTION: In order to write a normative statement or conformance clause using RFC2119 language, the target or subject of the rule needs to be included. Some of these are obvious, as we have rules governing components, composites, services, references etc. Other targets are less so, especially when it comes to conformance, as we need to identify artefacts that vendors can claim they handle according to the rules of the spec. We should enumerate a list of conformance targets early on, so that every time we use a MUST,MAY, or SHOULD, we know to what the rule applies to.

PROPOSAL: none


 Comments   
Comment by Michael Rowley [ 17/Jan/08 12:15 PM ]
"Conformance targets can be categorized into

1) document artifacts (or constructs within them) that can be checked statically.

2) SCA runtimes, which we may require to exhibit certain behaviors.

 

We recommend that each TC write its specifications to:

1. Reword the specifications using RFC 2119 keywords.

2. For each appearance of a 2119 keyword, specify the document, construct or runtime behavior that is being constrained."





[JAVA-19] Redirecting callbacks
Created: 31/Jan/08  Updated: 26/Jan/09

Status: Closed
Project: OASIS SCA Java TC
Component/s: Java Common Annotations and APIs specification
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Ron Barack Assigned To: Simon Nash
Resolution: Fixed Votes: 0

Issue Links:
Depends on
depends on JAVA-25 Callback Simplification Closed
is depended on by JAVA-10 State sharing between ServiceReferenc... Closed
is depended on by JAVA-8 Concurrency model for Service Referen... Closed

 Description   
RAISER: Michael Rowley
Thread: http://www.oasis-open.org/apps/org/workgroup/sca-j/email/archives/200801/msg00062.html
 
TARGET: Java Common Annotations and APIs, section 6.7.5 Customizing the callback
 
DESCRIPTION:
 
The last paragraph of this section says:
 
A callback object may be a service reference to another service. In that case, the callback messages go directly to the service that has been set as the callback. If the callback object is not a service reference, then callback messages go to the client and are then routed to the specific instance that has been registered as the callback object. However, if the callback interface has a stateless scope, then the callback object must be a service reference.
 
The second sentence of this (saying that “... callback messages go directly...”) is overly constraining has complex and confusing implications for runtimes.
 
PROPOSAL:
 
Remove the second sentence from this paragraph.


 Comments   
Comment by Ron Barack [ 07/Feb/08 12:18 PM ]
Accepted: http://www.oasis-open.org/apps/org/workgroup/sca-j/download.php/27106/SCA%20Java%20Minutes%202008-01-31.doc
Comment by Dave Booz [ 11/Nov/08 11:40 AM ]
Nov 11 - F2F - Agreed direction to remove this section.
Comment by Dave Booz [ 05/Dec/08 10:46 AM ]
awaiting proposal
Comment by Dave Booz [ 26/Jan/09 10:46 AM ]
resolved Jan 26 - telecon - resolved through issue 25 - see the minutes
Comment by Dave Booz [ 26/Jan/09 10:46 AM ]
fixed by the resolution of issue 25




[JAVA-20] annotations on parameters
Created: 31/Jan/08  Updated: 11/May/09

Status: Closed
Project: OASIS SCA Java TC
Component/s: Java Common Annotations and APIs specification
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Ron Barack Assigned To: Michael Rowley
Resolution: Fixed Votes: 0


 Description   
Raised By Peter Peshev

EMail Thread: http://www.oasis-open.org/apps/org/workgroup/sca-j/email/archives/200801/msg00048.html


TARGET: Java Common Annotations and APIs Specification Version 1.1 (WD
26 September 2007)
 
DESCRIPTION:
The current Reference and Property annotation are defined in sections
8.13 and 8.14 as :

@Target({METHOD, FIELD, PARAMETER})
@Retention(RUNTIME)
public @interface Reference {


@Target({METHOD, FIELD, PARAMETER})
@Retention(RUNTIME)
public @interface Property {


I.e. there is a possibility to define those annotations on parameter.
However the text description doesn't allow that feature and mentions
only field \ setter method injection :

"The @Property annotation type is used to annotate a Java class field or
a setter method that is used to inject an SCA property value. "

"The @Reference annotation type is used to annotate a Java class field
or a setter method that is used to inject a service that resolves the
reference."

PROPOSAL:
Drop the possibility of defining those annotations on parameters.



 Comments   
Comment by Ron Barack [ 07/Feb/08 12:20 PM ]
Accepted: http://www.oasis-open.org/apps/org/workgroup/sca-j/download.php/27106/SCA%20Java%20Minutes%202008-01-31.doc
Comment by Dave Booz [ 12/Nov/08 05:38 AM ]
Resolved at Nov 11 F2F - @reference aspect was resolved in Issue 43, therefore this resolution only needs to talk about @property.
Comment by Anish Karmarkar [ 12/Dec/08 01:47 AM ]
Applied the resolution in cd01-rev1 http://www.oasis-open.org/apps/org/workgroup/sca-j/download.php/30365/sca-javacaa-1.1-spec-cd01-rev1.pdf




[JAVA-21] Clarify Request Scope lifetime
Created: 31/Jan/08  Updated: 11/May/09

Status: Closed
Project: OASIS SCA Java TC
Component/s: Java Common Annotations and APIs specification
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Ron Barack Assigned To: Michael Rowley
Resolution: Fixed Votes: 0


 Description   
RAISER: Michael Rowley
Thread: http://www.oasis-open.org/apps/org/workgroup/sca-j/email/archives/200801/msg00047.html
 

TARGET: SCA Java Component Implementation Specification section titled "Request Scope"

 

DESCRIPTION:

 

The section currently starts with the following sentence:

 

"The lifecycle of request scope extends from the point a request on a remotable interface enters the SCA runtime and a thread processes that request until the thread completes synchronously processing the request."

 

From this description, it is not clear whether the request scope lasts through a remotable call to another component that happens to be local. In one possible interpretation it would depend on the binding. A call through a web service binding would be seen as changing threads, and therefore would be a new request scope. The same call through an SCA binding might be assumed to remain within the thread and therefore be within the same scope.

 

It is probably a bad idea for the scope to depend on the binding that is used, and it may even be a bad idea for the scope to depend on whether a call through a remotable interface _happens_ to be local.

 

PROPOSALS:

 

1) Have the request scope be only for a single remotable operation call. From that operation, any request scope component that is reached through only local-service calls would reach the same component instance. Calls through a remotable interface would introduce a new request scope.

 

2) Alternately, the request scope could last from the time a request "enters the SCA runtime" until it is done, but with the clarification that the "SCA Runtime" is domain-wide. As long as a call is made to another SCA component within the same domain (irrespective of the binding used) it is part of the same request scope.

 



 Comments   
Comment by Ron Barack [ 07/Feb/08 12:19 PM ]
Accepted: http://www.oasis-open.org/apps/org/workgroup/sca-j/download.php/27106/SCA%20Java%20Minutes%202008-01-31.doc
Comment by Dave Booz [ 12/Nov/08 09:39 AM ]
resolved Nov 11 at F2F - remove REQUEST scope
Comment by Anish Karmarkar [ 12/Dec/08 01:48 AM ]
Applied resolution in cd01-rev http://www.oasis-open.org/apps/org/workgroup/sca-j/download.php/30365/sca-javacaa-1.1-spec-cd01-rev1.pdf




[JAVA-22] When is a RequestContext available?
Created: 31/Jan/08  Updated: 06/Oct/08

Status: Closed
Project: OASIS SCA Java TC
Component/s: Java Common Annotations and APIs specification
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Ron Barack Assigned To: Unassigned
Resolution: Fixed Votes: 0


 Description   
RAISER: Simon Nash
Thread: http://www.oasis-open.org/apps/org/workgroup/sca-j/email/archives/200801/msg00053.html

TARGET: SCA Java Annotations and APIs Section 7.1: ComponentContext
 
DESCRIPTION:

The decription of ComponentContext.getRequestContext() says in lines
647-648 that it returns null if "... there is no current request or if the
context is unavailable". The situations where this applies need to be
defined more precisely. Here are some cases where a request context may
or not be available:
1. Within a business method for a service of the component.
2. Within a property or reference injection setter method for an instance
of the component.
3. Within a constructor for an instance of the component.
4. Within an Init or Destroy method for an instance of the component.

In case 1, it seems clear that getRequestContext() will always return
non-null. In the other cases, it is not clear what should be returned.

PROPOSAL:

getRequestContext() MUST return non-null for case 1 and SHOULD return null
for cases 2 through 4.


 Comments   
Comment by Ron Barack [ 07/Feb/08 12:27 PM ]
Accepted: http://www.oasis-open.org/apps/org/workgroup/sca-j/download.php/27106/SCA%20Java%20Minutes%202008-01-31.doc
Comment by Anish Karmarkar [ 14/Aug/08 08:24 PM ]
Issue resolved at the july 15/16 2008 f2f
http://www.oasis-open.org/apps/org/workgroup/sca-j/download.php/28926/SCA%20Java%20Minutes%202008-07-15-16.doc

Resolution:
Returns the context for the current SCA service request, or null if there is no current request or if the context is unavailable. This method MUST return non-null when invoked during the execution of a Java business method for a service operation or callback operation, on the same thread that the SCA runtime provided, and MUST return null in all other cases.
Comment by Anish Karmarkar [ 16/Aug/08 03:19 AM ]
Applied the issue resolution in WD04 located at:
http://www.oasis-open.org/apps/org/workgroup/sca-j/download.php/29077/sca-javacaa-1.1-spec-WD04.doc
Comment by Dave Booz [ 06/Oct/08 11:54 AM ]
Oct 6 - WD05 accepted as CD01
http://www.oasis-open.org/committees/download.php/29558/sca-javacaa-1.1-spec-WD05.pdf




[JAVA-23] Asynchronous Client interface to Synchronous Service not well described in Java Common Annotations & APIs Specification
Created: 31/Jan/08  Updated: 06/Oct/08

Status: Closed
Project: OASIS SCA Java TC
Component/s: Java Common Annotations and APIs specification
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Ron Barack Assigned To: Unassigned
Resolution: Fixed Votes: 0


 Description   
RAISER: Mike Edwards

THREAD: http://www.oasis-open.org/apps/org/workgroup/sca-j/email/archives/200801/msg00000.html

TARGET: Java Common Annotations & APIs Specification

DESCRIPTION:

(Section and line numbers here relate to the OASIS TC working draft sca-javacaa-draft-20070926.doc)

The Java Common Annotation and APIs specification is causing confusion about the facilities provided
to support asynchronous clients to synchronous services - there needs to be a better explanation about
what SCA supports.

The first section that deals with this is section 6.1 on @OneWay. It makes the following statement in lines
215 - 218:

"SCA does not currently define a mechanism for making non-blocking calls to methods that return values
or are declared to throw exceptions. It is recommended that service designers define one-way methods
as often as possible, in order to give the greatest degree of binding flexibility to deployers."

The first sentence here is in fact in contradiction with section 9 on "WSDL to Java and Java to WSDL"
The JAX-WS mapping has a full set of capabilities for client asynchronous invocation of a synchronous
service. Section 9 alludes to the need for some examples of the asynchronous invocation in line 1523:

"Note: This specification needs more examples and discussion of how JAX-WS's client asynchronous model is used."


PROPOSAL:

The following is a multipart proposal for changes and additions to the specification to deal with the issue:

1) Alter the text in Section 6.1 between lines 215 - 218, to read as follows:

"For a Java client to make a non-blocking call to methods that either return values or which throw exceptions,
a Java client MUST use the JAX-WS asychronous client API model that is described in section 9.

It is recommended that service designers define one-way methods
as often as possible, in order to give the greatest degree of binding flexibility to deployers."

2) Add the following text as a new Section 9.1:

"9.1 JAX-WS Client Asynchronous API for a synchronous service

The JAX-WS specification defines a mapping of a synchronous service invocation which provides a client
application with a means of invoking that service asynchronously, so that the client can invoke a service
operation and proceed to do other work without waiting for the service operation to complete its processing.
The client application can retrieve the results of the service either through a polling mechanism or via a
callback method which is invoked when the operation completes.

As an example, if the client code for a synchronous service invocation is like this:

      OrderResponse placeOrder( OrderRequest oRequest );

the equivalent asynchronous service invocation is like this:

      Future<?> placeOrderAsync( OrderRequest oRequest,
           AsyncHandler<OrderResponse> responseHandler );

and the asynchronous response to the invocation is sent back to the client via an asynchronous response handler declared as follows:

class OrderResponseHandler implements AsyncHandler<OrderResponse> {

   public void handleResponse( Response<OrderResponse> theResponse ){
      OrderResponse orderResponse = theResponse.get();
   }
}

Polling is provided via the Future object returned from the asycnhronous invocation."



 Comments   
Comment by Ron Barack [ 07/Feb/08 12:29 PM ]
Accepted: http://www.oasis-open.org/apps/org/workgroup/sca-j/download.php/27106/SCA%20Java%20Minutes%202008-01-31.doc
Comment by Michael Rowley [ 13/Mar/08 01:50 PM ]
DECISION from F2F of 2008-03-06:
http://www.oasis-open.org/apps/org/workgroup/sca-j/download.php/27571/SCA%20Java%20Minutes%20F2F%20of%202008-03-06%20and%202008-03-07.doc

1) Alter the text in Section 6.1 between lines 215 - 218, to read as follows:

"For a Java client to make a non-blocking call to methods that either return values or which throw exceptions, a Java client can use the JAX-WS asychronous client API model that is described in section 9.
It is considered to be a best practice that service designers define one-way methods as often as possible, in order to give the greatest degree of binding flexibility to deployers."

ACTION: SN to propose alternate proposal to respond to question 2 of issue 23
Comment by Ron Barack [ 29/May/08 08:43 AM ]
RESOLVED: http://www.oasis-open.org/apps/org/workgroup/sca-j/download.php/28440/SCA%20Java%20Minutes%202008-05-22.doc

Resolution Described here: http://lists.oasis-open.org/archives/sca-j/200805/msg00044.html
Comment by Anish Karmarkar [ 16/Aug/08 03:20 AM ]
Applied the issue resolution in WD04 located at:
http://www.oasis-open.org/apps/org/workgroup/sca-j/download.php/29077/sca-javacaa-1.1-spec-WD04.doc
Comment by Dave Booz [ 06/Oct/08 11:54 AM ]
Oct 6 - WD05 accepted as CD01
http://www.oasis-open.org/committees/download.php/29558/sca-javacaa-1.1-spec-WD05.pdf




[JAVA-24] The EJB bindings specification should provide explicity statesupport or non-support for Callbacks
Created: 07/Feb/08  Updated: 16/Feb/10

Status: Closed
Project: OASIS SCA Java TC
Component/s: EJB Session Binding Specification
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Ron Barack Assigned To: Unassigned
Resolution: Fixed Votes: 0


 Description   
Raiser: Dave Booz

Target: EJB Binding specification

Description:

At present, the EJB binding spec is completely silent on callbacks as
described in the Assembly specification. My assertion is that each binding
spec is obligated to clearly state what is and is not supported from the
Assembly specification. I don't believe that silence is sufficient due to
the inter-relationship of the various SCA specifications.

The SCA-Bindings TC is considering a similar question for each of the
binding specs owned by that TC.

Proposal:

None at present.


 Comments   
Comment by Dave Booz [ 05/Dec/08 10:47 AM ]
awaiting propsal
Comment by Dave Booz [ 10/Jun/09 08:20 AM ]
latest proposal: http://lists.oasis-open.org/archives/sca-j/200906/msg00026.html
Comment by Dave Booz [ 10/Jun/09 09:06 AM ]
latest proposal: http://lists.oasis-open.org/archives/sca-j/200906/msg00049.html
Comment by Mark Combellack [ 21/Jun/09 02:22 PM ]
Resolved on the call on 19th June 2009
Comment by Dave Booz [ 22/Jun/09 02:29 PM ]
resolution proposal is here: http://lists.oasis-open.org/archives/sca-j/200906/msg00068.html
Comment by Dave Booz [ 20/Jul/09 08:50 AM ]
applied: http://www.oasis-open.org/apps/org/workgroup/sca-j/download.php/33440/sca-ejbbinding-1.1-spec-wd-04.doc
Comment by Dave Booz [ 16/Feb/10 11:17 AM ]
Closed as a result of CD vote on Feb 15,2010.




[JAVA-25] Callback Simplification
Created: 13/Feb/08  Updated: 11/May/09

Status: Closed
Project: OASIS SCA Java TC
Component/s: Java Common Annotations and APIs specification
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Critical
Reporter: Ron Barack Assigned To: Simon Nash
Resolution: Fixed Votes: 0

Issue Links:
Depends on
is depended on by JAVA-8 Concurrency model for Service Referen... Closed
is depended on by JAVA-10 State sharing between ServiceReferenc... Closed
is depended on by JAVA-69 Misleading statement about lifetime o... Closed
is depended on by JAVA-19 Redirecting callbacks Closed
is depended on by JAVA-76 Incorrect code in section 6.7.4 exam... Closed

 Description   
RAISER: Michael Rowley

Thread: http://www.oasis-open.org/apps/org/workgroup/sca-j/email/archives/200802/msg00026.html
  
TARGET: Java API and Annotation Specification
  
DESCRIPTION:
  
One of SCA's goals is to present a simple programming model to service developers. Unfortunately, the current capabilities related to callbacks don't really qualify as simple. Developers have to be able to understand all of the possible combinations of:
  
- The scope of the client (4 possibilities)
- The scope of the service provider (4 more possibilities)
- Conversational or non-conversational on the main interface.
- Conversational or non-conversational on the callback interface.
- User specified callback IDs
- User specified callback objects.
- The relationship of callback IDs to conversation IDs (possibly user specified)
- ...and probably more
  
PROPOSAL:
  
Not included.

 Comments   
Comment by Michael Rowley [ 13/Mar/08 01:46 PM ]
Decision from F2F of 2008-03-06
http://www.oasis-open.org/apps/org/workgroup/sca-j/download.php/27571/SCA%20Java%20Minutes%20F2F%20of%202008-03-06%20and%202008-03-07.doc

Where a service has a conversational interface it MUST be implemented as by a conversation-scoped component. If no scope is specified on the implementation, then conversation scope is implied.
Comment by Dave Booz [ 11/Nov/08 11:42 AM ]
Nov 11 - F2F - Agreed direction to support ONLY application correlated callbacks.
Comment by Dave Booz [ 05/Dec/08 10:48 AM ]
awaiting text to review
Comment by Dave Booz [ 26/Jan/09 10:01 AM ]
Latest proposoal: http://lists.oasis-open.org/archives/sca-j/200901/msg00093.html
Comment by Dave Booz [ 26/Jan/09 10:28 AM ]
resolved Jan 26 - Telecon
see the minutes as the motion to resolve was complicated
Comment by Mike Edwards [ 23/Mar/09 09:34 AM ]
Applied in

sca-javacaa-1.1-spec-cd02-rev1.doc




[JAVA-26] Description of interface.java is needed
Created: 13/Feb/08  Updated: 06/Oct/08

Status: Closed
Project: OASIS SCA Java TC
Component/s: Java Common Annotations and APIs specification
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Ron Barack Assigned To: Unassigned
Resolution: Fixed Votes: 0


 Description   
TARGET: SCA Java Common APIs and Annotations
RAISER: Dvave Booz
Thread: http://www.oasis-open.org/apps/org/workgroup/sca-j/email/archives/200802/msg00023.html

DESCRIPTION: The SCA Assembly TC resolved an issue [1] that removed the
description of <interface.java/> from the Assembly spec. Both the SCA Java
CAA and SCA Java C&I specs both reference <interface.java/> but neither
explain it as both specs currently depend on the Assembly spec.

PROPOSAL: While not precise, lines 2129-2145 from the Assembly spec [3]
need to be placed into section 3 of the Java CAA spec [2], perhaps inserted
in front of section 3.1 or as new a section 3.3.


[1] http://www.osoa.org/jira/browse/ASSEMBLY-3

[2]
http://www.oasis-open.org/committees/download.php/26045/sca-javacaa-draft-20071108.doc

[3] http://www.oasis-open.org/committees/download.php/26725/sca-assembly-1
[1].1-spec-WD-02.doc


 Comments   
Comment by Michael Rowley [ 27/Feb/08 03:29 PM ]
Resolved on 2008-02-14
http://www.oasis-open.org/apps/org/workgroup/sca-j/download.php/27277/SCA%20Java%20Minutes%202008-02-14.doc
Comment by Anish Karmarkar [ 28/Feb/08 03:44 AM ]
Issue resolution applied in this version http://www.oasis-open.org/apps/org/workgroup/sca-j/download.php/27397/sca-javacaa-draft-20080228.doc
Comment by Dave Booz [ 06/Oct/08 12:01 PM ]
Incorporated into earlier drafts
Oct 6 - WD05 accepted as CD01
http://www.oasis-open.org/committees/download.php/29558/sca-javacaa-1.1-spec-WD05.pdf




[JAVA-27] Security Annotations in generated Component Type
Created: 28/Feb/08  Updated: 11/May/09

Status: Closed
Project: OASIS SCA Java TC
Component/s: Java Common Annotations and APIs specification
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Critical
Reporter: Ron Barack Assigned To: Anish Karmarkar
Resolution: Fixed Votes: 0

Issue Links:
Depends on
depends on JAVA-55 SCA Java Specifications do not Adequa... Closed

 Description   
Mail Thread: http://www.oasis-open.org/apps/org/workgroup/sca-j/email/archives/200802/msg00070.html


RAISER: Michael Rowley

 

TARGET: SCA Java Common Annotation and API Specification, section Security Implementation Policy

 

DESCRIPTION:

 

The Security Implementation Policy section describes annotations for:

@RunAs

@RolesAllowed

@PermitAll

@DenyAll

@DeclareRoles

 

These are described as "policy annotations", but the specification never describes how these annotations affect the generated Component Type for the class, nor how they relate to the policy framework.

 

These annotations are also not present in Chapter 8, which claims to list all of the annotations.

 

PROPOSAL:

 

None



 Comments   
Comment by Ron Barack [ 31/Mar/08 07:25 AM ]
Opened in http://www.oasis-open.org/apps/org/workgroup/sca-j/download.php/27482/SCA%20Java%20Minutes%202008-02-28.doc
Comment by Dave Booz [ 05/Dec/08 10:45 AM ]
Actually assigned to Yang Lei
Comment by Dave Booz [ 05/Dec/08 10:48 AM ]
awaiting proposal
Comment by Mark Combellack [ 22/Jan/09 03:36 AM ]
New proposal at:
http://lists.oasis-open.org/archives/sca-j/200901/msg00073.html
Comment by Dave Booz [ 09/Feb/09 09:43 AM ]
resolved Feb 9 - proposal http://lists.oasis-open.org/archives/sca-j/200902/msg00059.html
Comment by Mike Edwards [ 25/Mar/09 02:29 AM ]
Applied in:

sca-javacaa-1.1-spec-cd02-rev4.doc




[JAVA-28] Package Name Changes
Created: 28/Feb/08  Updated: 11/May/09

Status: Closed
Project: OASIS SCA Java TC
Component/s: Java Common Annotations and APIs specification
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Ron Barack Assigned To: Anish Karmarkar
Resolution: Fixed Votes: 0


 Description   
Mail Thread: http://www.oasis-open.org/apps/org/workgroup/sca-j/email/archives/200802/msg00048.html

RAISER: Sanjay Patil
TARGET: Java Common Annotations and APIs Specification
DESCRIPTION:
The Java Common Annotations and APIs Specification uses the 'org.osoa.sca' package name for the API and 'org.osoa.sca.annotations' package name for the annotations. There exist a good number of commercial and open source software implementations of SCA that use the current package names. It will be painful for these implementations to maintain backward compatibility if the package names in the final version of the specifications are going to be different from the current package names.

It is not clear whether the OASIS SCA-J TC would bless use of the current package names in the final versions of the specifications or not.

PROPOSAL:
Continue to use the current package names (org.osoa.sca, org.osoa.sca.annotations) in the final specifications.


 Comments   
Comment by Ron Barack [ 31/Mar/08 07:26 AM ]
Opened: http://www.oasis-open.org/apps/org/workgroup/sca-j/download.php/27482/SCA%20Java%20Minutes%202008-02-28.doc
Comment by Dave Booz [ 05/Dec/08 10:48 AM ]
awaiting feedback from TC-Admin
Comment by Dave Booz [ 16/Jan/09 09:22 AM ]
Result of appeal:
http://lists.oasis-open.org/archives/sca-j/200901/msg00037.html

org.oasisopen
Comment by Dave Booz [ 16/Jan/09 09:23 AM ]
resolved Jan 16
Comment by Anish Karmarkar [ 19/Jan/09 01:59 AM ]
Applied resolution in cd01-rev4:
http://www.oasis-open.org/apps/org/workgroup/sca-j/download.php/30736/sca-javacaa-1.1-spec-cd01-rev4.pdf
http://www.oasis-open.org/apps/org/workgroup/sca-j/download.php/30735/sca-javacaa-1.1-spec-cd01-rev4.doc




[JAVA-29] Specification inconsistent - states that callbacks can be used for both local and remote services and elsewhere says only for remote service interfaces
Created: 28/Feb/08  Updated: 06/Oct/08

Status: Closed
Project: OASIS SCA Java TC
Component/s: Java Common Annotations and APIs specification
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Ron Barack Assigned To: Unassigned
Resolution: Fixed Votes: 0


 Description   
Mail Thread: http://www.oasis-open.org/apps/org/workgroup/sca-j/email/archives/200802/msg00045.html


RAISER: Mark Combellack

 

TARGET: Java Common Annotations and APIs Specification

 

DESCRIPTION:

 

The Java Common Annotations and APIs Specification is inconsistent as it states that callbacks can be used for both local and remote services and elsewhere says only for remote services.

 

Line numbers are based on version 1.1 of the Working Draft dated 26 September 2007

 

In the following, line 356 states that "Callbacks may be used for both remotable and local services"

 

 

356 Callbacks may be used for both remotable and local services. Either both interfaces of a

357 bidirectional service must be remotable, or both must be local. It is illegal to mix the two. There

358 are two basic forms of callbacks: stateless callbacks and stateful callbacks.

 

In the following, line 359 states that "A callback interface is declared by using the @Callback annotation on a remotable service interface" This implies that @Callback can only be used on @Remotable service interfaces.

 

359 A callback interface is declared by using the @Callback annotation on a remotable service

360 interface, which takes the Java Class object of the interface as a parameter. The annotation may

361 also be applied to a method or to a field of an implementation, which is used in order to have a

362 callback injected, as explained in the next section.

 

 

PROPOSAL:

 

Remove the word remotable in line 359


 Comments   
Comment by Ron Barack [ 31/Mar/08 07:35 AM ]
Resolved as proposed: see http://www.oasis-open.org/apps/org/workgroup/sca-j/download.php/27482/SCA%20Java%20Minutes%202008-02-28.doc
Comment by Anish Karmarkar [ 16/Aug/08 03:20 AM ]
Applied the issue resolution in WD04 located at:
http://www.oasis-open.org/apps/org/workgroup/sca-j/download.php/29077/sca-javacaa-1.1-spec-WD04.doc
Comment by Dave Booz [ 06/Oct/08 11:55 AM ]
Oct 6 - WD05 accepted as CD01
http://www.oasis-open.org/committees/download.php/29558/sca-javacaa-1.1-spec-WD05.pdf




[JAVA-30] "Process" Scope
Created: 06/Mar/08  Updated: 11/May/09

Status: Closed
Project: OASIS SCA Java TC
Component/s: Java Common Annotations and APIs specification
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Ron Barack Assigned To: Anish Karmarkar
Resolution: Fixed Votes: 0


 Description   
RAISER: Michael Rowley

 

TARGET: SCA Java Common Annotation and API specification

 

DESCRIPTION:



There are some common scenarios where neither the STATELESS scope nor the COMPOSITE scope is exactly appropriate. The scenario is that you have a component that has some initialization logic that is expensive, but the developer wants calls to this component to be local as often as possible, in order that they may be fast.

 

The problem with COMPOSITE scope is that it must behave as if there were only one instance per domain. Without some kind of multi-process state sharing mechanism, this typically means that all requests have to be routed to a single instance in a single process. Any call to this component from any process other than the one that hosts the composite-scoped component then becomes expensive.

 

Stateless scope also is not well suited, since the stateless scope requires that the @Init method be called when the scope starts - i.e. on every call.

 

There should be a scope that allows one instance per process.

 

As an aside, the name of the COMPOSITE scope is confusing, and should possibly be changed to DOMAIN to make its domain-wide singleton nature more clear.

 

PROPOSAL:

 

Introduce a new PROCESS scope, where there is at most one instance per JVM.

 

Change the name of COMPOSITE scope to DOMAIN.


 Comments   
Comment by Ron Barack [ 31/Mar/08 07:29 AM ]
Opened: http://www.oasis-open.org/apps/org/workgroup/sca-j/download.php/27714/SCA%20Java%20Minutes%20F2F%20of%202008-03-06%20and%202008-03-07.doc
Comment by Dave Booz [ 05/Dec/08 10:50 AM ]
proposal: http://www.oasis-open.org/apps/org/workgroup/sca-j/email/archives/200812/msg00006.html
Comment by Dave Booz [ 16/Feb/09 10:40 AM ]
resolved Feb 16 telecon with proposal + ed. change as in minutes
Comment by Mike Edwards [ 25/Mar/09 01:48 AM ]
Applied in:

sca-javacaa-1.1-spec-cd02-rev4.doc




[JAVA-31] Semantics of ServiceReference.getConversationID()
Created: 06/Mar/08  Updated: 06/Oct/08

Status: Closed
Project: OASIS SCA Java TC
Component/s: Java Common Annotations and APIs specification
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Ron Barack Assigned To: Unassigned
Resolution: Fixed Votes: 0


 Description   
Mail Thread: http://www.oasis-open.org/apps/org/workgroup/sca-j/email/archives/200803/msg00013.html

RAISER: Simon Nash
  
TARGET: SCA Java Common Annotations and APIs
  
DESCRIPTION:

When a conversation has been initiated by calling through a proxy obtained
from a ServiceReference, and setConversationID() has not been called on
the ServiceReference, does ServiceReference.getConversationID() return
 a) null
 b) the system-generated conversation ID that would be obtained by
    calling ServiceReference.getConversation().getConversationID()
 c) either or the above depending on the implementation

Lines 363-367 of the Java Common Annotations and APIs spec state that a
system-generated conversation ID would be returned (option b). Lines 780-781
say that only a user-specified conversation would be returned (option a).

Here are the relevant extracts from the 2/28/08 Working Draft:

lines 340-343 section 6.5

If a method is invoked on a service reference after an @EndsConversation method has been called
then a new conversation will automatically be started. If ServiceReference.getConversationID()
is called after the @EndsConversationmethod is called, but before the next conversation has been
started, it will return null.

lines 363-367 section 6.6.2

Whether the conversation ID is chosen by the client or is generated by the system, the client
may access the conversation ID by calling ServiceReference.getConversationID().
If the conversation ID is not application specified, then the ServiceReference.getConversationID()
method is only guaranteed to return a valid value after the first operation has been invoked,
otherwise it returns null.

lines 780-781 section 7.4 ServiceReference

getConversationID() - Returns the id supplied by the user that will be associated with
conversations initiated through this reference.

lines 782-785 section 7.4 ServiceReference

setConversationID(Object conversationId) - Set the id to associate with any conversation
started through this reference. If the value supplied is null then the id will be generated
by the implementation. Throws an IllegalStateException if a conversation is currently
associated with this reference.

lines 800-802 section 7.5 Conversation

getConversationID() - Returns the identifier for this conversation. If a user-defined identity
had been supplied for this reference then its value will be returned; otherwise the identity
generated by the system when the conversation was initiated will be returned.

PROPOSAL:

Option a.

Replace lines 363-367 with the following:

Whether the conversation ID is chosen by the user or is generated by the system, the client
may access the conversation ID by calling getConversationID() on the current conversation object.

Replace lines 780-781 with the following:

getConversationID() - Returns the id supplied by the user that will be associated with
future conversations initiated through this reference, or null if no ID has been set by the user.

lines 782-785 section 7.4 ServiceReference

setConversationID(Object conversationId) - Set an ID, supplied by the user, to associate with any _future_ conversation
started through this reference. If the value supplied is null then the id will be generated
by the implementation. Throws an IllegalStateException if a conversation is currently
associated with this reference.



Simon C. Nash, IBM Distinguished Engineer
Member of the IBM Academy of Technology
Tel. +44-1962-815156 Fax +44-1962-818999



 Comments   
Comment by Michael Rowley [ 13/Mar/08 01:52 PM ]
RESOLVED atF2F of 2008-03-06:
http://www.oasis-open.org/apps/org/workgroup/sca-j/download.php/27571/SCA%20Java%20Minutes%20F2F%20of%202008-03-06%20and%202008-03-07.doc

Replace lines 363-367 with the following:

Whether the conversation ID is chosen by the user or is generated by the system, the client may access the conversation ID by calling getConversationID() on the current conversation object.

Replace lines 780-781 with the following:

getConversationID() - Returns the id supplied by the user that will be associated with future conversations initiated through this reference, or null if no ID has been set by the user.

lines 782-785 section 7.4 ServiceReference

setConversationID(Object conversationId) - Set an ID, supplied by the user, to associate with any _future_ conversation started through this reference. If the value supplied is null then the id will be generated by the implementation. Throws an IllegalStateException if a conversation is currently associated with this reference.
Comment by Anish Karmarkar [ 16/Aug/08 03:20 AM ]
Applied the issue resolution in WD04 located at:
http://www.oasis-open.org/apps/org/workgroup/sca-j/download.php/29077/sca-javacaa-1.1-spec-WD04.doc
Comment by Dave Booz [ 06/Oct/08 11:55 AM ]
Oct 6 - WD05 accepted as CD01
http://www.oasis-open.org/committees/download.php/29558/sca-javacaa-1.1-spec-WD05.pdf




[JAVA-32] Incorrect generated service name
Created: 31/Mar/08  Updated: 05/May/09

Status: Closed
Project: OASIS SCA Java TC
Component/s: Java Component Implementation Specification
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Ron Barack Assigned To: Unassigned
Resolution: Fixed Votes: 0


 Description   
RAISER : Michael Rowley
Mail Thread: http://www.oasis-open.org/apps/org/workgroup/sca-j/email/archives/200803/msg00068.html
 

TARGET: SCA J Component Implementation Specification (sca-javaci-draft-20070926)

 

TYPE : Editorial. (We should be able to resolve it immediately after opening it).

 

DESCRIPTION :

 

In the following snippet, the generated service name should be "HelloServiceImpl" not "HelloService": This is from the spec starting at line 85:

 

@Service(HelloServiceImpl.class)

public class HelloServiceImpl implements AnotherInterface {

 

   public String hello(String message) {

        ...

     }

   ...

}

 

In the above example, HelloWorldServiceImpl offers one service as defined by the public methods on the implementation class. The interface AnotherInterface in this case does not specify a service offered by the component. The following is an XML representation of the introspected component type:

<?xml version="1.0" encoding="ASCII"?>

<componentType xmlns="http://www.osoa.org/xmlns/sca/0.9">

 

     <service name="HelloService">

           <interface.java interface="services.hello.HelloServiceImpl"/>

     </service>

 

</componentType>

 

PROPOSAL:

 

Change "HelloService" to "HelloServiceImpl".

 

Michael


 Comments   
Comment by Ron Barack [ 29/May/08 08:59 AM ]
OPENED: http://www.oasis-open.org/apps/org/workgroup/sca-j/download.php/27868/Meeting%20Minutes%203-4-2008.doc
Comment by Ron Barack [ 29/May/08 09:13 AM ]
RESOLVED AS PROPOSED: http://www.oasis-open.org/apps/org/workgroup/sca-j/download.php/27868/Meeting%20Minutes%203-4-2008.doc
Comment by Dave Booz [ 16/Dec/08 01:57 PM ]
applied in wd02
Comment by Dave Booz [ 05/May/09 06:40 AM ]
Applied in CD01




[JAVA-33] Description of @Reference annotation is Incorrect
Created: 31/Mar/08  Updated: 06/Oct/08

Status: Closed
Project: OASIS SCA Java TC
Component/s: Java Common Annotations and APIs specification
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Ron Barack Assigned To: Anish Karmarkar
Resolution: Fixed Votes: 0


 Description   
RAISER: Mike Edwards

TARGET: Java Common Annotations and APIs Specification

DESCRIPTION:

The specification currently describes the @Reference annotation as applying to a
"setter method parameter" in lines 82/83 - this is incorrect and contradicts other parts
of the specification which deal with @Reference.



PROPOSAL:

Change lines 82/83 to read:

"Accessing a service using reference injection is done by defining a field,
a setter method, or a constructor parameter, typed by the service interface
and annotated with an @Reference annotation."



 Comments   
Comment by Ron Barack [ 29/May/08 09:00 AM ]
OPENED: http://www.oasis-open.org/apps/org/workgroup/sca-j/download.php/27868/Meeting%20Minutes%203-4-2008.doc
Comment by Ron Barack [ 29/May/08 09:13 AM ]
RESOLVED AS PROPOSED: http://www.oasis-open.org/apps/org/workgroup/sca-j/download.php/27868/Meeting%20Minutes%203-4-2008.doc
Comment by Anish Karmarkar [ 16/Aug/08 03:20 AM ]
Applied the issue resolution in WD04 located at:
http://www.oasis-open.org/apps/org/workgroup/sca-j/download.php/29077/sca-javacaa-1.1-spec-WD04.doc
Comment by Dave Booz [ 06/Oct/08 11:56 AM ]
Oct 6 - WD05 accepted as CD01
http://www.oasis-open.org/committees/download.php/29558/sca-javacaa-1.1-spec-WD05.pdf




[JAVA-34] Composite Scoped components should be able to implement Conversational interfaces
Created: 31/Mar/08  Updated: 10/Apr/08

Status: Closed
Project: OASIS SCA Java TC
Component/s: Java Common Annotations and APIs specification
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Ron Barack Assigned To: Michael Rowley
Resolution: Duplicate Votes: 0


 Description   
RAISER: Mike Edwards
Mail Thread: http://www.oasis-open.org/apps/org/workgroup/sca-j/email/archives/200803/msg00071.html

TARGET: Java Annotations and APIs Specification

DESCRIPTION:

The resolution of Issue 12 means that a conversational interface can only be implemented by a conversation scoped component:
http://www.osoa.org/jira/browse/JAVA-12

This restricts an important use case for composite scoped components - no longer can composite scoped components provide
conversational interfaces.

One major reason for having composite scoped components is that this covers the case of components whose implementations
are expensive to initialize. An example is an in-memory database component where the loading of the data might take a
substantial amount of time - done order to make subsequent queries and updates much faster.

It may well be the case that it is desirable for such a composite scoped component to be able to offer conversational interfaces
to its clients. An example is for an in-memory database component to offer an interface to clients which provides a cursor into
a large set of data and allow a series of requests to be issued using that cursor. It seems perverse for SCA to prevent the use
of these scenarios.

PROPOSAL:

Permit composite scoped components to implement conversational interfaces.

 Comments   
Comment by Ron Barack [ 10/Apr/08 10:36 AM ]
Duplicate of JAVA-12




[JAVA-35] The ServiceReference interface should extend Serializable
Created: 10/Apr/08  Updated: 06/Oct/08

Status: Closed
Project: OASIS SCA Java TC
Component/s: Java Common Annotations and APIs specification
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Ron Barack Assigned To: Unassigned
Resolution: Fixed Votes: 0


 Description   
RAISER: Mark Combellack

TARGET: The ServiceReference interface should extend Serializable
Mail Thread: http://www.oasis-open.org/apps/org/workgroup/sca-j/email/archives/200804/msg00012.html


DESCRIPTION:



Document references taken from:

Service Component Architecture Java Common Annotations and APIs Specification Version 1.1

Working Draft 28 February 2008

 

 

 

In several locations in the specification, it talks about passing ServiceReference instances around. These include:

 

Section 6.3 Passing Conversational Services as Parameters contains the following:

 

268 The service reference which represents a single conversation can be passed as a parameter to

269 another service, even if that other service is remote. This may be used in order to allow one

270 component to continue a conversation that had been started by another.

 

 

Section 6.5 Conversation Lifetime Summary contains the following:

 

325 Continuing conversations

326 The client can continue an existing conversation, by:

327 Holding the service reference that was created when the conversation started

328 Getting the service reference object passed as a parameter from another service, even

329 remotely

330 Loading a service reference that had been written to some form of persistent storage

 

 

The standard mechanism used by Java for transporting and persisting objects is to use Serialization. Currently, ServiceReference is not Serializable as it does not extend Serializable as ServiceReference and its parent (CallableReference) do not extend Serializable.

 

 

Section 7.3 CallableReference

 

739 public interface CallableReference<B> {

 

 

Section 7.4 ServiceReference

 

769 public interface ServiceReference<B> extends CallableReference<B>{

 

 

 

Making ServiceReference Serializable will allow:

 

- ServiceReferences to be passed over @Remotable interfaces as a parameter

- ServiceReferences to be returned by methods over @Remotable interfaces

- Standard approach for persisting ServiceReferences to some form of persistent storage by using the JDK java.io.ObjectOutputStream and java.io.ObjectInputStream classes.

- Applications that Serialize ServiceReferences will be portable across different vendors SCA Implementations**** (i.e. the Application code will run on both SCA Implementations without modification)

 

 

*** Note: I do not mean interoperable. I would not expect a ServiceReference Serialized in Vendor 1 SCA Implementation to be able to be deserialized and used in Vendor 2 SCA Implementation.

 


PROPOSAL:

There are two possible options. My preferred approach is Option 1.

 

 

Option 1 - Make CallableReference extend Serializable

 

By making CallableReference extend Serializable, this will also make ServiceReference Serializable.

 

The advantage of this approach is that a Component marked as @Conversational but @Scope("STATELESS") can persist the @Callback and use it in subsequent calls.

 

 

 

Option 2- Make just ServiceReference extend Serializable

 

This would mean that CallableReference is not Serializable and the @Callback cannot be persisted by a Component marked as @Conversational but @Scope("STATELESS") can persist the @Callback and use it in subsequent calls.

 

 
 


 Comments   
Comment by Ron Barack [ 29/May/08 08:55 AM ]
OPENED: http://www.oasis-open.org/apps/org/workgroup/sca-j/download.php/27937/Meeting%20Minutes%2010-04-2008.doc
Comment by Anish Karmarkar [ 14/Aug/08 08:18 PM ]
Issue resolved at the july 15/16 2008 f2f
http://www.oasis-open.org/apps/org/workgroup/sca-j/download.php/28926/SCA%20Java%20Minutes%202008-07-15-16.doc

Resolution:
callable reference extends serializable
Comment by Anish Karmarkar [ 16/Aug/08 03:21 AM ]
Applied the issue resolution in WD04 located at:
http://www.oasis-open.org/apps/org/workgroup/sca-j/download.php/29077/sca-javacaa-1.1-spec-WD04.doc
Comment by Dave Booz [ 06/Oct/08 11:56 AM ]
Oct 6 - WD05 accepted as CD01
http://www.oasis-open.org/committees/download.php/29558/sca-javacaa-1.1-spec-WD05.pdf




[JAVA-36] RequestContext.getServiceReference description is unclear
Created: 10/Apr/08  Updated: 06/Oct/08

Status: Closed
Project: OASIS SCA Java TC
Component/s: Java Common Annotations and APIs specification
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Ron Barack Assigned To: Unassigned
Resolution: Fixed Votes: 0


 Description   
RAISED BY: Dave Booz
Mail Thread: http://www.oasis-open.org/apps/org/workgroup/sca-j/email/archives/200804/msg00014.html

TARGET: Java Common Annotations and APIs (draft 20080228) - line 731-733.

DESCRIPTION: The textual description of the
RequestContext.getServiceReference() could be improved. It is not clear
why this API is different from RequestContext.getCallbackReference().

PROPOSAL:
Replace lines 731-733 with the following:

When invoked during the execution of a service operation, this API MUST
return a CallableReference that represents the service. When invoked
during the execution of a callback operation, this API MUST return a
CallableReference that represents the callback.

 Comments   
Comment by Ron Barack [ 29/May/08 08:55 AM ]
OPENED: http://www.oasis-open.org/apps/org/workgroup/sca-j/download.php/27937/Meeting%20Minutes%2010-04-2008.doc
Comment by Anish Karmarkar [ 14/Aug/08 08:20 PM ]
Issue resolved at the july 15/16 2008 f2f
http://www.oasis-open.org/apps/org/workgroup/sca-j/download.php/28926/SCA%20Java%20Minutes%202008-07-15-16.doc

Resolution:
When invoked during the execution of a service operation, this method MUST return a CallableReference that represents the service that was invoked.

When invoked during the execution of a callback operation, this method MUST return a CallableReference that represents the callback that was invoked.
Comment by Anish Karmarkar [ 16/Aug/08 03:21 AM ]
Applied the issue resolution in WD04 located at:
http://www.oasis-open.org/apps/org/workgroup/sca-j/download.php/29077/sca-javacaa-1.1-spec-WD04.doc
Comment by Dave Booz [ 06/Oct/08 11:56 AM ]
Oct 6 - WD05 accepted as CD01
http://www.oasis-open.org/committees/download.php/29558/sca-javacaa-1.1-spec-WD05.pdf




[JAVA-37] Injection on private fields - or not
Created: 17/Apr/08  Updated: 06/Oct/08

Status: Closed
Project: OASIS SCA Java TC
Component/s: Java Common Annotations and APIs specification
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Ron Barack Assigned To: Anish Karmarkar
Resolution: Fixed Votes: 0


 Description   
Raised By: Dave Booz

TARGET: Java Common Annotations an APIs (working draft - 28 Feb 2008:
sca-javacaa-draft-20080228.doc ).

DESCRIPTION: The spec is widely inconsistent in its approach to injection
on private fields. The first question that needs to be answered is whether
or not injection on private fields is allowed, disallowed, or requried to
be supported. There was discussion of this during the formation of the
OSOA V1.0 spec, where I believe the resolution was to disallow injection on
private fields. Despite that, the spec text was never sufficiently
addressed. As a result, I think the Java TC needs to first re-debate this
issue (as there may be other interpretations around due to lack of clarity
in the spec), and then clean up the text accordingly.

As evidence of the chaos, see the following non-exhaustive list:

(a)@conversationID:
line 349: If a protected or public field or setter method is annotated with
@ConversationID, then the conversation ID for the conversation is injected
onto the field The type of the field is not necessarily String. System
generated conversation IDs are always strings, but application generated
conversation IDs may be other complex types.

with an example on line 1572:

   @ConversationID
   private String ConversationID;


(b) @property (line 1174)
   Properties may also be injected via public setter methods even when the
   @Property annotation is not present. However, the @Property annotation
   must be used in order to inject a property onto a non-public field. In
   the case where there is no @Property annotation, the name of the
   property is the same as the name of the field or setter.


(c) @reference has similar text.

(d) And then in the @componentName and @context section there are also
private fields being annotated, and neither section addresses
private/public. These are also both injection sites.


PROPOSAL: This is not a formal proposal, but is intended to smoke out any
staunch opposition.
(a) Injection on private fields is disallowed.
(b) Cleanup the spec text - this is editorial work IMO.



 Comments   
Comment by Anish Karmarkar [ 14/Aug/08 08:15 PM ]
Issue resolved at the july 15/16 2008 f2f
http://www.oasis-open.org/apps/org/workgroup/sca-j/download.php/28926/SCA%20Java%20Minutes%202008-07-15-16.doc

Resolved by permitting injection onto any java visibility of constructors, fields or setter where allowed by Java
Comment by Anish Karmarkar [ 16/Aug/08 03:21 AM ]
Applied the issue resolution in WD04 located at:
http://www.oasis-open.org/apps/org/workgroup/sca-j/download.php/29077/sca-javacaa-1.1-spec-WD04.doc
Comment by Dave Booz [ 06/Oct/08 11:56 AM ]
Oct 6 - WD05 accepted as CD01
http://www.oasis-open.org/committees/download.php/29558/sca-javacaa-1.1-spec-WD05.pdf




[JAVA-38] Inconsistent rules for the use of @reference annotation
Created: 24/Apr/08  Updated: 13/Mar/09

Status: Closed
Project: OASIS SCA Java TC
Component/s: Java Common Annotations and APIs specification, Java Component Implementation Specification
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Ron Barack Assigned To: Mike Edwards
Resolution: Duplicate Votes: 0

Issue Links:
Depends on
depends on JAVA-55 SCA Java Specifications do not Adequa... Closed

 Description   
Raised By: Dave Booz

TARGET: SCA Java CA&A (WD02) and SCA Java C&I(draft-20070926)

DESCRIPTION:
Java CAA WD02 - Lines 1235-1239:

The problem in this text is that a reference cannot be injected onto a
protected field without
an @Reference annotation, which contradicts the C&I spec.

Java CI draft 20070926 - line 378

which says that a protected field can be a reference.


See also this email:
http://lists.oasis-open.org/archives/sca-j/200804/msg00040.html


PROPOSAL: Adjust the CAA spec to match the C&I spec.


 Comments   
Comment by Ron Barack [ 29/May/08 09:02 AM ]
OPENED: http://www.oasis-open.org/apps/org/workgroup/sca-j/download.php/28160/SCA%20Java%20Minutes%202008-04-24.doc
Comment by Dave Booz [ 05/Dec/08 11:09 AM ]
Issue 55 proposes to rewrite the relevant section of the Java C&I.
Comment by Dave Booz [ 05/Dec/08 11:10 AM ]
CAA CD01 lines are 1398-1400
Comment by Mark Combellack [ 02/Feb/09 05:39 AM ]
JAVA-55 has now been applied.
Comment by Dave Booz [ 13/Mar/09 09:59 AM ]
Java-133 removed problem text - closed as fixed by 133 - telecon Mar 13
Comment by Dave Booz [ 13/Mar/09 10:00 AM ]
Resolved by 133




[JAVA-39] Incorrect example in Java Component Implementation Spec v1.00 - Sec 1.2.4
Created: 08/May/08  Updated: 13/Mar/09

Status: Closed
Project: OASIS SCA Java TC
Component/s: Java Component Implementation Specification
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Ron Barack Assigned To: Mike Edwards
Resolution: Duplicate Votes: 0

Issue Links:
Depends on
depends on JAVA-55 SCA Java Specifications do not Adequa... Closed

 Description   
RAISED BY: Vamsi

Revising the description as per the last discussion on the issue (see [1]).

DESCRIPTION:
Java Component Implementation Specification v1.00 - Sec 1.2.4 - Lines 296
to 302:
296 /** Additional property set through a method */
297 public class Impl4 {
298 public String someProperty;
299 public SomeService someReference;
300 public Impl2(String a, SomeService b) {...}
301 @Property public void setAnotherProperty(int x) {...}
302 }

The constuctor name Impl2 in line 300 is not correct. Also, with the
presence of @Property annotation on setAnotherProperty() in line 301 it is
not clear how someProperty and someReference could be a property and
reference respectively as section 1.2.7 (Semantics of an Unannotated
Implementation) will not be applicable to this example.

PROPOSAL: Correct the constructor name and add comments to clarify how
someProperty and someReference are a property and a reference respectively.
Change lines 296 to 302 as given below:

296 /** Additional property set through a method */
297 public class Impl4 {
298 public String someProperty; // property specified in component
definition
299 public SomeService someReference; // reference specified in component
definition
300 public Impl4(String a, SomeService b) {...}
301 @Property public void setAnotherProperty(int x) {...}
302 }

[1] http://lists.oasis-open.org/archives/sca-j/200805/msg00010.html


 Comments   
Comment by Ron Barack [ 29/May/08 08:47 AM ]
OPENED: http://www.oasis-open.org/apps/org/workgroup/sca-j/download.php/28356/SCA%20Java%20Minutes%202008-05-15.doc
Comment by Dave Booz [ 05/Dec/08 11:13 AM ]
awaiting revised proposal
Comment by Dave Booz [ 13/Mar/09 09:57 AM ]
closed as resolved by 137 - telecon Mar 13
Comment by Dave Booz [ 13/Mar/09 09:58 AM ]
Resolved by 137




[JAVA-40] Incorrect interface name - Java Common Annotations and APIs v1.0 - Sec1.7.5
Created: 08/May/08  Updated: 30/Oct/08

Status: Closed
Project: OASIS SCA Java TC
Component/s: Java Common Annotations and APIs specification
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Ron Barack Assigned To: Unassigned
Resolution: No Action Votes: 0


 Description   
RAISED BY: Vamsi

DESCRIPTION:
Java Common Annotations and APIs v1.0 - Sec 1.7.5 - Line 945 reads:
"The ServiceReference Java interface has the following methods:"

This immediately follows the interface definition of Conversation.

PROPOSAL: Change ServiceReference to Conversation so that the line reads
"The Conversation Java interface has the following methods:"

See http://lists.oasis-open.org/archives/sca-j/200804/msg00053.html

 Comments   
Comment by Ron Barack [ 08/May/08 07:37 AM ]
OPENED: http://www.oasis-open.org/apps/org/workgroup/sca-j/download.php/28217/SCA%20Java%20Minutes%202008-05-01.txt
Comment by Mark Combellack [ 30/Oct/08 06:50 AM ]
Closed no action as discussed in meeting on 27th October 2008
http://www.oasis-open.org/committees/download.php/29842/SCA%20Java%20Minutes%202008-10-27.doc




[JAVA-41] Inconsistent method description for @Init and @Destroy annotations
Created: 08/May/08  Updated: 11/May/09

Status: Closed
Project: OASIS SCA Java TC
Component/s: Java Common Annotations and APIs specification
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Ron Barack Assigned To: Michael Rowley
Resolution: Fixed Votes: 0


 Description   
RAISED BY: Vamsi

DESCRIPTION:
Java Common Annotations and APIs v1.0 - Sec 1.2.4 - Line 269:
269 .... Note that only public, no argument methods may be annotated as
lifecycle methods.

Sec 1.8.8. - Lines 1225 to 1227:
1225 The @Destroy annotation type is used to annotate a Java class method
that will be called when the scope
1226 defined for the local service implemented by the class ends. The
method must have a void return value and
1227 no arguments. The annotated method must be public.

Sec 1.8.11 - Lines 1290 to 1293:
1290 The @Init annotation type is used to annotate a Java class method that
is called when the scope defined for
1291 the local service implemented by the class starts. The method must
have a void return value and no
1292 arguments. The annotated method must be public. The annotated method
is called after all property and
1293 reference injection is complete.

REASON: Sec 1.2.4 does not talk about return type of the method whereas
sections 1.8.8. and 1.8.11 say that the method must have a void return
value.

PROPOSAL: Make the method description consistent across these three
sections. Change line 269 to read the following:
.... Note that only public, no argument methods with a void return type may
be annotated as lifecycle methods.

In lines 1226 and 1291, change "void return value" to "void return type".

See http://lists.oasis-open.org/archives/sca-j/200804/msg00059.html



 Comments   
Comment by Ron Barack [ 08/May/08 07:37 AM ]
OPENED: http://www.oasis-open.org/apps/org/workgroup/sca-j/download.php/28217/SCA%20Java%20Minutes%202008-05-01.txt
Comment by Mark Combellack [ 30/Oct/08 06:49 AM ]
Resolved as discussed in meeting on 27th October 2008
http://www.oasis-open.org/committees/download.php/29842/SCA%20Java%20Minutes%202008-10-27.doc
Comment by Anish Karmarkar [ 12/Dec/08 01:48 AM ]
Applied resolution in cd01-rev http://www.oasis-open.org/apps/org/workgroup/sca-j/download.php/30365/sca-javacaa-1.1-spec-cd01-rev1.pdf




[JAVA-42] Incorrect examples of methods annotated @Init and @Destroy
Created: 08/May/08  Updated: 11/May/09

Status: Closed
Project: OASIS SCA Java TC
Component/s: Java Common Annotations and APIs specification
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Ron Barack Assigned To: Michael Rowley
Resolution: Fixed Votes: 0


 Description   
RAISED BY: Vamsi

DESCRIPTION:
Java Common Annotations and APIs v1.0

Sec 1.8.8 - Line 1232
1232 void myDestroyMethod() {

Sec 1.8.11 - Line 1298
1298 void myInitMethod() {

Reason: @Destroy and @Init annotations must be on a public method

PROPOSAL: add public keyword to the method definition so that it reads
1232 public void myDestroyMethod() {
1298 public void myInitMethod() {

See http://lists.oasis-open.org/archives/sca-j/200804/msg00054.html



 Comments   
Comment by Ron Barack [ 08/May/08 07:36 AM ]
OPENED: http://www.oasis-open.org/apps/org/workgroup/sca-j/download.php/28217/SCA%20Java%20Minutes%202008-05-01.txt
Comment by Mark Combellack [ 05/Nov/08 07:47 AM ]
Resolved in meeting of November 3rd
http://www.oasis-open.org/committees/download.php/29906/SCA%20Java%20Minutes%202008-11-03.doc
Comment by Anish Karmarkar [ 12/Dec/08 01:49 AM ]
Applied resolution in cd01-rev http://www.oasis-open.org/apps/org/workgroup/sca-j/download.php/30365/sca-javacaa-1.1-spec-cd01-rev1.pdf




[JAVA-43] @Reference annotation can also be used on a constructor parameter.
Created: 08/May/08  Updated: 11/May/09

Status: Closed
Project: OASIS SCA Java TC
Component/s: Java Common Annotations and APIs specification
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Ron Barack Assigned To: Michael Rowley
Resolution: Fixed Votes: 0


 Description   
RAISED BY: Vamsi

DESCRIPTION:
Java Common Annotations and APIs v1.0 - Sec 1.8.14 - Lines 1404 to 1406

The @Reference annotation type is used to annotate a Java class field or a
setter method that is used to
inject a service that resolves the reference. The interface of the service
injected is defined by the type of
the Java class field or the type of the setter method input argument.

PROPOSAL: Change lines 1404 through 1406 to read the following:
The @Reference annotation type is used to annotate a Java class field,
a setter method, or a constructor parameter that is used to inject a
service that resolves the reference. The interface of the service
injected is defined by the type of the Java class field or the type
of the input parameter of the setter method or constructor.

Thanks to Simon Nash for suggesting a better wording than I originally
proposed. See
http://lists.oasis-open.org/archives/sca-j/200804/msg00055.html



 Comments   
Comment by Ron Barack [ 08/May/08 07:35 AM ]
OPENED: http://www.oasis-open.org/apps/org/workgroup/sca-j/download.php/28217/SCA%20Java%20Minutes%202008-05-01.txt
Comment by Mark Combellack [ 30/Oct/08 06:48 AM ]
Resolved as discussed in meeting on 27th October 2008
http://www.oasis-open.org/committees/download.php/29842/SCA%20Java%20Minutes%202008-10-27.doc
Comment by Anish Karmarkar [ 12/Dec/08 01:49 AM ]
Applied resolution in cd01-rev http://www.oasis-open.org/apps/org/workgroup/sca-j/download.php/30365/sca-javacaa-1.1-spec-cd01-rev1.pdf




[JAVA-44] Runtime behaviour not specified for incorrect @Init/@Destroysignature
Created: 15/May/08  Updated: 06/Oct/08

Status: Closed
Project: OASIS SCA Java TC
Component/s: Java Common Annotations and APIs specification
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Ron Barack Assigned To: Unassigned
Resolution: Fixed Votes: 0


 Description   
RAISER: Simon Nash
  
TARGET: SCA Java Common Annotations and APIs
  
DESCRIPTION:

The Java Common Annotations and APIs spec says that @Init and @Destroy methods must be public, with a void return type and no arguments. It does not specify the runtime behaviour if this rule is violated. The specification should say whether or not the SCA runtime will invoke methods annotated with @Init and @Destroy that don't conform to the specification rules.

PROPOSAL:

The SCA runtime MUST invoke these methods if they conform to the stated rules, and MUST NOT invoke these methods if they don't conform to these rules.

Replace the following paragraph in section 8.10 of the 2/28 JavaCAA spec draft:
  
1116 The @Init annotation type is used to annotate a Java class method that is called when the scope
1117 defined for the local service implemented by the class starts. The method must have a void return
1118 value and no arguments. The annotated method must be public. The annotated method is called
1119 after all property and reference injection is complete.

by the following text:

The @Init annotation is used to denote a Java class method that is called when the scope defined for the
local service implemented by the class starts. The method MUST have a void return value and no arguments.
The annotated method MUST be public.

If there is a method that matches these criteria, the SCA runtime MUST call the annotated method after all
property and reference injection is complete. A method annotated with @Init that does not match these
criteria MUST NOT be called by the SCA runtime.

Replace the following paragraph in section 8.7 of the 2/28 JavaCAA spec draft:

1054 The @Destroy annotation type is used to annotate a Java class method that will be called when
1055 the scope defined for the local service implemented by the class ends. The method must have a
1056 void return value and no arguments. The annotated method must be public.

by the following text:

The @Destroy annotation is used to denote a Java class method that is called when the scope defined for the
local service implemented by the class ends. The method MUST have a void return value and no arguments.
The annotated method MUST be public.

If there is a method that matches these criteria, the SCA runtime MUST call the annotated method. A method
annotated with @Destroy that does not match these criteria MUST NOT be called by the SCA runtime.

 Comments   
Comment by Ron Barack [ 29/May/08 08:48 AM ]
OPENED: http://www.oasis-open.org/apps/org/workgroup/sca-j/download.php/28356/SCA%20Java%20Minutes%202008-05-15.doc
Comment by Anish Karmarkar [ 14/Aug/08 08:29 PM ]
Issue resolved at the july 15/16 2008 f2f
http://www.oasis-open.org/apps/org/workgroup/sca-j/download.php/28926/SCA%20Java%20Minutes%202008-07-15-16.doc

Resolution:

The @Init annotation is used to denote a single Java class method that is called when the scope defined for the
implementation class starts. The method MAY have any access modifier and MUST have a void return value and no arguments.

If there is a method that matches these criteria, the SCA runtime MUST call the annotated method after all
property and reference injection is complete. If the implementation class has a method with an @Init annotation that does not match these
criteria, the SCA runtime MUST NOT instantiate the implementation class.
 
+

equivalent text for @Destroy
Comment by Anish Karmarkar [ 16/Aug/08 03:22 AM ]
Applied the issue resolution in WD04 located at:
http://www.oasis-open.org/apps/org/workgroup/sca-j/download.php/29077/sca-javacaa-1.1-spec-WD04.doc
Comment by Dave Booz [ 06/Oct/08 11:57 AM ]
Oct 6 - WD05 accepted as CD01
http://www.oasis-open.org/committees/download.php/29558/sca-javacaa-1.1-spec-WD05.pdf




[JAVA-45] Inconsistent description of @Callback annotation
Created: 15/May/08  Updated: 06/Oct/08

Status: Closed
Project: OASIS SCA Java TC
Component/s: Java Common Annotations and APIs specification
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Ron Barack Assigned To: Unassigned
Resolution: Fixed Votes: 0


 Description   
RAISED BY: Vamsi

DESCRIPTION:
sca-javacaa-1.1-spec-WD-01-1.doc:

Sec 6.7 - Line 381-385

Callbacks can be used for both remotable and local services. Either both
interfaces of a bidirectional service MUST be remotable, or both MUST be
local. It is illegal to mix the two. There are two basic forms of
callbacks: stateless callbacks and stateful callbacks.


A callback interface is declared by using the @Callback annotation on a
remotable service interface, which takes the Java Class object of the
interface as a parameter.


Sec 8.2 - Lines 900-901

The @Callback annotation is used to annotate a remotable service interface
with a callback interface, which takes the Java Class object of the
callback interface as a parameter.



http://www.osoa.org/jira/browse/JAVA-29 seems to have raised this issue,
but only talks about the inconsitency in sec 6.7. It does not point to the
inconsistency in section 8.2.

PROPOSAL: Remove the word "remotable" from line 900.

 Comments   
Comment by Ron Barack [ 29/May/08 08:49 AM ]
OPENED AND RESOLVED (according to the proposal)
http://www.oasis-open.org/apps/org/workgroup/sca-j/download.php/28356/SCA%20Java%20Minutes%202008-05-15.doc
Comment by Anish Karmarkar [ 16/Aug/08 03:22 AM ]
Applied the issue resolution in WD04 located at:
http://www.oasis-open.org/apps/org/workgroup/sca-j/download.php/29077/sca-javacaa-1.1-spec-WD04.doc
Comment by Dave Booz [ 06/Oct/08 11:57 AM ]
Oct 6 - WD05 accepted as CD01
http://www.oasis-open.org/committees/download.php/29558/sca-javacaa-1.1-spec-WD05.pdf




[JAVA-46] equals() method on ServiceReference and CallableReference
Created: 22/May/08  Updated: 07/Dec/09

Status: Closed
Project: OASIS SCA Java TC
Component/s: Java Common Annotations and APIs specification
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Minor
Reporter: Mark Combellack Assigned To: Mark Combellack
Resolution: Won't Fix Votes: 0


 Description   
RAISER: Mark Combellack
  
TARGET: SCA Java Common Annotations and APIs
  
DESCRIPTION:



The equals() and hashCode() methods are some of the fundamental Java Object methods that are used for comparing objects. The SCA Java specifications do not describe what should happen when the equals() or hashCode() methods are called on a ServiceReference or CallableReference.

 

Without an explicit statement, SCA developers will not know whether they can compare ServiceReferences and CallableReferences.

 

I've sent an email to the SCA-Java list (see link below) that contains an example usage scenario.

 

http://lists.oasis-open.org/archives/sca-j/200805/msg00037.html

 


PROPOSAL:

Update the specification to state that the equals() method for ServiceReference can be used to test whether they refer to the same target.

 

Update the specification to state that the equals() method for CallableReference can be used to test whether they refer to the same target.

 

Update the specification to state that the hashCode() method for ServiceReference and CallableReference must comply with the hashCode() contract as defined by Java - see http://java.sun.com/j2se/1.5.0/docs/api/java/lang/Object.html#hashCode()
 


 Comments   
Comment by Ron Barack [ 29/May/08 08:42 AM ]
http://www.oasis-open.org/apps/org/workgroup/sca-j/download.php/28440/SCA%20Java%20Minutes%202008-05-22.doc
Comment by Dave Booz [ 05/Dec/08 11:41 AM ]
awaiting proposal
Comment by Mark Combellack [ 09/Feb/09 05:43 AM ]
Latest proposal at:
http://lists.oasis-open.org/archives/sca-j/200902/msg00073.html
Comment by Mark Combellack [ 30/Oct/09 06:07 AM ]
We no longer need to consider equals() method for CallableReference since this class has been removed.
Comment by Dave Booz [ 07/Dec/09 10:54 AM ]
closed Nov 7 telecon - Closed No Action




[JAVA-47] Missing description of what the @EagerInit annotation does
Created: 29/May/08  Updated: 11/May/09

Status: Closed
Project: OASIS SCA Java TC
Component/s: Java Common Annotations and APIs specification
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Ron Barack Assigned To: Michael Rowley
Resolution: Fixed Votes: 0


 Description   
RAISER: Mark Combellack
  
TARGET: SCA Java Common Annotations and APIs
  
DESCRIPTION:

Working Draft 01 - line 1080

Working Draft 03 - line 1208

 

There is no description of what the @EagerInit annotation does. All the other annotations have some description but it is missing for @EagerInit.

 

I raised this as an editorial issue in [1] but after editorial discussion, it was decided to raise an issue for it as it is more than just an editorial issue.

 

PROPOSAL:



Update the specification to add the following text at after line 1208 of the @EagerInit section in Working Draft 03

 

The @EagerInit annotation is used to annotate a Java class method on a Composite scoped implementation for eager initialization. When marked for eager initialization, the composite scoped instance is created when its containing component is started.

The annotated method MUST have a void return value and no arguments. The annotated method MUST be public. The annotated method is called after all property and reference injection is complete.


 Comments   
Comment by Dave Booz [ 22/Sep/08 01:00 PM ]
Resolved Sept 22:

The @EagerInit annotation is used to annotate the Java class of a COMPOSITE scoped implementation for eager initialization. When marked for eager initialization, the composite scoped instance is created when its containing component is started.

This description goes at line 1222 of WD 04.
Comment by Anish Karmarkar [ 12/Dec/08 01:49 AM ]
Applied resolution in cd01-rev http://www.oasis-open.org/apps/org/workgroup/sca-j/download.php/30365/sca-javacaa-1.1-spec-cd01-rev1.pdf




[JAVA-48] @Callback annotation does not feature in section on Interfaces
Created: 26/Jun/08  Updated: 11/May/09

Status: Closed
Project: OASIS SCA Java TC
Component/s: Java Common Annotations and APIs specification
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Simon Nash Assigned To: Michael Rowley
Resolution: Fixed Votes: 0


 Description   
DESCRIPTION:
sca-javacaa-1.1-spec-WD03.doc - Section 3 Interfaces - Line 170 reads:

"This section describes the SCA Java interface element and the SCA metadata
for Java interfaces."

The section includes a brief description of @Remotable and @Conversational
annotations which are used on interfaces. This section does not mention
the @Callback annotation which is also used on interfaces.


PROPOSAL:

Add a brief description of @Callback annotation to section 3 Interfaces.


 Comments   
Comment by Dave Booz [ 22/Sep/08 01:02 PM ]
Resolved via text in http://lists.oasis-open.org/archives/sca-j/200809/msg00082.html to be inserted after line 202 in WD-04
Comment by Anish Karmarkar [ 12/Dec/08 01:50 AM ]
Applied resolution in cd01-rev http://www.oasis-open.org/apps/org/workgroup/sca-j/download.php/30365/sca-javacaa-1.1-spec-cd01-rev1.pdf




[JAVA-49] Version requirements for SDO, JAXB and JAX-WS
Created: 26/Jun/08  Updated: 11/May/09

Status: Closed
Project: OASIS SCA Java TC
Component/s: Java Common Annotations and APIs specification
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Simon Nash Assigned To: Michael Rowley
Resolution: Fixed Votes: 0


 Description   
TARGET: Java Common Annotations and APIs, WD 03, sections 1.2, 8.16 and 9

DESCRIPTION: Version requirements for SDO, JAXB and JAX-WS

The current specification contains inconsistent and ambiguous references to the versions of SDO, JAXB and JAX-WS that are specified.

Section 1.2 (Normative References) refers to SDO 2.1 (correct link to OSOA), JAXB (incorrect link to JSR 31, JAXB 1.0), and JAX-WS (ambiguous link to JSR 224, which covers the 2.0 and 2.1 levels)

Section 8.16 (@Remotable) refers to SDO 2.0 or 2.1, and JAXB 2.0

Section 9 (WSDL to Java and Java to WSDL) refers to SDO 2.1 and JAXB 2.0

The above sections need to refer to a consistent version or versions of these specfications.


PROPOSAL:

The 2.1 versions of all these specifications should be referenced.

In section 1.2 (lines 39-40), replace reference [3] and the link by

[3] JAXB 2.1 Specification
http://jcp.org/en/jsr/detail?id=222

In section 1.2 (line 51), replace reference [7] by

[7] JAX-WS 2.1 Specification

In section 8.16 (line 1914), remove the reference to SDO 2.0.

In section 8.16 (line 1914), replace the reference to JAXB 2.0 by JAXB 2.1.

In section 9 (line 2205), replace the reference to JAX-WS by JAX-WS 2.1.

In section 9 (line 2212), replace the reference to JAXB 2.0 by JAXB 2.1.


 Comments   
Comment by Dave Booz [ 22/Sep/08 09:55 AM ]
Latest proposal here:
http://lists.oasis-open.org/archives/sca-j/200809/msg00080.html
Comment by Dave Booz [ 29/Sep/08 02:01 PM ]
Opened June 19:
http://www.oasis-open.org/apps/org/workgroup/sca-j/download.php/28677/SCA%20Java%20Minutes%202008-06-19.doc
Comment by Mark Combellack [ 15/Oct/08 04:54 AM ]
Resolved 13th October
http://www.oasis-open.org/committees/document.php?document_id=29665
Comment by Anish Karmarkar [ 12/Dec/08 01:50 AM ]
Applied resolution in cd01-rev http://www.oasis-open.org/apps/org/workgroup/sca-j/download.php/30365/sca-javacaa-1.1-spec-cd01-rev1.pdf




[JAVA-50] Define an API to call References whose SEI is not know at Design time
Created: 24/Jul/08  Updated: 14/Aug/08

Status: Closed
Project: OASIS SCA Java TC
Component/s: Java Common Annotations and APIs specification
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Anish Karmarkar Assigned To: Anish Karmarkar
Resolution: Won't Fix Votes: 0


 Description   
http://lists.oasis-open.org/archives/sca-j/200807/msg00036.html

TARGET: Java Common Annotations and APIs, WD 03

DESCRIPTION:
Currently the spec is missing an API to do dynamic calls. E.g. assuming that there is a framework that based on some metadata dynamically creates SDO DataObjects, knows which is the SCA reference to be invoked, knows the operation name. Then an API to do a dynamic call to this reference is very convenient.
The SDO specification defines the so called Data Access Service entity, which is an abstract entity used to call services. As far as I am aware - the DAS API is not specified too formally.
Maybe the focus of SCA-J is not to have such APIs at the end. And leave it as a vendor specific solution, but it would be interesting to discuss what t do in such case.

This issue is not related to JAVA-1 - which is about calling SCA References or Services from outside SCA Managed code.
This is rather to call a refernce from inisde a SCA managed component, but not knowing or caring or having, the actual interface.

PROPOSAL:
1. Come to a conclusion whether this is part of the spec, or should be vendor specific
2. If it should be part of the spec - analyze different approaches how it can be done
3. If it should be vendor specific - at least provide APIs how to do it.

 Comments   
Comment by Anish Karmarkar [ 14/Aug/08 08:07 PM ]
Issue rejected at the july 15/16 2008 f2f
http://www.oasis-open.org/apps/org/workgroup/sca-j/download.php/28926/SCA%20Java%20Minutes%202008-07-15-16.doc




[JAVA-51] More examples on mapping to Java
Created: 24/Jul/08  Updated: 10/Aug/09

Status: Closed
Project: OASIS SCA Java TC
Component/s: Java Common Annotations and APIs specification
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Minor
Reporter: Anish Karmarkar Assigned To: Unassigned
Resolution: Won't Fix Votes: 0


 Description   
http://lists.oasis-open.org/archives/sca-j/200807/msg00037.html

TARGET: Java Common Annotations and APIs, WD 03
DESCRIPTION:
The current specification is missing a detailed description of how <interface.wsdl> is mapped to a Java class.
IMO SCA-J and SCA-Bindigs specs have focused on the so called "Inside-Out"-case. E.g. start with the Java Implementation, and then expose it as web service. Most of the issues relate to this process, and most of the examples are - "component with service with interface.java, promoted to service on composite level with interface.wsdl".

If I am mistaken - then I appologise myslef...

But - it seems that a more common scenario is when one starts with WSDL. This would mean that "interface.java" does not need to be mentioned at all. And we will have components with a Service element with 'interface.wsdl'.
The SCA-J tells for this - just follow JAX-WS. But there are no examples.
And there are really intetresting cases. e.g.
-> Use JAX-WS and JAXB for data binding
-> Use JAX-WS and SDO for data binding
> Use Static SDO
> Use dynamic SDO
-> How to handle the WS Annotations coming from JSR 181, and how are they related to the ones defined in SCA-J ?

I am not telling that the current spec does not address this topic. Just that it may be enriched with more examples and made more formal, so that we can reach some state of interoperability on this topi at some point of time.

PROPOSAL:
No proposal yet. I have some ideas, but I would like to collect more feedback, and then create a common proposal for this.

 Comments   
Comment by Anish Karmarkar [ 14/Aug/08 08:10 PM ]
Issue opened at the july 15/16 2008 f2f
http://www.oasis-open.org/apps/org/workgroup/sca-j/download.php/28926/SCA%20Java%20Minutes%202008-07-15-16.doc
Comment by Dave Booz [ 05/Dec/08 11:43 AM ]
awaiting proposal
Comment by Dave Booz [ 10/Aug/09 10:56 AM ]
closed no action - Aug 10 telecon




[JAVA-52] RequestContext.getCallbackReference() description inadequate
Created: 24/Jul/08  Updated: 11/May/09

Status: Closed
Project: OASIS SCA Java TC
Component/s: Java Common Annotations and APIs specification
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Anish Karmarkar Assigned To: Anish Karmarkar
Resolution: Fixed Votes: 0


 Description   
http://lists.oasis-open.org/archives/sca-j/200807/msg00038.html

Title: RequestContext.getCallbackReference() description inadequate

Description: RequestContext.getCallbackReference() description does not say what should happen if it is called for a callback request or if it called for a request whose interface is not bi-directional.

Proposal:
change the description to say that in the above situation it either MUST return a null or MUST throw an exception.


 Comments   
Comment by Anish Karmarkar [ 14/Aug/08 08:01 PM ]
Issue accepted on 2008-07-24 concall
http://www.oasis-open.org/apps/org/workgroup/sca-j/download.php/28994/SCA%20Java%20Minutes%202008-07-24.doc

Issue accepted. Added getCallback() method to this issue.
Comment by Dave Booz [ 12/Jan/09 10:50 AM ]
resolved Jan 12 telecon - MUST return null was chosen. Editors need to form up the final words.
Comment by Anish Karmarkar [ 19/Jan/09 01:59 AM ]
Applied resolution in cd01-rev4:
http://www.oasis-open.org/apps/org/workgroup/sca-j/download.php/30736/sca-javacaa-1.1-spec-cd01-rev4.pdf
http://www.oasis-open.org/apps/org/workgroup/sca-j/download.php/30735/sca-javacaa-1.1-spec-cd01-rev4.doc




[JAVA-53] what happens if init() throws a runtime exception
Created: 24/Jul/08  Updated: 18/May/09

Status: Closed
Project: OASIS SCA Java TC
Component/s: Java Common Annotations and APIs specification
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Anish Karmarkar Assigned To: Mark Combellack
Resolution: Duplicate Votes: 0

Issue Links:
Depends on
depends on JAVA-65 There is no lifecycle defined for SCA... Closed

 Description   
http://lists.oasis-open.org/archives/sca-j/200807/msg00039.html

Title: what happens if init() throws a runtime exception

Target: JCAA spec

Description:

The spec does not say what should happen if the init method throws a runtime exception.

Proposal:

outline - we should say that if the init method throws a runtime exception none of the service operations should ever be called by the runtime.


 Comments   
Comment by Anish Karmarkar [ 14/Aug/08 08:03 PM ]
Issue accepted on the 2008-07-24 concall with new wordings for the issue.
http://www.oasis-open.org/apps/org/workgroup/sca-j/download.php/28994/SCA%20Java%20Minutes%202008-07-24.doc

New wordings:
Java specs do not say what the SCA runtime must do if there is an exception thrown by the user code. This applies to constructors, init methods, service invocations, injections etc
Comment by Dave Booz [ 05/Dec/08 11:48 AM ]
awaiting proposal
Comment by Mark Combellack [ 08/Dec/08 04:04 AM ]
The proposal for the SCA Component life cycle (JAVA-65) details what happens if an exception is thrown from the various life cycle methods

Once JAVA-65 is resolved, this issue can probably just be closed since JAVA-65 will cover it.
Comment by Dave Booz [ 18/May/09 09:48 AM ]
resolved May 18 telecon - as it is resolved by Java-65
Comment by Dave Booz [ 18/May/09 09:49 AM ]
Resolved by Java-65.




[JAVA-54] Section 7.1 of the Java CAA Specification is unclear
Created: 11/Aug/08  Updated: 16/Feb/10

Status: Closed
Project: OASIS SCA Java TC
Component/s: Java Common Annotations and APIs specification
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Critical
Reporter: Anish Karmarkar Assigned To: Unassigned
Resolution: Fixed Votes: 0


 Description   
Raised in email at http://lists.oasis-open.org/archives/sca-j/200807/msg00066.html

Raiser: Mike Edwards

Target: Java Common Annotations and APIs specification WD-03

Description:

Section 7.1 of the CAA specification describes the Component Context API.

This API has several methods with various parameters and return values.
The descriptions of these methods are all very brief and do not adequately describe preconditions,
postconditions, nor adequately describe the parameter values and return values for the methods.

The lack of clarity and detail means that implementers and users of the API cannot be sure what is
expected from each method.

Proposal:

None at present.


 Comments   
Comment by Anish Karmarkar [ 11/Aug/08 03:17 AM ]
Issue accepted at the 2008-08-04 concall.
http://www.oasis-open.org/apps/org/workgroup/sca-j/document.php?document_id=29023
Comment by Dave Booz [ 05/Dec/08 11:53 AM ]
awaiting proposal
Comment by Dave Booz [ 25/Jan/10 10:27 AM ]
resolved Jan 25: See minutes for resolution
Comment by Dave Booz [ 16/Feb/10 11:09 AM ]
Applied in CD03-rev3: http://www.oasis-open.org/committees/download.php/36172/sca-javacaa-1.1-spec-cd03-rev3.doc
Comment by Dave Booz [ 16/Feb/10 11:17 AM ]
Closed as a result of CD vote on Feb 15,2010.




[JAVA-55] SCA Java Specifications do not Adequately Define the ComponentType of a Java implementation
Created: 11/Aug/08  Updated: 05/May/09

Status: Closed
Project: OASIS SCA Java TC
Component/s: Java Component Implementation Specification
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Critical
Reporter: Anish Karmarkar Assigned To: Unassigned
Resolution: Fixed Votes: 0

Issue Links:
Depends on
depends on JAVA-111 Constructor name information may not ... Closed
is depended on by JAVA-87 Java-related C&I specs needs to defin... Closed
is depended on by JAVA-27 Security Annotations in generated Com... Closed
is depended on by JAVA-17 A hole in the algorithm of introspect... Closed
is depended on by JAVA-38 Inconsistent rules for the use of @re... Closed
is depended on by JAVA-39 Incorrect example in Java Component I... Closed

 Description   
Raised in email at http://lists.oasis-open.org/archives/sca-j/200808/msg00006.html

Raiser: Mike Edwards

Target: Java C&I sca-javaci-draft-20070926.pdf

(is this a first for this spec??)

Description:

<Note: I believe that a description of componentType belongs strictly with the component implementation specifications
and would be different (say) for Spring, EJBs (JEE) and POJOs - so I've raised this against the Java POJO spec...
we may need to do the same for the other specs>

The component type of a Java Component Implementation is not described adequately.

In particular, there is no rigorous set of (compliance testable) rules that relate the content of a Java POJO implementation
class to its (implied, derived) component type.

There are some examples in lines 71-78, 97-105, and 120-130. But there are no definitive or normative statements.

There are no statements in Sections 3 and 4 relating to References and Properties in component types.

Section 8 has some rules about deriving component type for an unannotated Java class - but:
- it only covers references and properties. Services are (confusingly) discussed elsewhere.
- it is not clear whether "unannotated" means "absolutely no @Reference or @Property annotations " or "parts of a class that are not annotated"
(ie if there is at least one @Reference or @Property annotation on a class, does that mean that it is treated as "annotated" and there is no
search for anything not annotated - or does a search for unannotated entities still take place?)
- it does not lay down rules for the generation of component type information from the discovered unannotated features of the class

Proposal:

1) Add a new section to the specification with the title "The Component Type of a Java Component Implementation"

- this section will provide normative detail on the component type of a Java component

2) Clarify the contents of Section 8

a) Make it clear that any @Reference or @Property annotation in a Java class means that the whole class is regarded as "annotated" and that
only annotated features of the class contribute to the component type. Only classes with no @Reference or @Property annotations
are treated according to the rules of "unannotated implementation"

b) Add in the material about unannotated services here.

b) Upgrade the description of the rules for an unanotated implementation to be explicit about the component type elements
that correspond to the various features of the class.

{email contains marked up version of the proposal as attachment}




 Comments   
Comment by Anish Karmarkar [ 11/Aug/08 03:21 AM ]
Issue accepted by the TC at the 2008-08-04 concall
http://www.oasis-open.org/apps/org/workgroup/sca-j/document.php?document_id=29023
Comment by Dave Booz [ 05/Dec/08 11:54 AM ]
awaiting updated proposal
Comment by Dave Booz [ 12/Dec/08 09:10 AM ]
Updated proposal: http://lists.oasis-open.org/archives/sca-j/200812/msg00060.html
Comment by Dave Booz [ 15/Dec/08 10:26 AM ]
Agreed resolution on Dec 15
Mike to send final words (version d)
Comment by Dave Booz [ 16/Dec/08 01:10 PM ]
applied to wd02
Comment by Dave Booz [ 05/May/09 06:40 AM ]
Applied in CD01




[JAVA-56] When more than one interface with the same unqualified name used in the @Service annotation
Created: 14/Aug/08  Updated: 11/May/09

Status: Closed
Project: OASIS SCA Java TC
Component/s: Java Common Annotations and APIs specification
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Mark Combellack Assigned To: Dave Booz
Resolution: Fixed Votes: 0


 Description   
RAISER: Vamsavardhana Chillakuru
Thread: http://www.oasis-open.org/apps/org/workgroup/sca-j/email/archives/200808/msg00054.html



TARGET: Java Component Implementation Specification



DESCRIPTION:

sca-javaci-draft-20070926.doc
Java Component Implementation Specification Version 1.1 draft - Section -
2.1:

The service name computed from @Service annotation is the unqualified name
of the class/interface specified in the annotation. What happens when
there is more than one interface with the same unqualified name (as given
in the example below) used in the @Service annotation?

package mypkg1;
public interface HelloService {
    String hello1(String msg);
}

package mypkg2;
public interface HelloService {
    String hello2(String msg);
}

@Service(interfaces = {mypkg1.HelloService.class,
mypkg2.HelloService.class})
public HelloServiceImpl implements mypkg1.HelloService, mypkg2.HelloService
{
    public String hello1(String msg) {
        return "hello1 " + msg;
    }
    public String hello2(String msg) {
        return "hello2 " + msg;
    }
}

 Is it an error? Should the service name include package name of the
interface/class as well?



PROPOSALS:

None

 Comments   
Comment by Dave Booz [ 29/Sep/08 02:04 PM ]
Opened Aug 18
http://www.oasis-open.org/apps/org/workgroup/sca-j/download.php/29201/SCA%20Java%20Minutes%202008-08-18.doc
Comment by Dave Booz [ 11/Nov/08 04:29 AM ]
resolved at F2F Nov 11:
Comment by Dave Booz [ 16/Dec/08 01:09 PM ]
note: the resolution is in CAA.
Comment by Dave Booz [ 16/Dec/08 01:10 PM ]
applied to CD012-rev3.
Comment by Dave Booz [ 16/Dec/08 01:10 PM ]
correction CD01-rev3




[JAVA-57] SCA Spring Client and Implementation Specification uses an unacceptable namespace
Created: 18/Aug/08  Updated: 06/Jun/11

Status: Closed
Project: OASIS SCA Java TC
Component/s: Spring Component Implementation Specification
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Anish Karmarkar Assigned To: Anish Karmarkar
Resolution: Fixed Votes: 0


 Description   
Raised at http://lists.oasis-open.org/archives/sca-j/200808/msg00081.html

Raiser: Mike Edwards

Target Specification: sca-springci-draft-20070926.doc

Description:

The Spring C&I specification has a schema defined starting at line 157, which uses the namespace:

http://www.springframework.org/schema/sca


This namespace is unacceptable in the OASIS specification and must be changed - the namespace is NOT
owned by springframework.org - and the XSD is not to be found at the location implied by the namespace.


Proposal:

Change the namespace and the target namespace of the schema to the following:

"http://docs.oasis-open.org/ns/opencsa/sca-j/spring/200808"

- this is owned by OASIS and the schema can be placed at the location implied by its URI


 Comments   
Comment by Dave Booz [ 29/Sep/08 02:07 PM ]
Opened Sept 8:
http://www.oasis-open.org/apps/org/workgroup/sca-j/download.php/29287/SCA%20Java%20Minutes%202008-09-08.doc
Comment by Mark Combellack [ 15/Oct/08 04:55 AM ]
Resolved 13th October
http://www.oasis-open.org/committees/document.php?document_id=29665
Comment by Mike Edwards [ 21/Nov/08 12:41 PM ]
Applied in sca-springci-1.1-spec-WD01.doc
Comment by Anish Karmarkar [ 06/Jun/11 06:31 PM ]
Accepted in CSD01




[JAVA-58] SCA Spring C&I Specification does not have a normative definition of how to calculate the ComponentType of a Spring Application context
Created: 18/Aug/08  Updated: 06/Jun/11

Status: Closed
Project: OASIS SCA Java TC
Component/s: Spring Component Implementation Specification
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Anish Karmarkar Assigned To: Mike Edwards
Resolution: Fixed Votes: 0

Issue Links:
Depends on
is depended on by JAVA-92 Spring C&I spec needs to define how e... Closed
Relates to
relates to JAVA-92 Spring C&I spec needs to define how e... Closed

 Description   
Raised at http://lists.oasis-open.org/archives/sca-j/200808/msg00082.html

Raiser: Mike Edwards

Target: sca-springci-draft-20070926.doc

Description:

The SCA Spring Client and Implementation specification does not normatively define how the componentType of a Spring Application context is
determined. This information is essential if there are to be conformance tests for runtimes which support the Spring implementation type.


Proposal:

TBD. (Will require a rewrite of several parts of the specification)

 Comments   
Comment by Dave Booz [ 29/Sep/08 02:07 PM ]
Opened Sept 8:
http://www.oasis-open.org/apps/org/workgroup/sca-j/download.php/29287/SCA%20Java%20Minutes%202008-09-08.doc
Comment by Dave Booz [ 12/Nov/08 09:13 AM ]
Linked to 92 at Nov 11 F2F
Comment by Dave Booz [ 24/Nov/08 10:30 AM ]
proposal:
http://lists.oasis-open.org/archives/sca-j/200811/msg00074.html
Comment by Dave Booz [ 05/Dec/08 11:55 AM ]
awaiting proposal
Comment by Dave Booz [ 22/May/09 09:15 AM ]
latest proposal: http://www.oasis-open.org/apps/org/workgroup/sca-j/download.php/32614/sca-springci-draft-20070926_Issue58c.pdf
Comment by Dave Booz [ 17/Jul/09 09:18 AM ]
latest proposal: http://www.oasis-open.org/apps/org/workgroup/sca-j/download.php/33357/sca-springci-draft-20070926_Issue58e.pdf
Comment by Dave Booz [ 17/Jul/09 09:19 AM ]
resolved July 17 telecon: with proposal above
Comment by Mike Edwards [ 14/Aug/09 08:23 AM ]
Applied in WD02 of Spring spec

sca-springci-1.1-spec-WD02.doc
Comment by Anish Karmarkar [ 06/Jun/11 06:31 PM ]
Accepted in CSD01




[JAVA-59] SCA Spring C & I specification does not state what happens when a Bean exposed as a service implements mutliple interfaces
Created: 18/Aug/08  Updated: 06/Jun/11

Status: Closed
Project: OASIS SCA Java TC
Component/s: Spring Component Implementation Specification
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Anish Karmarkar Assigned To: Mike Edwards
Resolution: Fixed Votes: 0


 Description   
Raised at http://lists.oasis-open.org/archives/sca-j/200808/msg00084.html

Raiser: Mike Edwards

Target: sca-springci-draft-20070926.doc

Description:

It is possible for a Spring Bean in a Spring Application context to implement more than one interface, which may in turn be exposed via SCA as a service.

The specification does not say how such a Bean should be exposed as a service - leaving any runtime implementation to make a guess.

Proposal:

Where a Spring Bean in a Spring Application context implements more than one interface which is either explicitly or implicitly exposed as a service according
to SCA Java rules:

- Each interface is exposed as a separate service
- The name of each service must be unique. Uniqueness is achieved by giving each service is the name "beanName.serviceName", where beanName is the
name of the Bean in the application context and serviceName is the name of the service, where the service name is EITHER given explicitly via an @Service
annotation in the code OR determined implicitly from the name of the interface.


 Comments   
Comment by Dave Booz [ 29/Sep/08 02:07 PM ]
Opened Sept 8:
http://www.oasis-open.org/apps/org/workgroup/sca-j/download.php/29287/SCA%20Java%20Minutes%202008-09-08.doc
Comment by Dave Booz [ 05/Dec/08 11:55 AM ]
awaiting proposal
Comment by Dave Booz [ 17/Jul/09 09:29 AM ]
latest proposal: http://lists.oasis-open.org/archives/sca-j/200907/msg00041.html
Comment by Dave Booz [ 17/Jul/09 09:37 AM ]
resolved July 17 telecon with proposal above.
Comment by Mike Edwards [ 14/Aug/09 08:23 AM ]
Applied in WD02 of Spring spec

sca-springci-1.1-spec-WD02.doc
Comment by Anish Karmarkar [ 06/Jun/11 06:30 PM ]
Accepted in CSD01




[JAVA-60] Sharing Java artifacts across contributions
Created: 04/Sep/08  Updated: 05/May/09

Status: Closed
Project: OASIS SCA Java TC
Component/s: Java Component Implementation Specification
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Critical
Reporter: Dave Booz Assigned To: Unassigned
Resolution: Fixed Votes: 0


 Description   
RAISED BY: Dave Booz

DESCRIPTION:

The SCA Assembly spec defines a means for sharing XML artifacts across SCA contributions. While some aspects of this are actively being debated (http://www.osoa.org/jira/browse/ASSEMBLY-8) as an issue, the same consideration of shared artifacts needs to be addressed by the Java TC. Chiefly the question is how to enable sharing of Java artifacts (Interfaces, JAXB objects, SDOs, potentially even component implementation classes, etc) across contributions such that a referring contribution can make use of Java artifacts from a referred to contribution.

PROPOSAL:

None, but my mental model starts with something called import.java/export.java, as an extension of the base assembly import/export model

http://lists.oasis-open.org/archives/sca-j/200808/msg00109.html

 Comments   
Comment by Dave Booz [ 29/Sep/08 02:07 PM ]
Opened Sept 8:
http://www.oasis-open.org/apps/org/workgroup/sca-j/download.php/29287/SCA%20Java%20Minutes%202008-09-08.doc
Comment by Dave Booz [ 05/Dec/08 11:55 AM ]
awaiting proposal
Comment by Dave Booz [ 03/Feb/09 09:50 AM ]
Latest proposal:
http://lists.oasis-open.org/archives/sca-j/200902/msg00039.html
Comment by Mark Combellack [ 03/Feb/09 09:50 AM ]
Latest proposal at:
http://lists.oasis-open.org/archives/sca-j/200902/msg00039.html
Comment by Dave Booz [ 16/Feb/09 09:40 AM ]
latest proposal:
http://www.oasis-open.org/apps/org/workgroup/sca-j/download.php/31240/sca-javaci-1.1-spec-wd02_issue60g.pdf
Comment by Dave Booz [ 16/Feb/09 09:51 AM ]
resolved Feb 16 with proposal above + editorial changes from minutes
Comment by Dave Booz [ 26/Feb/09 09:03 AM ]
applied: http://www.oasis-open.org/committees/download.php/31435/sca-javaci-1.1-spec-wd03.pdf
Comment by Dave Booz [ 05/May/09 06:40 AM ]
Applied in CD01




[JAVA-61] Describe the concurrency model for each scope
Created: 11/Sep/08  Updated: 11/May/09

Status: Closed
Project: OASIS SCA Java TC
Component/s: Java Common Annotations and APIs specification
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Dave Booz Assigned To: Anish Karmarkar
Resolution: Fixed Votes: 0


 Description   
DESCRIPTION:

The spec needs language to describe the concurrency model that a component developer needs to be prepared for when using any of the scopes. For example, the spec never describes whether or not a composite scoped implementation needs to be able to support concurrent execution on the same runtime instance.

FWIW, I was surprised to find this language missing, so perhaps I've just missed it.


PROPOSAL:

None.


 Comments   
Comment by Dave Booz [ 29/Sep/08 01:48 PM ]
Opened: Sept 29
http://www.oasis-open.org/apps/org/workgroup/sca-j/download.php/29472/SCA%20Java%20minutes%202008-09-29.pdf
Comment by Dave Booz [ 20/Oct/08 11:01 AM ]
Section 8.17 also need to be updated to remove or clarify the words relating to pooling and instance management as they are in appropriate here. They belong in Section 2.2. Section#s taken from CD01.
Comment by Dave Booz [ 13/Nov/08 04:30 AM ]
Resolved - Nov 11 F2F
Comment by Anish Karmarkar [ 12/Dec/08 07:09 PM ]
Resolution applied in cd01-rev2 http://www.oasis-open.org/apps/org/workgroup/sca-j/download.php/30383/sca-javacaa-1.1-spec-cd01-rev2.pdf




[JAVA-62] Clarify what a Component Implementation can do with threads
Created: 11/Sep/08  Updated: 09/Nov/09

Status: Closed
Project: OASIS SCA Java TC
Component/s: Java Component Implementation Specification
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Minor
Reporter: Mark Combellack Assigned To: Mark Combellack
Resolution: Won't Fix Votes: 0


 Description   
DESCRIPTION:

The current SCA-J specification does not mention any restrictions regarding threading that a developer must comply with when implementing a SCA Component. The SCA-J specification is silent on whether a component implementation can create new threads, kill threads, suspend threads, etc.

Implementations of SCA-J SCA Runtime are likely to use ThreadLocals to implement accessing the RequestContext, security credentials, Conversation IDs on Service Proxies, etc. If the developer is allowed to create their own threads, then these ThreadLocals may not function as intended.

The EJB 3 specification contains the following comment regarding threads (page 546 of ejb-3_0-fr-spec-ejbcore.pdf [1])


"The enterprise bean must not attempt to manage threads. The enterprise bean must not attempt to start, stop, suspend, or resume a thread, or to change a thread's priority or name. The enterprise bean must not attempt to manage thread groups.

These functions are reserved for the EJB container. Allowing the enterprise bean to manage threads would decrease the container's ability to properly manage the runtime environment."



This issue is related to JAVA-61 which describes what the Component Implementation can expect from the SCA Runtime for each Scope with regards to threading. However, it is different since this issue describes what the SCA Runtime can expect from the Component Implementation with regards to threads.


PROPOSAL:

Nothing concrete as yet but we have at least the following options available to us for consideration:

1) Do nothing - Leave the SCA-J specification as is and remain silent on threading
2) Restrict threading (like EJB3) so that threads cannot be created, stopped, suspended, etc
3) Allow creation of new threads in SCA-J and describe how it works and what are the restrictions



http://lists.oasis-open.org/archives/sca-j/200809/msg00024.html

 Comments   
Comment by Dave Booz [ 29/Sep/08 01:48 PM ]
Opened: Sept 29
http://www.oasis-open.org/apps/org/workgroup/sca-j/download.php/29472/SCA%20Java%20minutes%202008-09-29.pdf
Comment by Dave Booz [ 05/Dec/08 11:57 AM ]
awaiting proposal
Comment by Mark Combellack [ 30/Oct/09 06:08 AM ]
May need to consider what the test cases are doing with threads.
Comment by Dave Booz [ 09/Nov/09 09:59 AM ]
resolved Nov 9 telecon - close no action
Comment by Dave Booz [ 09/Nov/09 10:00 AM ]
Closed No Action Nov 9




[JAVA-63] SCA Spring C & I specification does not state whether Constructor Injection should be supported
Created: 11/Sep/08  Updated: 06/Jun/11

Status: Closed
Project: OASIS SCA Java TC
Component/s: Spring Component Implementation Specification
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Mark Combellack Assigned To: Mike Edwards
Resolution: Fixed Votes: 0


 Description   
Raiser: Ramkumar Ramalingam

Target: sca-springci-draft-20070926.doc


Description:
 
The SCA Spring Client and Implementation specification is silent on whether the Spring Constructor Injection should be supported or not.

Basically Spring supports two types of Dependency Injection(DI) techniques 1) Setter Injection and 2) Constructor Injection.

1) Setter Injection: In which the dependent module exposes a setter method which the framework uses to inject the dependency, the current specification supports this as shown below... by injecting the SCAReference using the setter method.

<bean id="Y" class"org.xyz.someapp.SomeOtherClass">
    <property name="bar" ref="SCAReference"/>
</bean>

2) Constructor Injection: In which the dependencies are provided through the class constructor. The Specs remains silent on whether this should be supported or not.

<bean id="Y" class"org.xyz.someapp.SomeOtherClass">
      <constructor-arg ref="SCAReference"/>
</bean>


Proposal:

None.



Original email: http://lists.oasis-open.org/archives/sca-j/200809/msg00027.html

 Comments   
Comment by Dave Booz [ 29/Sep/08 01:48 PM ]
Opened: Sept 29
http://www.oasis-open.org/apps/org/workgroup/sca-j/download.php/29472/SCA%20Java%20minutes%202008-09-29.pdf
Comment by Dave Booz [ 05/Dec/08 11:58 AM ]
awaiting proposal
Comment by Dave Booz [ 10/Aug/09 10:16 AM ]
latest proposal: http://lists.oasis-open.org/archives/sca-j/200908/msg00019.html
Comment by Dave Booz [ 10/Aug/09 10:17 AM ]
resolved Aug 10 telecon - see minutes for resolution
Comment by Anish Karmarkar [ 06/Aug/10 03:58 PM ]
Part of it applied in WD04 and the rest in WD05
Comment by Anish Karmarkar [ 16/Aug/10 06:10 PM ]
WD05 located at:
http://www.oasis-open.org/committees/download.php/39023/sca-springci-1.1-spec-WD05.doc
http://www.oasis-open.org/committees/download.php/39024/sca-springci-1.1-spec-WD05.pdf
Comment by Anish Karmarkar [ 06/Jun/11 06:30 PM ]
Accepted in CSD01




[JAVA-64] SCA Spring C & I specification does not state the purpose of sca:composite element
Created: 11/Sep/08  Updated: 06/Jun/11

Status: Closed
Project: OASIS SCA Java TC
Component/s: Spring Component Implementation Specification
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Mark Combellack Assigned To: Anish Karmarkar
Resolution: Fixed Votes: 0


 Description   
Raiser: Ramkumar Ramalingam

Target: sca-springci-draft-20070926.doc


Description:
 
The SCA Spring Client and Implementation specification is silent on the purpose of <sca:composite> tag available in the schema.

The Spring SCA Namespace Schema as defined in the current specification shows the following schema definition....

<xsd:element name="composite">
      <xsd:complexType>
            <xsd:attribute name="component" use="required">
             <xsd:simpleType>
                  <xsd:restriction base="xsd:string"/>
             </xsd:simpleType>
           </xsd:attribute>
           <xsd:attribute name="sca-adapter-class" use="optional">
                  <xsd:simpleType>
                         <xsd:restriction base="xsd:string"/>
                   </xsd:simpleType>
            </xsd:attribute>
        </xsd:complexType>
</xsd:element>


But the specification remains silent, on stating the purpose of this element within Spring Application Context.



Proposal:

None.



Original Email:
http://lists.oasis-open.org/archives/sca-j/200809/msg00028.html

 Comments   
Comment by Dave Booz [ 29/Sep/08 01:48 PM ]
Opened: Sept 29
http://www.oasis-open.org/apps/org/workgroup/sca-j/download.php/29472/SCA%20Java%20minutes%202008-09-29.pdf
Comment by Dave Booz [ 12/Nov/08 09:07 AM ]
Resolved at Nov 11 F2F - remove the composite element from the Spring SCA namespace
Comment by Mike Edwards [ 21/Nov/08 12:31 PM ]
Applied in sca-springci-1.1-spec-WD01.doc
Comment by Anish Karmarkar [ 06/Jun/11 06:29 PM ]
Accepted in CSD01




[JAVA-65] There is no lifecycle defined for SCA Components
Created: 11/Sep/08  Updated: 11/May/09

Status: Closed
Project: OASIS SCA Java TC
Component/s: Java Common Annotations and APIs specification
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Mark Combellack Assigned To: Anish Karmarkar
Resolution: Fixed Votes: 0

Issue Links:
Depends on
is depended on by JAVA-53 what happens if init() throws a runti... Closed

 Description   
DESCRIPTION:

The current SCA-J specification does not detail any information about the lifecycle of a SCA Component.
 

For example, the order of events for creating a SCA Component Implementation is not actually expressly defined in any one place. By looking at the descriptions of @Constructor and @Init you can extrapolate what happens. i.e. Call Constructor -inject all references and properties - call @Init. However, this sequence of events is not written down in one place.


Another example would be does the @Init method complete before the SCA Runtime can use the Component Implementation to service requests. The sensible answer is obviously yes. However, section 8.12 @Init (lines 1270 - 1271 of JCAA WD 04) states:

"The @Init annotation is used to denote a single Java class method that is called when the scope defined for the implementation class starts."

Since we do not have a well defined lifecycle model, a SCA Runtime would be specification compliant if it spawned a new Thread to call the @Init method and used other threads to process Service requests concurrently with the execution of the @Init method. The text only states "method that is called". It does not say that the method has to complete before the SCA Component Implementation can be used.


There are other lifecycle areas that will need to be covered but this should be enough to start the discussions.


PROPOSAL:

None

 Comments   
Comment by Mark Combellack [ 11/Sep/08 09:04 AM ]
Original email at http://lists.oasis-open.org/archives/sca-j/200809/msg00032.html
Comment by Mark Combellack [ 17/Sep/08 02:42 AM ]
Another example of where we are missing details on the life cycle for SCA is what can be done in the @Init and @EagerInit methods:

  * Can an @Init method use its references to invoke other SCA Components?
  * Can an @EagerInit method on a Composite Scoped Component invoke other SCA Components?

The @EagerInit case may be a little more complex but I am presuming that both of these scenarios are valid.

The second example of an @EagerInit method becomes more interesting when it is trying to invoke another Composite Scoped Component with an @EagerInit method since the SCA Runtime would need to ensure that the @EagerInit methods had been called on both Components.



The specification is also missing details on what can be done in the @Destroy methods

As an example, it would seem reasonable that a Composite Scoped component may have a Reference to a single instance of a Conversational Scoped Component that it shares for all invocations. When the @Destroy method is called, the code would want to call the @EndsSession method on the Conversational Scoped Component.
Comment by Dave Booz [ 29/Sep/08 01:49 PM ]
Opened: Sept 29
http://www.oasis-open.org/apps/org/workgroup/sca-j/download.php/29472/SCA%20Java%20minutes%202008-09-29.pdf
Comment by Dave Booz [ 05/Dec/08 11:50 AM ]
proposal: http://www.oasis-open.org/apps/org/workgroup/sca-j/email/archives/200811/msg00095.html
Comment by Mark Combellack [ 03/Feb/09 03:59 AM ]
Link to the proposal on the public email archive:
http://lists.oasis-open.org/archives/sca-j/200811/msg00095.html
Comment by Dave Booz [ 16/Mar/09 10:51 AM ]
latest proposal: http://lists.oasis-open.org/archives/sca-j/200903/msg00075.html
Comment by Dave Booz [ 17/Mar/09 10:23 AM ]
latest proposal: http://lists.oasis-open.org/archives/sca-j/200903/msg00110.html
Comment by Dave Booz [ 17/Mar/09 10:40 AM ]
resolved Mar 17 telecon - see minutes for updates to above proposal
Comment by Mike Edwards [ 25/Mar/09 04:42 AM ]
Applied in:

sca-javacaa-1.1-spec-cd02-rev4.doc




[JAVA-66] Should the definitions of the various Scopes be pushed up to the SCA-Assembly specification?
Created: 11/Sep/08  Updated: 29/Sep/08

Status: Closed
Project: OASIS SCA Java TC
Component/s: Java Common Annotations and APIs specification
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Mark Combellack Assigned To: Unassigned
Resolution: Won't Fix Votes: 0


 Description   
TARGET: Java CAA


DESCRIPTION:

The current SCA-J specification defines 4 Scopes - STATELESS, REQUEST, CONVERSATION and COMPOSITE.

Are these Scopes SCA-J specific concepts or should we consider pushing them up to the SCA-Assembly specification as they are not exclusive to the SCA-J specification.

I would imagine that other implementation specifications are likely to share some (if not all) of these Scopes.


PROPOSAL:

None


Original email at http://lists.oasis-open.org/archives/sca-j/200809/msg00033.html



 Comments   
Comment by Dave Booz [ 29/Sep/08 01:50 PM ]
This question needs to be addressed in the Assembly spec:
Closed Sept 29
http://www.oasis-open.org/apps/org/workgroup/sca-j/download.php/29472/SCA%20Java%20minutes%202008-09-29.pdf




[JAVA-67] Need normative rules for stateful callbacks
Created: 17/Sep/08  Updated: 26/Jan/09

Status: Closed
Project: OASIS SCA Java TC
Component/s: Java Common Annotations and APIs specification
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Simon Nash Assigned To: Unassigned
Resolution: Won't Fix Votes: 0

Issue Links:
Depends on
depends on JAVA-95 Simplified stateful implementation me... Closed

 Description   
TARGET: Java Common Annotations and APIs, WD 04, section 6.7.1

DESCRIPTION: Need normative rules for stateful callbacks

Section 6.7.1 describes stateful callbacks using the style of
a series of examples. This is not satisfactory, as examples
can never be normative. Instead, this section should contain
normative rules, with examples used to illustrate the rules.

PROPOSAL:

None at this time.

 Comments   
Comment by Dave Booz [ 29/Sep/08 01:50 PM ]
Opened: Sept 29
http://www.oasis-open.org/apps/org/workgroup/sca-j/download.php/29472/SCA%20Java%20minutes%202008-09-29.pdf
Comment by Dave Booz [ 26/Jan/09 10:34 AM ]
resolved Jan 26 - CNA




[JAVA-68] Uniqueness of conversation IDs
Created: 17/Sep/08  Updated: 26/Jan/09

Status: Closed
Project: OASIS SCA Java TC
Component/s: Java Common Annotations and APIs specification
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Simon Nash Assigned To: Unassigned
Resolution: Won't Fix Votes: 0

Issue Links:
Depends on
depends on JAVA-95 Simplified stateful implementation me... Closed

 Description   
TARGET: Java Common Annotations and APIs, WD 04, section 6.6.1

DESCRIPTION: Uniqueness of conversation IDs

In section 6.6.1, the following statements are made:

1) The ID must be unique to the client component over all time.

2) If the client is not an SCA component, then the ID must be
    globally unique.

Rule 1) seems both over-restrictive and under-restrictive.

It is under-restrictive because it implies that different clients
can use the same ID. If a conversation-scoped component uses the
ID as a key to select a conversational instance for dispatching,
the use of identical IDs by different clients could lead to the
wrong instance being selected.

It is over-restrictive because of the requirement for uniqueness
over all time. This cannot be necessary. If a service has ended
all the conversations in which it was engaged, and released all
state associated with those conversations, there can be no problem
with the client subsequently reusing some previously used ID.

Rule 2) is hard to understand. Firstly, it isn't clear from the
current SCA specs how a non-SCA client could make a conversational
invocation. Secondly, it isn't clear why the rule given here is
different from the rule given for SCA clients.

PROPOSAL:

None at this time.

 Comments   
Comment by Dave Booz [ 29/Sep/08 01:51 PM ]
Opened: Sept 29
http://www.oasis-open.org/apps/org/workgroup/sca-j/download.php/29472/SCA%20Java%20minutes%202008-09-29.pdf
Comment by Dave Booz [ 26/Jan/09 10:32 AM ]
resolved Jan 26 - telecon - CNA




[JAVA-69] Misleading statement about lifetime of stateful callbacks
Created: 17/Sep/08  Updated: 02/Feb/09

Status: Closed
Project: OASIS SCA Java TC
Component/s: Java Common Annotations and APIs specification
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Simon Nash Assigned To: Simon Nash
Resolution: Won't Fix Votes: 0

Issue Links:
Depends on
depends on JAVA-25 Callback Simplification Closed

 Description   
TARGET: Java Common Annotations and APIs, WD 04, section 6.6.1

DESCRIPTION: Misleading statement about lifetime of stateful callbacks

In section 6.7.1, line 433, there is a statement that for a service
that is conversation scoped, the callback will still be available
when the backend service sends back its asynchronous response.

The unconditional "will" in the above statement is not correct, as
the conversation may have ended by the time the backend response
is sent, and this would have released the conversational instance
and its injected callback.

PROPOSAL:

Change the sentence starting on line 432 to "If the example service
is conversation scoped and the conversation has not ended, the
callback will still be available when the backend service sends back
its asynchronous response."

 Comments   
Comment by Dave Booz [ 29/Sep/08 01:51 PM ]
Opened: Sept 29
http://www.oasis-open.org/apps/org/workgroup/sca-j/download.php/29472/SCA%20Java%20minutes%202008-09-29.pdf
Comment by Dave Booz [ 02/Feb/09 12:15 PM ]
resolved Feb 2 - virtual F2F - CNA




[JAVA-70] ConversationAttributes on class or interface?
Created: 17/Sep/08  Updated: 26/Jan/09

Status: Closed
Project: OASIS SCA Java TC
Component/s: Java Common Annotations and APIs specification
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Simon Nash Assigned To: Unassigned
Resolution: Won't Fix Votes: 0

Issue Links:
Depends on
depends on JAVA-95 Simplified stateful implementation me... Closed

 Description   
TARGET: Java Common Annotations and APIs, WD 04, section 6.7.1

DESCRIPTION: ConversationAttributes on class or interface?

Line 437 talks about interfaces declaring a @ConversationAttributes
annotation. However, section 8.7 implies that this annotation
applies to a class rather than an interface. The spec needs to
be made clear and self-consistent on whether this annotation can
be used on a class, an interface, or both.

There is also a typo on line 1146 in section 8.7. There should
not be a semicolon at the end of this line.

PROPOSAL:

None at this time.

 Comments   
Comment by Dave Booz [ 29/Sep/08 01:52 PM ]
Opened: Sept 29
http://www.oasis-open.org/apps/org/workgroup/sca-j/download.php/29472/SCA%20Java%20minutes%202008-09-29.pdf
Comment by Dave Booz [ 26/Jan/09 10:36 AM ]
Resolved Jan 26 telecon - CNA




[JAVA-71] Incorrect code in section 6.7.2 example
Created: 17/Sep/08  Updated: 11/May/09

Status: Closed
Project: OASIS SCA Java TC
Component/s: Java Common Annotations and APIs specification
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Simon Nash Assigned To: Anish Karmarkar
Resolution: Fixed Votes: 0


 Description   
TARGET: Java Common Annotations and APIs, WD 04, section 6.7.2

DESCRIPTION: Incorrect code in section 6.7.2 example

On line 511, this use of getCallbackID() is incorrect. This
code should obtain a RequestContext either by injection or from
the ComponentContext, then call RequestContext.getServiceReference()
to get the currently active invocation service reference, then
call getCallbackID() on that.

PROPOSAL:

Replace lines 510 through 511 by:

@Context RequestContext context;

public void receiveResult(String result) {
     Object key = context.getServiceReference().getCallbackID();


 Comments   
Comment by Dave Booz [ 29/Sep/08 01:52 PM ]
Opened: Sept 29
http://www.oasis-open.org/apps/org/workgroup/sca-j/download.php/29472/SCA%20Java%20minutes%202008-09-29.pdf
Comment by Mark Combellack [ 30/Oct/08 06:49 AM ]
Resolved as discussed in meeting on 27th October 2008
http://www.oasis-open.org/committees/download.php/29842/SCA%20Java%20Minutes%202008-10-27.doc
Comment by Anish Karmarkar [ 12/Dec/08 07:10 PM ]
Resolution applied in cd01-rev2 http://www.oasis-open.org/apps/org/workgroup/sca-j/download.php/30383/sca-javacaa-1.1-spec-cd01-rev2.pdf




[JAVA-72] Should not say callback ID is passed in reference parameters
Created: 17/Sep/08  Updated: 11/May/09

Status: Closed
Project: OASIS SCA Java TC
Component/s: Java Common Annotations and APIs specification
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Simon Nash Assigned To: Anish Karmarkar
Resolution: Fixed Votes: 0


 Description   
TARGET: Java Common Annotations and APIs, WD 04, section 6.7.4

DESCRIPTION: Should not say callback ID is passed in reference parameters

On lines 574-575, the parenthetical comment "(i.e., reference parameters)"
implies a specific wire representation. Wire representations are defined
by SCA bindings specifications and not by this specification.

PROPOSAL:

On lines 574-575, remove "(i.e., reference parameters)"

 Comments   
Comment by Dave Booz [ 29/Sep/08 01:52 PM ]
Opened: Sept 29
http://www.oasis-open.org/apps/org/workgroup/sca-j/download.php/29472/SCA%20Java%20minutes%202008-09-29.pdf
Comment by Mark Combellack [ 30/Oct/08 06:49 AM ]
Resolved as discussed in meeting on 27th October 2008
http://www.oasis-open.org/committees/download.php/29842/SCA%20Java%20Minutes%202008-10-27.doc
Comment by Anish Karmarkar [ 12/Dec/08 07:10 PM ]
Resolution applied in cd01-rev2 http://www.oasis-open.org/apps/org/workgroup/sca-j/download.php/30383/sca-javacaa-1.1-spec-cd01-rev2.pdf




[JAVA-73] Incorrect reference to "original request"
Created: 17/Sep/08  Updated: 11/May/09

Status: Closed
Project: OASIS SCA Java TC
Component/s: Java Common Annotations and APIs specification
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Simon Nash Assigned To: Anish Karmarkar
Resolution: Fixed Votes: 0


 Description   
TARGET: Java Common Annotations and APIs, WD 04, section 6.7.4

DESCRIPTION: Incorrect reference to "original request"

On line 589, the reference to "original request" is wrong.
It should say "callback request".

PROPOSAL:

On line 589, replace "original request" by "callback request".

 Comments   
Comment by Dave Booz [ 29/Sep/08 01:52 PM ]
Opened: Sept 29
http://www.oasis-open.org/apps/org/workgroup/sca-j/download.php/29472/SCA%20Java%20minutes%202008-09-29.pdf
Comment by Dave Booz [ 11/Nov/08 11:59 AM ]
Nov 11 - F2F - Resolved with textual change.
Comment by Anish Karmarkar [ 12/Dec/08 07:11 PM ]
Resolution applied in cd01-rev2 http://www.oasis-open.org/apps/org/workgroup/sca-j/download.php/30383/sca-javacaa-1.1-spec-cd01-rev2.pdf




[JAVA-74] Clarify meaning of "should implement"
Created: 17/Sep/08  Updated: 06/Mar/09

Status: Closed
Project: OASIS SCA Java TC
Component/s: Java Common Annotations and APIs specification
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Minor
Reporter: Simon Nash Assigned To: Unassigned
Resolution: Won't Fix Votes: 0


 Description   
TARGET: Java Common Annotations and APIs, WD 04, section 6.7.5

DESCRIPTION: Clarify meaning of "should implement"

On line 595, it isn't clear whether the phrase "should implement"
refers to "implements" in the strict Java language sense, or whether
it means that all the methods of the Java interface are available
on the implementation class.

PROPOSAL:

None at this time.

 Comments   
Comment by Dave Booz [ 29/Sep/08 01:52 PM ]
Opened: Sept 29
http://www.oasis-open.org/apps/org/workgroup/sca-j/download.php/29472/SCA%20Java%20minutes%202008-09-29.pdf
Comment by Dave Booz [ 05/Dec/08 12:03 PM ]
awaiting proposal
Comment by Mark Combellack [ 23/Feb/09 07:27 AM ]
Proposed resolution at http://lists.oasis-open.org/archives/sca-j/200902/msg00186.html
Comment by Dave Booz [ 06/Mar/09 09:34 AM ]
offending text was deleted by previously closed issue. Mar 6 telecon - CNA




[JAVA-75] Incorrect description of @Scope annotation default
Created: 17/Sep/08  Updated: 11/May/09

Status: Closed
Project: OASIS SCA Java TC
Component/s: Java Common Annotations and APIs specification
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Simon Nash Assigned To: Dave Booz
Resolution: Fixed Votes: 0


 Description   
TARGET: Java Common Annotations and APIs, WD 04, section 8.17

DESCRIPTION: Incorrect description of @Scope annotation default

On line 1630, the default scope is not always STATELESS. If the
implementation offers an @Conversational service, its default
scope is CONVERSATION (see line 171).

PROPOSAL:

Remove lines 1630 through 1632. After line 1638, insert the
text "The default value is STATELESS, except for an implementation
offering a @Conversational service, which has a default scope of
CONVERSATION. See section 2.2 for more details of the SCA-defined
scopes."

 Comments   
Comment by Dave Booz [ 29/Sep/08 01:53 PM ]
Opened: Sept 29
http://www.oasis-open.org/apps/org/workgroup/sca-j/download.php/29472/SCA%20Java%20minutes%202008-09-29.pdf
Comment by Mark Combellack [ 23/Oct/08 08:28 AM ]
Resolved: 20th October 2008
http://www.oasis-open.org/committees/download.php/29731/SCA%20Java%20Minutes%202008-10-20.doc
Comment by Anish Karmarkar [ 12/Dec/08 07:11 PM ]
Resolution applied in cd01-rev2 http://www.oasis-open.org/apps/org/workgroup/sca-j/download.php/30383/sca-javacaa-1.1-spec-cd01-rev2.pdf
Comment by Dave Booz [ 15/Dec/08 10:43 AM ]
Not entirely applied by Anish as he had a question - See Dec 15 minutes
Dave to finish the application of the resolution.




[JAVA-76]  Incorrect code in section 6.7.4 examples
Created: 17/Sep/08  Updated: 11/May/09

Status: Closed
Project: OASIS SCA Java TC
Component/s: Java Common Annotations and APIs specification
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Simon Nash Assigned To: Anish Karmarkar
Resolution: Fixed Votes: 0

Issue Links:
Depends on
depends on JAVA-25 Callback Simplification Closed

 Description   
TARGET: Java Common Annotations and APIs, WD 04, section 6.7.4

DESCRIPTION: Incorrect code in section 6.7.4 examples

1. On line 556, the getCallback() call should say getService().
    This is correct in line 548.

2. On line 567, the code shows the invocation of a static method
      ComponentContext.getRequestContext()
    This method isn't static and requires a ComponentContext instance
    that was set by injection.

PROPOSAL:

1. Replace line 556 by:

    MyCallback myCallback = callback.getService();

2. Replace lines 564 through 567 by:

    @Context ComponentContext context;

    public void someMethod() {

        MyCallback myCallback =
            context.getRequestContext().getCallback();

 Comments   
Comment by Dave Booz [ 29/Sep/08 01:53 PM ]
Opened: Sept 29
http://www.oasis-open.org/apps/org/workgroup/sca-j/download.php/29472/SCA%20Java%20minutes%202008-09-29.pdf
Comment by Dave Booz [ 05/Dec/08 12:04 PM ]
awaiting proposal
Comment by Mark Combellack [ 11/Feb/09 10:09 AM ]
Updated proposal at:
http://lists.oasis-open.org/archives/sca-j/200902/msg00098.html
Comment by Dave Booz [ 23/Feb/09 10:14 AM ]
resolved Feb 23 with proposal in email above
Comment by Mike Edwards [ 25/Mar/09 01:59 AM ]
Applied in:

sca-javacaa-1.1-spec-cd02-rev4.doc




[JAVA-77] A remotable service SHOULD be translatable into a generally accepted standard for a service, such as WSDL 1.1 or WSDL 2.0
Created: 17/Sep/08  Updated: 11/May/09

Status: Closed
Project: OASIS SCA Java TC
Component/s: Java Common Annotations and APIs specification
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Minor
Reporter: Dave Booz Assigned To: Pradeep Simha
Resolution: Fixed Votes: 0


 Description   
Reported by Pradeep Simha

TARGET: Java Common Annotations and APIs, WD 04, section 8.16
 
DESCRIPTION: A remotable service SHOULD be translatable into a generally accepted standard for a service, such as WSDL 1.1 or WSDL 2.0
 
On lines 1556-1557, the sentence "A remotable service can be published externally as a service and must be translatable into a WSDL portType" implies support for WSDL 1.1 only.
 
PROPOSAL:
 
Replace the text with the following:
 
A remotable service can be published externally as a service and SHOULD be translatable into a generally accepted standard for a service, such as WSDL 1.1 or WSDL 2.0


 Comments   
Comment by Dave Booz [ 06/Oct/08 11:46 AM ]
Opened Oct 6:
http://www.oasis-open.org/apps/org/workgroup/sca-j/download.php/29571/SCA%20Java%20Minutes%202008-10-06.doc
Comment by Dave Booz [ 05/Dec/08 01:24 PM ]
owned by Pradeep
Comment by Dave Booz [ 05/Dec/08 01:25 PM ]
awaiting proposal
Comment by Dave Booz [ 09/Mar/09 09:49 AM ]
latest proposal:
http://lists.oasis-open.org/archives/sca-j/200902/msg00166.html
Comment by Dave Booz [ 09/Mar/09 09:51 AM ]
resolved Mar 9 telecon with proposal in minutes
Comment by Mike Edwards [ 25/Mar/09 02:46 AM ]
Applied in:

sca-javacaa-1.1-spec-cd02-rev4.doc




[JAVA-78] Need API to set EPR and for a reference invocation
Created: 17/Sep/08  Updated: 03/Aug/09

Status: Closed
Project: OASIS SCA Java TC
Component/s: Java Common Annotations and APIs specification
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Minor
Reporter: Dave Booz Assigned To: Simon Nash
Resolution: No Action Votes: 0


 Description   
Reported by Pradeep Simha

TARGET: Java Common Annotations and APIs, WD 04, section 7
 
DESCRIPTION: Need API to set EPR for a reference invocation
 
The assembly specification mentions that when wiredByImpl attribute for a reference is set to "true", it indicates that the target of the reference is set at runtime by the implementation code. We need a Java API to achieve this.
 
PROPOSAL: None at this time


 Comments   
Comment by Dave Booz [ 06/Oct/08 11:47 AM ]
Opened Oct 6:
http://www.oasis-open.org/apps/org/workgroup/sca-j/download.php/29571/SCA%20Java%20Minutes%202008-10-06.doc
Comment by Dave Booz [ 05/Dec/08 01:25 PM ]
owned by Pradeep
Comment by Dave Booz [ 05/Dec/08 01:25 PM ]
awaiting proposal
Comment by Dave Booz [ 12/Mar/09 07:01 AM ]
Simon N to have proposal by Mar 16.
Comment by Mark Combellack [ 03/Aug/09 10:30 AM ]
Closed no action on the conference call on 3rd August 2009




[JAVA-79] Missing word "type" for "return type" in CAA spec - sec 3.1
Created: 17/Sep/08  Updated: 11/May/09

Status: Closed
Project: OASIS SCA Java TC
Component/s: Java Common Annotations and APIs specification
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Dave Booz Assigned To: Anish Karmarkar
Resolution: Fixed Votes: 0


 Description   
Reported by Vamsi

TARGET: Java Common Annotations and APIs, WD 04

DESCRIPTION: Sec 3.1, Line 189-190 reads:
For the Java interface type system, arguments and return of the service
methods are described using Java classes or simple Java types. ...

The word "type" is missing after "return".

PROPOSAL:
Add the word "type" after "return" so that the sentence reads:
For the Java interface type system, arguments and return type of the
service methods are described using Java classes or simple Java types. ...


 Comments   
Comment by Dave Booz [ 06/Oct/08 11:47 AM ]
Opened Oct 6:
http://www.oasis-open.org/apps/org/workgroup/sca-j/download.php/29571/SCA%20Java%20Minutes%202008-10-06.doc
Comment by Dave Booz [ 06/Oct/08 11:47 AM ]
Resolved Oct 6:
http://www.oasis-open.org/apps/org/workgroup/sca-j/download.php/29571/SCA%20Java%20Minutes%202008-10-06.doc
Comment by Anish Karmarkar [ 12/Dec/08 07:11 PM ]
Resolution applied in cd01-rev2 http://www.oasis-open.org/apps/org/workgroup/sca-j/download.php/30383/sca-javacaa-1.1-spec-cd01-rev2.pdf




[JAVA-80] Ambiguous description of method for @OneWay annotation
Created: 17/Sep/08  Updated: 06/Oct/08

Status: Closed
Project: OASIS SCA Java TC
Component/s: Java Common Annotations and APIs specification
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Dave Booz Assigned To: Anish Karmarkar
Resolution: Won't Fix Votes: 0


 Description   
Reported by Vamsi

TARGET: Java Common Annotations and APIs, WD 04

DESCRIPTION:
Sec 6.1, Line 255-256 reads:

Any method that returns "void" and has no declared exceptions may be marked
with an @OneWay annotation. ...

The description of return type for the method is ambiguous.

PROPOSAL: Change the sentence to the following:

Any method with a void return type and has no declared exceptions may be
marked with an @OneWay annotation.


 Comments   
Comment by Dave Booz [ 06/Oct/08 11:48 AM ]
Rejected Oct 6 (as it was fixed in WD05):
http://www.oasis-open.org/apps/org/workgroup/sca-j/download.php/29571/SCA%20Java%20Minutes%202008-10-06.doc




[JAVA-81] Normative references to SCA Spec docs point to v1.00 docs
Created: 17/Sep/08  Updated: 11/May/09

Status: Closed
Project: OASIS SCA Java TC
Component/s: Java Common Annotations and APIs specification
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Dave Booz Assigned To: Anish Karmarkar
Resolution: Fixed Votes: 0


 Description   
Reported by Vamsi
TARGET: Java Common Annotations and APIs, WD 04

DESCRIPTION: Sec 1.2 Normative References
References to SCA Assembly Specification and SCA Policy Framework provide
links to v1.00 of the respective specifications from OSOA. These links
should point to v1.1 OASIS docs/drafts.

PROPOSAL:
Change the links to point to latest v1.1 OASIS docs/drafts of SCA Assembly
Spec and SCA Policy Framework.

 Comments   
Comment by Dave Booz [ 06/Oct/08 11:49 AM ]
Opened Oct 6:
http://www.oasis-open.org/apps/org/workgroup/sca-j/download.php/29571/SCA%20Java%20Minutes%202008-10-06.doc
Comment by Dave Booz [ 06/Oct/08 11:49 AM ]
Resolved Oct 6:
http://www.oasis-open.org/apps/org/workgroup/sca-j/download.php/29571/SCA%20Java%20Minutes%202008-10-06.doc
Comment by Anish Karmarkar [ 12/Dec/08 07:11 PM ]
Resolution applied in cd01-rev2 http://www.oasis-open.org/apps/org/workgroup/sca-j/download.php/30383/sca-javacaa-1.1-spec-cd01-rev2.pdf




[JAVA-82] Inconsistent use of a and an when referring to annotations
Created: 22/Sep/08  Updated: 11/May/09

Status: Closed
Project: OASIS SCA Java TC
Component/s: Java Common Annotations and APIs specification
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Dave Booz Assigned To: Anish Karmarkar
Resolution: Fixed Votes: 0


 Description   
Submitted by Vamsi:
http://lists.oasis-open.org/archives/sca-j/200809/msg00041.html
REF: sca-javacaa-1.1-spec-WD04.doc

I am noticing that in the document the use of a and an with annotations is
not
consistent. For e.g.,

Line 342: A @Reference to a conversational service is injected
Line 437: interfaces declare a @ConversationAttributes annotation, ...
Line 1437: The presence of a @Reference annotation is reflected ...
Line 1683: A @Service annotation with no attributes is meaningless ...
Line 1709-1710: a @WebService annotation on the class ...

Line 96-97: ... an @Reference annotation.
Line 255-256: ... an @OneWay annotation.
Line 263-264: ... an @Conversational annotation.

See [1] for original e-mail posted to the mailing list.

PROPOSAL:
Make the usage of a and an consistent when referring to annotations by
treating "@" as silent when used with annotation such that normal english
usage prevails. The following examples illustrate this proposal:
1. a @Reference annotation -- read as, "a reference annotation"
2. a @Conversational annotation -- read as, "a conversational annotation"
3. an @EagerInit annotation -- read as, "an eager-init annotation"
4. a @OneWay annotation -- read as, "a one-way annotation"


[1] http://lists.oasis-open.org/archives/sca-j/200808/msg00080.html


 Comments   
Comment by Dave Booz [ 06/Oct/08 11:49 AM ]
Opened Oct6:
http://www.oasis-open.org/apps/org/workgroup/sca-j/download.php/29571/SCA%20Java%20Minutes%202008-10-06.doc
Comment by Dave Booz [ 14/Oct/08 03:21 PM ]
Note: This issue and proposal are relevant to the C&I spec as well as the CAA spec....and possibly others.
Comment by Mark Combellack [ 15/Oct/08 04:54 AM ]
Resolved 13th October
http://www.oasis-open.org/committees/document.php?document_id=29665
Comment by Anish Karmarkar [ 12/Dec/08 07:11 PM ]
Resolution applied in cd01-rev2 http://www.oasis-open.org/apps/org/workgroup/sca-j/download.php/30383/sca-javacaa-1.1-spec-cd01-rev2.pdf




[JAVA-83] Incorrect definition of the SCA JEE JSP Tag library
Created: 10/Oct/08  Updated: 07/Nov/08

Status: Applied
Project: OASIS SCA Java TC
Component/s: Java EE Integration Specification
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Mike Edwards Assigned To: Anish Karmarkar
Resolution: Unresolved Votes: 0


 Description   
Target: SCA Java EE Specification - sca-jee-1[1].1-spec-wd03.doc

Description: Lines 745 - 780 of the spec define the SCA taglib for JSPs. This definition is incorrect as it does not conform to the
                definition of the XSD for JSP taglibs.

                What is incorrect is that the <attribute/> elements for both "name" and "type" attributes are both missing a required
               <rtexprvalue/> child element, so that the taglib fails to validate against the taglib XSD ("http://java.sun.com/xml/ns/javaee/web-jsptaglibrary_2_1.xsd")


Proposal: Modify the taglib definition to include the <rtexprvalue/> elements as follows:


<?xml version = '1.0' encoding = 'ISO-8859-1'?>
<!DOCTYPE taglib PUBLIC "-//Sun Microsystems, Inc.//DTD JSP Tag Library 1.2//EN" "http://java.sun.com/xml/ns/javaee/web-jsptaglibrary_2_1.xsd">
<taglib version="2.1">

  <tlib-version>1.0</tlib-version>
  <short-name>SCA-JSP</short-name>
  <uri>http://www.osoa.org/sca/sca_jsp.tld&lt;/uri>
  <description>A tag library for integrating sca components with jsp
  </description>

  <tag>
    <name>reference</name>
    <tag-class><!—To be provided by the SCA runtime implementation--></tag-class>
    <tei-class><!—To be provided by the SCA runtime implementation--></tei-class>

    <attribute>
      <name>name</name>
      <required>true</required>
           <rtexprvalue>false</rtexprvalue>
      <type>java.lang.String</type>
    </attribute>

    <attribute>
      <name>type</name>
      <required>true</required>
           <rtexprvalue>false</rtexprvalue>
      <type>java.lang.String</type>
    </attribute>


    <body-content>empty</body-content>

  </tag>

</taglib>


 Comments   
Comment by Mark Combellack [ 15/Oct/08 04:53 AM ]
Opened 13th October
http://www.oasis-open.org/committees/document.php?document_id=29665
Comment by Mark Combellack [ 15/Oct/08 04:53 AM ]
Resolved 13th October
http://www.oasis-open.org/committees/document.php?document_id=29665
Comment by Mike Edwards [ 07/Nov/08 08:59 AM ]
Added to SCA Java EE specification draft 04b on 7th November.




[JAVA-84] Java CAA spec does not contain the interface.java schema
Created: 10/Oct/08  Updated: 11/May/09

Status: Closed
Project: OASIS SCA Java TC
Component/s: Java Common Annotations and APIs specification
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Anish Karmarkar Assigned To: Anish Karmarkar
Resolution: Fixed Votes: 0


 Description   
Description:
While packaging up the java caa cd 01 I realized that the Java CAA
contains the definition/description of <interface.java> but it does not
contain the schema. The schema is in the assembly spec. interface.java
used to be defined in assembly but was later moved to caa spec. The
schema similarly should be part of the caa spec.

Not entirely sure if this is a new issue, editorial issue or part of an
existing issue (which was resolved but not correctly applied by the
editors).

Proposal:
Create an appendix to include the schema for <interface.java>


 Comments   
Comment by Mark Combellack [ 15/Oct/08 04:53 AM ]
Opened 13th October
http://www.oasis-open.org/committees/document.php?document_id=29665
Comment by Mark Combellack [ 15/Oct/08 04:53 AM ]
Resolved 13th October
http://www.oasis-open.org/committees/document.php?document_id=29665
Comment by Anish Karmarkar [ 12/Dec/08 07:12 PM ]
Resolution applied in cd01-rev2 http://www.oasis-open.org/apps/org/workgroup/sca-j/download.php/30383/sca-javacaa-1.1-spec-cd01-rev2.pdf




[JAVA-85] ejb binding @uri has the wrong schema
Created: 30/Oct/08  Updated: 08/Dec/08

Status: Closed
Project: OASIS SCA Java TC
Component/s: EJB Session Binding Specification
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Dave Booz Assigned To: Unassigned
Resolution: Won't Fix Votes: 0


 Description   
RAISER: Dave Booz

TARGET: EJB Binding spec [1]

DESCRIPTION:

binding.ejb/@uri is typed as a anyURI. This is because the EJB binding inherits this attribute from the base binding schema.
The problem is that anyURI doesn't allow the '#' character. The EJB binding spec builds on the CORBA location syntax
which includes the '#' character. See lines 103-115 [1]

PROPOSAL:

None.


[1] http://www.oasis-open.org/apps/org/workgroup/sca-j/download.php/25979/sca-jejbbinding-1.1-spec-wd-02.doc

 Comments   
Comment by Mark Combellack [ 30/Oct/08 08:48 AM ]
Original email at:
http://lists.oasis-open.org/archives/sca-j/200810/msg00046.html
Comment by Dave Booz [ 08/Dec/08 10:32 AM ]
Dec 8 Telecon, rejected.




[JAVA-86] Update default EJB version of binding.ejb to EJB3
Created: 30/Oct/08  Updated: 16/Feb/10

Status: Closed
Project: OASIS SCA Java TC
Component/s: EJB Session Binding Specification
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Dave Booz Assigned To: Unassigned
Resolution: Fixed Votes: 0


 Description   
RAISER: Dave Booz

TARGET: EJB Binding spec [1]

DESCRIPTION:
The EJB binding spec currently indicates that the default EJB version is EJB2, meaning EJB 2.x Session beans. EJB 3.x is now quite common and popular, and might be the best default for binding.ejb.

PROPOSAL:
Change the default for @ejb-version to be "EJB3".


[1] http://www.oasis-open.org/apps/org/workgroup/sca-j/download.php/25979/sca-jejbbinding-1.1-spec-wd-02.doc

 Comments   
Comment by Mark Combellack [ 30/Oct/08 08:49 AM ]
Original email at:
http://lists.oasis-open.org/archives/sca-j/200810/msg00047.html
Comment by Dave Booz [ 03/Nov/08 10:37 AM ]
Opened Nov 3
Comment by Dave Booz [ 03/Nov/08 10:38 AM ]
Resolved Nov 3 with proposal in the description of the JIRA.
Comment by Dave Booz [ 01/Jul/09 01:37 PM ]
applied: http://www.oasis-open.org/committees/download.php/32799/sca-ejbbinding-1.1-spec-wd-03.doc
Comment by Dave Booz [ 16/Feb/10 11:17 AM ]
Closed as a result of CD vote on Feb 15,2010.




[JAVA-87] Java-related C&I specs needs to define how effective CT is synthesized
Created: 30/Oct/08  Updated: 05/May/09

Status: Closed
Project: OASIS SCA Java TC
Component/s: Java Component Implementation Specification
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Critical
Reporter: Anish Karmarkar Assigned To: Unassigned
Resolution: Fixed Votes: 0

Issue Links:
Depends on
depends on JAVA-55 SCA Java Specifications do not Adequa... Closed

 Description   
Target: Java C&I, Spring C&I, Java EE integration spec

Description:
Assembly TC resolved issue 36 [1] with the following resolution:

-----
Component type represents the configurable aspects of an implementation.
A component type consists of services that are offered, references to
other services that can be wired and properties that can be set. The
settable properties and the settable references to services are
configured by a component that uses the implementation.

An implementation type specification (for example, the WS-BPEL Client
and Implementation Specification Version 1.1 [ref]) specifies the
mechanism(s) by which the component type associated with an
implementation of that type is derived.

Since SCA allows a broad range of implementation technologies, it is
expected that some implementation technologies (for example, the Java
Client and Implementation Specification Version 1.1 [ref]) allow
for introspecting the implementation artifact(s) (for example, a Java
class) to derive the component type information. Other implementation
technologies might not allow for introspection of the implementation
artifact(s). In those cases where introspection is not allowed, SCA
encourages the use of a SCA component type side file. A component type
side file is an XML file whose document root element is
sca:componentType.

The implementation type specification defines
whether introspection is allowed, whether a side file is allowed, both are
allowed or some other mechanism specifies the CT.
The component type information derived through introspection is
called the 'introspected component type'. In any case, the implementation
type specification specifies how multiple sources of information
are combined to produce the 'effective component type'. The effective
component type is the component type metadata that is
presented to the using Component for configuration.

The extension of a componentType side file name MUST be
.componentType. The name and location of a componentType side file, if
allowed, is defined by the implementation type specification.

If a component type side file is not allowed for a particular
implementation type, the effective component type and introspected
component type are one and the same for that implementation type.

For the rest of this document, when the term 'component type' is used it
refers to the 'effective component type'.
-----

This puts requirements on C&I wrt defining whether side files are
allowed, how they interact with introspected CT and how effective CT is
synthesized. We need to define these things in the C&Is.

Proposal:

None at this point.


[1] http://www.osoa.org/jira/browse/ASSEMBLY-36


 Comments   
Comment by Mark Combellack [ 03/Nov/08 08:33 AM ]
Original email at:

http://lists.oasis-open.org/archives/sca-j/200810/msg00056.html
Comment by Dave Booz [ 03/Nov/08 10:28 AM ]
Constrained to Java C&I. Opened Nov 3.
Comment by Dave Booz [ 03/Nov/08 10:45 AM ]
Opened Nov 3.
Comment by Dave Booz [ 11/Nov/08 05:35 AM ]
At the F2F - Nov 11 - we had a good discussion (under issue 3) about whether @callback, @oneway, etc should be considered as part of defining services. e.g. an interface marked with @callback (but not @remotable), and the impl class implements it but does not contain @service, then is a local service exposed due to the presence of the @callback?
Comment by Dave Booz [ 16/Jan/09 09:50 AM ]
resolved Jan 16 - remove chap10 from CI WD02 - see minutes
Comment by Dave Booz [ 26/Feb/09 09:04 AM ]
applied: http://www.oasis-open.org/committees/download.php/31435/sca-javaci-1.1-spec-wd03.pdf
Comment by Dave Booz [ 05/May/09 06:40 AM ]
Applied in CD01




[JAVA-88] Java EE Spec: The @archive attribute of the implementation.jee element needs fixing
Created: 03/Nov/08  Updated: 21/Aug/09

Status: Open
Project: OASIS SCA Java TC
Component/s: Java EE Integration Specification
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Mike Edwards (IBM) Assigned To: Mike Edwards
Resolution: Unresolved Votes: 0


 Description   
Raiser: Mike Edwards

Target: sca-jee-1[1][1].1-spec-wd04.doc

Description:

Section 7: - the form of the @archive attribute of the implementation.jee element needs fixing to deal with references to
archives in other contributions. The current description can only handle an archive within the same contribution.

Proposal:

None

 Comments   
Comment by Mark Combellack [ 03/Nov/08 08:32 AM ]
Original email at:

http://lists.oasis-open.org/archives/sca-j/200811/msg00000.html
Comment by Dave Booz [ 03/Nov/08 10:45 AM ]
Opened Nov 3.
Comment by Dave Booz [ 05/Dec/08 01:30 PM ]
awaiting proposal
Comment by Dave Booz [ 21/Aug/09 09:19 AM ]
re-opened Aug 21 telecon




[JAVA-89] Java EE Spec: Section 7.1.1 & 7.1.2 - should say that the EJB references are optionally made into SCA references
Created: 03/Nov/08  Updated: 14/Sep/09

Status: Applied
Project: OASIS SCA Java TC
Component/s: Java EE Integration Specification
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Mike Edwards (IBM) Assigned To: Dave Booz
Resolution: Unresolved Votes: 0


 Description   
Raiser: Mike Edwards

Target: sca-jee-1[1][1].1-spec-wd04.doc

Description:

Section 7.1.1 & 7.1.2 - should say that the EJB references are optionally made into SCA references
- as is stated in 7.1.3.

This looks like a simple omission of intended normative statements from these sections.

Proposal:

Add the following text after line 914:

In the absence of optional extensions, the component type of a non-SCA-enhanced EJB module
does not contain SCA references. However, as an optional extension of the way in which SCA support
is provided for EJB modules, an SCA runtime can choose to provide the capability of re-wiring
EJB references using SCA. If an SCA runtime provides this optional extension, then the following
rule is applied:

Add the following text after the first sentence of line 952:

In the absence of optional extensions, the component type of a non-SCA-enhanced Web module
does not contain SCA references. However, as an optional extension of the way in which SCA support
is provided for Web modules, an SCA runtime can choose to provide the capability of re-wiring
EJB references using SCA. If an SCA runtime provides this optional extension, then the following
rule is applied:



 Comments   
Comment by Mark Combellack [ 03/Nov/08 08:31 AM ]
Original email at:

http://lists.oasis-open.org/archives/sca-j/200811/msg00001.html
Comment by Dave Booz [ 03/Nov/08 10:47 AM ]
Opened Nov 3.
Comment by Dave Booz [ 21/Aug/09 09:19 AM ]
re-opened Aug 21 telecon
Comment by Dave Booz [ 21/Aug/09 09:58 AM ]
resolved Aug 21 telecon - see minutes for text insertion locations
Comment by Dave Booz [ 14/Sep/09 03:26 PM ]
applied in WD06: http://www.oasis-open.org/committees/download.php/34200/sca-jee-1.1-spec-wd06.pdf




[JAVA-90] Java EE Spec: Section 5.1.1 normative change needs ratifying
Created: 03/Nov/08  Updated: 14/Sep/09

Status: Applied
Project: OASIS SCA Java TC
Component/s: Java EE Integration Specification
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Mike Edwards (IBM) Assigned To: Dave Booz
Resolution: Unresolved Votes: 0


 Description   
Raiser: Mike Edwards

Target: sca-jee-1[1][1].1-spec-wd04.doc

Description:

Section 5.1.1 of the Java EE spec had a normative change made to it in the creation
of WD-03

Before the creation of WD-03, the Java EE spec said:

"Implementations that support an install step separate from a deployment step may use
the Add Deployment Composite function to allow composites to be added to an installed
SCA-enhanced Java EE archive without modifying the archive itself."

Now it says:

"Implementations that support an install step separate from a deployment step SHOULD provide
the Add Deployment Composite function to allow composites to be added to an installed
SCA-enhanced Java EE archive without modifying the archive itself."

Proposal:

Accept the new form of the text.


 Comments   
Comment by Mark Combellack [ 03/Nov/08 08:31 AM ]
Original email at:

http://lists.oasis-open.org/archives/sca-j/200811/msg00003.html
Comment by Dave Booz [ 03/Nov/08 10:47 AM ]
Opened Nov 3
Comment by Dave Booz [ 21/Aug/09 09:19 AM ]
re-opened Aug 21 telecon
Comment by Dave Booz [ 24/Aug/09 10:41 AM ]
resolved Aug 24 telecon - with proposal in JIRA
Comment by Dave Booz [ 14/Sep/09 03:26 PM ]
applied in WD06: http://www.oasis-open.org/committees/download.php/34200/sca-jee-1.1-spec-wd06.pdf




[JAVA-91] Java EE Spec: Need to define the derivation of the name of a component contributed to the Domain by an application.composite file
Created: 03/Nov/08  Updated: 21/Aug/09

Status: Open
Project: OASIS SCA Java TC
Component/s: Java EE Integration Specification
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Mike Edwards (IBM) Assigned To: Mike Edwards
Resolution: Unresolved Votes: 0


 Description   
Raiser: Mike Edwards

Target: sca-jee-1[1][1].1-spec-wd04.doc

Description:

Section 5.1.3 describes the use of an application.composite file within a Java EE contribution.

This section indicates that the use of an application.composite file means the "automagical" deployment
of a component into the Domain, but the section does not describe what the component's name is or
how it is derived. The component name is essential if any SCA wiring is used at the Domain level.

Proposal:

None


 Comments   
Comment by Mark Combellack [ 03/Nov/08 08:32 AM ]
Original email at:

http://lists.oasis-open.org/archives/sca-j/200811/msg00007.html
Comment by Dave Booz [ 03/Nov/08 10:47 AM ]
Opened Nov 3
Comment by Dave Booz [ 05/Dec/08 02:03 PM ]
awaiting propsal
Comment by Dave Booz [ 21/Aug/09 09:19 AM ]
re-opened Aug 21 telecon




[JAVA-92] Spring C&I spec needs to define how effective CT is calculated
Created: 03/Nov/08  Updated: 06/Jun/11

Status: Closed
Project: OASIS SCA Java TC
Component/s: Spring Component Implementation Specification
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Anish Karmarkar Assigned To: Mike Edwards
Resolution: Fixed Votes: 0

Issue Links:
Depends on
depends on JAVA-58 SCA Spring C&I Specification does not... Closed
Relates to
relates to JAVA-58 SCA Spring C&I Specification does not... Closed

 Description   
Target: Spring C&I

Description:
Assembly TC resolved issue 36 [1] with the following resolution:

-----
Component type represents the configurable aspects of an implementation.
A component type consists of services that are offered, references to
other services that can be wired and properties that can be set. The
settable properties and the settable references to services are
configured by a component that uses the implementation.

An implementation type specification (for example, the WS-BPEL Client
and Implementation Specification Version 1.1 [ref]) specifies the
mechanism(s) by which the component type associated with an
implementation of that type is derived.

Since SCA allows a broad range of implementation technologies, it is
expected that some implementation technologies (for example, the Java
Client and Implementation Specification Version 1.1 [ref]) allow
for introspecting the implementation artifact(s) (for example, a Java
class) to derive the component type information. Other implementation
technologies might not allow for introspection of the implementation
artifact(s). In those cases where introspection is not allowed, SCA
encourages the use of a SCA component type side file. A component type
side file is an XML file whose document root element is
sca:componentType.

The implementation type specification defines
whether introspection is allowed, whether a side file is allowed, both are
allowed or some other mechanism specifies the CT.
The component type information derived through introspection is
called the 'introspected component type'. In any case, the implementation
type specification specifies how multiple sources of information
are combined to produce the 'effective component type'. The effective
component type is the component type metadata that is
presented to the using Component for configuration.

The extension of a componentType side file name MUST be
.componentType. The name and location of a componentType side file, if
allowed, is defined by the implementation type specification.

If a component type side file is not allowed for a particular
implementation type, the effective component type and introspected
component type are one and the same for that implementation type.

For the rest of this document, when the term 'component type' is used it
refers to the 'effective component type'.
-----

This puts requirements on C&I wrt defining whether side files are
allowed, how they interact with introspected CT and how effective CT is
synthesized. We need to define these things in the C&Is.

Proposal:

None at this point.


[1] http://www.osoa.org/jira/browse/ASSEMBLY-36


 Comments   
Comment by Dave Booz [ 03/Nov/08 10:51 AM ]
Spawned and Opened Nov 3 (from Issue 87)
Comment by Dave Booz [ 12/Nov/08 09:14 AM ]
Dependency created at Nov 11 F2F
Comment by Dave Booz [ 17/Jul/09 09:25 AM ]
resolved July 17 telecon: proposal in minutes
Comment by Mike Edwards [ 14/Aug/09 08:22 AM ]
Applied in WD02 of Spring spec

sca-springci-1.1-spec-WD02.doc
Comment by Anish Karmarkar [ 06/Jun/11 06:29 PM ]
Accepted in CSD01




[JAVA-93] JEE Integration spec needs to define how effective CT is calculated
Created: 03/Nov/08  Updated: 21/Aug/09

Status: Open
Project: OASIS SCA Java TC
Component/s: Java EE Integration Specification
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Anish Karmarkar Assigned To: Anish Karmarkar
Resolution: Unresolved Votes: 0


 Description   
Target: Java EE integration spec

Description:
Assembly TC resolved issue 36 [1] with the following resolution:

-----
Component type represents the configurable aspects of an implementation.
A component type consists of services that are offered, references to
other services that can be wired and properties that can be set. The
settable properties and the settable references to services are
configured by a component that uses the implementation.

An implementation type specification (for example, the WS-BPEL Client
and Implementation Specification Version 1.1 [ref]) specifies the
mechanism(s) by which the component type associated with an
implementation of that type is derived.

Since SCA allows a broad range of implementation technologies, it is
expected that some implementation technologies (for example, the Java
Client and Implementation Specification Version 1.1 [ref]) allow
for introspecting the implementation artifact(s) (for example, a Java
class) to derive the component type information. Other implementation
technologies might not allow for introspection of the implementation
artifact(s). In those cases where introspection is not allowed, SCA
encourages the use of a SCA component type side file. A component type
side file is an XML file whose document root element is
sca:componentType.

The implementation type specification defines
whether introspection is allowed, whether a side file is allowed, both are
allowed or some other mechanism specifies the CT.
The component type information derived through introspection is
called the 'introspected component type'. In any case, the implementation
type specification specifies how multiple sources of information
are combined to produce the 'effective component type'. The effective
component type is the component type metadata that is
presented to the using Component for configuration.

The extension of a componentType side file name MUST be
.componentType. The name and location of a componentType side file, if
allowed, is defined by the implementation type specification.

If a component type side file is not allowed for a particular
implementation type, the effective component type and introspected
component type are one and the same for that implementation type.

For the rest of this document, when the term 'component type' is used it
refers to the 'effective component type'.
-----

This puts requirements on C&I wrt defining whether side files are
allowed, how they interact with introspected CT and how effective CT is
synthesized. We need to define these things in the C&Is.

Proposal:

None at this point.


[1] http://www.osoa.org/jira/browse/ASSEMBLY-36


 Comments   
Comment by Dave Booz [ 03/Nov/08 10:51 AM ]
Spawned and Opened Nov 3 (from Issue 87)
Comment by Dave Booz [ 05/Dec/08 02:04 PM ]
awaiting proposal
Comment by Dave Booz [ 21/Aug/09 09:19 AM ]
re-opened Aug 21 telecon




[JAVA-94] Missing normative guidance on the usage of annotations in unsupported ways
Created: 13/Nov/08  Updated: 11/May/09

Status: Closed
Project: OASIS SCA Java TC
Component/s: Java Common Annotations and APIs specification
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Dave Booz Assigned To: Bryan Aupperle
Resolution: Fixed Votes: 0


 Description   
RAISER: Dave Booz

TARGET: Java CAA (any version)

DESCRIPTION:
SCA places constraints on the use of some SCA annotations that are not detectable by the Java compiler. The spec needs to have normative words which describe how an SCA runtime is supposed to treat annotations which appear at unsupported locations in a Java source file. For example, the definition of the @Property and @Reference annotations indicate that they are allowed on parameters, but the SCA Java CAA spec constrains that definition to constructor parameters. Is the use of @Property or @Reference on a non-constructor method parameter and error, should be ignored or something else?

PROPOSAL: None


 Comments   
Comment by Mark Combellack [ 24/Nov/08 07:28 AM ]
Original email at http://lists.oasis-open.org/archives/sca-j/200811/msg00038.html
Comment by Dave Booz [ 24/Nov/08 09:47 AM ]
opened Nov 24
Comment by Dave Booz [ 06/Jan/09 07:38 AM ]
Latest proposal:
http://lists.oasis-open.org/archives/sca-j/200901/msg00003.html
Comment by Mark Combellack [ 08/Jan/09 09:17 AM ]
Updated latest proposal at:
http://lists.oasis-open.org/archives/sca-j/200901/msg00010.html
Comment by Dave Booz [ 09/Jan/09 10:14 AM ]
resolved Jan 9 Telecon - with updates as in the minutes
Comment by Anish Karmarkar [ 19/Jan/09 02:00 AM ]
Applied resolution in cd01-rev4:
http://www.oasis-open.org/apps/org/workgroup/sca-j/download.php/30736/sca-javacaa-1.1-spec-cd01-rev4.pdf
http://www.oasis-open.org/apps/org/workgroup/sca-j/download.php/30735/sca-javacaa-1.1-spec-cd01-rev4.doc




[JAVA-95] Simplified stateful implementation mechanism to replace conversations
Created: 13/Nov/08  Updated: 11/May/09

Status: Closed
Project: OASIS SCA Java TC
Component/s: Java Common Annotations and APIs specification
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Critical
Reporter: Dave Booz Assigned To: Simon Nash
Resolution: Fixed Votes: 0

Issue Links:
Depends on
is depended on by JAVA-8 Concurrency model for Service Referen... Closed
is depended on by JAVA-10 State sharing between ServiceReferenc... Closed
is depended on by JAVA-67 Need normative rules for stateful cal... Closed
is depended on by JAVA-68 Uniqueness of conversation IDs Closed
is depended on by JAVA-70 ConversationAttributes on class or in... Closed
is depended on by JAVA-14 Conversation Attributes are not in Ja... Closed

 Description   
RAISER: Simon Nash

TARGET: Java Common Annotations and APIs

DESCRIPTION: Simplified stateful implementation mechanism to replace conversations

The current SCA-J approach to conversations uses conversational
annotations on interfaces together with a conversation scope for
implementations.

The functional capability currently provided by SCA-J conversations
is the ability for components to be stateful, with instance lifetimes
determined by business logic semantics.

This capability can be provided in a simpler and cleaner way by
removing conversation-related annotations on interfaces and making
the necessary state management an implementation concern, using
some combination of implementation metadata and SCA-J runtime APIs.

PROPOSAL: None at this time.

 Comments   
Comment by Mark Combellack [ 24/Nov/08 07:27 AM ]
Original email at http://lists.oasis-open.org/archives/sca-j/200811/msg00039.html
Comment by Dave Booz [ 24/Nov/08 09:55 AM ]
opened Nov 24
Comment by Dave Booz [ 23/Jan/09 09:48 AM ]
resolved Jan 23 - Telecon - Remove all semblence of conversations in CAA
Comment by Dave Booz [ 23/Jan/09 09:59 AM ]
changed to critical as formal resolution text is now being prepared
Comment by Dave Booz [ 26/Jan/09 09:45 AM ]
Latest proposal: http://lists.oasis-open.org/archives/sca-j/200901/msg00093.html
Comment by Dave Booz [ 26/Jan/09 09:59 AM ]
resolved on Jan 26 telecon with proposal noted above
Comment by Dave Booz [ 26/Jan/09 10:02 AM ]
CORRECTION: proposal is in this email: http://lists.oasis-open.org/archives/sca-j/200901/msg00108.html
Comment by Dave Booz [ 26/Feb/09 08:52 AM ]
Java C&I pieces removed in WD03.
Comment by Dave Booz [ 26/Feb/09 09:05 AM ]
applied to C&I ONLY: http://www.oasis-open.org/committees/download.php/31435/sca-javaci-1.1-spec-wd03.pdf
Comment by Mike Edwards [ 23/Mar/09 09:35 AM ]
Applied in:

sca-javacaa-1.1-spec-cd02-rev1.doc




[JAVA-96] Are annotations allowed on static methods
Created: 13/Nov/08  Updated: 11/May/09

Status: Closed
Project: OASIS SCA Java TC
Component/s: Java Common Annotations and APIs specification
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Dave Booz Assigned To: Dave Booz
Resolution: Fixed Votes: 0


 Description   
Raiser: Anish Karmarkar

Title: Are annotations allowed on static methods

Target: CAA spec

Description: Are annotations such as @Init and @Destroy allowed on
static methods?

Proposal:
none at this time

 Comments   
Comment by Mark Combellack [ 24/Nov/08 07:29 AM ]
Original email at http://lists.oasis-open.org/archives/sca-j/200811/msg00040.html
Comment by Dave Booz [ 24/Nov/08 09:58 AM ]
opened Nov 24
Comment by Dave Booz [ 08/Dec/08 07:12 AM ]
Actually owned by Vamsi
Comment by Mark Combellack [ 15/Dec/08 04:44 AM ]
Proposal at:
http://lists.oasis-open.org/archives/sca-j/200812/msg00046.html
Comment by Dave Booz [ 09/Jan/09 09:53 AM ]
Resolved Jan 9 with updated proposal as in the minutes (updates were from Anish)
Comment by Anish Karmarkar [ 19/Jan/09 02:00 AM ]
Applied resolution in cd01-rev4:
http://www.oasis-open.org/apps/org/workgroup/sca-j/download.php/30736/sca-javacaa-1.1-spec-cd01-rev4.pdf
http://www.oasis-open.org/apps/org/workgroup/sca-j/download.php/30735/sca-javacaa-1.1-spec-cd01-rev4.doc




[JAVA-97] no ability to attach different intents /PolicySets to different services
Created: 13/Nov/08  Updated: 06/Mar/09

Status: Closed
Project: OASIS SCA Java TC
Component/s: Java Common Annotations and APIs specification
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Minor
Reporter: Anish Karmarkar Assigned To: Unassigned
Resolution: Won't Fix Votes: 0


 Description   
Raiser: Anish Karmarkar

Title: no ability to attach different intents to different services

Target: CAA

Description:
The @Services can list > 1 interfaces, but the corresponding @Requires
and @PolicySet attribute cannot attach separate intents and policy sets
to each of those interfaces.

Proposal:
none

 Comments   
Comment by Mark Combellack [ 24/Nov/08 07:30 AM ]
Original email at http://lists.oasis-open.org/archives/sca-j/200811/msg00047.html
Comment by Dave Booz [ 24/Nov/08 10:01 AM ]
title changed as per Nov 24 telecon
Comment by Dave Booz [ 24/Nov/08 10:01 AM ]
opened Nov 24
Comment by Mark Combellack [ 23/Feb/09 07:27 AM ]
Proposed resolution at http://lists.oasis-open.org/archives/sca-j/200902/msg00187.html
Comment by Dave Booz [ 06/Mar/09 09:40 AM ]
closed Mar 6 telecon - CNA




[JAVA-98] Can annotations be inherited
Created: 13/Nov/08  Updated: 11/May/09

Status: Closed
Project: OASIS SCA Java TC
Component/s: Java Common Annotations and APIs specification
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Minor
Reporter: Anish Karmarkar Assigned To: Dave Booz
Resolution: Fixed Votes: 0

Issue Links:
Depends on
is depended on by JAVA-129 Problems with Example 2b in chapter 7 Closed

 Description   
Raiser: Anish Karmarkar

Title: Are annotations inherited by subclasses?

Target: CAA

Description:
Do we want annotations to be inherited? This would allow a subclass to
change the implementation behavior without changing the component type.

Proposal:
none

 Comments   
Comment by Mark Combellack [ 24/Nov/08 07:31 AM ]
Original email at http://lists.oasis-open.org/archives/sca-j/200811/msg00048.html
Comment by Dave Booz [ 24/Nov/08 10:02 AM ]
opened Nov 24
Comment by Mark Combellack [ 23/Feb/09 07:26 AM ]
Outline of proposal at http://lists.oasis-open.org/archives/sca-j/200902/msg00192.html
Comment by Dave Booz [ 16/Mar/09 11:41 AM ]
alternative proposal: http://lists.oasis-open.org/archives/sca-j/200903/msg00059.html
Comment by Dave Booz [ 20/Mar/09 10:24 AM ]
latest proposal: http://lists.oasis-open.org/archives/sca-j/200903/msg00150.html
Comment by Dave Booz [ 17/Apr/09 09:58 AM ]
updated statement of direction: See minutes of April 17 telecon
Comment by Dave Booz [ 20/Apr/09 09:43 AM ]
latest proposals:
Updated Java C&I: http://www.oasis-open.org/committees/download.php/32141/sca-javaci-1.1-spec-wd07%2Bissue98.pdf
Updated Java CAA: http://www.oasis-open.org/committees/download.php/32140/sca-javacaa-1.1-spec-cd02-rev4%2Bissue98.pdf
Comment by Dave Booz [ 20/Apr/09 09:46 AM ]
previous comment is WRONG, latest proposals are here:
http://www.oasis-open.org/apps/org/workgroup/sca-j/download.php/32149/sca-javacaa-1.1-spec-cd02-rev4%20issue98%20PolicySets.pdf
http://www.oasis-open.org/apps/org/workgroup/sca-j/download.php/32150/sca-javaci-1.1-spec-wd07%20issue98%20policySets.pdf
Comment by Dave Booz [ 24/Apr/09 09:14 AM ]
latest proposals are here: http://lists.oasis-open.org/archives/sca-j/200904/msg00109.html
Comment by Dave Booz [ 27/Apr/09 10:26 AM ]
latest proposals: http://lists.oasis-open.org/archives/sca-j/200904/msg00120.html
Comment by Dave Booz [ 27/Apr/09 10:57 AM ]
resolved April 27 telecon - with updates in the minutes
Comment by Dave Booz [ 27/Apr/09 01:56 PM ]
Java CI piece applied here: http://www.oasis-open.org/committees/download.php/32269/sca-javaci-1.1-spec-wd08.pdf
Comment by Mike Edwards [ 28/Apr/09 02:43 AM ]
Applied in cd02-rev6




[JAVA-99] @property and @reference cannot be final
Created: 13/Nov/08  Updated: 11/May/09

Status: Closed
Project: OASIS SCA Java TC
Component/s: Java Common Annotations and APIs specification
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Anish Karmarkar Assigned To: Anish Karmarkar
Resolution: Fixed Votes: 0


 Description   
RAISER: Anish Karmarkar

TITLE: @property and @reference cannot be final

TARGET: CAA

Description: The above annotations should not allowed on final fields.
Properties and references must be settable.

Proposal:
If these annotations occur on final fields it is considered to be an error.


 Comments   
Comment by Mark Combellack [ 24/Nov/08 07:31 AM ]
Original email at http://lists.oasis-open.org/archives/sca-j/200811/msg00049.html
Comment by Dave Booz [ 24/Nov/08 10:12 AM ]
opened Nov 24
Comment by Dave Booz [ 12/Jan/09 10:42 AM ]
resolved Jan 12 with proposal in minutes of telecon. Editors need to form the final words.
Comment by Anish Karmarkar [ 19/Jan/09 02:00 AM ]
Applied resolution in cd01-rev4:
http://www.oasis-open.org/apps/org/workgroup/sca-j/download.php/30736/sca-javacaa-1.1-spec-cd01-rev4.pdf
http://www.oasis-open.org/apps/org/workgroup/sca-j/download.php/30735/sca-javacaa-1.1-spec-cd01-rev4.doc




[JAVA-100] default requiredness for @Reference annotation is incorrect
Created: 13/Nov/08  Updated: 24/Nov/08

Status: Closed
Project: OASIS SCA Java TC
Component/s: Java Common Annotations and APIs specification
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Anish Karmarkar Assigned To: Anish Karmarkar
Resolution: Fixed Votes: 0


 Description   
Raiser: Anish Karmarkar

Title: default requiredness for @Reference annotation is incorrect

Target: CAA

Description:
The default requiredness for @Reference annotation is set to 'true'. I
believe this is incorrect. The default should be false. If the app
programmer wanted it to be required, he/she should have explicitly set
it to be so.

 Comments   
Comment by Mark Combellack [ 24/Nov/08 07:32 AM ]
Original email at http://lists.oasis-open.org/archives/sca-j/200811/msg00051.html
Comment by Dave Booz [ 24/Nov/08 10:19 AM ]
rejected unanimously - Nov 24




[JAVA-101]  element not fully described in Java CAA specification
Created: 21/Nov/08  Updated: 11/May/09

Status: Closed
Project: OASIS SCA Java TC
Component/s: Java Common Annotations and APIs specification
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Mike Edwards (IBM) Assigned To: Mike Edwards
Resolution: Fixed Votes: 0


 Description   
Raiser: Mike Edwards

Target: Java CAA specification - sca-javacaa-1.1-spec-cd01.doc

Description:

Section 3.1 of the Java CAA specification is supposed to contain the normative description of the
<interface.java/> element of SCA. However, the description is incomplete - for example, it is
missing a description of the @callbackInterface attribute.

This needs fixing.

Proposal:

Replace the whole of section 3.1 with the following text:

---------------------------------------
3.1 Java Interface element - <interface.java/>

The Java interface element is used in SCDL files in places where an interface is declared in terms of
a Java interface class. The Java interface element identifies the Java interface class and optionally
identifies a callback interface, where the first Java interface represents the forward (service) call
interface and the second interface represents the interface used to call back from the service to the
client.

The following is the pseudo-schema for the interface.java element:
<interface.java interface="NCName" callbackInterface="NCName"?/>

The interface.java element has the following attributes:
interface (1..1) - MUST be the fully qualified name of the Java interface class [JCA30001]
callbackInterface (0..1) - MUST be the fully qualified name of a Java interface used for callbacks [JCA30002]

The following shows an example of the Java interface element:.
<interface.java interface="services.stockquote.StockQuoteService"
                callbackInterface="services.stockquote.StockQuoteServiceCallback"/>

Here, the Java interface is defined in the Java class file ./services/stockquote/StockQuoteService.class, where
the root directory is defined by the contribution in which the interface exists. Similarly, the callback interface
is defined in the Java class file ./services/stockquote/StockQuoteServiceCallback.class.

Note that the Java interface class identified by the @interface attribute can contain a Java @Callback annotation
which identifies a callback interface. If this is the case, then it is not necessary to provide the @callbackInterface
attribute. However, if the Java interface class identified by the @interface attribute does contain a Java @Callback
annotation, then the Java interface class identified by the @callbackInterface attribute MUST be the same interface
class. [JCA30003]

For the Java interface type system, arguments and return values of the service methods are described using
Java classes or simple Java types. It is recommended that the Java Classes used conform to the requirements of either
JAXB [JAXB] or of Service Data Objects [SDO] because of their integration with XML technologies.
------------------------------------------


 Comments   
Comment by Mark Combellack [ 24/Nov/08 07:34 AM ]
Original email at http://lists.oasis-open.org/archives/sca-j/200811/msg00070.html
Comment by Dave Booz [ 24/Nov/08 10:25 AM ]
opened Nov 24
Comment by Dave Booz [ 12/Jan/09 10:57 AM ]
resolved on Jan 12 telecon - with text in JIRA.
Comment by Anish Karmarkar [ 19/Jan/09 02:00 AM ]
Applied resolution in cd01-rev4:
http://www.oasis-open.org/apps/org/workgroup/sca-j/download.php/30736/sca-javacaa-1.1-spec-cd01-rev4.pdf
http://www.oasis-open.org/apps/org/workgroup/sca-j/download.php/30735/sca-javacaa-1.1-spec-cd01-rev4.doc




[JAVA-102] Need to have a Name parameter on the @Service annotation
Created: 21/Nov/08  Updated: 11/May/09

Status: Closed
Project: OASIS SCA Java TC
Component/s: Java Common Annotations and APIs specification
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Mike Edwards (IBM) Assigned To: Anish Karmarkar
Resolution: Fixed Votes: 0


 Description   
Raiser: Mike Edwards

Target: Java CAA spec - sca-javacaa-1.1-spec-cd01.doc

Description:

In the current specification, the name of a service is fixed by the name of the interface which it implements.
This is very inflexible. It is desirable to permit the programmer to choose a name for a service which is
not related to the interface class which it uses.


Proposal:

Add a new optional attribute to the @Service annotation called names, which is an array of Strings.
If present, names must contain one String for each interface contained in the interfaces
attribute of the @Service annotation - with the sequence of names being the same as
the sequence of interfaces. The string contained in names is used as the name of the SCA service.

The following is a marked up version of section 8.18 of the Java CAA specification which forms the
normative text of this proposal:


 Comments   
Comment by Mark Combellack [ 24/Nov/08 07:34 AM ]
Original email at http://lists.oasis-open.org/archives/sca-j/200811/msg00072.html
Comment by Dave Booz [ 24/Nov/08 10:26 AM ]
opened Nov 24
Comment by Dave Booz [ 23/Feb/09 10:06 AM ]
proposal pending from Simon Nash
Comment by Mark Combellack [ 27/Feb/09 07:32 AM ]
Updated proposal at:
http://lists.oasis-open.org/archives/sca-j/200902/msg00222.html
Comment by Dave Booz [ 09/Mar/09 10:18 AM ]
resolved Mar 9 - see the minutes for resolution text
Comment by Mike Edwards [ 25/Mar/09 03:07 AM ]
Applied in:

sca-javacaa-1.1-spec-cd02-rev4.doc




[JAVA-103] @Remotable annotation incorrectly marked as optional in Java EE spec
Created: 24/Nov/08  Updated: 21/Sep/09

Status: Resolved
Project: OASIS SCA Java TC
Component/s: Java EE Integration Specification
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Mike Edwards (IBM) Assigned To: Mike Edwards
Resolution: Unresolved Votes: 0


 Description   
Raiser: Mike Edwards (on behalf of Java EE subcommittee)

Target: Java EE Specification

Description:

Appendix B - row "@Remotable" - this labels the @Remotable annotation as "May be supported",
but if an @Reference field points to some SCA service which is defined in terms of a Java interface,
that service would *HAVE* to use @Remotable on the interface.

As a result, @Remotable cannot validly be optional.


Proposal:

This row should be changed to "MUST be supported" to avoid the need for an extended EJB to
have to produce a copy of the interface with @Remotable removed.


 Comments   
Comment by Mark Combellack [ 24/Nov/08 07:10 AM ]
Original email at:

http://lists.oasis-open.org/archives/sca-j/200811/msg00083.html
Comment by Dave Booz [ 24/Nov/08 10:30 AM ]
opened Nov 24
Comment by Dave Booz [ 21/Aug/09 09:19 AM ]
re-opened Aug 21 telecon
Comment by Dave Booz [ 21/Sep/09 10:03 AM ]
resolved Sept 21 telecon - see minutes for resolution text




[JAVA-104] RFC2119 Language is needed for CAA Specification
Created: 25/Nov/08  Updated: 11/May/09

Status: Closed
Project: OASIS SCA Java TC
Component/s: Java Common Annotations and APIs specification
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Blocker
Reporter: Dave Booz Assigned To: Anish Karmarkar
Resolution: Fixed Votes: 0


 Description   
TARGET: Java CAA,

DESCRIPTION:
RFC2119 language is missing from the CAA specification.

PROPOSAL:
Do it.


 Comments   
Comment by Dave Booz [ 25/Nov/08 03:32 PM ]
Opened Nov 24
Comment by Mark Combellack [ 02/Feb/09 04:36 AM ]
Mike kindly volunteered to do the RFC2119 work in the call on 2009-01-30.
Comment by Dave Booz [ 27/Feb/09 09:19 AM ]
latest proposal: http://lists.oasis-open.org/archives/sca-j/200902/msg00201.html
Comment by Dave Booz [ 16/Mar/09 09:41 AM ]
latest proposal: http://lists.oasis-open.org/archives/sca-j/200903/msg00085.html
Comment by Dave Booz [ 16/Mar/09 10:50 AM ]
resolved Mar 16 - telecon with proposal above plus one update from the minutes
Comment by Mike Edwards [ 23/Mar/09 09:38 AM ]
Applied in:

sca-javacaa-1.1-spec-cd02-rev3.doc




[JAVA-105] RFC2119 Language is needed for C&I Specification
Created: 25/Nov/08  Updated: 05/May/09

Status: Closed
Project: OASIS SCA Java TC
Component/s: Java Component Implementation Specification
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Blocker
Reporter: Dave Booz Assigned To: Unassigned
Resolution: Fixed Votes: 0


 Description   
TARGET: Java C&I

DESCRIPTION:
RFC2119 language is missing from the C&I specification.

PROPOSAL:
Do it.


 Comments   
Comment by Dave Booz [ 25/Nov/08 03:33 PM ]
opened Nov 24
Comment by Mark Combellack [ 02/Feb/09 04:36 AM ]
Mike kindly volunteered to do the RFC2119 work in the call on 2009-01-30.
Comment by Dave Booz [ 20/Mar/09 10:01 AM ]
latest proposal: http://www.oasis-open.org/apps/org/workgroup/sca-j/download.php/31730/sca-javaci-1.1-spec-wd04_proposal4.pdf
Comment by Dave Booz [ 20/Mar/09 10:03 AM ]
resolved Mar 20 telecon - see minutes for an update
Comment by Dave Booz [ 24/Mar/09 02:59 PM ]
Applied in final WD04 document: http://www.oasis-open.org/committees/download.php/31781/sca-javaci-1.1-spec-wd04.doc
Comment by Dave Booz [ 05/May/09 06:40 AM ]
Applied in CD01




[JAVA-106] RFC2119 Language is needed for Spring C&I Specification
Created: 25/Nov/08  Updated: 06/Jun/11

Status: Closed
Project: OASIS SCA Java TC
Component/s: Spring Component Implementation Specification
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Dave Booz Assigned To: Mike Edwards
Resolution: Fixed Votes: 0


 Description   
TARGET: Spring C&I

DESCRIPTION:
RFC2119 language is missing from the Spring C&I specification.

PROPOSAL:
Do it.


 Comments   
Comment by Dave Booz [ 25/Nov/08 03:34 PM ]
Opened Nov 24
Comment by Mark Combellack [ 07/Aug/09 09:24 AM ]
Resolved on call on August 7th 2009
Comment by Mike Edwards [ 14/Aug/09 08:24 AM ]
Applied in WD03 of Spring spec

sca-springci-1.1-spec-WD03.doc
Comment by Anish Karmarkar [ 06/Jun/11 06:28 PM ]
Accepted in CSD01




[JAVA-107] RFC2119 Language is needed for the EJB Binding Specification
Created: 25/Nov/08  Updated: 16/Feb/10

Status: Closed
Project: OASIS SCA Java TC
Component/s: EJB Session Binding Specification
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Dave Booz Assigned To: Unassigned
Resolution: Fixed Votes: 0


 Description   
TARGET: EJB Binding

DESCRIPTION:
RFC2119 language is missing from the EJB Binding specification.

PROPOSAL:
Do it.


 Comments   
Comment by Dave Booz [ 25/Nov/08 03:36 PM ]
opened Nov 24
Comment by Dave Booz [ 22/Jul/09 09:24 AM ]
latest proposal (v1): http://www.oasis-open.org/committees/download.php/33490/sca-ejbbinding-1.1-spec-wd-04%2Bissue107_v1.doc
Comment by Dave Booz [ 10/Aug/09 10:24 AM ]
latest proposal: http://lists.oasis-open.org/archives/sca-j/200907/msg00111.html
Comment by Dave Booz [ 14/Aug/09 09:10 AM ]
latest: http://lists.oasis-open.org/archives/sca-j/200908/msg00033.html
Comment by Dave Booz [ 14/Aug/09 09:32 AM ]
resolved Aug 14 telecon: see final changes in minutes
Comment by Dave Booz [ 14/Aug/09 10:33 AM ]
applied: http://www.oasis-open.org/apps/org/workgroup/sca-j/download.php/33809/sca-ejbbinding-1.1-spec-wd-05.pdf
Comment by Dave Booz [ 16/Feb/10 11:17 AM ]
Closed as a result of CD vote on Feb 15,2010.




[JAVA-108] RFC2119 Language is needed for the SCA-JEE Specification
Created: 25/Nov/08  Updated: 21/Aug/09

Status: Open
Project: OASIS SCA Java TC
Component/s: Java EE Integration Specification
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Dave Booz Assigned To: Unassigned
Resolution: Unresolved Votes: 0


 Description   
TARGET: SCA JEE Integration Specification

DESCRIPTION:
RFC2119 language is missing from the SCA-JEE specification.

PROPOSAL:
Do it.



 Comments   
Comment by Dave Booz [ 25/Nov/08 03:37 PM ]
opened Nov 24
Comment by Dave Booz [ 21/Aug/09 09:19 AM ]
re-opened Aug 21 telecon




[JAVA-109] Property and reference names computed from SCA annotations in web modules not specified explicitly
Created: 01/Dec/08  Updated: 21/Aug/09

Status: Open
Project: OASIS SCA Java TC
Component/s: Java EE Integration Specification
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Dave Booz Assigned To: Dave Booz
Resolution: Unresolved Votes: 0


 Description   
Target: sca-jee-1.1-spec-wd05.doc

Description:
Section 6.4.3 "Providing additional component type data for web
application" mentions that @Property and @Reference annotations can be
used, but does not specify how the property name and reference name should
be computed in the case where the property or reference name is not
specified in the annotation. Note that section 6.1.4.1 gives an example in
case of session beans. Incase of EJB's, the field name or the setter
method name alone is good enough to compute the property or reference name
as each EJB will result in a component. In case of a web module, since the
entire module results in a single component, we may have to use something
more than just the field name or setter method name as two fields with same
name from two different web artifacts will have to result in two different
properties or references in the computed component type. The spec has to
make it clear how the property and reference names are computed when name
is not specified in @Property and @Reference used on a web artifact.

Proposal:
In the absence of name in the @Property or @Reference annotation, prepend
the java classname of the artifact followed by underscore to the field name
or setter method name to compute the property name or reference name.

For illustration, add an example with an annotated class and the computed
component type.

 C