[JBoss JIRA] Created: (AS7-1053) Revisit requirement that realm name needs to match endpoint name with Remoting / Native Interface
by Darran Lofthouse (JIRA)
Revisit requirement that realm name needs to match endpoint name with Remoting / Native Interface
-------------------------------------------------------------------------------------------------
Key: AS7-1053
URL: https://issues.jboss.org/browse/AS7-1053
Project: Application Server 7
Issue Type: Task
Components: Remoting
Reporter: Darran Lofthouse
Assignee: Darran Lofthouse
Fix For: 7.1.0.Alpha1
It is reported that the realm used for the endpoint needs to match the endpoint name - for this reason the realm appears as 'endpoint'
The realm should actually match the name of the realm being used as this is to inform the user of the realm they are using. This may also need expanding to multiple realms in the future so users in different realms can all authenticate against the same resource.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 4 months
[JBoss JIRA] (AS7-2104) TS: Pick the most acceptable test packages organization
by Ondrej Zizka (Created) (JIRA)
TS: Pick the most acceptable test packages organization
-------------------------------------------------------
Key: AS7-2104
URL: https://issues.jboss.org/browse/AS7-2104
Project: Application Server 7
Issue Type: Sub-task
Components: Test Suite
Reporter: Ondrej Zizka
Assignee: Ondrej Zizka
1) Split classes to src/main and src/test ?
This seems to be decided before - integration tests suite has all classes in src/test.
{quote}
(02:35:15) barreiro: When I start I done it that way so that it clear to me what was the test code, the test subject and the resources --- I knew that probably I would have to change the location later.
{quote}
2) Low-level Test packages micro
{quote}
(02:37:51) barreiro: should I create one sub package for each test --- like /web/xxxTestCase --- or stick with the old schema of having web/tests and web/servlets, ... etc.
(02:38:01) ozizka: Not sure if democracy is the principle to follow here, but I'd like devs to agree upon these things. TBD next week
(02:38:41) ozizka: Depends if you reuse them.
(02:39:24) ozizka: But generally, I'd prefer the first approach -
(02:39:53) ozizka: with reused things being placed one level higher, or next to
(02:40:16) ozizka: The structure should reflect test's structure
(02:40:24) barreiro: IMO, democracy is not the way to go in a OSS project :P ... I'll do it the way you ask me to ;)
(02:40:34) ozizka: Ok :)
(02:40:57) ozizka: But anyway - what's your preference?
(02:41:07) ozizka: Or what would suite better for _your_ case
(02:42:42) barreiro: the ultimate goal is that someone from outside can easily understand what's going on. Like me, I just landed in this project. :P
(02:43:58) barreiro: surely that it should reflect the test's structure. but I would rather have a common structure in most modules ...
(02:45:30) barreiro: like, at some level there is a clear list of the tests in the package that is not mixed with other stuff --- be it a list of packages or a test package with all the test classes
(02:45:43) ozizka: Well, 1st option is current practice, I'd stick with that.
(02:46:47) barreiro: and from there should be clear (as possible) what resources are used.
(02:47:34) ozizka: I was thinking about using a mechanism used in Wicket framework, if you know that,
(02:47:57) ozizka: which is, having a mechanism to load resources from places
(02:48:04) barreiro: After a while I start to understand how AS6 is structured ... the problem is that there is too much voodoo in the back that defeats it's purpose.
(02:48:18) ozizka: where the test class is loaded, or it's superclass, etc.
(02:48:45) ozizka: Eventually it could go by packages up. But perhaps too magical for a testsuite
(02:49:10) ozizka: Right. That's the voodoo.
(02:56:27) barreiro: yep. Shrinkwrap and arquilling are great for that. The magic is greatly reduced, without adding much complexity.
(02:58:10) ozizka: One other argument to have the package-per-test separation is that if we decided the other way, moving the files would be easier
{quote}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 4 months
[JBoss JIRA] Created: (AS7-864) Support expressions in interface and socket related configs
by Brian Stansberry (JIRA)
Support expressions in interface and socket related configs
-----------------------------------------------------------
Key: AS7-864
URL: https://issues.jboss.org/browse/AS7-864
Project: Application Server 7
Issue Type: Sub-task
Components: Domain Management
Reporter: Brian Stansberry
Assignee: Brian Stansberry
Fix For: 7.0.0.CR1
Make it possible to fairly easily control socket bindings from the command line. So, we need expression support for:
1) Static interface criteria values (i.e. <inet-address value="${x}"/> and <loopback-address value="${x}"/>
2) The port-offset on a socket-binding-group
3) The multicast address and port on a socket-binding
4) *Perhaps* the default-interface on a socket-binding-group
5) *Perhaps* the interface on a socket-binding
6) The address and port in host.xml's <domain-controller><remote...> element
7) The port in the <management-interface> child elements
8) *Perhaps* the interface in the <management-interface> child elements
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 4 months