Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Wildfly Support #195

Closed
wants to merge 11 commits into from
Closed

Wildfly Support #195

wants to merge 11 commits into from

Conversation

hantsy
Copy link
Contributor

@hantsy hantsy commented Mar 21, 2021

No description provided.

@hantsy
Copy link
Contributor Author

hantsy commented Mar 21, 2021

@m-reza-rahman About the class- name of data-source in web.xml, in the current code it is set to JDBC driver class name. But WildFly requires a DataSource impl, eg. org.h2.jdbcx.JdbcDataSource there.

In the master of my fork, I also used DataSource implementation class for pg database which works on both Payara and WildFly.

@m-reza-rahman
Copy link
Contributor

This is failing multiple checks. Can you kindly fix that?

@hantsy hantsy force-pushed the wildfly branch 2 times, most recently from f841fc5 to f72d496 Compare March 22, 2021 02:58
@hantsy
Copy link
Contributor Author

hantsy commented Mar 22, 2021

Not sure why the format checking fialed after doing some rebase in the branch.

@hantsy
Copy link
Contributor Author

hantsy commented Mar 22, 2021

The eclipse eca checking is a little strange. When using git commit with -s command line parameter, it failed. Rebase and edit the comment and remove the last empty line, it passed.

I used a Windows 10.

@m-reza-rahman
Copy link
Contributor

I am sorry Hantsy, this has been a tough weekend. I promise I will prioritize this PR next weekend. It will be cool to be able to fully support WildFly and Payara.

Copy link
Contributor

@m-reza-rahman m-reza-rahman left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please address these issues. The PR looks otherwise reasonable.


You can do that with the following script:
```shell script
wget https://download.jboss.org/wildfly/23.0.0.Final/wildfly-23.0.0.Final.zip
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Let's kindly investigate using WildFly embedded for the Arquillian tests. That should be possible unlike Payara.

@@ -13,7 +12,11 @@
@Override
public Map<String, Object> getProperties() {
Map<String, Object> properties = new HashMap<String, Object>();
properties.put(ServerProperties.BV_SEND_ERROR_IN_RESPONSE, true);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why is changing this necessary? Are the Jersey classes conflicting with RESTEasy? How about the other way around?

Copy link
Contributor Author

@hantsy hantsy Apr 5, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The class ServerProperties is not available in WildFly/Resteasy.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I was wondering what would happen if we just included the Jersey dependency in the class-path. Also, is there a RESTEasy version of this? In which case we need to add that too?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For a real portable solution, I think it is better to write an ExceptionMapper for it.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Resteasy could have its solution for bean validation processing.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Converted to text literal, to avoid Class not found exception under WildFly/Resteasy.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You can leave this as-is. I will handle it after merge, no problem.

@@ -168,7 +168,7 @@ public boolean equals(Object object) {
if (this == object) {
return true;
}
if (object == null || getClass() != object.getClass()) {
if (object == null || !(object instanceof Cargo)) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Let's decouple these into a separate PR in the master branch to reduce clutter here and focus on the actual portability changes.

Copy link
Contributor Author

@hantsy hantsy Apr 7, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If this is moved to a separate PR, this should be extracted firstly and be merged before the WildFly pr, in Hibernate entity comparation depends on this.

@@ -28,6 +29,7 @@
import org.eclipse.cargotracker.interfaces.booking.facade.internal.assembler.LocationDtoAssembler;

@ApplicationScoped
@Transactional
Copy link
Contributor

@m-reza-rahman m-reza-rahman Apr 4, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I understand this is a way to avoid Hibernate lazy instantiation issues. However, this approach is a bit of a hack and counter to separation of concerns in DDD. There should be no reason for this to be transactional other than dealing with Hibernate. Instead, let us do a bit deeper domain analysis and see if lazy loading can be avoided altogether, probably using entity graphs. In the layers above the repository layer, you can introduce "load...For..." methods that are domain case specific. Ideally, this could extend to the repository layer as well. If not, you can introduce a finder parameter such as "LOAD_FULLY", "LOAD_PARTIALLY" or "LOAD_MINIMALLY" that maps to various entity graphs in the repository layer. This technique will keep things portable with Hibernate and still maintain proper layering instead of leaking data loading concerns into the business and UI tiers. Let me know if this all makes sense or we can discuss it in more detail. You can look at some further discussion here: #33.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Currently, this is the simplest approach to avoid the lazy exception. As mentioned in #33 maybe define @entitygraph is the better solution. But for before experience, like what do in JBoss Seam, or Apache DeltaSpike(I do not remember the details), there is a generic open session in view like solution to apply to JSF request lifecycle.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I really hate to say this, but I don't think we can have that approach in a DDD focused project. Do you think you could take some time to address this please? That would be awesome!

@@ -1,8 +1,13 @@
<!DOCTYPE html>
<html xmlns="http://www.w3.org/1999/xhtml"
xmlns:h="http://java.sun.com/jsf/html"
xmlns:f="http://java.sun.com/jsf/core"
xmlns:h="http://xmlns.jcp.org/jsf/html"
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please incorporate this into a separate PR against the master branch. That will reduce clutter here and keep things focused on portability.

Copy link
Contributor Author

@hantsy hantsy Apr 7, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

OK, I just noticed this file when cleaning the backed bean, not clean all xmlns in facelets templates. Move to a separate PR is ok, could clean all xmlns there.

@m-reza-rahman m-reza-rahman deleted the branch eclipse-ee4j:develop April 9, 2021 19:16
@hantsy hantsy deleted the wildfly branch April 18, 2021 02:55
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants