[Design of EJB 3.0] - Logging JNDI names of beans at INFO level
by jaikiran
Currently, when a EJB3 bean is deployed, the Default local/remote business interface JNDI names are logged at DEBUG level and by default don't appear on the CONSOLE.
This is what i see on the console:
| INFO [JBossASKernel] Created KernelDeployment for: myapp_ejb3.jar
| INFO [JBossASKernel] installing bean: jboss.j2ee:ear=ZEJB3Persistence.ear,jar=myapp_ejb3.jar,name=UserManagerBean,
| INFO [JBossASKernel] with dependencies:
| INFO [JBossASKernel] and demands:
| INFO [JBossASKernel] persistence.unit:unitName=ZEJB3Persistence.ear/myapp_ejb3.jar#EJB3Persistence
| INFO [JBossASKernel] jboss.ejb:service=EJBTimerService
| INFO [JBossASKernel] and supplies:
| INFO [JBossASKernel] Class:org.myapp.ejb.UserManagerRemote
| INFO [JBossASKernel] jndi:ZEJB3Persistence/UserManagerBean/local-org.myapp.ejb.UserManagerLocal
| INFO [JBossASKernel] Class:org.myapp.ejb.UserManagerLocal
| INFO [JBossASKernel] jndi:ZEJB3Persistence/UserManagerBean/local
| INFO [JBossASKernel] jndi:RemoteUserManagerBean
| INFO [JBossASKernel] jndi:ZEJB3Persistence/UserManagerBean/remote-org.myapp.ejb.UserManagerRemote
| INFO [JBossASKernel] jndi:testMappedNameJai
| INFO [JBossASKernel] Added bean(jboss.j2ee:ear=ZEJB3Persistence.ear,jar=myapp_ejb3.jar,name=UserManagerBean,service
|
| .....
| INFO [EJBContainer] STARTED EJB: org.myapp.ejb.impl.UserManagerBean ejbName: UserManagerBean
| .....
|
And in the server.log, we have this useful information at DEBUG level:
DEBUG [org.jboss.ejb3.proxy.jndiregistrar.JndiSessionRegistrarBase] Default Remote Business View for EJB UserManagerBean to be bound into JNDI at "RemoteUserManagerBean"
| DEBUG [org.jboss.ejb3.proxy.jndiregistrar.JndiSessionRegistrarBase] Default Local Business View for EJB UserManagerBean to be bound into JNDI at "LocalUserManagerBean"
|
I have seen some posts in the User forum where the users found it hard to notice these messages in the server.log because of the other logs contained in that file.
Is it OK to change the logging level of these JNDI binding message for the default business interfaces to INFO level?
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4179274#4179274
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4179274
15 years, 7 months
[Design of EJB 3.0] - Re: EJBTHREE-1454 Encapsulate Container infomation in TO/VO
by jaikiran
"ALRubinger" wrote :
|
| "jaikiran" wrote :
| | I just noticed that there is a StatefulSessionInvokableContext (in proxy) which currently implements the InvokableContext. I guess, this should now implement the new InvokableSessionContext. Do you recommend that i change this too?
| |
|
| Yep.
|
Okay, i included this in my changes.
"ALRubinger" wrote :
| If you can verify the clusteredsession tests in TestSuite are OK, than this is good for commit.
|
|
Andrew,
Sorry that this one took really long than what i expected. Mainly because of my lack of understanding on how to get the clustered testcases working in the testsuite. All that i learnt, while trying to get the clusteredsession testcases running, i have noted in this wiki http://wiki.jboss.org/wiki/DevEJB3RunClusteredTestCases. Might help someone else, or even me, the next time i try this :-)
I started off with running the testsuite without including my changes (for EJBTHREE-1454) to get the tests passing and results comparable with the "EJB3 Plugin Against AS5 trunk" http://hudson.jboss.org/hudson/job/EJB3_Plugin_AS_TRUNK/. After a lot of (trial and error) iterations i was able to get them passing and results almost the same as that of hudson (i had a couple of more testcases failing without even including my changes).
I then patched my local JBossAS (Trunk) with the EJBTHREE-1454 changes (followed the "Patch AS" section in this wiki http://wiki.jboss.org/wiki/en/DevEJB3NewPlugin) and ran the clusteredsession testcases again. No new failures/errors were introduced. So the patch looks OK.
Andrew,
Now that the testsuite too looks OK with these changes, do you want me to commit this? Futhermore, the poms that i have changed are:
proxy module:
Index: pom.xml
| ===================================================================
| --- pom.xml (revision 78909)
| +++ pom.xml (working copy)
| @@ -13,7 +13,7 @@
| <!-- Artifact Configuration -->
| <groupId>org.jboss.ejb3</groupId>
| <artifactId>jboss-ejb3-proxy</artifactId>
| - <version>0.1.6-SNAPSHOT</version>
| + <version>0.1.7-SNAPSHOT</version>
| <name>JBoss EJB 3.0 Proxy</name>
| <description>JBoss EJB3 Proxy Component</description>
| <url>http://www.jboss.org/jbossejb3</url>
|
proxy-clustered module (to depend on the proxy's newer version):
| Index: pom.xml
| ===================================================================
| --- pom.xml (revision 78909)
| +++ pom.xml (working copy)
| @@ -90,7 +90,7 @@
| <dependency>
| <groupId>org.jboss.ejb3</groupId>
| <artifactId>jboss-ejb3-proxy</artifactId>
| - <version>0.1.2</version>
| + <version>0.1.7-SNAPSHOT</version>
| </dependency>
|
| <dependency>
|
core module pom (to depend on the newer versions of proxy and proxy-clustered):
Index: pom.xml
| ===================================================================
| --- pom.xml (revision 78909)
| +++ pom.xml (working copy)
| @@ -365,13 +365,13 @@
| <dependency>
| <groupId>org.jboss.ejb3</groupId>
| <artifactId>jboss-ejb3-proxy</artifactId>
| - <version>0.1.6-SNAPSHOT</version>
| + <version>0.1.7-SNAPSHOT</version>
| </dependency>
|
| <dependency>
| <groupId>org.jboss.ejb3</groupId>
| <artifactId>jboss-ejb3-proxy-clustered</artifactId>
| - <version>0.1.3</version>
| + <version>0.1.4-SNAPSHOT</version>
| </dependency>
|
| <dependency>
|
plugin module pom (to integrate these newer version of proxy and proxy-clustered in the JBoss AS):
Index: pom.xml
| ===================================================================
| --- pom.xml (revision 78909)
| +++ pom.xml (working copy)
| @@ -95,14 +95,14 @@
| <groupId>org.jboss.ejb3</groupId>
| <artifactId>jboss-ejb3-proxy</artifactId>
| <classifier>client</classifier>
| - <version>0.1.6-SNAPSHOT</version>
| + <version>0.1.7-SNAPSHOT</version>
| </dependency>
|
| <dependency>
| <groupId>org.jboss.ejb3</groupId>
| <artifactId>jboss-ejb3-proxy-clustered</artifactId>
| <classifier>client</classifier>
| - <version>0.1.3</version>
| + <version>0.1.4-SNAPSHOT</version>
| </dependency>
|
| <dependency>
|
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4179227#4179227
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4179227
15 years, 7 months
[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Why do messages destined for paging not get assigned mes
by clebert.suconic＠jboss.com
The date portion is only used to start the counter.
After the server is started, the counter is added as any other longer. And I don't think any server in the workd would be able to overlap a long counter.
In an hipotetical situation where a server could overlap a long, we would just generate IDs for messages that were already consumed, and that would be ok.
The only problem with the each 397 days, is when the date portion gets close to 7fffffff, what would generate negative IDs after 200 million consumed messages. With the reset on negative values we would be protected against that very edge condition.
20 MS... I just copied that from 1.4.... we could get rid of that. (But we don't use the refresh for nothing but that very edge condition)
As for the negative loop, the above explains it why. That's a protection against a very edge condition that would only happen if you started the server at a very specific millisecond once every 368 days. I think we need to keep it, and I don't think we have anything to worry about it. The ID generation seems safe to me.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4179217#4179217
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4179217
15 years, 7 months
[Design of JBoss Web Services] - Re: Review of fix for JBWS-2304
by richard.opalka＠jboss.com
"darran.lofthouse(a)jboss.com" wrote : Overall I think the mechanism to cache the Document and DocumentBuilder should be re-factored to possibly associate it with the MessageContext and the message itself so that it does not need to be in it's own ThreadLocal with a potential for leaks - however I am not sure if such a bug change would be suitable at the moment.
|
| Anyway I just wanted to see if you have any additional thoughts on this fix before I commit.
|
Hi Darran,
to be honest I don't like our current DOMUtils ThreadLocals capability. ThreadLocals holding thread-specific fields should only be used when there is no other good option available. The following are top two reasons to avoid ThreadLocals:
The use of thread-specific variables tends to hide parameters that influence behaviour and can make it harder to check for errors or leakage. In this sense, thread-specific variables present the same, although less extreme, traceability problems as static global variables.
Use of thread-specific variables can detract from reusability by increasing code dependencies.
In other words if you will refactor our DOMUtils and will remove ThreadLocals dependent code, I will really like your solution ;)
Richard
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4179207#4179207
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4179207
15 years, 7 months