rico-projects / rico Goto Github PK

🆕🐥 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 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

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

🆕🐥 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.

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

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)

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

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.

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

after #79, JavaDoc is missing internal links.

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.

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]

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)

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

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

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.

🆕🐥 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 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.

🆕🐥 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.

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

🆕🐥 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.

From @hendrikebbers on April 5, 2018 9:16

This is how the logo looks like:

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

🆕🐥 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.

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

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 by gemaSantiago
Monday Jan 25, 2016 at 12:52 GMT
Originally opened as https://github.com/canoo/dolphin-platform/issues/21

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

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

leftover from #79

@hendrikebbers please extend some information what needs to be done

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) .

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

🆕🐥 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.

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.

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

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 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.

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

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

🆕🐥 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 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

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.

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?

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

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.

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.

Leftover from #79

see DataService.java for possible improvement