-
Notifications
You must be signed in to change notification settings - Fork 143
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
Wildfly Support #195
Conversation
Signed-off-by: Akira Kawauchi <[email protected]>
Signed-off-by: Akira Kawauchi <[email protected]>
@m-reza-rahman About the In the master of my fork, I also used |
This is failing multiple checks. Can you kindly fix that? |
f841fc5
to
f72d496
Compare
Not sure why the format checking fialed after doing some rebase in the branch. |
The eclipse eca checking is a little strange. When using I used a Windows 10. |
Signed-off-by: Akira Kawauchi <[email protected]>
Move coordinates constants of public/mapFrame.xhtml to server-side
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. |
There was a problem hiding this 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 |
There was a problem hiding this comment.
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); |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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)) { |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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 |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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" |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
Signed-off-by: Hantsy Bai <[email protected]>
Signed-off-by: Hantsy Bai <[email protected]>
Signed-off-by: Hantsy Bai <[email protected]>
No description provided.