<bean name="JSFUrlIntegrationDeployer-20"
class="org.jboss.jsf.deployer.JSFUrlIntegrationDeployer">
<property name="JSFImplName">
<value>Mojarra-2.0</value>
</property>
<property name="JSFImplManagementDeployer">
<inject bean="JSFImplManagementDeployer"/>
</property>
<property name="additionalURLs">
<collection elementClass="java.lang.String">
<value>${jboss.lib.url}scanning-plugins.jar</value> // HERE
</collection>
</property>
</bean>
This is not good -- the additionalURLs.
I know why you put it there, but this can probably create a bunch of problems with other
scanning plugins.
e.g. CCE on Hibernate's Scanner
I think you can actually just rip off my JBossAnnotationProvider and put it into your
jboss-faces.jar,
and you then simply depend on scanning-plugins.jar,
which is actually already available at boot classpath - due to deployers usage,
and mc-int-servlet.jar which is in common/lib.
Let me know when you copied the JBP, so I'll remove it from scanning lib.
Who adds this jboss-faces.jar to classpath?
Your integration deployers? Based on what?
jboss-faces.jar == jboss-faces-SNAPSHOT.jar ?
OK, I checked the source code, so I know the answers to this questions.
On thing I also noticed you should probably put jboss-structure.xml
into jsf.deployer/META-INF,
so you're not depending on "proper" structure deployers to be used,
when *not* recognizing your Mojara and jsf-libs dir as non-deployments.
e.g. someone might resurrect sar' lib/ structure deployer or have matching group
structure deployer
I can add this if you like.