[JBoss Seam] - Small Seam code optimization suggestion
by ylazzari
Hi,
I was profiling my web application and I took note of some little modifications that could be done in the Seam code that in my opinion would improve performance a little bit. Mind you this is just a little bit but I'll take every milliseconds I can get! I don't mean to critisize or anything. They are just suggestions.
#1:
During the execution of one JSF request, I noticed a lot of calls to the org.jboss.seam.Component.hasAnnotation method. Couldn't this information be cached somewhere? I know the reflection API is quite fast but in this particular context, couldn't all the "metadata" of a component be stored as class members of the Component class? I know some if already is but I found something that could be added. In the org.jboss.seam.contexts.ServerConversationContext class, the following method seems to be called hundreds of times per request:
| private boolean isPerNestedConversation(String name)
| {
| Component component = Component.forName(name);
| return (component != null) && component.beanClassHasAnnotation(PerNestedConversation.class);
| }
|
Could't a "perNestedConversation" class member be added on the org.jboss.seam.Component class and initialized when initializing the component instead of looking for the annotation every time? This is just one example. I haven't looked everywhere where the org.jboss.seam.Component.hasAnnotation is called but perhaps similar optimizations could be done elsewhere.
#2:
In my particular project, I disabled Seam's transaction management by setting the "transaction-management-enabled" attribute to "false" on the "core:init" element in a components.xml file. Basically, I don't want Seam to do anything as far as dabatase transaction and entites are concerned. In the org.jboss.seam.Component.hasAnnotation.initDefaultInterceptors method, certain interceptors that pertain to transaction management are still added. Again, this is a small detail but the ones that bug me are the RollbackInterceptor and the ManagedEntityIdentityInterceptor. Well, maybe they're not necessarily related to transaction management but anyways, both of them wind up doing lookups in the JNDI tree for a transaction (through various methods of the org.jboss.seam.transaction.Transaction class) and I don't have any set. I'd like to get rid of these unnecessary JNDI lookups. Perhaps adding a check for org.jboss.seam.core.Init.instance().isTransactionManagementEnabled() in the org.jboss.seam.Component.hasAnnotation.initDefaultInterceptors method before adding those 2 interceptors would do the trick?
That's it for now. Again, I know it's not much but a couple of milliseconds here and there amount to something in the end.
Thanks.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4088201#4088201
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4088201
18 years, 7 months
[Installation, Configuration & DEPLOYMENT] - Re: JBOSS prompting for XDB Username password.
by StevenTowler
The other option is to move the XDB port if no one is already using it. Below are some instructions from some documentation I have lying around:
anonymous wrote :
| 1. Logon to the database as SYS
| 2. Using SQL*Plus change the HTTP port from 8080 to 8081 using the command:
| SQL> call dbms_xdb.cfg_update(updateXML(dbms_xdb.cfg_get(),
| '/xdbconfig/sysconfig/protocolconfig/
| httpconfig/http-port/text()',8081));
| 3. Using SQL*Plus change the FTP port from 2100 to 2111 using the commands:
| SQL> call dbms_xdb.cfg_update(updateXML(dbms_xdb.cfg_get(),
| '/xdbconfig/sysconfig/protocolconfig/
| ftpconfig/ftp-port/text()',2111));
| SQL> commit;
| SQL> exec dbms_xdb.cfg_refresh;
| 4. Using SQL*Plus verifying the changes have taken effect using the commands:
| SQL> set long 100000
| SQL> set pagesize 1000
| SQL> select dbms_xdb.cfg_get from dual;
| 5. After the port numbers have changed install JBoss using the default
| configuration with port number 8080.
| 6. Perform tests to ensure that JBoss is working properly.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4088200#4088200
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4088200
18 years, 7 months
[JBoss Seam] - Re: Layering the code in Seam
by magoicochea
First of all sorry to BUMP this topic again, is just that I had been busy the last month and I forgot to check it.
I tried to look on the wiki, but I did not find the example fernando_jmt mentioned. I don't think that I need a DAO (after all I have read that they don't seem to be useful on Seam although you can use them)
For example for a person maintenance page I would like to have this classes (plus the interfaces that may be needed)
Presentation Layer: Manages all the presentation logic for this page.
Business Layer: Manages all the business logic for the class
Data Layer: Manages all the logic related to storing the object on the database.
I think that maybe I could use the manager bean as the presentation layer object and create there the entity manager and send it as a parameter to the other layers when invoking the methods along with the entity bean, so I would end up having something like this:
Presentation:
public void savePerson(EntityManager em,Person person)
{
//apply presentation logic
personBusiness.savePerson(em,person)
}
Business:
public void savePerson(EntityManager em,Person person)
{
//apply business logic
personData.savePerson(em,person)
}
Data:
public void savePerson(EntityManager em,Person person)
{
//apply data access logic
savePerson(em,person)
}
I like how the code ends up separated because I think it is easier to maintain, however, my intuition tells me that this is not the right way to do this on Seam and that this may end up being inefficient. For example, when developing with hibernate I create the session on the business layer, not on presentation and I think that there may also be some features from Seam that makes this easier.
At the end of the day what I don't like about the examples I saw was that they tend to mix this three layers in just one class, which seems a little messy to me on large projects. If someone could provide me with a simple CRUD example for this I would be very thankful.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4088199#4088199
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4088199
18 years, 7 months
[EJB 3.0] - Re: sharing state between web modules and ejb modules
by ALRubinger
On both accounts, the short answer is: that's entirely up to you.
If both web modules, the application, and the MDB are deployed in the same JVM, that should make things easier for you; you'd be able to make a central registration point (probably backed by a Map so you can do key-based lookups) to hold the SFSB stubs such that they could be obtained from either webapp (remember, only one can have access to any one stub at a time).
As for the MDB listener - I haven't seen the size of this SFSB, but if its small enough you could probably send it as a field of a POJO in an ObjectMessage. Or have the MDB do the lookup just as the webapps are through the centralization.
Again, I don't have your specs...the above are simply some ideas that jumped out at me without fully analyzing your particular problem.
And of course, be sure to call your @Remove method on the SFSB when you're done with it.
S,
ALR
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4088193#4088193
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4088193
18 years, 7 months