[JBoss JIRA] (JBIDE-19453) Remote host information does not fit in the server editor
by Rob Stryker (JIRA)
[ https://issues.jboss.org/browse/JBIDE-19453?page=com.atlassian.jira.plugi... ]
Rob Stryker resolved JBIDE-19453.
---------------------------------
Resolution: Done
I suspect very strongly that the commit I made today will fix your issue. I'm resolving this because I am optimistic ;) Wait for a build and then test again =P
> Remote host information does not fit in the server editor
> ---------------------------------------------------------
>
> Key: JBIDE-19453
> URL: https://issues.jboss.org/browse/JBIDE-19453
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: server
> Affects Versions: 4.2.3.Beta1
> Reporter: Martin Malina
> Assignee: Rob Stryker
> Fix For: 4.3.0.Beta1
>
> Attachments: remote-runtime-does-not-fit.png, server-editor-2.png, server-editor-linux.png
>
>
> Today I noticed this. When I set up a remote server and then open it in the Server editor, the part under Server Behavior where it shows the remote host configuration (e.g. Remote Server Home) does not fix - it needs more space to the right, but it's hidden and there is no way to scroll to view it.
> !remote-runtime-does-not-fit.png!
> The same problem applies to both JBDS 8.1.0.Beta1 and JBDS 9.0.0.Alpha1. So you may want to clone this for 4.3.x.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 11 months
[JBoss JIRA] (JBIDE-19453) Remote host information does not fit in the server editor
by Rob Stryker (JIRA)
[ https://issues.jboss.org/browse/JBIDE-19453?page=com.atlassian.jira.plugi... ]
Rob Stryker commented on JBIDE-19453:
-------------------------------------
Unfortunately we don't control the minimum width of the column. Theoretically we could make it wider by simply adding a very large widget and forcing it wider, but, then it'd become inconvenient for the user to properly fit both columns on the screen wtihout a scrollbar, so that's not really a good solution.
I've made a commit that lowers the minimum size of the server-home text field from 200 down to 150, and i've put the minimum width of the base-dir field down to 100. The fields will still expand to fill whatever space is left after the browse button and label are placed, if there is any extra... but it basically means that those text fields are 'able' to be squished, so long as they don't shrink below 150 and 100 pixels respectively.
So if for some reason your font size throughout your entire workspace is huge, and the labels on the left side take up the entire widget, then you'll still be shit-out-of-luck and be unable to see the browse button. Unfortunately, this is more a problem with the scrollbars than anything.
See https://bugs.eclipse.org/bugs/show_bug.cgi?id=464223 for more information.
> Remote host information does not fit in the server editor
> ---------------------------------------------------------
>
> Key: JBIDE-19453
> URL: https://issues.jboss.org/browse/JBIDE-19453
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: server
> Affects Versions: 4.2.3.Beta1
> Reporter: Martin Malina
> Assignee: Rob Stryker
> Fix For: 4.3.0.Beta1
>
> Attachments: remote-runtime-does-not-fit.png, server-editor-2.png, server-editor-linux.png
>
>
> Today I noticed this. When I set up a remote server and then open it in the Server editor, the part under Server Behavior where it shows the remote host configuration (e.g. Remote Server Home) does not fix - it needs more space to the right, but it's hidden and there is no way to scroll to view it.
> !remote-runtime-does-not-fit.png!
> The same problem applies to both JBDS 8.1.0.Beta1 and JBDS 9.0.0.Alpha1. So you may want to clone this for 4.3.x.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 11 months
[JBoss JIRA] (JBIDE-18876) Improve TP publishing so changes released to git or deployed to nexus would not break developer local builds
by Denis Golovin (JIRA)
[ https://issues.jboss.org/browse/JBIDE-18876?page=com.atlassian.jira.plugi... ]
Denis Golovin commented on JBIDE-18876:
---------------------------------------
Example of failing build after TP was updated a day ago and builds are still failing:
[INFO] [INFO] Adding repository http://download.jboss.org/jbosstools/targetplatforms/jbosstoolstarget/4.5...
[INFO] [ERROR] Failed to resolve target definition /home/eskimo/data/Projects/jbdevstudio/4.3.x/fork/jbds-releng/.m2/org/jboss/tools/targetplatforms/jbosstools-unified/4.50.0.Beta1-SNAPSHOT/jbosstools-unified-4.50.0.Beta1-SNAPSHOT-jbosstools-unified.target: Could not find "org.eclipse.e4.ui.importer/0.1.0.v20150505-1028" in the repositories of the current location -> [Help 1]
> Improve TP publishing so changes released to git or deployed to nexus would not break developer local builds
> ------------------------------------------------------------------------------------------------------------
>
> Key: JBIDE-18876
> URL: https://issues.jboss.org/browse/JBIDE-18876
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: build
> Affects Versions: 4.3.0.Alpha1
> Reporter: Denis Golovin
> Assignee: Denis Golovin
> Priority: Minor
> Fix For: 4.3.x
>
>
> Latest Thym update is 'good' example for this problem. I was in the middle of testing some changes in parent/pom.xml and suddenly build start to fail with Thym resolution problem. IMO what happened is TP .target files were published to nexus before actual p2-repos appeared online. Building from latest revision didn't help ether because of the same problem. I had to revert to previous revision to continue my task.
> So it would be good if TP builds publish binaries first and then release TP sources to git and deploy to nexus.
> Please note, that when sftp/rsync for unified TP binaries is finished it doesn't mean p2-repos are available from download.jboss.org right away.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 11 months
[JBoss JIRA] (JBIDE-18274) AS7/WildFly8/EAP6 with oracle java 7 fails to start when bound to your hostname
by Rob Stryker (JIRA)
[ https://issues.jboss.org/browse/JBIDE-18274?page=com.atlassian.jira.plugi... ]
Rob Stryker commented on JBIDE-18274:
-------------------------------------
I'm honestly not even sure what to check.
We run the following code:
{code}
private static boolean onePing(String url) {
URLConnection conn = null;
try {
URL pingUrl = new URL(url);
conn = pingUrl.openConnection();
((HttpURLConnection)conn).getResponseCode();
return true;
} catch( FileNotFoundException fnfe ) {
return true;
} catch (MalformedURLException e) {
// Should NEVER happen since the URL's are hand-crafted, but whatever
Status s = new Status(IStatus.ERROR, JBossServerCorePlugin.PLUGIN_ID, e.getMessage(), e);
JBossServerCorePlugin.getDefault().log(s);
} catch (IOException e) {
// Does not need to be logged
return false;
} finally {
if( conn != null ) {
((HttpURLConnection)conn).disconnect();
}
}
return false;
}
{code}
where URL = http://[hostname]:[webport], which very simply resolves to http://freaking:8080
Can you try running a POJP with this code when your server is up and running, and see if this method returns true or false?
ALso, can you be specific about what behavior profile your server is in? local+fs? local+mgmt? etc?
> AS7/WildFly8/EAP6 with oracle java 7 fails to start when bound to your hostname
> -------------------------------------------------------------------------------
>
> Key: JBIDE-18274
> URL: https://issues.jboss.org/browse/JBIDE-18274
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: server
> Affects Versions: 4.2.0.CR1
> Reporter: Martin Malina
> Assignee: Rob Stryker
> Priority: Minor
> Fix For: 4.3.0.Beta1
>
> Attachments: server-adapter.png, server-editor.png, server-logs.png, server-runtime.png
>
>
> This is a follow up of JBIDE-17935 .
> Previously, Rob fixed this:
> {quote}
> I've surprisingly been able to replicate this and it's a race-condition. I'll need to synchronize some variables in this class here.
> {quote}
> But in this rare case it still fails for me.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 11 months
[JBoss JIRA] (JBIDE-19761) Hibernate Tools DelegatingReverseEngineeringStrategy not working
by Luis Lima (JIRA)
[ https://issues.jboss.org/browse/JBIDE-19761?page=com.atlassian.jira.plugi... ]
Luis Lima commented on JBIDE-19761:
-----------------------------------
Hi Koen,
Thanks for taking the time to look into this. You're correct, I can't believe I missed that after spending hours around this problem trying to figure out what was wrong.
Thank you for pointing it out for me and sorry for wasting your time, this issue can be closed as it wasn't an issue at all and my mistake everything is working as it should.
Sorry again.
Regards
Luis
> Hibernate Tools DelegatingReverseEngineeringStrategy not working
> ----------------------------------------------------------------
>
> Key: JBIDE-19761
> URL: https://issues.jboss.org/browse/JBIDE-19761
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: hibernate
> Environment: Eclipse Luna
> Reporter: Luis Lima
> Assignee: Koen Aers
> Priority: Blocker
> Fix For: 4.1.3.Final, 4.3.0.Beta1
>
>
> I'm using the HibernateTools plugin (latest version) with Eclipse Luna and keep getting an error when trying to use my own reverse engineering implementation class. Every time I try to generate my classes I get this exception from Eclipse:
> org.hibernate.console.HibernateConsoleRuntimeException: java.lang.IllegalAccessException: Class org.jboss.tools.hibernate.proxy.ServiceProxy can not access a member of class org.hibernate.cfg.reveng.ReverseEngineeringStrategyUtil with modifiers "private" java.lang.IllegalAccessException: Class org.jboss.tools.hibernate.proxy.ServiceProxy can not access a member of class org.hibernate.cfg.reveng.ReverseEngineeringStrategyUtil with modifiers "private"
> Seems there's some incompatibility with ServiceProxy and the ReverseEngineeringStrategyUtil class as it seems to be trying to access a method that's no longer private. The stacktrace doesn't really provide any info other than this so hopefully this is a known issue and someone might be able to suggest how to fix it.
> It's not related to my code since right now my ReverseEngineeringStrategy implementation is doing nothing ie:
> @Override
> public String tableToClassName(TableIdentifier tableIdentifier){
> return super.tableToClassName(tableIdentifier);
> }
> My libraries are 4.3 (4.3.1.CR1 more specifically) and I also have the console configuration set to that version.
> Here's my maven dependency:
> <dependency>
> <groupId>org.hibernate</groupId>
> <artifactId>hibernate-tools</artifactId>
> <version>4.3.1.CR1</version>
> </dependency>
> And always get the error.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 11 months