[JBoss JIRA] Created: (JBIDE-9203) Plain text value for translation is chosen wrongly when translating .jsp page via Externalize Selected String
by Vlado Pakan (JIRA)
Plain text value for translation is chosen wrongly when translating .jsp page via Externalize Selected String
-------------------------------------------------------------------------------------------------------------
Key: JBIDE-9203
URL: https://issues.jboss.org/browse/JBIDE-9203
Project: Tools (JBoss Tools)
Issue Type: Bug
Components: Visual Page Editor core
Affects Versions: 3.3.0.M2
Environment: Linux 32bit, Sun JDK 1.6.0_25, jbdevstudio-product-linux-gtk-5.0.0.v201106172137N-H681-M2.
Reporter: Vlado Pakan
Assignee: Yahor Radtsevich
Fix For: 3.3.0.M3
1. Create JSF kick start project
2. Open hello.jsp page
3. Insert "Plain" text as shown on picture below and choose Externalize selected string toolbar button
In the Externalize String dialog is set text "Plain" as Property value but together with special characters <EOL>
!externalizestringdialog.png!
4. Choose next>, next>, OK. (Use default values)
hello.jsp page look like this. <EOL> characters around "Plain" text were removed/replaced with reference to .properties file:
!externalizestringresult.png!
hello.properties has wrong contnent:
!propertiesfile.png!
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 1 month
[JBoss JIRA] Created: (JBIDE-7279) Provide support for JAX-WS 2.2 APIs
by Lukas Jungmann (JIRA)
Provide support for JAX-WS 2.2 APIs
-----------------------------------
Key: JBIDE-7279
URL: https://jira.jboss.org/browse/JBIDE-7279
Project: Tools (JBoss Tools)
Issue Type: Feature Request
Components: Webservices
Affects Versions: 3.2.0.Beta1
Reporter: Lukas Jungmann
Assignee: Brian Fitzpatrick
[this is to be checked against JBossAS 6.0M5 or newer]
for a project which has target runtime set to JBossAS6/uses JBossWS 3.3.x
-user should be allowed to set JAX-WS spec version in a top-down web service and web service client wizards to 2.2
-editor should not show errors for following generated type of constructor:
public Info(WebServiceFeature ... features) {
super(WSDL_LOCATION, SERVICE, features);
}
(in the other words editor/ide has to know about APIs from $JBOSS_HOME/lib/endorsed)
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 1 month
[JBoss JIRA] (JBIDE-10968) soa tooling build can't aggregate runtime.{drools, esb, jbpm}.detector unless they're on an upstream site
by Nick Boldt (JIRA)
Nick Boldt created JBIDE-10968:
----------------------------------
Summary: soa tooling build can't aggregate runtime.{drools,esb,jbpm}.detector unless they're on an upstream site
Key: JBIDE-10968
URL: https://issues.jboss.org/browse/JBIDE-10968
Project: Tools (JBoss Tools)
Issue Type: Bug
Components: drools, esb, jbpm, runtime detection, SOA Tooling
Affects Versions: 3.3.0.Beta1, 3.3.0.Beta1-soa
Reporter: Nick Boldt
Assignee: Douglas Palmer
Fix For: 3.3.0.Beta1, 3.3.0.Beta1-soa
Max, the issue is not that they need to exist on the soa side, it's that to BUILD the soa site, they need to exist upstream first.
Thus, they would need to ALSO be on the JBT Core site as well as the JBT SOA site.
Or else we need some other way to get them in there, like having them move from being part of Runtime to some other "Runtime-SOA" component which only SOA builds, downstream from Runtime and JBT Core aggregation.
N
On 02/20/2012 11:37 AM, Max Rydahl Andersen wrote:
> please open jira on this - this is a technical issue on how runtime detection should work outofthebox.
>
> something SOA and Core engineering team need to coordinate on.
>
> but yes, since the runtime detectors rely on the soa stuff they need to exist on soa side of things.
>
> /max
>
> On Feb 20, 2012, at 7:32 AM, Nick Boldt wrote:
>
>> The JBT SOA Tooling aggregate [1] now sources from the upstream JBT Core site [2], and does NOT use the JBT Core composite staging site [3], only the JBT SOA Tooling one [4] so as to avoid getting a mismatched set of upstream plugins (eg., a newer Runtime component in staging vs. the last pulled nightly snapshot).
>>
>> However, this means that the build is failing because it can't find the org.jboss.tools.runtime.{drools,esb,jbpm}.detector.feature features, as they're *not currently published* to the JBT Core nightly site [2], only the composite [3] and the individual component's staging site [5]. This may be simply an oversight, or it was done intentionally because these detectors only make sense to be in the SOA Tooling site, not in Core.
>>
>> To solve this we should probably put these features into the JBT Aggregate site (albeit as hidden features). Then they can be found by the SOA Tooling jobs and categorized there.
>>
>> Does that make sense?
>>
>> [1] https://hudson.qa.jboss.com/hudson/job/jbosstools-3.3_stable_branch.soa-t...
>>
>> [2] http://download.jboss.org/jbosstools/updates/nightly/core/3.3.indigo/
>>
>> [3] http://download.jboss.org/jbosstools/builds/staging/_composite_/core/3.3....
>>
>> [4] http://download.jboss.org/jbosstools/builds/staging/_composite_/soa-tooli...
>>
>> [5] http://download.jboss.org/jbosstools/builds/staging/jbosstools-3.3_stable...
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 1 month
[JBoss JIRA] Created: (JBIDE-9310) JBoss tools does not take AS 6's jsf.deployer into account
by arjan tijms (JIRA)
JBoss tools does not take AS 6's jsf.deployer into account
----------------------------------------------------------
Key: JBIDE-9310
URL: https://issues.jboss.org/browse/JBIDE-9310
Project: Tools (JBoss Tools)
Issue Type: Bug
Reporter: arjan tijms
In JBoss AS 6, one can change which JSF implementation JBoss AS uses by editing /deployers/jsf.deployer/META-INF/jsf-integration-deployer-jboss-beans.xml. JBoss bundles Mojarra 1.2, 2.0 and MyFaces 2.0 by default.
However, if one changes this, JBoss tools keeps putting the two hardcoded libs in /deployers/jsf.deployer/Mojarra-2.0/jsf-libs on the IDE's lookup path. This means that stepping through JSF source code is totally broken then.
A workaround is to copy the libs from the other configuration to /deployers/jsf.deployer/Mojarra-2.0/jsf-libs and rename them to jsf-api-2.0.3-b05.jar and jsf-impl-2.0.3-b05.jar. This works, but there is something unsettling of having e.g. the 2.1.2 libs called 2.0.3 just for the sake of the ability to debug.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 1 month