Wrong beanmanager retrieved by CDI.current().getBeanManager() in Struts1
by Eric B
I'm running into a really strange behaviour, and I'm not entirely sure
where/how to start looking for this or if it is something that I can easily
reproduce in a test case (or if it is even worthwhile).
I've got a mutil-war JEE EAR application that uses EJBs, Struts1. and
Struts2.
My EAR is as follows:
EAR
- root.war
- ejb.jar
- web.war
- ws.war
- lib/common jars
In one of my war1 web filters, I am sucessfully able to retrieve a bean
from the CDI using:
SessionManager sessionManager =
CDI.current().select(SessionManager.class).get()
However, in a Struts1 action, I'm trying to retrieve the same bean from the
CDI using:
SessionManager sessionManager =
CDI.current().select(SessionManager.class).get()
but WELD throws and error that it is unable to resolve the SessionManager
bean:
org.jboss.weld.exceptions.UnsatisfiedResolutionException: WELD-001308:
Unable to resolve any beans for Type: interface
webapp.session.SessionManager; Qualifiers: []
When I dig more into it, I see that CDI.current().getBeanManager() in the
filter always returns the beanManager for my ear/web.war deployment.
However, when trying the same call in my Struts 1 Action, instead, it will
at times retrieve the bean manager for other deployments, seemingly
randomly:
- ear/root.war
- ear/ws.war
- ear/ejb.jar
- ear/web.war
If I retrieve the BeanManager manually from the JNDI, using a JNDI lookup,
I am able to retrieve the bean without problems:
BeanManager beanManager = (BeanManager) new
InitialContext().lookup("java:comp/BeanManager");
Set<Bean<?>> beans = beanManager.getBeans(SessionManager.class);
Bean<?> bean = beanManager.resolve(beans);
CreationalContext<?> context = beanManager.createCreationalContext(bean);
SessionManager sessionManager = (SessionManager)
beanManager.getReference(bean, SessionManager.class, context);
So at the end, I'm not entirely sure why CDI.current().getBeanManager()
would be retrieving the BeanManager from a different context. Might this
be a bug in Weld, a problem in the container, or something strange that is
happening due to the way that Struts1 was designed? Or do I need to do/add
something specific to a config to enable CDI access from within a servlet?
Struts1 is launched as a servlet in the web.xml:
<servlet>
<servlet-name>action</servlet-name>
<servlet-class>org.apache.struts.action.ActionServlet</servlet-class>
<init-param>
<param-name>config</param-name>
<param-value>/WEB-INF/struts-config.xml</param-value>
</init-param>
<init-param>
<param-name>chainConfig</param-name>
<param-value>/WEB-INF/chain-config.xml</param-value>
</init-param>
<load-on-startup>1</load-on-startup>
</servlet>
Thanks!
Eric
6 years, 9 months
Re: [wildfly-dev] WFLY-9574 - Distribution files does not have POSIX permissions perfectly set
by Brian Stansberry
Seems I forgot to "Reply to All" yesterday. The following was meant to be
sent to wildfly-dev.
On Wed, Nov 29, 2017 at 10:04 AM, Brian Stansberry <
brian.stansberry(a)redhat.com> wrote:
> Before getting into the specifics, first a general note re: perms.
>
> Our general permission set for is rwxr-xr-x for directories and rwxr--r--
> for files. If someone thinks that's wrong in general; speak up. ;).
> Otherwise I think any deviation from that we should justify. Not that
> deviations are wrong, just that they need to have a reason.
>
> On Wed, Nov 29, 2017 at 3:12 AM, Romain Pelisse <belaran(a)redhat.com>
> wrote:
>
>> Well, the diff is between the RPM and the zipfile is pretty long, but it
>> boils down to the 3 set of differences I've pointed out on WFLY-9574:
>> <https://issues.jboss.org/browse/WFLY-9574>
>>
>> - *.properties and .jar* files are associated with the mask rw-rw-r--
>> giving access to it to any other users and allowing group member to modify
>> the file - the RPM distribution fixes that by removing the write privileges
>> for the group (rw-r--r--). I personnaly don't see the value of letting the
>> group members modify those files, I just can see how this could be
>> exploited, so I would say it falls into "clearly wrong and not our intent".
>> A case might be made for the .properties files, but for jars file I really
>> don't see a valid use case (unless of course, any of you know one) ;
>>
>> There are a few different things here, so let's deal with them separately.
>
> For jars, with an unzip of wildfly-11.0.0.Final.zip, I see them as
> rwxr--r--. Which seems correct to me. In case I'm seeing something wrong, I
> don't see why they should vary from the general standard. And the
> module.xml file should be consistent, since there's not much point in
> locking people from touching jars but letting them change what jars get
> loaded.
>
> For properties files, let's consider them on a more fine-grained basis.
> For example, the properties files used by the security realms have
> different kinds of data than logging.properties does.
>
> The perms on the security realm property files are rw-------, not
> rw-rw-r--.
>
> The logging.properties files are rw-r--r-- which is consistent with the
> domain|host|standalone.xml files and with the general standard.
>
>
>>
>> -
>> - *some directories* like 'domain/tmp/auth' have too restrictive mask
>> like rwx------ and RPMS to turned them into rwxrwxr-x (that I don't really
>> agree with) and
>>
>>
>> - *other directories*, likes 'domain' have again a too permissive
>> mask rwxrwxr-x (should be rwxr-xr-x) - and this IMHO, make senses.
>>
>> In the unzip I see these directories as rwxr-xr-x, which I think is fine.
>
> Are you concerned with any other directories besides $JBOSS_HOME/domain
> and $JBOSS_HOME/standalone?
>
>> So we need to find an agreement on those three items, and then see how we
>> proceed to implement the fix (if needed).
>>
>> On Tue, Nov 28, 2017 at 10:00 PM, Brian Stansberry <
>> brian.stansberry(a)redhat.com> wrote:
>>
>>> I think we need to start with the assumption that the permissions we
>>> have in the zip are the way they are for a reason and evaluate possible
>>> changes based on discussion here of each type of change. Maybe the RPM
>>> settings are better, maybe they are not. Or maybe they are better but the
>>> improvement is not worth the disruption a change may cause to our end
>>> users, who may rely on the current zip settings. Or maybe what we have in
>>> the zip is clearly wrong and doesn't follow our own intent. I expect we'll
>>> probably see a little of each category, although hopefully some changes for
>>> WF 11 removed the "clearly wrong and doesn't follow our intent" cases. :)
>>>
>>> On Tue, Nov 28, 2017 at 8:37 AM, Romain Pelisse <belaran(a)redhat.com>
>>> wrote:
>>>
>>>> Hi,
>>>>
>>>> As reported on JBEAP-12374[1], there is some discrepancies between the
>>>> ZIP file we provided for Widlfy/EAP and the RPM generate. Most of those
>>>> discrepancies - or the most relevant ones, are some fine tuning performed
>>>> on the (POSIX) privileges (things such as removing the write privilege for
>>>> member of the same group as the owner of the file).
>>>>
>>>> I've looked into this and because those files are produced by our own
>>>> Maven plugin (as part of wildfly-build-tools), we can not simply modify the
>>>> assembly.xml. Which actually is probably for the best, as it would made the
>>>> assembly file quite cumbersome.
>>>>
>>>> Anyhow, I've worked on a proposal[2] for the wildfly-build-tools, but
>>>> when I reported the problem on WFLY-9574[3], Brian suggested I started a
>>>> discussion here. So does anyone have a (strong) opinion about this issue
>>>> and/or how to resolve it ? :)
>>>>
>>>> (For the record, I do think it is best to fix the privileges to follow
>>>> what the RPM does for us for now, but if you feel this issue should not be
>>>> addressed, and dev- the issue, I'm certainly not opposed to it either).
>>>>
>>>> [1] https://issues.jboss.org/browse/JBEAP-12374
>>>> [2] https://github.com/wildfly/wildfly-build-tools/pull/40
>>>> [3] https://issues.jboss.org/browse/WFLY-9574
>>>>
>>>> _______________________________________________
>>>> wildfly-dev mailing list
>>>> wildfly-dev(a)lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>>
>>>
>>>
>>>
>>> --
>>> Brian Stansberry
>>> Manager, Senior Principal Software Engineer
>>> Red Hat
>>>
>>
>>
>
>
> --
> Brian Stansberry
> Manager, Senior Principal Software Engineer
> Red Hat
>
--
Brian Stansberry
Manager, Senior Principal Software Engineer
Red Hat
6 years, 9 months
Upgrading Bean Validation and Hibernate Validator in WildFly 12
by Guillaume Smet
Hi everyone,
(posted with the wrong address a few days ago and then stuck in the
moderation queue, please discard the one in the moderation queue)
As mentioned by Gunnar in a previous thread, we would like to upgrade Bean
Validation and Hibernate Validator in WildFly 12.
I created a PR before the holidays:
https://issues.jboss.org/browse/WFLY-9615
(there are some test failures on Linux but I don't think they are related
to the PR as the other builds are passing)
BV 2.0 and HV 6.0 are highly compatible with the previous versions: we
removed a few advanced features marked as experimental as they have now
been included in Bean Validation in another form, but, apart from that, the
upgrade should go smoothly for the users.
We have released HV 6.0 at the beginning of August and it has matured since
then (we are at 6.0.7.Final).
Our migration guide is here: https://developer.jboss.org/wiki/
HibernateValidatorMigrationGuide .
Two important things to note:
- the groupId of Hibernate Validator has changed: it was org.hibernate, it
is now org.hibernate.validator. I added the according banned dependencies
in WildFly to be sure we don't ship both;
- in 6.0.6.Final, we reintroduced some API/configuration knobs that were
removed in prior versions of 6.0. We deprecated them in 5.4 but as WildFly
has never shipped 5.4, we thought it was better to keep them for 6.0 and
remove them later (so that we have at least once WildFly version with the
deprecation).
Apart from the new features brought by Bean Validation 2.0, we worked on
reducing the memory footprint of HV and improving the performances so it
would be nice to bring all that to our WildFly users.
Feedback welcome.
--
Guillaume
6 years, 9 months