rico-projects / rico

Main repository for the Rico Application Framework

⚠️ IMPORTANT: ⚠️ Rico has been put "on hold". To learn what is meant by that please read the blog post and feel free to contact us via [email protected] to clarify open questions.

Rico

This repository contains all Java related sources of Rico. Clients for other languages will be provided in seperate repositories (JavaScript, AngularJS, Polymer and Android).

This project joined Hacktoberfest 2020! Issues that can give you a good start are have the label "Hacktoberfest" and maintainers are willing to help.

About Rico

Rico is a client-server-framework that provides several functionalities and APIs to create enterprise applications. This includes features like tracing pr monitoring that are critical in developing applications, escpecially in modern cloud based and distributed application landscapes. To do so the Rico provides generic APIs with specific implementation for the mostly used frameworks and toolkits in modern application development.

Rico provides implementations for all its features for the given frameworks on the server:

• JavaEE / JakartaEE
• Spring (Boot)

Next to tis Rico provides implementations for the following ui toolkits and languages.

• Plain Java client
• JavaFX
• JavaScript client (external repo)
• Polymer 2 client (external repo)
• AngularJS (1.x) client (external repo)
• Angular (>2.x) client (external repo)

Features of Rico

As already mentioned Rico provides a list of general features that are usefull in mostly all enterprise applications. A detailed description of the features will be part of the future technical documentation of Rico. Until now Rico provides APIs for the following functionalities:

• client scope / session
• ui toolkit friendly http client
• application management
• general context manager
• metrics handling
• server timing
• security and sso
• remoting
• logging
• projection
• tracing

An introduction of Rico can be found in the Karakun DevHub.

Issues

Please note that this repository is the main repository for all rico modules. Currently, we maintain some modules (especially the JavaScript libraries) in separate repos. To keep it easer to get an overview of the issues, we track all of them in this repository.

Development

To get an overview about the project structure, please look at the repective chapter in our documentation.

Also, please refer to the CODE_OF_CONDUCT.md, CONTIBUTING.md and JAVA_STYLE_GUIDE.md .

Development origin

The Rico framework is the successor of the Dolphin Platform that provided functionality like an asynchronous remoting layer for enterprise applications based on generic APIs. While Rico shares the general idea of the Dolphin Platform it provides a lot more functionality.

🆕🐥🐶 First Timers Support

At Karakun we ❤️ open source. Based on this we develop the complete Rico framework as an open source project. If you are new to open source development we have some specific issues for you. Just have a look at all issues with the 'good first issue' label. This issues are reserved for people who never contributed to Open Source before. We know that the process of creating a pull request is the biggest barrier for new contributors. This issues are for you 💝 We use such issues for example to get involved at Hacktoberfest. If you want to know more about open source development and contribution in general you should have a look at this overview.

License

The project is released as open source under the Apache License Version 2.0

rico's Issues

Byte[] support in model by adding ConverterFactory implementation

🆕🐥 First Timers Only

This issue is reserved for people who never contributed to Rico or Open Source before. We know that the process of creating a pull request is the biggest barrier for new contributors. This issue is for you 💝

👾 Description of the issue

To support different data types in the model layer of the remoting modules Rico provides an SPI that is defined by the ConverterFactory interface. For this one an implementation for byte[] support is still missing.

📋 Step by Step

To solve this issue and contribute a fix you should check the following step-by-step list. A more detailed documentation of the workflow can be found here.

• Claim this issue: Comment below.
• Fork the repository in github by simply clicking the 'fork' button.
• Check out the forked repository
• Create a feature branch for the issue. We do not have any naming definition for branches.
• Commit your changes.
• Start a Pull Request.
• Done 👍 Ask in comments for a review :)
• If the reviewer find some missing peaces or a problem he will start a discussion with you and describe the next steps how the problem can be solved.
• You did it 🎉 We will merge the fix in the master branch.
• Thanks, thanks, thanks for being part of this project as an open source contributor ❤️

🎉 Contribute to Hacktoberfest

Solve this issue as part of the Hacktoberfest event and get a change to receive cool goodies like a T-Shirt. 🎽

🤔❓ Questions

If you have any questions just ask us directly in this issue by adding a comment. Next to this you can find a general manual about open source contributions here.

Issue-Import-Test

Issue by hendrikebbers
Friday Jan 22, 2016 at 14:19 GMT
Originally opened as https://github.com/canoo/dolphin-platform/issues/17

---

Example:

CompleteableFuture f = ...
f.get(); <- this can end in a deadlock

f.get(10, SECONDS); <- this is much better

the timeout should be configured in the ClientConfiguration

Date conversion uses different timezones for both directions

LocalDateConverterFactory uses UTC on one side and local timezone on the other side.

Adding . editorconfig file

🆕🐥 First Timers Only

This issue is reserved for people who never contributed to Rico or Open Source before. We know that the process of creating a pull request is the biggest barrier for new contributors. This issue is for you 💝

👾 Description of the issue

We should add a .editorconfig file to the rico repositories. See https://editorconfig.org/ for the definition. A good solution can be found in https://github.com/adoptopenjdk/IcedTea-Web

📋 Step by Step

To solve this issue and contribute a fix you should check the following step-by-step list. A more detailed documentation of the workflow can be found here.

• Claim this issue: Comment below.
• Fork the repository in github by simply clicking the 'fork' button.
• Check out the forked repository
• Create a feature branch for the issue. We do not have any naming definition for branches.
• Commit your changes.
• Start a Pull Request.
• Done 👍 Ask in comments for a review :)
• If the reviewer find some missing peaces or a problem he will start a discussion with you and describe the next steps how the problem can be solved.
• You did it 🎉 We will merge the fix in the master branch.
• Thanks, thanks, thanks for being part of this project as an open source contributor ❤️

🎉 Contribute to Hacktoberfest

Solve this issue as part of the Hacktoberfest event and get a change to receive cool goodies like a T-Shirt. 🎽

🤔❓ Questions

If you have any questions just ask us directly in this issue by adding a comment. Next to this you can find a general manual about open source contributions here.

Fix release build and version numbers

We need to revisit the release build.

• Make sure the right version is used in all parts of the build
• Make sure the right version is checked into git

Places the version is currently used

• /gradle.properties
• /base/rico-core/src/main/resources/build.properties

While at it:

• Maybe take the version and other info from the Manifest instead of the build.properties

Issue-Import-Test

From @hastebrot on May 7, 2018 6:31

Google will release Polymer 3 at Google I/O 2018 this week (conference sessions on May 9th). With Polymer 3 we'll still have the option to use <remoting-controller> as mixin for PolymerElement. But the stated goal of the Polymer team it to allow lighter and more loosely coupled elements, hence they'll introduce LitElement (headed for 1.0 release in the coming months). This new Web Component base class will be the successor of PolymerElement.

To support PolymerElement in Polymer 3 we probably have to additionally provide <remoting-controller> on npm registry. It would also be nice if the element is converted to JavaScript modules, though still using HTML imports should still be fine. The PolymerElement will not see active development in the future.

To support LitElement in Polymer 3 we'd have to rethink how Dolphin Platform communicates changes to this base class. It will get rid of the Polymer data system and template stamping (no property effects with set() and splice(), no templates with two-way bindings). The Polymer team suggests to use Redux state store instead, but also says with LitElement you should be free for more different options.

Copied from original issue: canoo/dolphin-platform#908

Provide Hash-function for Download-Input Stream

leftover from #79

@hendrikebbers please extend some information what needs to be done

Issue-Import-Test

From @joha78 on May 24, 2018 15:11

In keycloakConnection.createServerProxyConnection() is the parameter for "realmName" missing. The realmName should be added as request header in keycloakConnection.createServerProxyConnection().

The missed header is named: X-platform-security-realm

With best regards
Jörg

Copied from original issue: canoo/dolphin-platform#910

Issue-Import-Test

Issue by gemaSantiago
Monday Jan 25, 2016 at 13:09 GMT
Originally opened as https://github.com/canoo/dolphin-platform/issues/24

---

It's possible to can refactor the unit tests of the event bus based on this lib.
https://github.com/jayway/awaitility

(Talk to Andres)

Rico-JS, Rico-Angular: Move functionality to Rico-JS.

Some functionality implemented in Adapter libraies belongs into Rico-JS as it's required for every client.
These are

• #45
• #46

By this issue, that functionality should be moved into RicoJS and thus fix problems for every other client (e.g. Polymer)

Rico-Angular: Using multiple controllers duplicates model entries

When adding a second controller to the rico-samples project and using that in the angular client, the list items of the todo list are duplicated.
This happens only on the client side, the model on the server stays as intented.

Issue-Import-Test

From @hendrikebbers on March 28, 2018 13:36

Currently we only have unix based scripts.
See: https://github.com/canoo/dolphin-platform-examples/tree/master/simple-security/keycloak-container

Copied from original issue: canoo/dolphin-platform#889

Issue-Import-Test

Issue by aalmiray
Thursday Feb 04, 2016 at 17:30 GMT
Originally opened as https://github.com/canoo/dolphin-platform/issues/77

---

FxBinder establishes a soft binding (via listeners) between a DP property and a JavaFX property. Most of the times the JavaFX property belongs to an UI widget. It would simplify matters for a developer if all updates flowing from a DP property to a JavaFX property happened inside the UI thread.

Currently the updates happen inside the same thread that updated the DP property, which is is the UI thread for now, but that's a different design issue one level down enforced by Open Dolphin.

Perhaps FXBinder could have a setting that lets the developer define if they want the update to happen inside the UI thread or not, to keep behavior compatibility.

Issue-Import-Test

From @hendrikebbers on April 5, 2018 9:16

This is how the logo looks like:

Copied from original issue: canoo/dolphin-platform#895

Issue-Import-Test

Issue by gemaSantiago
Monday Jan 25, 2016 at 13:29 GMT
Originally opened as https://github.com/canoo/dolphin-platform/issues/33

---

Check old Remoting branches

One of the next goals for rico will be a new internal Remoting layer. 2 branches already contain improvements in that area:

• message-pack
• legacy-removed

There are several other branches like 'legacy-removed-3'. Currently I have no idea about the content of such branches.

Issue-Import-Test

Issue by gemaSantiago
Monday Jan 25, 2016 at 13:37 GMT
Originally opened as https://github.com/canoo/dolphin-platform/issues/36

---

Components : dolphin-js

Way to discover @RemotingAction(s) on Controller

Would like to see a way to get a list of available actions in the ProxyController/Client. This would allow us to verify Action bindings in DukeScript / Dolphin applications.

SpringJUnitControllerTest is not using Junit 5

🆕🐥 First Timers Only

This issue is reserved for people who never contributed to Rico or Open Source before. We know that the process of creating a pull request is the biggest barrier for new contributors. This issue is for you 💝

👾 Description of the issue

After #79 and the update to recent spring versions, The class SpringJUnitControllerTest should be base on JUnit 5.

📋 Step by Step

To solve this issue and contribute a fix you should check the following step-by-step list. A more detailed documentation of the workflow can be found here.

• Claim this issue: Comment below.
• Fork the repository in github by simply clicking the 'fork' button.
• Check out the forked repository
• Create a feature branch for the issue. We do not have any naming definition for branches, but it doesn't hurt if it contains the issue number.
• Commit your changes.
• Start a Pull Request.
• Done 👍 Ask in comments for a review :)
• If the reviewer find some missing pieces or a problem he will start a discussion with you and describe the next steps how the problem can be solved.
• You did it 🎉 We will merge the fix in the master branch.
• Thanks, thanks, thanks for being part of this project as an open source contributor ❤️

🎉 Contribute to Hacktoberfest

Solve this issue as part of the Hacktoberfest event and get a change to receive cool goodies like a T-Shirt. 🎽

🤔❓ Questions

If you have any questions just ask us directly in this issue by adding a comment. Next to this you can find a general manual about open source contributions here.

Issue-Import-Test

From @hastebrot on May 7, 2018 6:31

Google will release Polymer 3 at Google I/O 2018 this week (conference sessions on May 9th). With Polymer 3 we'll still have the option to use <remoting-controller> as mixin for PolymerElement. But the stated goal of the Polymer team it to allow lighter and more loosely coupled elements, hence they'll introduce LitElement (headed for 1.0 release in the coming months). This new Web Component base class will be the successor of PolymerElement.

To support PolymerElement in Polymer 3 we probably have to additionally provide <remoting-controller> on npm registry. It would also be nice if the element is converted to JavaScript modules, though still using HTML imports should still be fine. The PolymerElement will not see active development in the future.

To support LitElement in Polymer 3 we'd have to rethink how Dolphin Platform communicates changes to this base class. It will get rid of the Polymer data system and template stamping (no property effects with set() and splice(), no templates with two-way bindings). The Polymer team suggests to use Redux state store instead, but also says with LitElement you should be free for more different options.

Copied from original issue: canoo/dolphin-platform#908

Issue-Import-Test

From @hendrikebbers on May 24, 2018 9:22

The DateConverter of DP uses a SimpleDateFormat instance internally. This instance is used for all convert calls. Since all DateConverters are singletons the same SimpleDateFormat instance will be used for all calls. On the server this means that the same instance will be reused for all clients.

The problem here ist, that the SimpleDateFormat instance can not be used in parallel. Therefore we need to refactor the factory to create a new instance with each call or use thread local instances. More info can be found here: http://blog.udby.com/archives/164

Copied from original issue: canoo/dolphin-platform#909

Issue-Import-Test

Issue by netopyr
Thursday Feb 04, 2016 at 15:43 GMT
Originally opened as https://github.com/canoo/dolphin-platform/issues/75

---

In Open Dolphin each presentation model is unique and thus contains all meta-information.

The Dolphin Platform maps objects onto presentation models. As we often have several instances of the same class, we are currently sending the same kind of meta-information over and over again. Instead we should introduce something like a presentation model blue print for a DolphinBean which is sent only once. When we create another instance of that DolphinBean, we can simply refer to the blue print and use its meta-data.

Add git commit hash to MANIFEST.MF file.

🆕🐥 First Timers Only

This issue is reserved for people who never contributed to Rico or Open Source before. We know that the process of creating a pull request is the biggest barrier for new contributors. This issue is for you 💝

👾 Description of the issue

Add git commit hash to MANIFEST.MF file.
It would be very nice to include the git commit from which a jar file was built into its MANIFEST.MF file.

The task is to use "net.nemerosa.versioning" or another gradle plugin to make the git commit has available at build time.
Then as the second step include the git commit hash in the MANIFEST.MF
The content of the MANIFEST.MF is defined in the build.gradle file.

📋 Step by Step

To solve this issue and contribute a fix you should check the following step-by-step list. A more detailed documentation of the workflow can be found here.

• Claim this issue: Comment below.
• Fork the repository in github by simply clicking the 'fork' button.
• Check out the forked repository
• Create a feature branch for the issue. We do not have any naming definition for branches.
• Commit your changes.
• Start a Pull Request.
• Done 👍 Ask in comments for a review :)
• If the reviewer find some missing peaces or a problem he will start a discussion with you and describe the next steps how the problem can be solved.
• You did it 🎉 We will merge the fix in the master branch.
• Thanks, thanks, thanks for being part of this project as an open source contributor ❤️

🎉 Contribute to Hacktoberfest

Solve this issue as part of the Hacktoberfest event and get a change to receive cool goodies like a T-Shirt. 🎽

🤔❓ Questions

If you have any questions just ask us directly in this issue by adding a comment. Next to this you can find a general manual about open source contributions here.

Issue-Import-Test

From @hendrikebbers on May 25, 2018 9:38

DolphinContext.destroy() should be called on client session timeout.

Copied from original issue: canoo/dolphin-platform#911

Security: Allow all key cloak realms

At the moment a list of allowed key cloak realms must be specified in the Rico configuration. We should add a flag that allows any realm.

Issue-Import-Test

Issue by giftkugel
Friday Mar 16, 2018 at 09:18 GMT
Originally opened as https://github.com/canoo/dolphin-platform/issues/872

---

Hi,

we need more tests for the AngularJS client.

Regards
Simon

Related to #614

Security: NPE if user has no roles

🆕🐥 First Timers Only

This issue is reserved for people who never contributed to Rico or Open Source before. We know that the process of creating a pull request is the biggest barrier for new contributors. This issue is for you 💝

👾 Description of the issue

UserKeycloakImpl.getRoles() throws a NPE if the user has no roles.

public Set<String> getRoles() {

    return Collections.unmodifiableSet(this.keycloakSecurityContext.getToken().getRealmAccess().getRoles());

}

It's because KeycloakSecurityContext.getToken().getRealmAccess() return null. It would be better if it would return an empty list.

📋 Step by Step

To solve this issue and contribute a fix you should check the following step-by-step list. A more detailed documentation of the workflow can be found here.

• Claim this issue: Comment below.
• Fork the repository in github by simply clicking the 'fork' button.
• Check out the forked repository
• Create a feature branch for the issue. We do not have any naming definition for branches.
• Commit your changes.
• Start a Pull Request.
• Done 👍 Ask in comments for a review :)
• If the reviewer find some missing peaces or a problem he will start a discussion with you and describe the next steps how the problem can be solved.
• You did it 🎉 We will merge the fix in the master branch.
• Thanks, thanks, thanks for being part of this project as an open source contributor ❤️

🎉 Contribute to Hacktoberfest

Solve this issue as part of the Hacktoberfest event and get a change to receive cool goodies like a T-Shirt. 🎽

🤔❓ Questions

If you have any questions just ask us directly in this issue by adding a comment. Next to this you can find a general manual about open source contributions here.

Issue-Import-Test

Issue by giftkugel
Friday Mar 16, 2018 at 09:18 GMT
Originally opened as https://github.com/canoo/dolphin-platform/issues/872

---

Hi,

we need more tests for the AngularJS client.

Regards
Simon

Related to #614

Rico-Angular: Instanciating multiple controllers "at the same time" mixes up the model references

When multiple controllers are created "at the same time", meaning timely very close to eeach other, the model references of these controllers are mixed up.

Some investigation has shown that this is related to the highlanderPM used in RicoJS tohandle model instanciation. (see https://github.com/rico-projects/rico-js/blob/29f12ed97c1701b77b2c8e0beecca8576f39bdcd/src/remoting/controllerManager.js#L53) .

Issue-Import-Test

From @netopyr on June 16, 2016 8:38

We need to access some meta-information about Dolphin properties. For a start the owning bean and the property name would be sufficient.

Copied from original issue: canoo/dolphin-platform#198

JavaDoc: @Param for generics produces warning

Leftover from #79

see DataService.java for possible improvement

Improve directory structure

The directory structure is a bit weird and should be changed into a better structure.

Suggestion

├── docs
│   └── images (merge content of metadata and readme)
└── modules (all source files of the project)
    ├── core
    │   ├── *
    │   ├── extensions
    │   └── incubation
    └── modules
        ├── remoting
        ├── security
        └── incubation
├── tools (formerly known as scripts)
└── test
    └── integration

clarify FIXME comment in TestClientConnectorImpl

Clarify the FIXME comment in https://github.com/rico-projects/rico/pull/112/files#diff-c9675d8780364c543c2d172ad6f47deeR81

and add a test impl if the change should be integrated as asked in the comment

Check old branches

Several branches might have a good & small change that would make sense to be merged / added before we continue with new functionality. We should check the following branches:

• observer-in-core
• eventbus-model

Rico version is not shown correctly in banner

🆕🐥 First Timers Only

This issue is reserved for people who never contributed to Rico or Open Source before. We know that the process of creating a pull request is the biggest barrier for new contributors. This issue is for you 💝

👾 Description of the issue
During startup in a SpringBoot application, Rico prints out an ANSI banner that should also contain it's version, but it shows only $version.

📋 Step by Step

To solve this issue and contribute a fix you should check the following step-by-step list. A more detailed documentation of the workflow can be found here.

• Claim this issue: Comment below.
• Fork the repository in github by simply clicking the 'fork' button.
• Check out the forked repository
• Create a feature branch for the issue. We do not have any naming definition for branches.
• Commit your changes.
• Start a Pull Request.
• Done 👍 Ask in comments for a review :)
• If the reviewer find some missing peaces or a problem he will start a discussion with you and describe the next steps how the problem can be solved.
• You did it 🎉 We will merge the fix in the master branch.
• Thanks, thanks, thanks for being part of this project as an open source contributor ❤️

🎉 Contribute to Hacktoberfest

Solve this issue as part of the Hacktoberfest event and get a change to receive cool goodies like a T-Shirt. 🎽

🤔❓ Questions

If you have any questions just ask us directly in this issue by adding a comment. Next to this you can find a general manual about open source contributions here.

External repository links for client library implementations in README are pointing to a wrong URL

🆕🐥 First Timers Only

This issue is reserved for people who never contributed to Rico or Open Source before. We know that the process of creating a pull request is the biggest barrier for new contributors. This issue is for you 💝

👾 Description of the issue

In the README.md#L34-L37 external repository links for JavaScript, Polymer 2, AngularJS and Angular are pointing to the wrong URL. They all point to:
https://github.com/rico-project/$REPO_NAME the correct URL is:
https://github.com/rico-projects/$REPO_NAME

📋 Step by Step

To solve this issue and contribute a fix you should check the following step-by-step list. A more detailed documentation of the workflow can be found here.

• Claim this issue: Comment below.
• Fork the repository in Github by simply clicking the 'fork' button.
• Check out the forked repository
• Create a feature branch for the issue. We do not have any naming definition for branches.
• Commit your changes.
• Start a Pull Request.
• Done 👍 Ask in comments for a review :)
• If the reviewer find some missing peaces or a problem he will start a discussion with you and describe the next steps how the problem can be solved.
• You did it 🎉 We will merge the fix in the master branch.
• Thanks, thanks, thanks for being part of this project as an open source contributor ❤️

🎉 Contribute to Hacktoberfest

Solve this issue as part of the Hacktoberfest event and get a change to receive cool goodies like a T-Shirt. 🎽

🤔❓ Questions

If you have any questions just ask us directly in this issue by adding a comment. Next to this you can find a general manual about open source contributions here.

Double.NEGATIVE_INFINITY won't be transferred correctly by remoting

private Property<Double> prefWidth;
prefWidth.set(Region.USE_PREF_SIZE);

Using Region.USE_PREF_SIZE (== Double.NEGATIVE_INFINITY) is important for the rico-projector. It results in this exception but should not:

Caused by: java.lang.ClassCastException: java.lang.String cannot be cast to java.lang.Number
	at dev.rico.internal.remoting.converters.DoubleConverterFactory$1.convertFromRemoting(DoubleConverterFactory.java:32) ~[rico-remoting-common-1.0.1.jar:na]
	at dev.rico.internal.remoting.info.PropertyInfo.convertFromRemoting(PropertyInfo.java:46) ~[rico-remoting-common-1.0.1.jar:na]
	at dev.rico.internal.remoting.PropertyImpl$1.propertyChange(PropertyImpl.java:54) ~[rico-remoting-common-1.0.1.jar:na]

Issue-Import-Test

From @joha78 on April 1, 2018 20:33

This is not really an issue, but in the client it is not distinguishable whether

security.login(user, password)

failed because the keycloak server is down or because the password was wrong because both cases report the same Exception / message.

Copied from original issue: canoo/dolphin-platform#894

Issue-Import-Test

From @joha78 on May 28, 2018 7:29

Aktuellste Version mit "dynamische (client managed) Realm" aktiviert.

Wenn vom Server etwas vom Client gesendet wird, dann kommt es im Client in der falschen View raus.

Das führt zu solchen Meldungen:
2018-05-28 01:48:33.766 [ERROR] RemotingController MAIN_VIEW_CONTROLLER Bean not found in model! {destinationCity: “Rom”, departureCity: “Hamburg”, …..

Das Merkwürdige daran, die Daten die angeblich in MAIN_VIEW_CONTROLLER landen sollen, sind tatsächlich für eine ganz andere View, also einen ganz anderen Controller, bestimmt.

Der Controller hat ja ein init(), welches Model-Modifikationen an den Client weitergibt. Da ist noch alles ok. Wenn ich dann aber später etwas sende, z.B aus einer Server-Action heraus, dann kommt es im Client nicht mehr an der richtigen Stelle an.

Copied from original issue: canoo/dolphin-platform#912

apply new package structure to test packages

🆕🐥 First Timers Only

This issue is reserved for people who never contributed to Rico or Open Source before. We know that the process of creating a pull request is the biggest barrier for new contributors. This issue is for you 💝

👾 Description of the issue

The new package structure introduces with #79 was not applied to the contents of test/ in all modules. These should be aligned. Therefore all test packages that are not aligned to the packages under main/ should be refactored. The following image gives an example of the rico-remoting-server module that provides the dev.rico.remoting.server as package under main/ but dev.rico.server.remoting as package under test/.

📋 Step by Step

To solve this issue and contribute a fix you should check the following step-by-step list. A more detailed documentation of the workflow can be found here.

• Claim this issue: Comment below.
• Fork the repository in github by simply clicking the 'fork' button.
• Check out the forked repository
• Create a feature branch for the issue. We do not have any naming definition for branches, but it doesn't hurt if it contains the issue number ;-)
• Commit your changes.
• Start a Pull Request.
• Done 👍 Ask in comments for a review :)
• If the reviewer finds some missing pieces or a problem he will start a discussion with you and describe the next steps how the problem can be solved.
• You did it 🎉 We will merge the fix in the master branch.
• Thanks, thanks, thanks for being part of this project as an open source contributor ❤️

🎉 Contribute to Hacktoberfest

Solve this issue as part of the Hacktoberfest event and get a change to receive cool goodies like a T-Shirt. 🎽

🤔❓ Questions

If you have any questions just ask us directly in this issue by adding a comment. Next to this you can find a general manual about open source contributions here.

Issue-Import-Test

Issue by aalmiray
Thursday Feb 04, 2016 at 16:26 GMT
Originally opened as https://github.com/canoo/dolphin-platform/issues/76

---

All calls to ClientContext.createControllerProxy share the same singleton bean InternalAttributesBean. When several calls to this method are issued there's the chance of a race condition, with the effect that a controllerProxy will see the model of another controller or its id, instead of the model and id it should have.

This design leads into CCE down the road, whenever a simple call such as MyBean bean = controllerProxy.getModel() is issued. The application may complain that the proxy's model may not be casted to the expected class MyBean.

JavaDoc is missing internal links

after #79, JavaDoc is missing internal links.

Issue-Import-Test

Issue by gemaSantiago
Monday Jan 25, 2016 at 13:05 GMT
Originally opened as https://github.com/canoo/dolphin-platform/issues/22

---

Andres:
I'd suggest to move this dependency to the constructor and annotate the constructor with @Inject. In a DI ready environment the dependency will be resolved automatically. In a non DI environment then the dependency must be set manually. Right now I think DP assumes controllers have a no-args constructor and instantiates them accordingly. In a DI environment DP can obtain a controller instance from the DI injector. In a non-DI environment DP will directly instantiate the controller. DP may have a couple of factory classes that helps it create instances of DolphinEventBus and controllers. It should know it's running on DI or not so that it can use the right strategy.
Hendrik:
Currently there is a factory method to create Controller instances. It is implemented in the spring and JEE module. Both modules provides DolphinEventBus and BeanManager as beans that can be injected. Using @Inject here will help us defining the unitTests by just creating a new ImplInstance (that can than have a public constructor). I will check this later and create a new feature commit for it. So we won't change it in this review, ok?

Better error handling in ClientSessionLifecycleHandlerImpl

In onSessionCreated and onSessionDestroyed we iterate over a listener list. If an exception is thrown in one listener no other lister will be handled. Especially in that case the framework should try to call all listeners and rethrow exceptions afterwards.

Issue-Import-Test

Issue by netopyr
Monday Feb 01, 2016 at 14:51 GMT
Originally opened as https://github.com/canoo/dolphin-platform/issues/70

---

When the client is not connected (during initialization and during a disconnect), we should queue all requests and send them once the connection is back.

Not sure if this can be done or if it gets too complicated as there can be changes piling up on client and server side. We need to try.

Issue-Import-Test

Issue by gemaSantiago
Monday Jan 25, 2016 at 12:52 GMT
Originally opened as https://github.com/canoo/dolphin-platform/issues/21

---