Re: [wildfly-dev] Could a wildlfy jira be reviewed, if possible?
by Panagiotis Sotiropoulos
Hello,
How about removing the "ear exclusion" line (https://github.com/wildfly/wildfly-core/pull/1317/files#diff-9ed4135f0f37...) and keeping the rule of not adding the Service Activator files in the parent modules of the ones where the Service Activator classes are included? That means closing https://issues.jboss.org/browse/WFCORE-1234 and keeping https://issues.jboss.org/browse/WFCORE-1235.
Regards,
Panagiotis
----- Original Message -----
From: "David M. Lloyd" <david.lloyd(a)redhat.com>
To: "Stuart Douglas" <sdouglas(a)redhat.com>, "Brian Stansberry" <brian.stansberry(a)redhat.com>
Cc: "Jason T. Greene" <jason.greene(a)redhat.com>, "Panagiotis Sotiropoulos" <psotirop(a)redhat.com>
Sent: Tuesday, June 14, 2016 3:15:32 PM
Subject: Re: Could a wildlfy jira be reviewed, if possible?
True but this is not ideal because instantiating the activator might
have side-effects. I think looking in VFS is the right way to do this.
On 06/13/2016 07:11 PM, Stuart Douglas wrote:
> I guess there is a slightly more hacky way to approach this where you
> just ensure that the resulting ServiceActivator's ClassLoader is the
> same as the module class loader, although this will result in
> ServiceActivators being instantiated multiple times but then not
> actually used.
>
> Stuart
>
> On Tue, Jun 14, 2016 at 10:09 AM, Stuart Douglas <sdouglas(a)redhat.com> wrote:
>> Firstly the PR itself is crap, just checking if the deployment name
>> ends with ".ear" is not the correct way to do things, and it does not
>> even fix the underlying problem (which is caused by ServiceActivator
>> files being visible from multiple deployments).
>>
>> I think your interpretation of what the semantics should be is
>> correct. I think the only real way to implement this however is to
>> change from using Module.loadServices() to using VFS based discovery
>> to get more control over the loading process.
>>
>> Stuart
>>
>> On Tue, Jun 14, 2016 at 1:08 AM, Brian Stansberry
>> <brian.stansberry(a)redhat.com> wrote:
>>> Hi David, Jason, Stuart:
>>>
>>> We need to decide how to deal with these PRs. AIUI that means deciding what
>>> are the supported semantics and then what changes are needed to meet those.
>>>
>>> IMO it seems like the semantics should be simple. For each
>>> META-INF/services/org.jboss.msc.service.ServiceActivator file in the overall
>>> deployment, the service gets activated once and only once. If there are 2
>>> such files that install the same service, we execute both, there's a
>>> DuplicateServiceException, and the user fixes their deployment.
>>>
>>> On 6/13/16 8:41 AM, Panagiotis Sotiropoulos wrote:
>>>>
>>>> Hello Mr Brian,
>>>>
>>>> Could you please review https://issues.jboss.org/browse/WFCORE-1235,
>>>> https://issues.jboss.org/browse/WFCORE-1234 (they have the same PR). It is
>>>> related to https://bugzilla.redhat.com/show_bug.cgi?id=1286272 (which is
>>>> related to https://bugzilla.redhat.com/show_bug.cgi?id=1292044 (VERIFIED)).
>>>>
>>>> Thank you in advance.
>>>>
>>>> Best Regards,
>>>> Panagiotis Sotiropoulos
>>>>
>>>
>>>
>>> --
>>> Brian Stansberry
>>> Senior Principal Software Engineer
>>> JBoss by Red Hat
--
- DML
7 years, 10 months
Managed exploded deployments
by Brian Stansberry
Emmanuel Hugonnet has been working on a long requested feature to have
WildFly support "managed exploded deployments." We have a requirements
analysis doc for this at https://developer.jboss.org/docs/DOC-55497 and
I just wanted to point that out to the list so anyone interested can
have a look, and comment on this thread or on the document.
A managed deployment is one where the user provided content is copied by
the server/host controller into its internal content repo and then
thereafter that copy is what is used. I estimate that 99%+ of all zipped
deployments in WildFly are managed. With an unmanaged deployment the
user provides the server with the local FS path to the content and then
the server directly uses that content. All exploded deployments are
unmanaged, as we don't support managed yet.
We propose to add 5 new operations to the deployment resource:
explode (to convert and archive deployment to exploded)
add-content
update-content
remove-content
read-content
There is one "nice-to-have" requirement listed on the doc where I'm
increasingly thinking it needs to be a hard requirement, so thought on
this are appreciated:
"The explode operation can take an optional path parameter, the value of
which is a path within the deployment that should be exploded.
* The use case for this is scenarios like an exploded ear that
contains an unexploded war, and then the user later wishes the war to be
exploded.
* This is much closer to a hard requirement if the nice-to-have
requirement for recursively exploding is not supported.
* This operation will fail if the content referred to by the path
parameter is already exploded or is not a zip file.
* This operation will fail if any content between the root of the
deployment and the content referred to by the path parameter is an
unexploded archive.
* So,
/deployment=foo.ear:explode(path=/thewar.war/WEB-INF/lib/thejar.jar)
would fail if thewar.war hadn't previously been exploded."
--
Brian Stansberry
Senior Principal Software Engineer
JBoss by Red Hat
7 years, 10 months
A few questions about the NoSQL MongoDB client subsystem configuration...
by Scott Marlow
[1] is an example of the MongoDB subsystem configuration (work in
progress), that specifies three different connection profiles
(mongodbtestprofile_ack, mongodbtestprofile_unack,
mongodbtestprofile_custom). It should be easy for users to specify one
of the MongoDB constants for the write-concern setting, for each of the
MongoDB profiles. Specifying a custom write-concern is also possible
(see mongodbtestprofile_custom and underlying MongoDB java driver api [2]).
In [1], I prefer the first configuration example that names the custom
write-concern element "custom-write-concern", as I thought it might be
confusing if users used the same "write-concern" name in two different
places, however, using "write-concern" for both, could be more consistent.
Should we use "custom-write-concern" or "write-concern" for the custom
configuration element?
It comes down to a choice between:
<mongo ...>
...
<custom-write-concern name="default” w=“1” j=“true” wtimeout=“1”/>
</mongo>
OR
<mongo ...>
...
<write-concern name="default” w=“1” j=“true” wtimeout=“1”/>
</mongo>
For those not reading [1], we also can support one of the predefined
write-concern constants via:
<mongo ... write-concern="ACKNOWLEDGED">
...
</mongo>
Also, is the 'name="default"' setting required for addressing specific
elements with the CLI tool? I assume this is the case but don't
remember for sure.
Thanks for the input/discussion! :-)
Scott
[1] https://gist.github.com/scottmarlow/6895f15219ca16a5bc95fc19ef5b397e
[2]
https://api.mongodb.com/java/3.1/com/mongodb/WriteConcern.html#WriteConce...
7 years, 10 months
WildFly call to sp_reset_connection on SQL Server 2008 R2
by Jorge Solórzano
Hi,
I'm using Microsoft SQL Server JDBC Driver 4.2 with WildFly 10, and looking
at https://msdn.microsoft.com/en-us/library/ms378484.aspx there is a note
about connection pooling:
The JDBC driver does not currently call the sp_reset_connection stored
> procedure when it returns the connection to the pool. Instead, the driver
> relies on third-party Java Application Servers to return the connections
> back to their original states.
>
**I
create a trace
and
that sp is not executed
when the connection is returned to the pool,
this should be called explicitly in my app or the Application Server
should do it?
7 years, 10 months
WildFly Plugin Core Project
by James Perkins
Hello All,
I've been asked a few times about creating a WildFly Plugin Core project
with some of the utilities from the wildfly-maven-plugin. Since it came up
twice today alone I'm wondering if we should have a separate
wildfly-plugin-core project.
This would be useful if we wanted to have a Gradle or SBT plugin as well.
Maybe it's useful for JBoss Tools too. WildFly Arquillian could use it too.
The idea would be to separate out the code that creates the deployment
operations as well as the code that creates and launches a container
process (maybe). Also expose of the helper stuff done to check the status
of a sever, get all the server groups of a managed domain, etc. It would
probably be fairly small overall. Essentially just some utilities that
create some common operations so consumers don't need to know how the
operation needs to be constructed.
If it sounds reasonable the next step would be to determine if it should be
it's own project or just a maven module in the wildfly-maven-plugin. The
only reason I'd lean towards it's own project is to keep the release stream
separate from the wildfly-maven-plugin.
Thoughts?
--
James R. Perkins
JBoss by Red Hat
7 years, 10 months
Elytron Subsystem Review
by Darran Lofthouse
At some point (unless Jason agrees core does not need the subsystem) we
are going to be looking to move the Elytron subsystem over from it's
isolated repository into the wildfly-core repository, to make that
process less painful and also to start giving other teams more
confidence in it's stability I was thinking if we should start reviewing
the subsystem early.
This isn't a call for everyone to check out the whole subsystem and
comment on it all as we know there are some resources in there still to
be re-worked.
However on the Elytron team we know which pieces are stable / reaching
stability so I was thinking if we were to start grouping related
resource maybe by capability we could set up some smaller reviews.
Ideally then when I submit the PR to merge into wildfly-core the actual
content of the subsystem should be reviewed already and the review of
that PR should be more about how it is fitting into the wildfly-core
maven project structure.
If others are interested in this I will see how we can start to chop it
into review-able chunks.
Regards,
Darran Lofthouse.
7 years, 10 months
JavaMail provider module and jboss-deployment-structure.xml
by Carl Harris
I have a custom JavaMail provider installed as a module in Wildfly 10.
In the configuration, I specify a mail session using the custom provider like this:
<mail-session name="rcpt" jndi-name="FixedRecipient">
<custom-server name="FixedRecipient">
<!-- configuration properties hee -->
</custom-server>
</mail-session>
If I make the provider a global module in the configuration, a deployment can successfully use the provider.
However, if I specify the provider as module dependency in jboss-deployment-structure.xml, when trying to create a javax.mail.Session using the provider, a NoSuchProviderException is thrown (as though the base Session implementation cannot find a META-INF/javamail.providers mapping that identifies the custom provider).
I don't know whether specifying the provider as a deployment structure dependency should work or not, but it seems like it should.
Can someone please explain?
carl
7 years, 10 months
