missing artifacts in central
by Dan Allen
One user is reporting that the JSF 2 artifact is missing from the central
repo, which weld depends on. Therefore, users must still use the JBoss Maven
2 repository to build a JSF app with Weld.
Who is willing to track down how to get this artifact uploaded? I know how
to get something into the JBoss repository, but not central. Perhaps we need
to hound the Mojarra team to publish a JSF 2.0 artifact.
-Dan
Missing:
----------
1) javax.faces:jsf-api:jar:2.0.0-RC
Try downloading the file manually from the project website.
Then, install it using the command:
mvn install:install-file -DgroupId=javax.faces -DartifactId=jsf-api
-Dversion=2.0.0-RC -Dpackaging=jar -Dfile=/path/to/file
Alternatively, if you host your own repository you can deploy the file
there:
mvn deploy:deploy-file -DgroupId=javax.faces -DartifactId=jsf-api
-Dversion=2.0.0-RC -Dpackaging=jar -Dfile=/path/to/file -Durl=[url]
-DrepositoryId=[id]
Path to dependency:
1) org.example:helloworld:war:0.0.1-SNAPSHOT
2) javax.faces:jsf-api:jar:2.0.0-RC
----------
1 required artifact is missing.
for artifact:
org.example:helloworld:war:0.0.1-SNAPSHOT
from the specified remote repositories:
central (http://repo1.maven.org/maven2)
-Dan
--
Dan Allen
Senior Software Engineer, Red Hat | Author of Seam in Action
Registered Linux User #231597
http://mojavelinux.com
http://mojavelinux.com/seaminaction
http://www.google.com/profiles/dan.j.allen
14 years, 10 months
Infinite mutual recursion in HierarchyDiscovery.resolveType
by Clint Popetz
Hi,
The following:
abstract class ChoiceParent<T> { }
class Choice<T, E> extends ChoiceParent<T>
{
public Choice<T, E> aMethod()
{
return null;
}
}
will produce an infinite recursion between resolveType and
resolveTypeParameter if weld tries to load it. I've added a class to test/
in org.jboss.weld.test.unit.implementation.annotatedItem that triggers
this.
I'm not competant enough with generics to touch that code.
-Clint
--
Clint Popetz
http://42lines.net
Scalable Web Application Development
14 years, 10 months
Using Interceptor/Decorator On Dependent Scoped Beans
by Gurkan Erdogdu
Hi;
Does the 299 specification indicate that interceptors and decorators should
not be called for dependent scoped beans?
Currently we do not implement Interceptor/Decorator on @Dependent scoped beans in OWB because we do all interceptor/decorator stuff using proxy and @Dependent scoped beans do not require client proxy.
Does anyone has a good use case/example when dependent scoped beans are useful or necessary?
Thanks;
--Gurkan
14 years, 10 months
Question about @Decorates
by Gavin King
Does Weld currently require the use of @Inject on delegate injection points?
I've just noticed that with the change to the 330 annotations, it
perhaps makes more sense to change the name of this annotation and
require that @Inject be used, like this:
@Decorator
class TimestampLogger implements Logger {
private Logger logger;
@Inject
public TimestampLogger(@Delegate @Debug Logger logger) {
this.logger=logger;
}
...
}
@Decorator
class TimestampLogger implements Logger {
@Inject @Delegate @Any Logger logger;
...
}
We could perhaps even say that @Delegate is a qualifier.
--
Gavin King
gavin.king(a)gmail.com
http://in.relation.to/Bloggers/Gavin
http://hibernate.org
http://seamframework.org
14 years, 10 months
CDI JavaDoc
by Gavin King
OK, folks we got one big, important job before the spec can go final.
We need to re-do the JavaDoc for all the standard APIs.
Each type needs a complete explanation (perhaps copy/paste from the
spec). The important stuff (everything except for exceptions) needs
examples. We need links between related types (things used together).
We also need to fix all the errors that currently exist.
I think it's very, very important that this stuff be extremely
well-documented. For many developers, this javadoc will be their very
first contact with JSR-299!
--
Gavin King
gavin.king(a)gmail.com
http://in.relation.to/Bloggers/Gavin
http://hibernate.org
http://seamframework.org
14 years, 10 months
Goals for JavaDoc
by Gavin King
David just asked me about exactly what I want from the Javadoc. Here's
a rough guide:
The goal is that people should be just about able to use things from
just reading javadoc. It doesnt need to baby people, or explain things
that are not directly relevant to the particular annotation, or go
into very technical definitions, but it should contain all the
information about:
* what the annotation or interface is for,
* how it is used,
* what other annotations or interfaces it is used together with,
* what its behavior is, and
* the example(s) of its use.
If the user has to go digging about in the spec to figure out what an
annotation does, they are already wasting time and they will already
think 299 is "hard". Our goal is that reasonably sophisticated users
should be able to get up and running with this stuff *without* needing
additional docs.
Note that the *.spi packages do not need to be documented at quite the
same level as the application-developer-visible stuff.
--
Gavin King
gavin.king(a)gmail.com
http://in.relation.to/Bloggers/Gavin
http://hibernate.org
http://seamframework.org
14 years, 10 months
Fwd: @AroundInvoke -- JCDI vs EJB3 and return type Object?
by Sven Linstaedt
Is this a minor bug in the spec? If this s the case, please also review the
example in 9.5.1.
br, Sven
---------- Forwarded message ----------
From: Sven Linstaedt <sven.linstaedt(a)googlemail.com>
Date: 2009/10/23
Subject: Re: @AroundInvoke -- JCDI vs EJB3 and return type Object?
To: openwebbeans-dev(a)incubator.apache.org
At a first glance I would consider this a bug in the example. I can not
imagine Gavin introduced some kind of "special interceptors for void
returning methods". This would rather be a use case for decorators.
I will forward your question to the jboss list, if you don't mind.
Besides... thanks for for the review.
br, Sven
2009/10/22 Eric Covener <covener(a)apache.org>
Interceptor methods with @AroundInvoke in EJB3 requires a return type
> of Object, which is enforced by
> WebBeansUtil.java::checkAroundInvokeAnnotationCriterias(). In EJB3,
> Interceptors return InvocationContext.proceed() to their caller.
>
> However it seems that @AroundInvoke in JCDI is documented somewhat
> differently -- in the JCDI spec (1.3.6) the example has a void return
> type and just calls InvocationContext.proceed().
>
> Should the JCDI spec example look just like EJB3, or is this an
> OWB-specific restriction?
>
> --
> Eric Covener
> covener(a)gmail.com
>
14 years, 10 months
Weld SPI change: addition of serialization SPI
by Marius Bogoevici
Following a discussion with Pete from earlier this week, I exposed the
functionality that was provided internally via ContextualStore,
SerializableContextual, and SerializableContextualInstance as part of
the Weld SPI - the org.jboss.weld.serialization.spi and
org.weld.serialization.spi.helpers package.
The intent is to provide integrators that need to deal with the
passivation and activation of Contextuals and instances of Contextuals
with means that are consistent with the mechanisms that are used
internally by Weld for that purpose. Practically, we're going to use
this part of the SPI for dealing with activation/passivation of
Interceptors and Decorators that are attached to EJBs when integrating
with JBoss AS.
While this has no impact from a functional standpoint, this means that,
when retrieving the trunk for weld/core, please make sure that
org.jboss.weld:weld-spi is in sync (and use mvn -U for a forced snapshot
update for weld-spi). A snapshot should be deployed by Hudson at some
point.
Cheers,
Marius
14 years, 10 months
