JMS queues: default attributes
by Heiko Braun
Looking at the schema schema for the JMS subsystem, I can see the attributes 'durable', 'selector'.
None of them are set. I expect default values for these attributes, no?
[domain@localhost:9999 /] /profile=default/subsystem=jms/queue=testQueue:read-resource(recursive=true)
{
"outcome" => "success",
"result" => {"entries" => ["queue/test"]},
"compensating-operation" => undefined
}
12 years, 11 months
JMS subsystem, clarification needed
by Heiko Braun
[domain@localhost:9999 /] /profile=default/subsystem=jms:read-resource(recursive=true)
{
"outcome" => "success",
"result" => {
"connection-factory" => {
"InVmConnectionFactory" => {
"connector" => {"in-vm" => {"backup-connector-name" => "netty"}},
"entries" => ["java:/ConnectionFactory"]
},
"RemoteConnectionFactory" => {
"connector" => {"netty" => {"backup-connector-name" => "in-vm"}},
"entries" => ["RemoteConnectionFactory"]
}
},
"queue" => {"testQueue" => {"entries" => ["queue/test"]}},
"topic" => {"testTopic" => {"entries" => ["topic/test"]}}
},
"compensating-operation" => undefined
}
Can someone explain JMS resource to me?
What are the "entries" attributes in both cases?
Assuming these are JNDI names, why are they mapped to list types?
Ike
12 years, 11 months
Console: Settings Dialogue
by Heiko Braun
Stan,
In the upper right corner you can find a settings dialogue now.
There isn't much besides the locale to chose from atm.
However it allows you to verify other locales.
If in doubt about the translation (assuming you don't speak german)
then simply provide the bundle descriptor with a default value:
@DefaultStringValue("Server Group")
String serverGroup();
These will then be applied to all bundles that don't provide a value for this particular key.
The keys are by default the method names.
There is an equivalent annotation for message bundles:
@DefaultMessage("Turns left for player ''{0}'': {1}")
String turnsLeft(String username, int numTurns);
Ike
12 years, 12 months
JBoss Invocation Usability Question
by Richard Opalka
Hi Folks,
I'm not the java class file format familiar so asking in public.
Would it be possible to update jboss-invocation generated byte code
so the proxies it generates would be debugable?
I'm facing the usability issue. I have an EJB3 impl class and when
trying
to debug its methods I'm getting the following error in IDE (see
attachment).
Rio
--
Richard Opalka
ropalka(a)redhat.com
JBoss, by Red Hat
Office: +420 222 365 200
Mobile: +420 731 186 942
12 years, 12 months
Console Roadmap, Checkpoint
by Heiko Braun
I've updated the console roadmap here:
http://community.jboss.org/wiki/ManagementConsoleRoadmap
We've reached a point where it has become obvious that we won't be able to
deliver all the requirements with AS 7.0.0.Final (Assuming it's end of May)
Therefore I would suggest the following approach:
- Deliver a reasonable feature set with 1.0.0.Final
This means a focus on core management functionality: What's really important?
- Postpone extended use cases: Deployment & Management plans, User Management
- Everything else goes into a subsequent milestone end of this year
The contents of the Final release need to be time boxed, but I cannot decide on my own what's will be included.
But as food for thought I would suggest we focus on regularly used features and leave out the edge cases:
[Subsystems]
- JCA
- Datasources
- JMS Queues
- Logging
- Web
- WebServices
- [...]
[Common]
- i18n
- Red Hat Look & Feel
IMO, we should aim for the feature that are expected to be frequently used and do them well.
Edge cases will still be covered through the xml files or the CLI.
Again, this is a call for participation. Let us know what you think would be the most frequent use cases.
We already cover deployments, server-group and server instance management. What else?
Ike
12 years, 12 months
Console Beta8
by Heiko Braun
Brian I'll spin another release for your session on Wednesday.
(Configuration and Management with JBoss Application Server 7 Domains)
Unfortunately the upload is broken in Beta7 and there some more management op's
related to the domain concepts.
Let me know if you need anything else.
Heiko
12 years, 12 months
AS7-431: unmanaged content
by Brian Stansberry
Switching to the main as7 dev list as when this is ready it's going to
require some coordination. But first some comments on the patch:
1) Looks like there's a problem with the "relativeTo" handling in
FileSystemDeploymentScannerService:
http://pastebin.com/3PhN3VLg
2) DeploymentFullReplaceHandler in domain-controller needs conversion as
well.
3) ServerDeploymentRepository.addExternalFileReference can disappear. :)
Now the coordination part:
This work will break the existing console and the CLI, so before merging
it we'll need a coordinated change to those (cli is easier since it's
the same code base).
The change this introduces can be conceptualized by looking at the xml
in the JIRA description at [1]
a) the content of a deployment is now represented via a child element,
instead of just the attribute on the <deployment/> element.
b) we support "unmanaged" content, where the child element points to an
archive or exploded directory on the filesystem. Unmanaged means we
haven't slurped the deployment bits into our content repository from
which we will deploy them (and replicate them around the domain if
domain mode is used.) Instead it's the user's responsibility to put the
files where they say they are.
c) the eventual aim is to support associating multiple pieces of content
with a deployment, although this is not currently implemented.
Effect of this is in the configuration model on Carlo's branch, a
resource representing a deployment no longer has a "hash" attribute.
Instead it has a "content" attribute of type ModelType.LIST. Each
element in that list has these attributes:
"hash" -- the sha1 hash for managed content
OR, if "hash" is undefined, meaning content is unmanaged"
"archive" -- ModelType.BOOLEAN indicating whether the unmanaged content
is a zip
"path" -- absolute or relative filesystem path
"relative-to" -- (optional if "path is absolute) name of a system path
against which "path" should be resolved
The "add" and "full-replace" operations for a deployment have analogous
changes. Instead of root level parameters describing the content (e.g.
"hash" or "input-stream-index" or "url") they take a root level
"content" parameter of ModelType.LIST. The elements in the list describe
the content.
We need to decide what to do with the <deployment> element under
<server-group>. I don't see any reason to duplicate all the content
stuff. Simpler is just listing the unique name and whether the
deployment is enabled:
<domain>
<deployments>
<deployment name="foo.ear" runtime-name="foo.ear">
<content id="d37ede977b022a1456ec5e7a5eee07549cb1c414"/>
</deployment>
</deployments>
<server-groups>
<server-group ...>
<deployments>
<deployment name="foo.ear" enabled="true"/>
</deployments>
</server-group>
</server-groups>
</domain>
[1] https://issues.jboss.org/browse/AS7-431
On 4/28/11 10:16 PM, Brian Stansberry wrote:
> My system has been screwed up all afternoon/evening. I'm going to have
> to look at this in the morning. :(
>
> On 4/28/11 3:31 PM, Carlo de Wolf wrote:
>> Test is passing now.
>>
>> https://github.com/jbossas/jboss-as/pull/32 is amended.
>>
>> Carlo
>>
>> On 04/27/2011 06:28 AM, Brian Stansberry wrote:
>>> On 4/26/11 5:07 PM, Brian Stansberry wrote:
>>>> I tested the former using the domain.interactive demo. That's not
>>>> adequate of course. We need to solve knowing when a HostController and
>>>> all its servers are fully up so we can execute proper tests without
>>>> getting spurious failures due to timing.
>>>>
>>>> For the exploded thing, I'll add a variant of
>>>> ServerInModuleStartupTestCase.testFilesystemDeployment(), hopefully
>>>> tonight.
>>>>
>>>
>>> Test added to upstream:
>>> http://github.com/jbossas/jboss-as/compare/54d4c17...b8eb339
>>>
>>>> On 4/26/11 4:24 PM, Carlo de Wolf wrote:
>>>>> Do we have test cases for those things?
>>>>>
>>>>> Carlo
>>>>>
>>>>> On 04/26/2011 10:58 PM, Brian Stansberry wrote:
>>>>>> See https://github.com/bstansberry/jboss-as/commits/AS7-431 for the
>>>>>> small things.
>>>>>>
>>>>>> Before we can merge this though, we need:
>>>>>>
>>>>>> 1) the DeploymentFullReplaceHandlers to work
>>>>>> 2) exploded deployment from the deployments/ dir is broken. We should
>>>>>> convert the FS scanner to add unmanaged content.
>>>>>>
>>>>>> If it's not implemented before this is merged, we need to have a JIRA
>>>>>> for the TODO in domain mode DeploymentAddHandler to deal with
>>>>>> unmanaged
>>>>>> content.
>>>>>>
>>>>>> On 4/26/11 1:46 PM, Brian Stansberry wrote:
>>>>>>> I'm testing this out; have a few comments, but I think the easiest
>>>>>>> way
>>>>>>> to make them is to put them on a branch.
>>>>>>>
>>>>>>> One thing to discuss is the name of this "content" dir. I don't much
>>>>>>> like that name since 1) it's so vague 2) we use the same name in
>>>>>>> other
>>>>>>> places in the dist for the dir where we store managed content. The
>>>>>>> old
>>>>>>> "system-content" in Alpha1 somewhat indicated that it was our
>>>>>>> stuff, not
>>>>>>> theirs. If we're not concerned about that "ours vs. theirs"
>>>>>>> distinction
>>>>>>> and are just trying to create a well-known location for sticking
>>>>>>> unmanaged content, then perhaps "unmanaged-content" ? (I hope someone
>>>>>>> has a better suggestion.)
>>>>>>>
>>>>>>> On 4/26/11 10:21 AM, Carlo de Wolf wrote:
>>>>>>>> Now with domain working.
>>>>>>>>
>>>>>>>> Carlo
>>>>>>>>
>>>>>>>> On 04/26/2011 01:53 PM, Carlo de Wolf wrote:
>>>>>>>>> As Kabir spotted, the domain-controller bits are not working. I'm
>>>>>>>>> working on those now.
>>>>>>>>>
>>>>>>>>> Carlo
>>>>>>>>>
>>>>>>>>> On 04/26/2011 10:15 AM, Carlo de Wolf wrote:
>>>>>>>>>> Please review or pull https://github.com/jbossas/jboss-as/pull/32.
>>>>>>>>>>
>>>>>>>>>> Thanks,
>>>>>>>>>>
>>>>>>>>>> Carlo
>>>>>>>>>> _______________________________________________
>>>>>>>>>> jbossas-pull-requests mailing list
>>>>>>>>>> jbossas-pull-requests(a)lists.jboss.org
>>>>>>>>>> https://lists.jboss.org/mailman/listinfo/jbossas-pull-requests
>>>>>>>>> _______________________________________________
>>>>>>>>> jbossas-pull-requests mailing list
>>>>>>>>> jbossas-pull-requests(a)lists.jboss.org
>>>>>>>>> https://lists.jboss.org/mailman/listinfo/jbossas-pull-requests
>>>>>>>> _______________________________________________
>>>>>>>> jbossas-pull-requests mailing list
>>>>>>>> jbossas-pull-requests(a)lists.jboss.org
>>>>>>>> https://lists.jboss.org/mailman/listinfo/jbossas-pull-requests
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>
>
>
--
Brian Stansberry
Principal Software Engineer
JBoss by Red Hat
12 years, 12 months
