[JBoss JIRA] Created: (JBIDE-9483) CDI extensions are not loaded if they are declared in a source folder.
by Alexey Kazakov (JIRA)
CDI extensions are not loaded if they are declared in a source folder.
----------------------------------------------------------------------
Key: JBIDE-9483
URL: https://issues.jboss.org/browse/JBIDE-9483
Project: Tools (JBoss Tools)
Issue Type: Bug
Components: cdi extensions
Affects Versions: 3.3.0.M3
Reporter: Alexey Kazakov
Assignee: Viacheslav Kabanovich
Fix For: 3.3.x
EXECUTE: Create two CDI projects: Project A and B. Project A should be included in the class path of project B.
EXECUTE: Create a file A/<sourceFolder>/META-INF/services/javax.enterprise.inject.spi.Extension
EXECUTE: Add the following text to the service file:
{code}
org.jboss.seam.servlet.ServletExtension
{code}
EXECUTE: Create any bean in project B and add the following injection point to the bean:
{code}
@Inject @RequestParam("id")
private String bookId;
{code}
ASSERT: bookId is not marked as unsatisfied dependency. <- Failure
EXECUTE: Remove A/<sourceFolder>/META-INF/services/javax.enterprise.inject.spi.Extension
EXECUTE: Build the projects.
ASSERT: bookId is marked as unsatisfied dependency.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 10 months
[JBoss JIRA] Created: (JBIDE-9323) Possibility to contribute on vpe toolbar in eclipse
by Maxim Areshkau (JIRA)
Possibility to contribute on vpe toolbar in eclipse
---------------------------------------------------
Key: JBIDE-9323
URL: https://issues.jboss.org/browse/JBIDE-9323
Project: Tools (JBoss Tools)
Issue Type: Task
Components: Visual Page Editor core
Affects Versions: 3.3.0.M2
Reporter: Maxim Areshkau
Assignee: Yahor Radtsevich
VPE icons have some logic behind them(disabled when visual part not visible). We need possibility to contribute on this toolbar. For now this is inpossible. Because refresh icon function has hardcoded commands'id. Better to refresh all commands on some org.jboss.tools.vpe.category. That allows contribute to vpe-toolbar.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 10 months
[JBoss JIRA] Created: (JBDS-1834) Relabel "Certified" features as "Selected" to match the actual level of support provided for those add-ons
by Nick Boldt (JIRA)
Relabel "Certified" features as "Selected" to match the actual level of support provided for those add-ons
----------------------------------------------------------------------------------------------------------
Key: JBDS-1834
URL: https://issues.jboss.org/browse/JBDS-1834
Project: Developer Studio (JBoss Developer Studio)
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: updatesite
Affects Versions: 4.1.1.M1, 5.0.0.M3
Reporter: Nick Boldt
Fix For: 4.1.1.Final, 5.0.0.M4
Per lengthy discussions, I believe the plan is to relabel some features on the JBDS Extras sites for 4.x and 5.x as follows:
{code}
* Selected *
FindBugs
Git (5.x version includes eGit, jGit, and Mylyn support for GitHub; 4.x version is just eGit/jGit)
Maven/m2e (including wtp integration)
Mylyn (incl. connectors for CVS, SVN, Git, GitHub; JIRA support only in 5.x)
PMD
Spring IDE
Subclipse
TestNG
* Certified *
BPEL Editor
* Unknown / New for 5.x / TBD *
jslint
checkstyle
{code}
To facilitate with this exercise, I've changed the update site index pages to list the features they contain. Here are the latest nightlies for 4.x and 5.x:
http://www.qa.jboss.com/binaries/RHDS/builds/staging/devstudio-4.1_stable...
and
http://www.qa.jboss.com/binaries/RHDS/builds/staging/devstudio-5.0_trunk....
http://www.qa.jboss.com/binaries/RHDS/builds/staging/devstudio-5.0_trunk.... (not technically an "Extras" site but listed here in case people wonder where BPEL went)
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 10 months
[JBoss JIRA] Created: (JBIDE-9508) JBoss7ManagerServicePoller: catch block at line 158 should add exception to status
by Andre Dietisheim (JIRA)
JBoss7ManagerServicePoller: catch block at line 158 should add exception to status
----------------------------------------------------------------------------------
Key: JBIDE-9508
URL: https://issues.jboss.org/browse/JBIDE-9508
Project: Tools (JBoss Tools)
Issue Type: Bug
Components: JBossAS
Affects Versions: 3.3.0.M3
Reporter: Andre Dietisheim
Assignee: Andre Dietisheim
Fix For: 3.3.x
JBoss7ManagerServicePoller#getCurrentStateSynchronous:
{code}
} catch(Exception e) {
Status s = new Status(IStatus.INFO, JBossServerCorePlugin.PLUGIN_ID,
"An attempt to reach the JBoss 7 Management Service on host " + server.getHost() //$NON-NLS-1$
+ " and port " + getManagementPort(server) + " has resulted in an exception"); //$NON-NLS-1$ //$NON-NLS-2$
return s;
}
{code}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 10 months
[JBoss JIRA] Created: (JBIDE-9650) [Regression] - Servers under 7 (6 and below) do not suspend deployment scanner before publishing
by Rob Stryker (JIRA)
[Regression] - Servers under 7 (6 and below) do not suspend deployment scanner before publishing
------------------------------------------------------------------------------------------------
Key: JBIDE-9650
URL: https://issues.jboss.org/browse/JBIDE-9650
Project: Tools (JBoss Tools)
Issue Type: Bug
Components: JBossAS/Servers
Affects Versions: 3.3.0.M3
Reporter: Rob Stryker
Assignee: Rob Stryker
Priority: Blocker
Fix For: 3.3.0.M4
A critical regression has been discovered while investigating the ability to delay the popup of the web browser until the server is finished deploying.
A commit was pushed in on July 7th, 59 days ago, reversing the logic that was used to determine if the deployment scanner should be stopped or not. The original (and intended) behaviour was that if the server is started, and a JMX extension is provided, to disable the scanner during publish events.
The offending commit is here:
http://source.jboss.org/changelog/JBossTools?cs=32709
You can see that the logic was removed from one class to another. LocalJBossBehaviorDelegate had the following code:
protected boolean shouldSuspendScanner() {
return getActualBehavior().shouldSuspendScanner() &&
ExtensionManager.getDefault().getJMXRunner() != null;
}
The code in the "actual behaviour" had the following:
if( getServer().getServerState() != IServer.STATE_STARTED)
return false;
The code in LocalJBossBehaviourDelegate was replaced with:
protected boolean shouldSuspendScanner() {
return getServer().getServerState() != IServer.STATE_STARTED
&& ExtensionManager.getDefault().getJMXRunner() != null;
}
You can see that the original code ensured that if the server state was NOT started, it would NOT suspend JMX... ie, that the server being started is a requirement to suspend JMX deployment scanner. In the new code, you can see that it will TRY to suspend if the server is NOT started, and that if the server *IS* started, it *WILL NOT* try to suspend.
It is extremely obvious that no testing for this usecase was performed during the time period around this patch.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 10 months
[JBoss JIRA] Created: (JBIDE-9410) consider building vpe and jsf as a single hudson job or reorganize dependencies between jsf and vpe/xulrunner features
by Nick Boldt (JIRA)
consider building vpe and jsf as a single hudson job or reorganize dependencies between jsf and vpe/xulrunner features
----------------------------------------------------------------------------------------------------------------------
Key: JBIDE-9410
URL: https://issues.jboss.org/browse/JBIDE-9410
Project: Tools (JBoss Tools)
Issue Type: Bug
Components: JSF, Visual Page Editor core, XULRunner
Affects Versions: 3.3.0.M3
Reporter: Nick Boldt
Assignee: Alexey Kazakov
Fix For: 3.3.0.M3
I have been wrestling with this problem (or similar) for about the last two weeks:
{code}
[INFO] [Software being installed: com.jboss.jbds.site raw:0.0.2.'SNAPSHOT'/format(n[.n=0;[.n=0;[-S]]]):0.0.2-SNAPSHOT,
Only one of the following can be installed at once: [
org.jboss.tools.xulrunner.initializer 3.1.0.v20110726-1048-H409-M3,
org.jboss.tools.xulrunner.initializer 3.1.0.v20110726-1947-H410-M3],
Cannot satisfy dependency: com.jboss.jbds.site raw:0.0.2.'SNAPSHOT'/format(n[.n=0;[.n=0;[-S]]]):0.0.2-SNAPSHOT depends on:
org.jboss.tools.richfaces.feature.feature.group 0.0.0,
Cannot satisfy dependency: com.jboss.jbds.site raw:0.0.2.'SNAPSHOT'/format(n[.n=0;[.n=0;[-S]]]):0.0.2-SNAPSHOT depends on:
org.jboss.tools.xulrunner.feature.feature.group 0.0.0,
Cannot satisfy dependency: org.jboss.tools.richfaces.feature.feature.group 3.3.0.v20110726-1419-H339-M3 depends on:
org.jboss.tools.xulrunner.initializer [3.1.0.v20110726-1048-H409-M3],
Cannot satisfy dependency: org.jboss.tools.xulrunner.feature.feature.group 1.9.216.v20110726-1947-H410-M3 depends on:
org.jboss.tools.xulrunner.initializer [3.1.0.v20110726-1947-H410-M3]]
Basically, this is caused by VPE spinning a build which includes org.jboss.tools.xulrunner.initializer 3.1.0.v20110726-1048-H409-M3, then JSF (richfaces) spins and picks up that H409 build and includes it in its site. Then, while the JBDS update site is spinning, the VPE build spins again and now depends on H410 instead of H409. Because the aggregate can only include ONE version and each feature has strict version requirements, there is no solution for p2 to be able to create a site with the two inputs.
So, either we need to build these two components together as a single job, or we need some other way to ensure this "vpe respin breaks jsf installability" problem is solved.
Maybe the richfaces.feature should DEPEND ON the xulrunner.feature instead of INCLUDING the org.jboss.tools.xulrunner.initializer plugin? Or just depend on that single plugin?
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 10 months
[JBoss JIRA] Created: (JBIDE-9291) Extend the classpath for JBoss 7
by Juergen Zimmermann (JIRA)
Extend the classpath for JBoss 7
--------------------------------
Key: JBIDE-9291
URL: https://issues.jboss.org/browse/JBIDE-9291
Project: Tools (JBoss Tools)
Issue Type: Feature Request
Components: JBossAS
Affects Versions: 3.3.0.M2
Reporter: Juergen Zimmermann
Assignee: Rob Stryker
I'd recommend to extend the classpath settings for JBossAS 7 by these 6 JARs:
1) modules/org/hibernate/validator/main/hibernate-validator-VERSION.jar
-> e.g. @Email, @ScriptAssert
2) modules/org/resteasy/resteasy-jaxrs/main/resteasy-jaxrs-VERSION.jar
-> @Form
3) modules/org/resteasy/resteasy-jaxb-provider/main/resteasy-jaxb-provider-VERSION.jar
-> Provider for XML representations when submitting a GET request for a RESTful webservice
4) modules/org/resteasy/resteasy-multipart-provider/main/resteasy-multipart-provider-VERSION.jar
-> Provider for POST requests with MIME type application/x-www-form-urlencoded
5) modules/org/jboss/logging/main/jboss-logging-VERSION.jar
-> org.jboss.logging.Logger
6) modules/org/picketbox/main/picketbox-VERSION.jar
-> org.jboss.security.*
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 10 months