[JBoss JIRA] (JBIDE-23352) Deploy Docker Wizard: Default routing port selection need more info for users
by Jeff MAURY (JIRA)
[ https://issues.jboss.org/browse/JBIDE-23352?page=com.atlassian.jira.plugi... ]
Jeff MAURY commented on JBIDE-23352:
------------------------------------
Exposing ports in dockerfile is informational only. So you could imaging deploying an image that is listening on certain ports but not exposed in the docker file. So user may want to create a service on those ports
> Deploy Docker Wizard: Default routing port selection need more info for users
> -----------------------------------------------------------------------------
>
> Key: JBIDE-23352
> URL: https://issues.jboss.org/browse/JBIDE-23352
> Project: Tools (JBoss Tools)
> Issue Type: Enhancement
> Components: openshift
> Affects Versions: 4.4.1.AM2
> Reporter: Marián Labuda
> Labels: deploy_docker_wizard, openshift_v3
> Fix For: 4.4.2.Final
>
> Attachments: no_route_selected.png, refdoc-services-1.png, refdoc-services-2.png, webui-deploy-docker-image.png
>
>
> In the wizard on wizard page Services & Routing Settings, there is a table with mapped ports. No port is selected by default , but OpenShift knows what to open.
> If there is only one port mapping, we could check it by default. If there are more port mappings, we could show a label/info/description what is gonna be done under the hood, so users will know what is happening.
> steps to reproduce:
> # EXEC: In Docker Explroer: pick an image and choose "Deploy to OpenShift..." in the context menu
> # EXEC: get to the "Services & Routing Settings" page
> !no_route_selected.png!
> It's not obvious to the user what the wizard will create: A service that "exposes" pod ports and a route that points to this service. Furthermore it's not obvious that without a "checked" (used by route) port, the route will round-robin through the available ports. Additionally we should show the user what ports are exposed by the pod, and which ones are ports that the user added while no explicit exposure is defined in the pod (so he's on his own, if there's nothing listening on them he'll have users face non-functional or no reposonses at all).
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 5 months
[JBoss JIRA] (JBIDE-23149) Reverse engineering strategy cannot be set to custom class if generation target is Hibernate 5.x
by Koen Aers (JIRA)
[ https://issues.jboss.org/browse/JBIDE-23149?page=com.atlassian.jira.plugi... ]
Koen Aers updated JBIDE-23149:
------------------------------
Fix Version/s: 4.4.2.Final
(was: 4.4.2.AM3)
> Reverse engineering strategy cannot be set to custom class if generation target is Hibernate 5.x
> ------------------------------------------------------------------------------------------------
>
> Key: JBIDE-23149
> URL: https://issues.jboss.org/browse/JBIDE-23149
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: hibernate
> Affects Versions: 4.4.0.Final
> Reporter: Antal Varga
> Assignee: Koen Aers
> Fix For: 4.4.2.Final
>
> Attachments: BaseReverseEngineeringStrategy.java, RMAReverseEngineeringStrategy.java
>
>
> The reason for that is the change in ServiceImpl.java in org.jboss.tools.hibernate.runtime.v_5_0*.jar or later.
> private Object newReverseEngineeringStrategy(String className, Object delegate) {...}
> tries to load class using the class loader of the delegate object at first which is *org.hibernate.cfg.reveng.OverrideRepository* and resides in *hibernate-tools-x.yy.jar*.
> The main problem is that while in case of the earlier Hibernate generation targets (e.g. 4.3) the reverse engineering strategy class loading was done by *org.hibernate.util.xpl.ReflectHelper* (and worked well), this option
> happens only as a fallback case now *BUT this only happens if the constructor has not been found* (only NoSuchMethodException is caught).
> Therefore a reverse engineering strategy can only be loaded if it is loaded by the classloader of the hibernate-tools-x.yy.jar or one of its parent loaders (OSGI can make the things more complicated).
> *I think the solution would be to catch ClassNotFoundException as well and try to load reverse engineering class using ReflectHelper in this case.*
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 5 months
[JBoss JIRA] (JBIDE-23066) Generating hbm.xml files always happens using the 3.5 runtime
by Koen Aers (JIRA)
[ https://issues.jboss.org/browse/JBIDE-23066?page=com.atlassian.jira.plugi... ]
Koen Aers updated JBIDE-23066:
------------------------------
Fix Version/s: 4.4.2.Final
(was: 4.4.2.AM3)
> Generating hbm.xml files always happens using the 3.5 runtime
> -------------------------------------------------------------
>
> Key: JBIDE-23066
> URL: https://issues.jboss.org/browse/JBIDE-23066
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: hibernate
> Affects Versions: 4.4.1.Final
> Reporter: Koen Aers
> Assignee: Koen Aers
> Fix For: 4.4.2.Final
>
>
> This issue is related to JBIDE-22997 and JBIDE-23059. After implementing JBIDE-23059 the phenomenon described in JBIDE-22997 disappeared but the hbm.xml files are now always generated using the 3.5 runtime, even when the project is a hibernate project with a console configuration using another version.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 5 months