[ https://issues.jboss.org/browse/JBIDE-8461?page=com.atlassian.jira.plugin... ] Burr Sutter updated JBIDE-8461: ------------------------------- Attachment: native_lib_editing2.png The change to "nativeHello" is undone when you return to the dialog -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/JBIDE-8461?page=com.atlassian.jira.plugin... ] Max Rydahl Andersen updated JBIDE-8461: --------------------------------------- Fix Version/s: 3.3.0.M1 3.2.1 Component/s: JBossAS -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/JBIDE-8461?page=com.atlassian.jira.plugin... ] Burr Sutter commented on JBIDE-8461: ------------------------------------ I think the UI is confusing - it looks like the end-user can make a change but the change simply does not take effect - perhaps put up an appropriate warning to indicate those settings are read-only or just remove the "edit" button. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/JBIDE-8461?page=com.atlassian.jira.plugin... ] Max Rydahl Andersen commented on JBIDE-8461: -------------------------------------------- Burr, btw. I don't see any *.dll files in JBoss 6 download - are you sure this should even work on AS 6 ? Where are you getting the matching DLL from ? -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/JBIDE-8461?page=com.atlassian.jira.plugin... ] Max Rydahl Andersen commented on JBIDE-8461: -------------------------------------------- Before I forget after some digging we can solve the specific issue with java.library.path by utilizing the Native Library support for Eclipse classpath containers. Thus instead of us "tweaking" the launchconfig we simply declare on jboss's classpath container that it has a native library part; then if users does not specify anything that is what will be used but if users does declare -Djava.library.path then that will override anything we provide. That should give the best balance of magically working out of the box and explicit control if needed. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/JBIDE-8461?page=com.atlassian.jira.plugin... ] Rob Stryker commented on JBIDE-8461: ------------------------------------ It seems the code during POJP launches that adds the library path only applies when launching a "project". Since a server is not a project in eclipse, this batch of code never gets executed. I basically have two options here: 1) I can fix the code that was broken before, so that modifying the parameter actually works properly 2) I could try to execute the same code (adding to library param) based on the classpath entries of projects already deployed on the server. Item 1 obviously is the easiest fix. But if item 2 has some awesome benefits, it would be worth it entirely. Unfortunately, item 2 has severe drawbacks. Imagine a workspace with 3 web projects. Each web project demands native code from a different folder. Depending on which are deployed to the server at the time the server starts up would change the flag. The good side here is that the values the user hard-sets in the launch config himself would override this logic. But it also has bad sides, specifically, that if you start the server with zero modules deployed onto it, none of those native folders make it on during the server launch. I think this would confuse a lot of users, how depending on what module is already deployed could change the behaviour so greatly. Users often remove and re-add modules all the time, and they also often restart servers. A user would now need to pay careful attention to which modules are published before startup. Also, this would make the usecase of a clean startup (0 deployed modules) and then publishing afterwards impossible, since the server would have already started with none of the 3 apps' native code on the library path. I will make a patch that moves the behaviour here more in line with that of generic POJP launches, but I cannot move it entirely. Patch will be ready in a short while. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/JBIDE-8461?page=com.atlassian.jira.plugin... ] Max Rydahl Andersen commented on JBIDE-8461: -------------------------------------------- excellent -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/JBIDE-8461?page=com.atlassian.jira.plugin... ] Rob Stryker commented on JBIDE-8461: ------------------------------------ The reason no java.library.path is being set for EAP 5.1 is because no such native folder exists. The user can open the launch configuration and add his own overriding for the java library path by setting the flag in vm arguments. (Open server editor, click "Open launch configuration", and add the flag to the vm args.) In the event no flag is set (lib folder not manually set by user), the launch configuration attempts to set a default. The default is assumed to be at {serverHome}/bin/native. If that folder does not exist, no native flag is set. The property being set to the string you mentioned is probably just your system's default native folder. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira