[UNITSOFMEASUREMENT-165] Add getSystemUnit() method to QuantityFactory Created: 27/Sep/15  Updated: 27/Sep/15  Resolved: 27/Sep/15

Status: Resolved
Project: unitsofmeasurement
Component/s: API
Affects Version/s: 0.8-RC3
Fix Version/s: 0.8

Type: Improvement Priority: Major
Reporter: keilw Assignee: keilw
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: api, design, factory
Epic Link: Design
Sprint: Public Draft

 Description   

QuantityFactory should expose the method getSystemUnit() similar to Unit.






[UNITSOFMEASUREMENT-128] Add ServiceProvider interface Created: 09/Apr/15  Updated: 09/Jun/15  Resolved: 09/Jun/15

Status: Resolved
Project: unitsofmeasurement
Component/s: API
Affects Version/s: None
Fix Version/s: None

Type: New Feature Priority: Major
Reporter: keilw Assignee: keilw
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Blocks
blocks UNITSOFMEASUREMENT-99 Rename javax.measure.spi.*Service as ... Resolved
Tags: api, design, spi
Epic Link: Design
Sprint: Q2/15

 Description   

Similar to JSR 354 (using the BP https://github.com/JavaMoney/jsr354-api-bp/blob/master/src/main/java/javax/money/spi/ServiceProvider.java as it's Java 6/7 compliant) it seems good to have a ServiceProvider interface. That may be the only "Provider" for the SPI, sticking to the "*Service" naming convention for other components, since ServiceProvider then literally provides services rather than again providers Implementing this unlike 354 might be up to RI or other implementations.



 Comments   
Comment by keilw [ 09/Apr/15 ]

Changing all names from *Service to *Provider wouldn't make sense if ServiceProvider in a way 354 applies it was introduced. Since it provides those *Service elements





Create TCK (UNITSOFMEASUREMENT-101)

[UNITSOFMEASUREMENT-118] Add Tests according to Spec Chapter 4 Created: 27/Jan/15  Updated: 03/Apr/16  Resolved: 03/Apr/16

Status: Resolved
Project: unitsofmeasurement
Component/s: TCK
Affects Version/s: 0.7.1
Fix Version/s: 0.9

Type: Sub-task Priority: Critical
Reporter: keilw Assignee: keilw
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
is related to UNITSOFMEASUREMENT-159 Move test-audit.xml to main/resources Resolved
Tags: api, spec, tck-red, test, testing
Sprint: Q1/15, Final Draft

 Description   

Spec Chapter 4 (API) requires TCK Tests

  • Assess if and which tests are required
  • Where necessary update test-audit.xml of the TCK project
  • Write tests for sections identified as relevant


 Comments   
Comment by keilw [ 03/Apr/16 ]

This looks pretty complete





[UNITSOFMEASUREMENT-89] SystemOfUnits.getUnits() needs to define which unit it returns Created: 16/Dec/14  Updated: 26/Oct/15  Resolved: 26/Oct/15

Status: Resolved
Project: unitsofmeasurement
Component/s: API
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Minor
Reporter: desruisseaux Assignee: keilw
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
is related to UNITSOFMEASUREMENT-90 UnitFormatService is missing a getAva... Resolved
is related to UNITSOFMEASUREMENT-124 Introduce a Unit "DB" Resolved
is related to UNITSOFMEASUREMENT-88 SystemOfUnits need to tell its base u... Resolved
Tags: api, document, javadoc
Epic Link: Documents
Sprint: Public Draft

 Description   

Current Javadoc of SystemOfUnits.getUnits() currently only said "Returns a read only view over the units defined in this system". This insufficient, since the set of units is potentially infinite.

I suggest to update the Javadoc with something like "Returns a read only view over units explicitly defined by this system. This include the base and derived units which are assigned a special name and symbol, like watt. This set does not include new units created by arithmetic or other operations".






[UNITSOFMEASUREMENT-69] Rethink hierarchy (and possibly naming) of Quantity and Measurement Created: 31/Oct/14  Updated: 04/Mar/15  Resolved: 20/Nov/14

Status: Resolved
Project: unitsofmeasurement
Component/s: API
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: dautelle Assignee: keilw
Resolution: Fixed Votes: 0
Labels: None
Σ Remaining Estimate: Not Specified Remaining Estimate: Not Specified
Σ Time Spent: Not Specified Time Spent: Not Specified
Σ Original Estimate: Not Specified Original Estimate: Not Specified

Issue Links:
Related
is related to UNITSOFMEASUREMENT-65 Move QuantityFactory from "function" ... Resolved
Sub-Tasks:
Key
Summary
Type
Status
Assignee
UNITSOFMEASUREMENT-73 Refactor Quantity Sub-task Resolved keilw  
Tags: api, inheritance
Epic Link: Design
Sprint: Early Draft

 Description   

Jean-Marie pointed out what he feels is a hierarchical inversion Measurement should extend Quantity and not the vice versa (a measurement is a quantity "measured"; hence with a value stated in a unit)

and suggested

 interface Measurement<Q> extends Quantity<Q> {
     Number getValue()
     Unit<Q> getUnit()
     toUnit(Unit<Q>) // toUnit should be here and not in the Quantity interface (a quantity intrinsically has no unit)
}

Wikipedia: http://en.wikipedia.org/wiki/Quantity makes distinction between quantities with magnitute or multitude.
Furthermore "..., the measurements of quantities" goes alongside Jean-Marie's proposal to swap them.
Eclipse UOMo also knows an (Eclipse Interface style) IMeasure http://git.eclipse.org/c/uomo/org.eclipse.uomo.git/tree/bundles/org.eclipse.uomo.units/src/main/java/org/eclipse/uomo/units/IMeasure.java
extending Quantity of the earlier Unit-API.

If we want to cover non-numeric quantities and Measurement was therefore a numeric quantity would the Quantity interface therefore be nothing more than a "tagging Interface" for the type-safe generic element <Q>? If the numeric value and unit as well as to() (which is strictly related to a getUnit() method) all went from Quantity to a sub-Interface Measurement there is no method left.

Although it is arguable, if say a T-Shirt size like "M" or "XL" can often be simply converted into a numeric Clothes measurement like "45" or "52", such conversions do exist in real life. It often tends to be a Range which we only Support on an implementation level (in RI or alternate implementations like the SE port) so unless Range would implement at least Qantity or Measurement itself, a conversion may exceed the scope of the API.



 Comments   
Comment by keilw [ 31/Oct/14 ]

Only for a reference, not to apply here there are some bizarre hierarchies, just to mention OpenXC by Ford:
http://android.openxcplatform.com/reference/com/openxc/units/Quantity.html
Where Quantity extends Unit which then has concrete subtypes named Liter or Kilometer.

Comment by desruisseaux [ 01/Nov/14 ]

I'm not aware of universally accepted definition of "quantity". Some peoples make a distinction between "quantity" and "physical quantity". For example in an article cited by Werner, the author first mentions "physical quantity", then use only the word "quantity" in the remaining of his article. He said "Typically these quantities possess unit of measure", but I think that he implicitly means "physical quantity".

One could imagine the following type hierarchy:

    Quantity
       ↑
    Measurement
       ↑
    PhysicalQuantity or Scalar or ScalarMeasure

But where would we put Vector, Tensor or any other kind of measurement that are not a scalar in this hierarchy? Putting Vector as a subtype of Measurement seems contradictory with the Quantity base type.

There is my proposal:

  • I think that Measurement should not extend Quantity, because (to me) it would imply that all measurements are scalars, which would exclude other kind of measurements like vectors.
  • I think we should explain that, for the sake of simplicity, JSR-363 merges the "pure quantity" concept with the "physical quantity" concept, and that we call that just "quantity". We may define our quantity as a "quantitative measurement".

A Quantity in the "pure" sense is hard to fit in our type hierarchy (e.g. above-cited contradiction with non-scalar measurement) and make all Length, Mass, etc. subtypes useless for other purpose than marking interface. Furthermore the above hierarchy would allow users to parameterize Unit instances with arbitrary Measurement subtypes that are not something like Length or Mass. On the other hand, keeping the current hierarchy, with the idea that we merged "quantity" concept with "physical quantity" or "quantitative measurement", keep Unit parameterization safer (can not use arbitrary Measurement), and keep Measurement applicable to non-scalar measurement.

In summary, I suggest to keep current hierarchy as-is but explain better what we means by "quantity".

Comment by keilw [ 20/Nov/14 ]

Was resolved by removing Measurement from the API. Current design of Quantity assumes we only support <b>numeric</b> quantities, not things like "Small, Medium, Large", etc. There are means to support this in Java, especially enums (we might want to mention that in the spec, too ), thus it can be seen as low or no priority for this JSR.

Unlike OSGi Measurenent, we consider Quantity and Measurement as 2 separate entities. Also see Martin Fowler's analysis: http://martinfowler.com/apsupp/apchap3.pdf
Measurement can contain Quantity rather than extending it. There's room for this in implementations, especially since methods like <b>timestamp</b> can be different on ME or SE. Should there be a need to graduate such type into the API we'll consider it either at a later stage of this JSR or a later version.

Comment by keilw [ 04/Mar/15 ]

Just for the record, a fork of the simple UCAR Unit library into another project named Visad also contains a Quantity type: https://www.unidata.ucar.edu/software/idv/docs/javadoc/ucar/visad/quantities/Quantity.html
Actually there are 3 but this one has children ScalarQuantity, VectorQuantity similar to what was discussed here and ScalarQuantity got sub-classes like Acceleration, Length, etc., very much like we do here except that we currently don't distinguish between Scalar and Vector, effectively all the API supports is just ScalarQuantity for now.





[UNITSOFMEASUREMENT-67] Convenience Factory Methods for Quantity or Unit Created: 26/Oct/14  Updated: 15/Nov/14  Resolved: 15/Nov/14

Status: Resolved
Project: unitsofmeasurement
Component/s: API, RI
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Major
Reporter: keilw Assignee: keilw
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
is related to UNITSOFMEASUREMENT-65 Move QuantityFactory from "function" ... Resolved
is related to UNITSOFMEASUREMENT-71 Should we rename of(CharacterSequence... Resolved
Tags: api, design, factory
Epic Link: Design
Sprint: Early Draft

 Description   

Along the lines of a proposed Java 9 JEP (https://bugs.openjdk.java.net/browse/JDK-8048330) to add convenience methods to Java Collections types like List, Map, Set or their implementing classes like ArrayList.

As of now, the API must support both Java SE and ME (8), so adding a static method like of() to an interface is not an option (could be if Java ME 9 or 8.x should ever support Lambdas as Mark Reinhold hinted )
The closest to an interface are abstract base classes like AbstractUnit or AbstractQuantity in the RI.
AbstractUnit contains an of() convenience factory for strings like "10 cm". while for Quantity implementations it was moved to BaseQuantity. IMHO a mistake, because

public static <Q extends Quantity<Q>> AbstractQuantity<Q> of(double, Unit<Q>)

in BaseQuantity actually returns a new DoubleQuantity instance.
DoubleQuantity does not extend BaseQuantity but AbstractQuantity, thus the of(double, Unit<Q>) method should either be in the concrete DoubleQuantity class (which however is not public right now) or AbstractQuantity not BaseQuantity.

Doing so on AbstractQuantity and AbstractUnit seems more consequent towards a possible future addition to the actual interface (if Lambdas worked for ME, too)



 Comments   
Comment by keilw [ 30/Oct/14 ]

If Quantities returned a Quantity instance directly, then both convenience factory methods in concrete or abstract types become less useful and it means, QuantityFactory would better be OPTIONAL via SPI. Should the facade return QuantityFactory like JSR 354 does in similar classes, then it remains a first class API type similar to JavaMoney MonetaryAmountFactory

Comment by desruisseaux [ 01/Nov/14 ]

I propose:

  • QuantityFactory as an interface doing the real work. Users are responsible for fetching their QuantityFactory instance using java.util.ServiceLoader or OSGi.
  • Quantities as a set of static methods only, which are only convenience methods fetching a default QuantityFactory using ServiceLoader (or whatever mechanism) and delegating the work to it.
Comment by keilw [ 03/Nov/14 ]

Thanks, that sounds reasonable. Otavio has recently through other tasks (mostly in the SE port) refactored BaseQuantity into NumberQuantity. As it reflects aspects of JavaFX Binding, it seems good for RI or similar implementations (leaving aside in our current design EVERY Quantity is also a numeric quantity since getValue() only returns a number now )
When this "base quantity" (the only concrete class that is fully exposed to sub-classing, although a user could directly use AbstractQuantity for more freedom if they want) is subclassed, overloading the static of() method becomes tricky and cumbersome, so I suggest to remove that for now. Other factories for specific types, maybe we could leave. With a new name like NumberQuantity while they are not subclasses it delegating to special (primitive) numbers like long or double sounds OK.
All other factory methods should happen in Quantities or a similar specialized static facade.
Java 9 won't remove Collections either, even if it may add new of() methods to the Interface itself. We won't risk more reduncancy than that and in a hypothetical JDK module in the future, maybe there's ME 9 offering Lambdas, so we could offer that kind of stuff to a 1.x or 2.x Version of the API instead





[UNITSOFMEASUREMENT-56] Could we move AbstractQuantity into API/SPI? Created: 17/Sep/14  Updated: 26/Jul/15  Resolved: 26/Jul/15

Status: Resolved
Project: unitsofmeasurement
Component/s: API, RI
Affects Version/s: None
Fix Version/s: 0.7

Type: Improvement Priority: Minor
Reporter: keilw Assignee: keilw
Resolution: Won't Fix Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Duplicate
is duplicated by UNITSOFMEASUREMENT-98 Consider providing the "Units" class ... Resolved
Related
is related to UNITSOFMEASUREMENT-145 Move Bootstrap mechanism into API Resolved
is related to UNITSOFMEASUREMENT-13 Do we need AbstractMeasurement in RI? Closed
is related to UNITSOFMEASUREMENT-121 Introduce "Pluggable" Unit Systems an... Resolved
is related to UNITSOFMEASUREMENT-42 Could we add AbstractSystemOfUnits to... Closed
Tags: api, design, implementation, refactoring
Epic Link: Design
Sprint: JavaOne, Public Draft

 Description   

If as intended, some of the factory methods went from AbstractQuantity into either QuantityFactory or a concrete class like BaseQuantity would it make sense to provide a general abstract base class like that in the API or at least SPI of the JSR instead of particular implementations?

Several JSRs do this, Collection API with
AbstractMap etc.
Servlet or Portlet API with
GenericServlet or GenericPortlet.

Whether we call it AbstractQuantity hence keeping it abstract or something like GenericQuantity we may see. Different JSRs provide both as mentioned.



 Comments   
Comment by otaviojava [ 17/Sep/14 ]

I believe no, the API just should define the contract.
You are referring old APIs, nowadays almost always the best solution is the composition.

Comment by keilw [ 17/Sep/14 ]

Glad to hear, another example for old APIs (just took nearly a decade to add to Java 8 ) is JSR 310. Where API and RI are horribly entangled and almost every implementation of the anemic interfaces like Temporal have completely different behavior and pose high degree of duplication...

To avoid that a common base class in RI/SE port will likely stay, but I would be OK to keep them in each implementation. Let's hear other's thoughts.

Comment by leomrlima [ 29/Sep/14 ]

Similiar to #42, let's keep the API clean of any implementation!

Comment by keilw [ 11/Jul/15 ]

I would like to reopen this for consideration as at least one or the other concrete (or abstract) class must be factored into the API as a single point of access to the SPI/API.
Look at CDI it got a CDI class in the SPI package and there is at least one other class Unmanaged since 1.1.

The SPI and its package are optional, so it's a default implementation for SystemOfUnits which works the same way in SE and ME, so this would make it more common here (for pluggable Unit Systems)

Comment by keilw [ 26/Jul/15 ]

There are a few implementation specific references, e.g. to AbstractUnit in AbstractSystemOfUnits, so moving it to API does not make sense in this form.





[UNITSOFMEASUREMENT-55] Remove generic V from Measurement Created: 17/Sep/14  Updated: 29/Sep/14  Resolved: 17/Sep/14

Status: Resolved
Project: unitsofmeasurement
Component/s: API
Affects Version/s: None
Fix Version/s: 0.7

Type: Improvement Priority: Major
Reporter: keilw Assignee: keilw
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: api, design
Epic Link: Design
Sprint: JavaOne

 Description   

After Measurement had most numeric methods and values delegated to the Quantity subtype, it seems less useful to keep a generic <V> argument there.

Where it makes sense is for Quantity to extend ValueSupplier<Number> but as described in recent JavaDoc for Measurement its concrete classes are free to implement ValueSupplier<DESIRED_TYPE> to match the behavioral pattern of Quantity kind of like extending or implementing Comparable, Serializable, etc. but the base interface does not enforce it, so <V> seems redundant for Measurement.



 Comments   
Comment by otaviojava [ 17/Sep/14 ]

[DONE]
https://github.com/unitsofmeasurement/unit-api/pull/11

https://github.com/unitsofmeasurement/unit-ri/pull/24

Comment by otaviojava [ 17/Sep/14 ]

PR: to solve this design:
https://github.com/unitsofmeasurement/unit-api/pull/11
https://github.com/unitsofmeasurement/unit-ri/pull/24

Comment by keilw [ 17/Sep/14 ]

Unfortunately the change seriously broke the API;-(

Comment by keilw [ 17/Sep/14 ]

Please refrain from @Override for places where interfaces are implemented.
This may have started working from Java SE 8 on or so, but the API is backward compatible to Java 5 (also see this year's JavaOne Embedded Challenge winner Lhings: https://github.com/lhings/java_lhings_library ) which is why the @Override breaks build in some cases.

Comment by otaviojava [ 17/Sep/14 ]

@kelliw I runned the test and is ok the API.

Comment by keilw [ 17/Sep/14 ]

SE port has not applied the changes yet. Compiler gets irritated by the @Override, so let's not use that please, the API needs to be Java 5 compatible, that is why it causes compile errors. Maven seems to ignore that if run against Java 7 or 8, which looks more like a Maven problem, the Java 5/6 code must not have @Override for implementing methods.
So

@Override
toString()

is OK, but

@Override
getUnit()

isn't.

Comment by keilw [ 17/Sep/14 ]

After resolving @Override annotation problem it looks OK





[SWINGX_WS-37] Make JMapViewer TileFactoryInfo extensible by extracting interface Created: 15/Nov/11  Updated: 15/Nov/11

Status: Open
Project: swingx-ws
Component/s: None
Affects Version/s: 1.1
Fix Version/s: None

Type: Improvement Priority: Major
Reporter: brettryan Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: Text File 0003-Refactored-TileFactoryInfo-to-be-extensible.patch     Text File 0004-API-now-using-ITileFactoryInfo.patch     Text File 0005-Corrected-map-component-to-use-intefraces-appropriat.patch     Text File 0006-Added-alternate-implementations.patch     Text File 0007-Demonstrations-using-alternate-servers.patch     Text File 0011-Exit-app-on-window-close.patch    
Tags: api

 Description   

Implementors must currently work with the bounds of TileFactoryInfo, it would be simpler if this was an interface instead.

The attached patch extracts the interfaces and remains API compatible for other implementors.

There are 5 patch files, 0003 - 0007 with the last two being alternate server implementations to demonstrate usage.



 Comments   
Comment by brettryan [ 15/Nov/11 ]

Alternate implementation and demonstration of usage.

Comment by brettryan [ 15/Nov/11 ]

Correctly set app to close on window close for sample app.





[LWUIT-479] Save the nodes states of the tree Component Created: 26/Sep/11  Updated: 26/Sep/11

Status: Open
Project: lwuit
Component/s: None
Affects Version/s: current
Fix Version/s: None

Type: Improvement Priority: Major
Reporter: ThomasPz Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: 1 day
Time Spent: Not Specified
Original Estimate: 1 day
Environment:

lwuit 1.5


Tags: Tree, api, nodes

 Description   

Make an Api to the tree component to manipulate the Node States.

Get the actual state of a node. Save them. Restore them. Open a node. collaps a node. etc.

See this post for details:

http://www.java.net/forum/topic/mobile-embedded/lwuit/save-node-states-tree-component






[JAX_RS_SPEC-518] Configurable @Path resolution strategies Created: 12/Oct/15  Updated: 12/Oct/15

Status: Open
Project: jax-rs-spec
Component/s: spec
Affects Version/s: 2.1
Fix Version/s: None

Type: Improvement Priority: Minor
Reporter: mkarg Assignee: Marek Potociar
Resolution: Unresolved Votes: 5
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Status Whiteboard:

to be discussed post-2.1

Tags: api, path

 Description   

Due to ongoing discussions on the Jersey mailing list, I am filing this issue for consideration in post-2.1 (e. g. 3.0).

Apparently the @Path resolution strategy is neither well-understood nor intuitive to the average Joe, so there had been suggestions for different alternative resolution strategies.

To preserve backwards compatibility, the original strategy from 2.0 and prior has to be the default, certainly, but maybe there is room in post-2.1 (e. g. 3.0) to provide alternative strategies that can be explicitly switched on by users.

Besides a simple selector switch that switches between old and new strategy, I could imagine that it makes sense to provide an annotation-based approach which lets an application bundle provide its own application-specific resolution strategy.






[JAX_RS_SPEC-191] Update Chapter 6 based on changes to filter API Created: 17/Apr/12  Updated: 18/Jun/13  Due: 27/Apr/12  Resolved: 23/May/12

Status: Resolved
Project: jax-rs-spec
Component/s: None
Affects Version/s: 2.0
Fix Version/s: 2.0

Type: Task Priority: Major
Reporter: Santiago Pericas-Geertsen Assignee: Santiago Pericas-Geertsen
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: api, filter

 Description   

Update Chapter 6 based on changes to filter API.



 Comments   
Comment by Santiago Pericas-Geertsen [ 23/May/12 ]

Updated it for EDR3.





[JAX_RS_SPEC-190] Update Chapter 8 based on changes to async API Created: 17/Apr/12  Updated: 18/Jun/13  Due: 27/Apr/12  Resolved: 23/May/12

Status: Resolved
Project: jax-rs-spec
Component/s: None
Affects Version/s: 2.0
Fix Version/s: 2.0

Type: Task Priority: Major
Reporter: Santiago Pericas-Geertsen Assignee: Santiago Pericas-Geertsen
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: api, async, asynchronous

 Description   

Update Chapter 8 based on changes to async API.



 Comments   
Comment by Santiago Pericas-Geertsen [ 23/May/12 ]

Changes incorporated in EDR3.





[JAVASERVERFACES-2516] Redirecting with view params via navigation API tranfers only first param Created: 13/Sep/12  Updated: 11/Feb/13  Resolved: 11/Feb/13

Status: Closed
Project: javaserverfaces
Component/s: navigation
Affects Version/s: 2.1.13
Fix Version/s: 2.1.19, 2.2.0-m10

Type: Bug Priority: Trivial
Reporter: flopsi Assignee: Manfred Riem
Resolution: Duplicate Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Duplicate
is duplicated by JAVASERVERFACES-2718 includeViewParams does not work Closed
Tags: api, navigation, parameters, redirect, view

 Description   

Hi everybody,

i have two views with the same <f:viewParam name="..."/>'s defined (without bean reference). Now i try to navigate from one view to the other via navigation API preserving the parameters (includeViewParams flag set). But the generated URL only contains the first param, so after redirect all view params are gone but the first. Here is some code:

public String navigateTo(String view) {
FacesContext ctx = FacesContext.getCurrentInstance();
String viewId = ctx.getViewRoot().getViewId();
Application app = ctx.getApplication();
SeamNavigationHandler handler = (SeamNavigationHandler) app.getNavigationHandler();
Map<String, Set<NavigationCase>> navCases = handler.getNavigationCases();
NavigationCase navCase = new NavigationCase(viewId, null, "success", null, view, null, true, true);
Set<NavigationCase> navCaseSet = new HashSet<NavigationCase>();
navCaseSet.add(navCase);
navCases.put(navCase.getFromViewId(), navCaseSet);
return "success";
}

While debugging down i found the following method in com.sun.faces.application.view.MultiViewHandler which is used to copy view parameter values from source to destination view (please see also method MultiViewHandler.addViewParameters):

private static String getStringValueToTransfer(FacesContext context, UIViewParameter param, Collection<UIViewParameter> viewParams) {
if (viewParams != null && !viewParams.isEmpty()) {
for (UIViewParameter candidate : viewParams) {
if ((null != candidate.getName() && null != param.getName()) &&
candidate.getName().equals(param.getName()))

{ return candidate.getStringValue(context); }

else

{ return param.getStringValue(context); }

}
}
return null;
}

It seems pretty clear to me now why only the first param is transfered... It should only return param.getStringValue(context) if the name is not found in ALL iterations, right?
Or is it somewhat intended?

Thanks, best regards
Flo



 Comments   
Comment by Manfred Riem [ 08/Nov/12 ]

Can you please attach an example application (with sources) that demonstrates the problem?

Comment by Manfred Riem [ 07/Dec/12 ]

Can you verify if it is still an issue with the latest 2.1 release?

Comment by Manfred Riem [ 14/Jan/13 ]

Lowering priority because of no response





[JAVASERVERFACES-2092] f:convertDateTime validation error message FR Created: 01/Jun/11  Updated: 26/Jun/12  Resolved: 11/Jun/11

Status: Closed
Project: javaserverfaces
Component/s: None
Affects Version/s: current, 2.0.4, 2.1.1
Fix Version/s: 2.1.2

Type: Bug Priority: Major
Reporter: mansour Assignee: Ed Burns
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: 0 minutes
Time Spent: 1 hour, 30 minutes
Original Estimate: Not Specified
Environment:

Mojarra (tested with versions 2.0.4 and 2.1.1), tomcat 6.0, windows


Attachments: Text File 20110601-i_mojarra_2092.patch     File JSF2MessageBug.war    
Issue Links:
Duplicate
is duplicated by JAVASERVERFACES-2091 f:convertDateTime validation error me... Closed
Tags: api, i18n, jsf2, message

 Description   

Here is a simple example of date input text with <f:convertDateTime/> :

 
<h:inputText id="dateOfBirth" value="#{user.dateOfBirth}" 
    size="20" required="true" label="Date of Birth">
    <f:convertDateTime />
</h:inputText>
<h:message for="dateOfBirth" style="color:red" />

When we execute this with an error in date conversion (ex : xxxxx) in the inputText field, the error message displayed in <h:message> with locale FR contains the token '

{1}

' which means that a parameter is not interpreted :

Date of Birth : 'xxxxx' na pas pu être interprété en tant que date. Exemple : \{1\}

When we switch the locale in english, there is no problem the message is correctly displayed :

Date of Birth: 'xxxxx' could not be understood as a date. Example: Jun 1, 2011

Solution : in jsf-api.jar/javax.faces.Messages_fr.properties the character ' (quote) is not escaped in many messages, so try to put a double quote like this : ''

I've attached a sample web project that illustrates the problem



 Comments   
Comment by Ed Burns [ 01/Jun/11 ]

Please review this fix.

Comment by mansour [ 07/Jun/11 ]

Thank you for the patch, it works better now but it seems that you forgot some characters ''(quotes) that are not replaced by "\u00ab" and "\u00bb"in the file JsfToolsMessages_fr.properties. For the moment, we will include the file messages_fr.properties corrected in the web application and we wait for a new version that correct this 2.0.x or 2.1.x ?

Comment by Ed Burns [ 07/Jun/11 ]

Committed to trunk.

Sending jsf-api/src/main/java/javax/faces/LogStrings_fr.properties
Sending jsf-api/src/main/java/javax/faces/Messages_fr.properties
Sending jsf-demo/archive/carstore/src/java/carstore/bundles/Jalopy_fr.properties
Sending jsf-demo/archive/carstore/src/java/carstore/bundles/Luxury_fr.properties
Sending jsf-demo/archive/carstore/src/java/carstore/bundles/Messages_fr.properties
Sending jsf-demo/archive/carstore/src/java/carstore/bundles/Resources_fr.properties
Sending jsf-demo/archive/carstore/src/java/carstore/bundles/SUV_fr.properties
Sending jsf-ri/src/main/resources/com/sun/faces/LogStrings_fr.properties
Sending jsf-ri/src/main/resources/com/sun/faces/resources/Messages_fr.properties
Sending jsf-tools/src/main/resources/JsfToolsMessages_fr.properties
Transmitting file data ..........
Committed revision 9136.

Comment by Ed Burns [ 07/Jun/11 ]

Committed to 2.1 branch.

Sending jsf-api/src/main/java/javax/faces/LogStrings_fr.properties
Sending jsf-api/src/main/java/javax/faces/Messages_fr.properties
Sending jsf-demo/archive/carstore/src/java/carstore/bundles/Jalopy_fr.properties
Sending jsf-demo/archive/carstore/src/java/carstore/bundles/Luxury_fr.properties
Sending jsf-demo/archive/carstore/src/java/carstore/bundles/Messages_fr.properties
Sending jsf-demo/archive/carstore/src/java/carstore/bundles/Resources_fr.properties
Sending jsf-demo/archive/carstore/src/java/carstore/bundles/SUV_fr.properties
Sending jsf-ri/src/main/resources/com/sun/faces/LogStrings_fr.properties
Sending jsf-ri/src/main/resources/com/sun/faces/resources/Messages_fr.properties
Sending jsf-tools/src/main/resources/JsfToolsMessages_fr.properties
Transmitting file data ..........
Committed revision 9137.

Comment by Ed Burns [ 07/Jun/11 ]

Committed to 2.0.x branch, but we've already cut 2.0.6. Therefore, it will be in 2.0.7.

Thanks for reporting it.

Sending jsf-api/src/main/java/javax/faces/LogStrings_fr.properties
Sending jsf-api/src/main/java/javax/faces/Messages_fr.properties
Sending jsf-demo/archive/carstore/src/java/carstore/bundles/Jalopy_fr.properties
Sending jsf-demo/archive/carstore/src/java/carstore/bundles/Luxury_fr.properties
Sending jsf-demo/archive/carstore/src/java/carstore/bundles/Messages_fr.properties
Sending jsf-demo/archive/carstore/src/java/carstore/bundles/Resources_fr.properties
Sending jsf-demo/archive/carstore/src/java/carstore/bundles/SUV_fr.properties
Sending jsf-ri/src/main/resources/com/sun/faces/LogStrings_fr.properties
Sending jsf-ri/src/main/resources/com/sun/faces/resources/Messages_fr.properties
Sending jsf-tools/src/main/resources/JsfToolsMessages_fr.properties
Transmitting file data ..........
Committed revision 9138.

Comment by rogerk [ 11/Jun/11 ]

fix version

Comment by rogerk [ 11/Jun/11 ]

fix version

Comment by rogerk [ 11/Jun/11 ]

fix version





[JAVASERVERFACES-2091] f:convertDateTime validation error message FR Created: 01/Jun/11  Updated: 07/Mar/13  Resolved: 07/Mar/13

Status: Closed
Project: javaserverfaces
Component/s: None
Affects Version/s: 2.0.4, 2.1.1
Fix Version/s: None

Type: Bug Priority: Trivial
Reporter: mansour Assignee: Unassigned
Resolution: Incomplete Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Mojarra (tested with versions 2.0.4 and 2.1.1), tomcat 6.0, windows


Attachments: File JSF2MessageBug.war    
Issue Links:
Duplicate
duplicates JAVASERVERFACES-2092 f:convertDateTime validation error me... Closed
Tags: api, i18n, jsf2, message

 Description   

Here is a simple example of date input text with <f:convertDateTime/> :

 
<h:inputText id="dateOfBirth" value="#{user.dateOfBirth}" 
    size="20" required="true" label="Date of Birth">
    <f:convertDateTime />
</h:inputText>
<h:message for="dateOfBirth" style="color:red" />

When we execute this with an error in date conversion (ex : xxxxx) in the inputText field, the error message displayed in <h:message> with locale FR contains the token '

{1}

' which means that a parameter is not interpreted :

Date of Birth : 'xxxxx' na pas pu être interprété en tant que date. Exemple : \{1\}

When we switch the locale in english, there is no problem the message is correctly displayed :

Date of Birth: 'xxxxx' could not be understood as a date. Example: Jun 1, 2011

Solution : in jsf-api.jar/javax.faces.Messages_fr.properties the character ' (quote) is not escaped in many messages, so try to put a double quote like this : ''

I've attached a sample web project that illustrates the problem



 Comments   
Comment by Manfred Riem [ 11/Dec/12 ]

Can you verify if this is still an issue on the latest 2.1 release?

Comment by Manfred Riem [ 10/Jan/13 ]

Lowering priority because of no response

Comment by Manfred Riem [ 07/Feb/13 ]

Lowering priority because of no response

Comment by Manfred Riem [ 07/Mar/13 ]

Closing because of inactivity





[JAVAMONEY-152] Explore API consistency tools like Revapi and others Created: 11/Sep/15  Updated: 18/Jan/16  Resolved: 18/Jan/16

Status: Resolved
Project: javamoney
Component/s: API, Impl: RI
Affects Version/s: 1.1
Fix Version/s: 1.1

Type: Task Priority: Major
Reporter: keilw Assignee: keilw
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Blocks
blocks JAVAMONEY-136 Broken compatibility with 1.0 Resolved
Tags: api, check, version

 Description   

While Clirr seems to have issues with some Java versions (8?) this tool that also refers to almost every major tool with a similar purpose looks like it's a bit more recent: http://revapi.org/

It also got a Maven plugin, so maybe it could work across the necessary environments more easily.



 Comments   
Comment by keilw [ 29/Dec/15 ]

JApiCmp is another tool which seems a bit more active and with more configuration options, exclude lists, etc.: https://siom79.github.io/japicmp/

Comment by keilw [ 18/Jan/16 ]

Seems done as we identified JAPICmp as best solution.





[JAVAMONEY-151] Does the asType method on RoundedMoney make sense? Created: 28/Aug/15  Updated: 18/Jan/16  Resolved: 18/Jan/16

Status: Resolved
Project: javamoney
Component/s: Impl: RI
Affects Version/s: 1.1
Fix Version/s: 1.1

Type: Bug Priority: Major
Reporter: otaviojava Assignee: otaviojava
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: api, design, format

 Description   

Looking to RoundedMoney class there is a method: asType.
This method isn't of interface and nobody on RI is using this method.



 Comments   
Comment by keilw [ 28/Aug/15 ]

Given the comment

   /*
     * }(non-Javadoc)
     * @see javax.money.MonetaryAmount#asType(java.lang.Class, javax.money.Rounding)
     */

it looks like an older API method. So probably a leftover.

The correct way to do this nevertheless is to mark the method as @deprecated now, remove the misleading JavaDoc reference. And remove it from a future version (possibly 1.0.2 already).
It is a public method of a public class. Apps or even other frameworks using Moneta might be calling it (just look at the "sun.misc.Unsafe" tragedy )

Comment by otaviojava [ 28/Aug/15 ]

Yeah.
I believe the version 1.0.2 will the modularized and cleaner version.

Comment by keilw [ 28/Aug/15 ]

Sure, the point is except for an obvious typo (strictly speaking you'd have to keep the wrong version @deprecated there, too ) we should not rename or delete public methods in API (there it's a NO-GO anyway) or RI.

tck-examples I recently stumbled over one package being called "text" instead of "test", but that is an example or blueprint, not a reusable piece of code, so fixing it there is fairly unproblematic. You call it from the outside via Maven anyway.





[JAVAMONEY-149] Why pseudo-API in the RI? Created: 28/Aug/15  Updated: 18/Jan/16  Resolved: 18/Jan/16

Status: Resolved
Project: javamoney
Component/s: Impl: RI
Affects Version/s: 1.1
Fix Version/s: 1.1

Type: Bug Priority: Major
Reporter: keilw Assignee: otaviojava
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Blocks
is blocked by JAVAMONEY-150 Mutability of MonetaryAmountSymbols Resolved
Tags: api, design, format

 Description   

As we were pushed to this package because it currently breaks in Moneta-BP, a valid question must be raised, if pseudo-API by extending (not implementing) an API interface in the RI is desired at this stage.
MonetaryAmountFormatSymbols extends MonetaryFormat referring to a (highly mutable but there's going to be another issue for that) class MonetaryAmountSymbols.

Actual demand for it has to be revisited and (like a proper JSR) possibly just added as feature request for a future version of the API.



 Comments   
Comment by otaviojava [ 28/Aug/15 ]

This guy is from stackoverflow and money list.
On this way the design put a pseudo-design, I will working to fix it.

Comment by keilw [ 28/Aug/15 ]

Could you quote the stackoverflow link here please?

Comment by otaviojava [ 18/Jan/16 ]

These class was removed.





[JAVAMONEY-13] Abstraction for Currencies Created: 31/Jan/13  Updated: 08/Aug/13  Resolved: 26/Apr/13

Status: Closed
Project: javamoney
Component/s: API
Affects Version/s: 0.3
Fix Version/s: 0.4-EDR1

Type: New Feature Priority: Critical
Reporter: atsticks Assignee: atsticks
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: 0 minutes
Time Spent: Not Specified
Original Estimate: 0 minutes

Tags: Currency, CurrencyUnit, api, multi-curency, time_handling

 Description   

Provide an interface and a value type for a CurrencyUnit, which provides the following functionality:

  • the CurrencyUnit interface modelled does not define any methods for changing the internal state.
  • the value type must be final and immutable, and implement the CurrencyUnit interface.
  • CurrencyUnit may have different namespaces, e.g. 'ISO-4217' (default), but also arbitrary others are supported.
  • the namespace of a CurrencyUnit can be accessed by a corresponding method String getNamespace().
  • a CurrencyUnit must have a unique literal currency code unique within the namespace, accessible by a method String getCurrencyCode().
  • a CurrencyUnit provides the basic non localized methods similar to java.util.Currency for maximal backwards compatibility:
    • int getNumericCode() Gets a numeric currency code. Hereby -1 is returned if no numeric code is available for an instance.
    • int getDefaultFractionDigits(), Gets the number of fractional digits typically used by a currency. -1 is returned if no such value is available for an instance
  • a CurrencyUnit has a time period defined, when it is valid. This is modelled by Long getValidFrom(); and Long getValidUntil();.
    • If no feasible values can be returned, or the currency unit is still valid in the current context, null is returned for the time period methods.
    • the implementation of CurrencyUnit by java.util.Currency should always return null for both methods as a default.
    • SPI implementation may create additional instances of CurrencyUnit also for the ISO-4217 namespace, that reflect the currency duration as defined also by ISO.
  • A CurrencyUnit has a boolean flag if it has a legal tender.
  • Finally a CurrencyUnit can be a real or a virtual currency, modelled by the boolean isVirtual() method.
  • a Currencynit extends AttributeProvider, which allows to provide additional arbitrary attributes. This is required since complex use cases, such as not clearly defined ISO codes and legal tenders may require passing additional information, that can not be fully covered by this JSR.
  • The implementations of CurrencyUnit must implement Comparable<CurrencyUnit>, whereas the interface does not define this requirements due to decoupling aspects.

Access
Instances of CurrencyUnit can be obtained

  • by using the CurrencyProvider available on the Monetary singleton. This allows to support more complex use cases, e.g. classification based access, historic currencies and alternate namespaces.
  • by using the static factory method on java.util.Currency instance (the JDK class must, of course, implement CurrencyUnit.





[JAVAMONEY-1] Eliminate BigMoney Created: 20/Apr/12  Updated: 05/Feb/13  Resolved: 01/Dec/12

Status: Closed
Project: javamoney
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: keilw Assignee: keilw
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: api

 Description   

While from the stub contribution by JodaMoney, the Big* something must not be in the API, at least not the Spec and top level javax.money package.



 Comments   
Comment by keilw [ 01/Dec/12 ]

BigMoney is gone, the base interface (currently named Monetary) is to be implemented by an adequate type like java.util.Money or similar in OpenJDK and similar platforms.





[JAVA_STATE_MANAGEMEN-2] getVersion() method in StateManager might be misnamed Created: 19/Apr/12  Updated: 26/Apr/12

Status: Open
Project: java-state-managemen
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Critical
Reporter: keilw Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: api, naming

 Description   

I noticed, the StateManager has a method getVersion() which actually returns a Collection of String values.
JavaDoc states
/**

  • Retrieve the versions of {@link javax.state.ext.version.VersionableState}

    supported by this manager.
    *

  • @return the collection of versions supported
    */
    Collection<String> getVersion();

Unless the strings are parts of a single version, e.g. Major, Minor, Patch, etc. I believe this should better be called getVersions().



 Comments   
Comment by peteraymond [ 26/Apr/12 ]

Agreed. I suggested getSupportedVersions just before you came on the call.





[HTTP_CLIENT-104] Should HttpBodyFilter be able to return new ByteBuffer instances. Created: 10/Dec/12  Updated: 10/Dec/12

Status: Open
Project: http-client
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Critical
Reporter: chegar Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: api

 Description   

Should HttpBodyFilter be able to return new ByteBuffer instances? This is problematic for response body types where the body is written in user provided buffers. Of course, the client implementation could simply copy the data in any new ByteBuffer instances returned by body filters. This would be very inefficient. There is also the issue where the returned ByteBuffer could contain more data than the user supplied one.






[HK2-69] Add support for @Unqualified annotation Created: 23/Jul/12  Updated: 06/Dec/13  Resolved: 06/Dec/13

Status: Resolved
Project: hk2
Component/s: None
Affects Version/s: 2.1.*
Fix Version/s: 2.1.*

Type: New Feature Priority: Critical
Reporter: Marek Potociar Assignee: jwells
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: api, jersey

 Description   

The annotation should work both with ServiceLocator.getAllServices(...) as well as with IterableProvider.



 Comments   
Comment by jwells [ 24/Sep/12 ]

Implemented





[HK2-66] Merge Descriptor and ActiveDescriptor in the public API Created: 16/Jul/12  Updated: 06/Dec/13  Resolved: 06/Dec/13

Status: Resolved
Project: hk2
Component/s: None
Affects Version/s: 2.1.*
Fix Version/s: 2.1.*

Type: Improvement Priority: Critical
Reporter: Marek Potociar Assignee: jwells
Resolution: Duplicate Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: api, jersey

 Description   

From the end-user perspective the two API classes make no difference and just cause confusion around which one should be used. The differentiation seems to be an internal implementation detail that should be dealt with inside the impl and not exposed to the end users.



 Comments   
Comment by jwells [ 17/Jul/12 ]

Dup of HK2-65





[HK2-65] Merge Descriptor and ActiveDescriptor in the public API Created: 16/Jul/12  Updated: 06/Dec/13  Resolved: 06/Dec/13

Status: Resolved
Project: hk2
Component/s: None
Affects Version/s: 2.1.*
Fix Version/s: 2.1.*

Type: Improvement Priority: Minor
Reporter: Marek Potociar Assignee: jwells
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: api, jersey

 Description   

From the end-user perspective the two API classes make no difference and just cause confusion around which one should be used. The differentiation seems to be an internal implementation detail that should be dealt with inside the impl and not exposed to the end users.



 Comments   
Comment by jwells [ 10/Jun/13 ]

The Descriptor is a representation of the service using only serializable (and simple) fields such as boolean, int an String. ActiveDescriptor is a more complete description of the service but has non-serializable fields such as Class and Annotation. These things are different enough that we will keep them separate.





[HK2-64] Add ServiceLocator.createDynamicConfiguration() convenience method Created: 16/Jul/12  Updated: 06/Dec/13  Resolved: 06/Dec/13

Status: Resolved
Project: hk2
Component/s: None
Affects Version/s: 2.1.*
Fix Version/s: 2.1.*

Type: New Feature Priority: Major
Reporter: Marek Potociar Assignee: jwells
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: api, jersey

 Description   

We have a lot of places where we just repeat the same code:

final DynamicConfigurationService dcs = serviceLocator.getService(DynamicConfigurationService.class);
final DynamicConfiguration dc = dcs.createDynamicConfiguration();

Seems the only use case for working with DCS is really just to create a new configuration. So I'd say the DCS could be hidden as an internal HK2 impl detail and the DC could be directly exposed via ServiceLocator interface:

final DynamicConfiguration dc = serviceLocator.createDynamicConfiguration();


 Comments   
Comment by jwells [ 22/Oct/12 ]

I added this method to ServiceLocatorUtilities





[EJB_SPEC-84] Add getLocale() to javax.ejb.EJBContext with semantics similar to ServletRequest#getLocale() Created: 16/Jan/13  Updated: 05/Apr/13

Status: Open
Project: ejb-spec
Component/s: None
Affects Version/s: 3.2
Fix Version/s: Future version

Type: New Feature Priority: Major
Reporter: ljnelson Assignee: marina vatkina
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: api, ejb

 Description   

Please consider adding the following method to javax.ejb.EJBContext:

/**
 * Returns the caller's preferred {@link Locale}, if available.
 * If no caller {@link Locale} can be determined, then this 
 * method returns the value returned by {@link 
 * Locale#getLocale()}.  This method never returns {@code 
 * null}.
 *
 * @return the {@link Locale} that the caller would prefer
 * any localized content to be generated for, or if no such 
 * {@link Locale} is available, the {@linkplain default
 * Locale</tt> for the system}; never {@code null}
 */
public java.util.Locale getLocale();

Rationale

Many times the business logic inside an EJB needs to know the Locale of its caller. While obviously a Locale can be passed in to any EJB method in its parameter list, a container-provided facility for offering up the caller's Locale automatically would be very convenient.






Generated at Thu Sep 29 06:44:52 UTC 2016 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.