Re: [jbosstools-dev] questions about eclipse project facet
by Max Rydahl Andersen
please use jbosstools-dev for dev questions Grid. (moved it)
> 1 when I add the bpel facet, I only use codes to add the facet, don't do others, but in the org.eclipse.wst.common.project.facet.core.xml:
> <fixed facet="bpel.facet.core"/>
> Who and why add the fixed facet?
I'll assume the facet system.
> 2 when I remove the bpel facet, using facetproject.uninstallprojectfacet(), I only can remove:
> <installed facet="bpel.facet.core" version="2.0"/> from
> org.eclipse.wst.common.project.facet.core.xml. The
> <fixed facet="bpel.facet.core"/> is still there.
> How do I can remove the fixed facet?
fixed facets are locked in based on the project type - so if you created it as a BPEL project that is fixed in as I understand it.
See http://www.eclipse.org/articles/Article-BuildingProjectFacets/tutorial.html
/max
http://about.me/maxandersen
15 years
.settings in o.j.ide.eclipse.as.core
by Alexey Kazakov
Hi Rob, Andre,
I removed -org.eclipse.jdt.core.compiler.codegen.targetPlatform=1.5
from
trunk/as/plugins/org.jboss.ide.eclipse.as.core/.settings/org.eclipse.jdt.core.prefs
to get rid of compilation error in Eclipse for this plug-in since it
uses Java 1.6 syntax and MANIFES.MF has
Bundle-RequiredExecutionEnvironment: JavaSE-1.6
Committed to trunk.
15 years
Re: [jbosstools-dev] Ambiguous EL names
by Alexey Kazakov
Thanks Pete.
I created the issue - https://issues.jboss.org/browse/WELD-930
On 06/25/2011 04:52 AM, Pete Muir wrote:
> This looks to me like a bug in Weld (one that crept in from a pre-final spec revision) - that it checks if the declaring bean class is an alternative, and if it is, makes the producer an alternative. Can you file a WELD issue for this? I'll update the quickstart to explicitly make the producer an alternative.
>
> Pete
15 years
Compilation error in ForgeLauncheHelper
by Alexey Kazakov
Hi Koen,
there is a compilation error in
org.jboss.tools.forge.core.ForgeLauncheHelper.java in trunk: The method
getName() is undefined for the type ForgeRuntime (line 149)
15 years
Ambiguous EL names
by Alexey Kazakov
Hi Pete,
I'm looking at examples from
https://github.com/pmuir/jboss-as-developer-guide/tree/master/quickstarts and
I have a question...
There is org.jboss.as.quickstarts.login.EJBUserManager:
/...
@Named("userManager")
@RequestScoped
@Alternative
@Stateful
public class EJBUserManager implements UserManager {
...
@Produces
@Named
@RequestScoped
public List<User> getUsers() throws Exception {
...
}
...
}
/
It's an alternative bean class which declare a @Named producer.
And there is also another bean
org.jboss.as.quickstarts.login.ManagedBeanUserManager:
/@Named("userManager")
@RequestScoped
public class ManagedBeanUserManager implements UserManager {
@SuppressWarnings("unchecked")
@Produces
@Named
@RequestScoped
public List<User> getUsers() throws Exception {
...
}
...
}
/
So EL names of both bean classes ("userManager") are the same. This is
OK and JBoss Tools doesn't treat it as a problem because EJBUserManager
is an alternative.
But EL names of the producers are treated as ambiguous EL names ("users").
I looked at the spec. and still don't understand where our tooling is wrong:
/5.3.1. Ambiguous EL names
An ambiguous EL name exists in an EL expression when an EL name resolves
to multiple beans. When an ambiguous EL
name exists, the container attempts to resolve the ambiguity. If any of
the beans are alternatives, the container eliminates
all beans that are not alternatives, *except for producer methods and
fields of beans that are alternatives*. If there is exactly
one bean remaining, the container will select this bean, and the
ambiguous EL name is called resolvable./
Thanks.
15 years
