October 2008 - jboss-dev-forums - Jboss List Archives

[Design of EJB 3.0] - Re: jboss.entity.manager.factory.jndi.name

by iradix

I think the trick is to place <property name="hibernate.transaction.factory_class" value="org.hibernate.transaction.JTATransactionFactory"/> | | <property name="hibernate.transaction.manager_lookup_class" value="org.hibernate.transaction.JBossTransactionManagerLookup"/> within the properties section of the persistence.xml file. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4185844#4185844 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4185844

15 years, 10 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: Merged ClassInfo annotation view?

by scott.stark＠jboss.org

The problem is ManagedObjects are not created for the component deployment units as the parent deployment unit KernelDeployment metadata exposes the List beanFactories managed property. For a given BeanMetaData I need the component MetaData that overrides it. I don't see how I get this in a general way such that a single ManagedObjectCreator implementation can be used. I'll have to create a KernelDeployment specific implementation. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4185843#4185843 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4185843

15 years, 10 months

1
0
0 / 0

[Design of Clustering on JBoss] - Re: JBAS-6089: Disable Client Auto-Discovery By Default?

by bstansberry＠jboss.com

This is too big of a change in behavior to implement in the community 4.x series or in EAP 4.x. It's also too big of a change to make for 5.x, as such a large change would have to go in 5.0.0 and it's too late in the release process to do that.. Not that I want to, as there is a valid workaround, one which involves a best practice anway. I could consider the change for AS 6, but would need to be convinced that the workaround is inadequate and the potential disruption is justified. The workaround for AS 5 is, as you said, to use -u to assign a distinct multicast address to each cluster. This is a best practice, regardless of this HA-JNDI issue. Doing this will prevent server nodes responding to discovery packets from clients not specifically configured to use the correct multicast address via the jnp.discoveryGroup naming environment property. That same solution can be used in AS 4.x and EAP 4.x as well, although it is less reliable due to the "PromiscuousTraffic" problem discussed at http://www.jboss.org/community/docs/DOC-11710. AS 5.0.0.GA will include a fix for that problem in the HA-JNDI service. Another solution is to change the HA-JNDI service's "AutoDiscoveryGroup" config from the default 1102, using a different value in each cluster. Then configure clients to use the correct port via the jnp.discoveryPort naming environment property. A third solution is, of course, to turn off autodiscovery on the server side via the HA-JNDI "DiscoveryDisabled" property. The -u solution though is the one that comes closest to "working out of the box" as it involves no config file changes. anonymous wrote : * Use of the -g run.bat/run.sh command line argument as the client will only accept replies from "DefaultPartition" clusters by default. This workaround won't work, as that's not the way autodiscovery is handled. If on the client side you configure jnp.partitionName, that value is included in the auto discovery packet. If not configured, no name is included. It's on the server-side that the validation check is performed, and the absence of a name is treated as a wildcard, i.e. a response is returned. So, to take advantage of -g to prevent invalid responses, jnp.partitionName would have to be configured on the client side. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4185842#4185842 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4185842

15 years, 10 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: Merged ClassInfo annotation view?

by scott.stark＠jboss.org

Its the BeanMetaDataDeployer, there is no ManagedObjectCreatorDeployer any longer. The ManagedObjectCreator implementation plugs into the DeployersImpl and processes every DeploymentContext passed in from the MainDeployer. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4185841#4185841 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4185841

15 years, 10 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: Merged ClassInfo annotation view?

by alesj

"scott.stark(a)jboss.org" wrote : In fact, there MetaData obtained from the DeploymentUnit.getMetaData does not have anything it appears. | It should only appear on components. Does your deployer have setComponentsOnly(true) or setWantComponents(true)? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4185838#4185838 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4185838

15 years, 10 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: Merged ClassInfo annotation view?

by scott.stark＠jboss.org

I have all of the changes in deployers and managed, but as I'm testing these in jbossas I don't see the BeanMetaData annotations showing up in the MetaData for the deployments. In fact, there MetaData obtained from the DeploymentUnit.getMetaData does not have anything it appears. I'm using the current jboss-deployers trunk code and jboss-managed trunk where I have the changes locally. I'm going to drill down into why there is nothing in the MetaData tree. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4185834#4185834 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4185834

15 years, 10 months

1
0
0 / 0

[Design of Clustering on JBoss] - JBAS-6089: Disable Client Auto-Discovery By Default?

by jiwils

It's been requested that in future JBoss releases, the use of auto-discovery by clients be disabled by default. JBAS-6089 [1] captures this feature request, and this forum thread is for capturing the discussion surrounding this JIRA. Essentially, in the cases where the provided JNDI URL isn't available, auto-discovery can cause unexpected behavior as it is possible to connect to clusters that have nothing to do with the client. Potential workarounds are: * Use of the -g run.bat/run.sh command line argument as the client will only accept replies from "DefaultPartition" clusters by default. * Use of -u run.bat/run.sh command line argument as this causes the auto-discovery service to listen to the specified multicast address rather than the default so it won't get the client request in the first place. Thoughts? [1] https://jira.jboss.org/jira/browse/JBAS-6089 View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4185832#4185832 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4185832

15 years, 10 months

1
0
0 / 0

[Design of EJB 3.0] - Re: jboss.entity.manager.factory.jndi.name

by atamur

thanks for advice. but when i do that i get: The chosen transaction strategy requires access to the JTA TransactionManager seems that <persistence:entity-manager-factory name="myPersistenceUnit"/> is working outside J2EE container ... View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4185829#4185829 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4185829

15 years, 10 months

1
0
0 / 0

[Design of EJB 3.0] - Re: Bringing in ejb3-cache

by ALRubinger

Oh boy, so now we've got: * The Legacy Cache stuff in EJB3 Core * Carlo's SPI in ejb3-cache * Brian's ha-server-cache-jbc, which implements ha-server-cache-spi, which isn't an extension of ejb3-cache... So I need to know in which direction we're moving. For now I'll just get enough hooks in there so I can take the Thread.sleep()s out of the tests and resolve EJBTHREE-1551. S, ALR View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4185827#4185827 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4185827

15 years, 10 months

1
0
0 / 0

[Design of POJO Server] - Re: JBAS-6104; slow Seam deployments

by alesj

"stan.silvert(a)jboss.com" wrote : | Can you be more specific about the messages I should see? | In boot log: | 16:00:56,625 INFO [VFSCacheFactory] Initializing VFSCache [org.jboss.virtual.plugins.cache.TimedVFSCache] ... | 16:00:56,625 DEBUG [TimedVFSCache] Creating timed cache policy, lifetime: null, threadSafe: true, resolution: null | View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4185814#4185814 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4185814

15 years, 10 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-dev-forums October 2008