vo.blinn (24) [Avatar] Offline
#1
Examples, accompanying this book, presumably (wasn't able to get them since the published link is broken [please, see errata]) contain ant @ 1.6.5 (as shown on Figure 1.10).
The Q is: does it still make sense to refer to that version of the tool when 1.7 is available for quite some time?

Many thanks!
javidjamae (28) [Avatar] Offline
#2
Re: Comment
The accompanying code is not available yet, but should be soon. I will look into getting the scripts working with 1.7.

Thanks,
Javid
vo.blinn (24) [Avatar] Offline
#3
Section 2.2.1 is devoted to logging using log4j.
Today's developers are less familiar with that non-standard package, as
with native JDK logging.
Besides, startup option allows to choose between the 2 as in:
. un --log=jdk --configuration=prod

It is well understood that original JBoss logging was done in pre java.util.logging era.

It might make sense to consider moving both log4j and JDK configurations into an appendix.

Thank you.
vo.blinn (24) [Avatar] Offline
#4
Table 3.6 ( p. 65 of my copy) has the following rows:

jboss.jca:name=XXX,service=LocalTxCM

Manages the connection manager, which is responsible for
the connection pool. You can use this MBean to manage
various aspects of distributed transactions, such as the local
XA resource transaction timeout value.

jboss.jca:name=XXX,service=XATxCM

Manages the connection manager, which is responsible for
the connection pool. You can use this MBean to manage
various aspects of distributed transactions, such as the
distributed XA resource transaction timeout value.

jboss.jca:name=XXX,service=NoTxCM

Manages the connection manager, which is responsible for
the connection pool.

(as was mentioned earlier, mailer defaces tables)

service values give a hint that they might relate data source transaction type (table 3.4).
If true, then is it possible to have more than one "connection manager" MBean per DS?

Thank you,
vo.blinn (24) [Avatar] Offline
#5
Re: Comment
It is probably in some JBoss document, where remote client connectivity is described.

For the completeness, would it be beneficial to include a section outlining connectivity/lookup differences between within same and from different VM? Maybe an appendix will suffice.

Thank you.
PeterJ (83) [Avatar] Offline
#6
Re: Comment
You get only one of the three MBeans - Local, XA or No. The MBeans are automatically generated by the server when the *-ds.xml fiel is deployed.
PeterJ (83) [Avatar] Offline
#7
Re: Comment
Based on comments from posts in the JBoss forums, the vast majority (99%+) of users use Log4j in their own apps, therefore I am fairly confident that our readers will be familiar with it. I will consider adding in something about switching logging providers, but be aware that we are currently way over our page count on the book and are looking to remove, not add, things.
PeterJ (83) [Avatar] Offline
#8
Re: Comment
Regarding connectivity, do you mean looking up things in JNDI? There is a JNDI appendix.
vo.blinn (24) [Avatar] Offline
#9
Re: Comment
However, from the table's name: "Mbeans created for a datasource", it is not clear that
that it is an OR.
Or, maybe, it is my reading.

Thank you, Peter!
vo.blinn (24) [Avatar] Offline
#10
Re: Comment
Well, people who were on JBoss from the good old days are, most likely, on L4J.
Projects we are running, with JBoss being just one of the potential deployment targets,
implement standard logging.
My understanding is that JBoss newcomers is your target audience. That's being the case,
sampling logging habits from JBoss forums is, probably, not quite reflective.

However, my point is not to argue with you, but to make a reasoned suggestion.

Bringing volume argument to justify completeness sacrifices should ... stay between you and the publisher.

Again, all is "IMO".
And, yes, many thanks!
vo.blinn (24) [Avatar] Offline
#11
Re: Comment
Appendix A indeed talks about JBossNS and ENC. It should be sufficient, if accompanying source contains a "remote" lookup sample.
In any case, either a referral to that source or a paragraph addressing the case
will be helpful: J2EE is not only about Web.

Thanks!
vo.blinn (24) [Avatar] Offline
#12
Section 8.1.4 has the following stmt: "The JMS Façade makes the Core into a JMS provider. You can provide other façades to implement other messaging systems."

Got a feeling that smth was cut short here: a reference to "other messaging" options existing in J2EE realm or a footnote pointer to another document that discusses building of an alternative facade might be helpful.

Thank you,
vo.blinn (24) [Avatar] Offline
#13
Section 8.2.1 "Coding the Store class" on p. 187, refers to jndi.properties example file somewhere in appendix.
While appendix is not complete, looked through some possible samples in the book
and, indeed, found some.

For example, p. 350 quotes jndi.properties as:
java.naming.factory.initial=org.jnp.interfaces.NamingContextFactory
java.naming.factory.url.pkgs=org.jboss.naming


Page 379, has another version of the file (though related to HA JNDI):
java.naming.factory.initial=org.jnp.interfaces.NamingContextFactory
java.naming.provider.url=192.168.1.140:1099


While my "default" properties file consists of this:
java.naming.factory.initial=org.jnp.interfaces.NamingContextFactory
java.naming.factory.url.pkgs=org.jboss.naming:org.jnp.interfaces


The only thing all 3 have in common - first line.

Hence my Qs:
1. Which one is to be used by a remote client?
2. The one on p 379 should look familiar to those who ever developed a client.
If something similar is intended to be used by the remote client, then how that client can obtain port mapping for the particular server it intends to connect to?
3. What other properties can be provided to the InitialContext and how to discover them?

Many thanks!
PeterJ (83) [Avatar] Offline
#14
Re: Comment
The typical jndi.properties file (which is not yet in the appendix) contains:

java.naming.factory.initial=org.jnp.interfaces.NamingContextFactory
java.naming.provider.url=jnp://localhost:1099
java.naming.factory.url.pkgs=org.jboss.naming:org.jnp.interfaces

Of course, you can replace "localhost" on the second line with the name or IP address of the host running the app server. The port (1099) is the JNDI port. Many time one or more of the lines is missing because the app server does defaults that work.
vo.blinn (24) [Avatar] Offline
#15
Re: Comment
A word on completeness vs. volume (this is not to dictate you how and what to/not to):
if the volume is at premium, consider referring readers unfamiliar with J2EE to the
appropriate tutorials and devoting the book to JBoss v 5 specifics, recipes, follow-me's.

Me going over this book in order to determine whether to recommend it to my developers
(and what level) or, rather, send them to JBoss publications:
don't have a luxury to waste developer's time.
PeterJ (83) [Avatar] Offline
#16
Re: Comment
Yes, that is exactly the kind of information that will be in the front matter (which is not yet in the MEAP download). The book assumes prior Java EE knowledge, and focuses on the filling in the "vendor-specific" things that most general Java EE books and tutorials avoid. The examples we provide are more to have something to use to highlight the configuration possibilities than to provide a "how to" on developing that type of application.
vo.blinn (24) [Avatar] Offline
#17
Re: Comment
Thank you, Peter.

One thing is still missing from "my" vision of a complete picture: ports mapping.
1099 is the default.
What does one need to do to
- change it to some other value?
- discover that change?

Let's assume I have 2 co-located non-federated installations.
I want to run both. How can I discover port mapping for the original
to avoid runtime conflicts?

Thanks!
PeterJ (83) [Avatar] Offline
#18
Re: Comment
Port mapping? Ch 17, section 17.2.2.
vo.blinn (24) [Avatar] Offline
#19
Re: Comment
Thank you for the ports mapping.

Meanwhile, here is another one.


1. Section 8.4 Using Message-Driven POJOs, p. 197
"... on a server configuration that does not support EJB, such as a standalone
messaging server configuration."

While MOM architecture has been discussed in 8.1.1 "Understanding messaging system architectures",
the term "stand alone" messaging server is introduced here for the first time, as all referrals
prior to were viewed as an integral part of the AS, same as, say, Naming server.
That is confirmed by Figure 8.6

Maybe its configuration deserves an introduction at an earlier phase.

2. Earlier on p. 196:
a typo ".. POJOs that be be registered as message ..."
vo.blinn (24) [Avatar] Offline
#20
Section 8.5.1 p. 200, contains the following:
"Finally, modify the persistence service descriptor, postgresql-persistenceservice.
xml. You can find this file in the examples/config directory of the JBoss Messaging
download (note that this file does not come with JBoss AS)."

As was mentioned earlier, I, probably, overlooked, but was not able to find a definition of standalone Messaging and what constitutes it.

Besides, beta 2 tree contains only the following "related" configurations:
null-persistence-service.xml
clustered-mysql-persistence-service.xml
hsqldb-persistence-service.xml

and none of them under examples/config.

Thank you,
PeterJ (83) [Avatar] Offline
#21
Re: Comment
I removed the reference to the standalone messaging server.

I am not sure where you are looking for the *-persistence-service.xml file, but with the JBoss Messaging 1.4.0 CR2 binary download, in the examples/config directory, there are 10 *-persistence-service.xml files, including ones for MySQL and PostgreSQL. (My mentioning "beta 2", I think you are looking in the JBoss Application Server download, and the sentence clearly states that those files are NOT in that download.)