JBoss AS 6.0.0.M1 does not support any EJB 3.1 features.
https://jira.jboss.org/jira/browse/JBAS-7526
View the original post :
http://www.jboss.org/index.html?module=bbop=viewtopicp=4269540#4269540
Reply to the post :
http://www.jboss.org/index.html?module=bbop=postingmode=replyp=4269540
The first and foremost question everybody will ask is: does it contain EJB 3.1
features?
The short answer is: no (keep on reading ;-) ).
Jason Greene wrote : JBoss AS 6.0.0.M1 is the first milestone release of the
community driven AS 6 series. It includes support for certain key technologies
Plugin release 1.0.19, which installs the 1.1.22 bundle into JBoss AS 5.1.0.GA,
is the last release we'll do of the plugin. With the release of JBoss AS
6.0.0.M1 we'll switch over to 'Package Manager'. It will allow us to replace
components on a much finer scale than the Plugin is capable of.
Duplicate post, see
http://www.jboss.org/index.html?module=bbop=viewtopict=164123.
View the original post :
http://www.jboss.org/index.html?module=bbop=viewtopicp=4267060#4267060
Reply to the post :
http://www.jboss.org/index.html?module=bbop=postingmode=replyp=4267060
Alternatively enable tracing on org.jboss.security and get the real exception.
catch(LoginException e)
| {
| // Don't log anonymous user failures unless trace level logging is
on
| if( principal != null principal.getName() != null || trace )
|
It's hardcoded in Ejb3Deployment.registerContainer.
Please file an issue in https://jira.jboss.org/jira/browse/EJBTHREE
Note that this is a low priority. The issue will probably dissipate when the
new deployers come online.
The bean should really have an optional dependency on
The real question is: why did it detect an EJB in the EAR?
jboss.j2ee:ear=MVCCSampleEAR.ear,jar=MVCCSampleEAR.ear,name=PersonManager,service=EJB3
What's the exact layout of the EAR?
View the original post :
http://www.jboss.org/index.html?module=bbop=viewtopicp=4244330#4244330
Reply to the post
An AOP interceptor can access the client address:
https://jira.jboss.org/jira/browse/JBREM-758.
It's not yet available through an EJB API yet:
https://jira.jboss.org/jira/browse/EJBTHREE-902.
So you can write an AOP interceptor, put it into ejb3-interceptors-aop.xml and
push the client
It's actually Weblogic which is faulty here. To determine whether you want to
call-by-value (remote) or call-by-reference (local) we must have a reference to
the appropriate interface.
The construct posted by Jaikiran should work, if not open a Jira.
View the original post :
Sounds like https://jira.jboss.org/jira/browse/EJBTHREE-1520. The associated
unit test is passing fine.
Please post your NPE.
View the original post :
http://www.jboss.org/index.html?module=bbop=viewtopicp=4236616#4236616
Reply to the post :
You can find the latest stuff here:
http://anonsvn.jboss.org/repos/jbossas/projects/ejb3/trunk/embedded/
You may want to checkout all of trunk and build it.
View the original post :
http://www.jboss.org/index.html?module=bbop=viewtopicp=4235397#4235397
Reply to the post :
For AS 5.1 you can use the EJB 3.1 Embeddable prototype
http://www.jboss.org/community/wiki/EJB31Embeddable
The latest version can also deploy datasources and JPA entities.
Properties properties = new Properties();
| container = EJBContainer.createEJBContainer(properties);
|
Already old, because a plugin release has already gone passed. :-)
But here is AS 5.1.0.GA with a new and better EJB 3 implementation:
Rajesh Rajasek wrote : JBoss AS 5.1.0.GA is released and is available for
download.
| http://www.jboss.org/jbossas/downloads/
|
| Along with many bug fixes
That piece of source is here:
http://viewvc.jboss.org/cgi-bin/viewvc.cgi/jbossas/projects/ejb3/tags/jboss-ejb3-core-1.0.0/src/main/java/org/jboss/ejb3/stateless/StatelessContainer.java?annotate=83287
Apparently the business method called can't be found in the AOP Advisor.
Could you try again
By spec res-type is mandatory if no injection target is given. In practice we
can continue without, because it's just a LinkRef to the jndi-name.
Issue a warning, but allow the construct. Create a test case accordingly.
The bug was introduced with:
EJB 3.0 Persistence 5.6.3 wrote : Propagation of persistence contexts only
applies within a local environment. Persistence contexts are not propagated to
remote tiers.
So propagation will not occur if the call is really remote. Calling locally
through a remote interface will propagate the PC.
https://jira.jboss.org/jira/browse/EJBTHREE-1358
https://jira.jboss.org/jira/browse/JBPAPP-1938
This is fixed in the upcoming EJB 3 Plugin and Enterprise Application Platform
releases.
View the original post :
http://www.jboss.org/index.html?module=bbop=viewtopicp=4228431#4228431
Reply to the
There seems to be an illegal configuration in connectadministration-ejb.jar on
which the deployment chokes.
Does it contain a jboss.xml? If so, could you post it?
Would it be possible to attach said jar to EJBTHREE-1751?
View the original post :
It looks like a bug in JBDEPLOYERS. It registers a MBean under the same name
for components from different units.
View the original post :
http://www.jboss.org/index.html?module=bbop=viewtopicp=4226544#4226544
Reply to the post :
Just before the NPE there should a log debug message starting with:
Found endpoint for interface:
If so, please post it.
View the original post :
http://www.jboss.org/index.html?module=bbop=viewtopicp=4224590#4224590
Reply to the post :
Alternatively, if you're on the VDF you can pick up the PersistenceMetaData
attachment from the PerisistenceParsingDeployer.
http://anonsvn.jboss.org/repos/jbossas/projects/jpa/trunk/deployers/src/main/java/org/jboss/jpa/deployers/PersistenceParsingDeployer.java
View the original post :
I disagree:
The JPA consumer (AS / Embedded) has no facility to identify an entity. This is
custom logic per JPA provider.
For example the JPA provider could have a @WhopperEntity which is an extension
to the standard @Entity (extra cheese).
In which case we'll never find it.
View the original
//ValueMetaData inject = builder.createInject(containerMCBeanName, null, null,
ControllerState.DESCRIBED);
| AbstractInjectionValueMetaData inject = new
AbstractInjectionValueMetaData(containerMCBeanName);
| inject.setWhenRequiredState(ControllerState.DESCRIBED);
|
We could bind a 'home' interface and call it 'meta' instead.
View the original post :
http://www.jboss.org/index.html?module=bbop=viewtopicp=4216088#4216088
Reply to the post :
http://www.jboss.org/index.html?module=bbop=postingmode=replyp=4216088
Why doesn't the @PreDestroy on the SeamInterceptor work?
View the original post :
http://www.jboss.org/index.html?module=bbop=viewtopicp=4216089#4216089
Reply to the post :
http://www.jboss.org/index.html?module=bbop=postingmode=replyp=4216089
___
pete.m...@jboss.org wrote : ...
| So, is there a spec'd way to do this? Or a JBoss way?
No and no.
We could create a new interceptor group which allows for ordering on a new
level. But that should not be be limited to Seam so we would need ordering
within that new group as well.
What's the
So why does the AliasDeploymentDeployer add an attachment?
|protected static void addAliasComponent(DeploymentUnit unit,
NamedAliasMetaData alias)
|{
| DeploymentUnit component =
unit.addComponent(alias.getAliasValue().toString());
|
The underlying problem is that we don't have a (JTA) data source deployer in
E-EJB3.
jta-profile needs to move down the food chain. jpa-profile needs to be created
and we need a simple jca-profile for the above. Then ejb3-embedded should be
based on profile3_1 and your set to go.
View the
The EJB 3 1.0.0 release that is available for as a plugin for AS 5.0.0.GA has
also gone into AS 5.0.1.GA.
Rajesh Rajasekaran wrote : JBoss AS 5.0.1.GA has been released and is
available for download at
| http://www.jboss.org/jbossas/downloads/
|
| This is the first bug fixing release
That doesn't work because the bean itself isn't there yet. So right now I
examine the BeanMetaData.
(iterating over mainDeployer.getTopLevel())
private DeploymentUnit findBean(DeploymentUnit deploymentUnit, String
contextName)
|{
| if(deploymentUnit == null)
| return
This bit:
bean name=AnnotationHandlerFactory
| constructor
factoryClass=org.jboss.kernel.plugins.annotations.BeanAnnotationAdapterFactory
factoryMethod=getInstance /
|/bean
|bean name=AnnotationHandler
| constructor factoryMethod=getBeanAnnotationAdapter
|
I need to have deployment unit aware injection / annotations, so stuff like:
@PersistenceUnit
|public void setEntityManagerFactory(EntityManagerFactory emf)
|{
| this.emf = emf;
|}
works within a MC bean while obeying the scoping rules.
@EJB annotations need the same
Non-persistent timers are not supported in the current EJB 3 implementation.
View the original post :
http://www.jboss.org/index.html?module=bbop=viewtopicp=4210042#4210042
Reply to the post :
http://www.jboss.org/index.html?module=bbop=postingmode=replyp=4210042
Would you mind filing a Jira with the code that lead into the
NullPointerException?
I would rather see a proper check, than a NPE.
Thanks.
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=4208098#4208098
Reply to the post :
ALRubinger wrote : ...
| JBossAS 5.0.0.GA shipped with a composite of the EJB3 components, which
together had a release version of 1.0.0-Beta7.
| ...
That is 1.0.0-Beta10. :-)
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=4204639#4204639
Reply to the post
The Embeddable EJB 3.1 is a work in progress.
We did silently release an 1.0.0-Alpha1 which is compatible with AS 5.0.0.GA.
I'm planning to do a 1.0.0-Alpha2 release which is compatible with EJB 3 1.0.0.
For more instructions on how to use: http://wiki.jboss.org/wiki/EJB31Embeddable.
The plan
The aim of the game here is to get one set of stable components which are
certified against EJB 3.0 specs. Since it's a lengthy process to ascertain both
certification and stability I want these components to stay solidly in place
for a long time.
On top of this we'll develop new components to
The final release of JBoss EJB 3 1.0.0 is now available. To use it within JBoss
AS 5.0.0.GA download the provided installer.
http://sourceforge.net/project/showfiles.php?group_id=22866package_id=132063
JBoss EJB 3 1.0.0 is an EJB 3.0 spec compliant implementation for use in JBoss
Application
After injecting PersistenceUnitDependencyResolver, this piece of pseudo code
should do the trick:
String beanName =
persistenceUnitDependencyResolver.resolvePersistenceUnitSupplier(deploymentUnit,
persistenceUnitName);
| PersistenceUnitDeployment deployment = lookup(beanName);
|
A new release of EJB 3 is available bundled in JBoss AS 5.0.0.GA.
Rajesh Rajasekaran wrote : JBoss Application Server 5.0.0.GA has been
released and is available for download.
| http://www.jboss.org/jbossas/downloads/
|
| This is the final
This is probably the culprit:
jboss:jboss-common-core:jar:2.0.2.GA:compile
It probably ends up before org.jboss:jboss-common-core:jar:2.2.8.GA on the
classpath.
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=4190251#4190251
Reply to the post :
[EMAIL PROTECTED] wrote :/**
| | * @return A Map of EJB descriptors, keyed by the EJB bean class
| | */
| |public MapClass?, EjbDescriptor? discoverEjbs();
A bean class can be used by multiple EJBs. So you'll have to come up with
another key.
View the original post :
I've upgraded embedded to use MC 2.0.0.CR5 and applied the workaround. For now
embedded is using core SNAPSHOT.
https://jira.jboss.org/jira/browse/EJBTHREE-1575[/url]
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=4188134#4188134
Reply to the post :
Adrian,
When I call deploymentUnit.addComponent(test); I get back a deployment unit
which signifies component test.
What can I do with this component? How does it differ from a regular deployment
unit?
View the original post :
https://jira.jboss.org/jira/browse/JBMICROCONT-380
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=4187367#4187367
Reply to the post :
http://www.jboss.com/index.html?module=bbop=postingmode=replyp=4187367
___
At least MC should say that we entered a non-deterministic situation and throw
an exception.
I think it would be better to have an UndeterminedConstructorInfo which does
some extra work at the end.
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=4187370#4187370
So far can't find anything different than my own setup except junit, which I
have as:dependency
| groupIdjunit/groupId
| artifactIdjunit/artifactId
| version[4,)/version
| scopetest/scope
| /dependency
What JDK are you using?
View the original post :
It's not the exact same problem, but close.
Usually this indicates that Maven has chosen the wrong dependency somewhere.
Are you using Maven 2.0.9?
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=4186483#4186483
Reply to the post :
Just to be sure: post the output of mvn -Dverbose=true dependency:tree here.
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=4186484#4186484
Reply to the post :
http://www.jboss.com/index.html?module=bbop=postingmode=replyp=4186484
javidjamae wrote : So does anybody have the final word on whether this
functionality will be in JBoss 5 or not?
|
| If it will be in JBoss 5, any ideas on what I am doing something wrong in
my code? Or is the functionality broken right now?
|
| Thanks.
It'll work if you configure JPA
You must use JPA (/ persistence.xml) to get a persistence unit, not Hibernate
directly.
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=4181141#4181141
Reply to the post :
http://www.jboss.com/index.html?module=bbop=postingmode=replyp=4181141
There is no distribution download for 1.0.0-Beta4. This release is meant to be
used within the JBoss AS build process (as is any release of EJB 3 right now).
Although we do have a prototype for a new plugin which can install the latest
EJB 3 into JBoss AS (see
No, but you can always plug-in the EAR deployer.
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=4180473#4180473
Reply to the post :
http://www.jboss.com/index.html?module=bbop=postingmode=replyp=4180473
___
jboss-user
Fixed in rev 61993 (so it's in AS 5 Beta 2). I suggest using AS 5.0 CR2.
PS. You shouldn't access an EJBs EM in another thread. The transaction isn't
propagated, so you'll probably run into interesting problems.
View the original post :
My is guess is you're running into this issue:
https://jira.jboss.org/jira/browse/EJBTHREE-1246.
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=4180212#4180212
Reply to the post :
http://www.jboss.com/index.html?module=bbop=postingmode=replyp=4180212
Yesterday Kenneth announced the public review of the EJB 3.1 JSR
(http://jcp.org/en/jsr/detail?id=318).
I've been mucking around a bit, especially with chapter 22, the Embeddable
Usage. And thus came up with a prototype which should be usable in any Maven
project:
You don't have to alter the application.xml. EE 8.4.2 bullet 1 shows the rules
when you don't have one. Most likely all the jars are correctly designated and
the application will come up.
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=4180292#4180292
Reply to
The following xml:
aop xmlns=urn:jboss:aop-beans:1.0
| bind pointcut=execution(*
org.jboss.ejb3.test.ejbthree1023.AnnotatedLocalBean-woven())
| interceptor class=org.jboss.ejb3.test.ejbthree1023.TestInterceptor/
| /bind
| bind pointcut=execution(*
Yes, this is intended behaviour. The DefaultPersistenceUnitDependencyResolver
only works for spec compliant deployments.
If you want you can plug in your own implementation of a
PersistenceUnitDependencyResolver which goes beyond the spec. But if the other
ear/jar containing the persistence
jaikiran wrote : I haven't given a try with deploying independent jar files.
I have always used a EAR inside which i have the jar(s). Let me see if there is
some issue with individual jar files.
|
| By the way, this looks a bit strange to me:
|
| anonymous wrote : 19:15:40,616 INFO
JeffBrooks wrote : ...
| Wolfc, I assume you agree with the rubbish comment and not with GColeman's
comment about how disappointing JBoss 5 is.
I didn't not expect such a bug to surface in CR2, so I'm just as disappointed
with the situation as you guys. Not using JBoss AS 5 as a workaround
Couldn't agree more. I think the underlying issue is:
https://jira.jboss.org/jira/browse/JBAS-5895, but I want to be sure.
So making sure the actual EJBs are not in a jar which is in lib (optionally
specifying it as an ejb module in application.xml) should resolve the problem.
View the
It appears that for any EJB3 annotated classes found on the ear's classpath the
Ejb3Deployer gets booted. Most likely the OptAnnotationDeployer creates EJB
meta data for the ear.
If possible try to contain the EJB3 classes to an ejb module and make sure it's
not in any library directory of the
As for the exit() not being called:
https://jira.jboss.org/jira/browse/EJBTHREE-1496
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=4177976#4177976
Reply to the post :
http://www.jboss.com/index.html?module=bbop=postingmode=replyp=4177976
First of all for any NullPointerException which doesn't give any message a Jira
can be opened. Preferably with some test code attached that reproduces the
problem.
This NPE is caused by improper specification of the properties in
persistence.xml. You must use the forum code tag if you want to
A new release of EJB 3 is available bundled in JBoss AS 5.0.0.CR2.
Rajesh Rajasekaran wrote : JBoss Application Server 5.0.0.CR2 has been
released and is available for download.
| http://www.jboss.org/jbossas/downloads/
|
| This is the last candidate
|
This is not possible in AS 4.
In AS 5 you can enable scanning of wars by setting the 'scanWars' property to
true in ejb3.deployer/META-INF/ejb3-deployers-jboss-beans.xml
(ejb3-deployers-beans.xml for CR1).
View the original post :
Most likely the message is received before the transaction of the first MDB has
been fully completed. Even when using a transacted session this can happen.
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=4167821#4167821
Reply to the post :
You can use the code that stems from EJBTHREE-619 as a base for your solution.
Change the MBean to suit your own needs and then have it bind a proxy in JNDI
that you can lookup in the bean.
If you want it injectable, then you need to change the ejb3 code itself.
View the original post :
The short answer is: there is nothing yet to replace the old Embeddable EJB3 in
a way that's usable for current scenarios.
Embeddable EJB3 Alpha 9 is an AS 5 Alpha preview (thus has Micro Container in
it). There already where some incompability issues with AS 4 and when AS 5
started moving
You're not missing a configuration setting. It really is not implemented yet.
:-)
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=4167357#4167357
Reply to the post :
http://www.jboss.com/index.html?module=bbop=postingmode=replyp=4167357
The transaction timeout only works if specified on the EJB3 bean itself. Since
you're using a Seam component which delegates to TimerServiceDispatcher (which
is the EJB3), the transaction timeout annotation will not take hold.
View the original post :
Create an issue here: https://jira.jboss.org/jira/browse/JBAS on component
'Scheduling/Timers'.
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=4165297#4165297
Reply to the post :
http://www.jboss.com/index.html?module=bbop=postingmode=replyp=4165297
There are two ways to use Quartz from EJB3:
1. the unsupported EJB3 Quartz timer service:
https://jira.jboss.org/jira/browse/EJBTHREE-619
2. or the Quartz resource adapter:
http://wiki.jboss.org/auth/wiki/QuartzSchedulerIntegration
View the original post :
activation-config-property-name and activation-config-property-value are
designated xsd:string in the xsd. That means that any spaces, linefeeds,
carriage returns and tabs are interpreted literally. So you must remove those
from the descriptor.
View the original post :
You can specify a resource-adapter-name in jboss.xml as shown here:
http://wiki.jboss.org/auth/wiki/ConfigMessageListener
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=4162294#4162294
Reply to the post :
There is this document on recovery modules:
https://www.redhat.com/docs/manuals/jboss/jboss-eap-4.3/doc/jbossts/TX_Core_Failure_Recovery_Guide.pdf
But no extra module should be needed. Do you have a small test case that
exhibits this problem? If so, open a Jira and attach it.
View the original
Given the following code:
@MapValue(keyClass=String.class, value={}, valueClass=String.class)
|public void setDefaultPersistenceProperties(Properties p)
|{
| this.defaultPersistenceProperties = p;
|}
With the following override:
bean name=PersistenceUnitDeployer
Parsing is already done and has finished correctly. This has nothing to do with
XB. It's all about MC juggling meta data.
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=4162028#4162028
Reply to the post :
ch11s01 wrote : Warning
|
| The type of each value must be specified using either the elementClass or
type/class attribute in order for the collection to be created.
Which I already did in the annotation.
I agree that MC is pretty dumb to not be able to create meta data that amounts
to
EntityManagerHelper is trying to create an EntityManagerFactory. This is not
allowed within a JavaEE container.
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=4161238#4161238
Reply to the post :
On a similar note: http://jira.jboss.com/jira/browse/JBMICROCONT-288
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=4151409#4151409
Reply to the post :
http://www.jboss.com/index.html?module=bbop=postingmode=replyp=4151409
A bean annotated with @Service acts as a stateful bean with just one instance
available. So in effect it's the same as a singleton in EJB 3.1. Any lookup or
injection of the service bean will result in an association with that single
instance.
With the use of @Management the service bean will
Is there a notion of hierarchical context within MC?
For example I want to start 2 stateless containers, both need to have a pool.
So I want to install pool 1 into context A and pool 2 into context B. Then
depending on where I install the container it will inject the correct pool with
the same
Sorry for the confusion.
It's not possible to deploy an ear in EJB 3 Embedded.
For Embedded JBoss go to it's forum and ask again.
(It should work though. :-) )
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=4145488#4145488
Reply to the post :
This defines the view that gets exposed (and injected):
@Remote ({GenericsEJBInjection.class})
Not the actual implementing of an interface. So you have two duplicate views in
1 deployment. So the 'workaround' specified by jaikiran is actually the correct
way to resolve it.
View the original
http://jira.jboss.org/jira/browse/EJBTHREE-751
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=4141857#4141857
Reply to the post :
http://www.jboss.com/index.html?module=bbop=postingmode=replyp=4141857
___
jboss-user
ariekenb wrote : After doing this I only see 2 instances of my stateless
session bean created, even in tests where it's called from multiple different
MDBs and directly from clients. It appears StrictMaxPool is much more
conservative in ThreadlocalPool.
|
| doktora - Maybe using
This is a bug in AS 4.2.2 where if it can't find the name in JNDI and there is
no cluster active it will give a NPE instead of NameNotFoundException.
Fixed in AS 5.0.
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=4140558#4140558
Reply to the post :
I'm planning to change this behavior in light of EJB 3.1. The supported way
will be to use @PostConstruct in a @Singleton.
So for now I would say use @PosConstruct in a @Service bean.
Note that the create, start, stop, destroy methods will become deprecated and
might disappear completely.
View
A new release of the EJB 3 module is available bundled into JBoss Application
Server 5.0.0.Beta3.
Rajesh Rajasekaran wrote : JBoss Application Server 5.0.0.Beta3 is out, right
in time for the holidays.
|
| Download it from sourceforge
|
http://jira.jboss.com/jira/browse/EJBTHREE-1118
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=4113946#4113946
Reply to the post :
http://www.jboss.com/index.html?module=bbop=postingmode=replyp=4113946
___
jboss-user
http://jira.jboss.com/jira/browse/EJBTHREE-1071
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=4110115#4110115
Reply to the post :
http://www.jboss.com/index.html?module=bbop=postingmode=replyp=4110115
___
jboss-user
http://jira.jboss.com/jira/browse/EJBTHREE-1118
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=4105420#4105420
Reply to the post :
http://www.jboss.com/index.html?module=bbop=postingmode=replyp=4105420
___
jboss-user
You are calling the entity manager in a NOT_SUPPORTED context from
fetchProcess. If you want the REQUIRES_NEW to take affect, you must call
fetchProcess_real through a business object instead of directly.
View the original post :
This behavior has changed with the implementation of a new ThreadlocalPool. Now
the pool completely cleans up at undeploy and calls @PreDestroy on all session
bean instances.
See http://jira.jboss.com/jira/browse/EJBTHREE-1031
View the original post :
In AS 4.2.2 the ThreadlocalPool does call @PreDestroy on undeploy. This is a
'side effect' of another issue with ThreadlocalPool.
See http://jira.jboss.com/jira/browse/EJBTHREE-1031
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=4100216#4100216
Reply to the
Which annotation are you using to inject the entity manager?
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=4099341#4099341
Reply to the post :
http://www.jboss.com/index.html?module=bbop=postingmode=replyp=4099341
Is persistence.xml located in the META-INF directory of the jar file?
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=4095266#4095266
Reply to the post :
http://www.jboss.com/index.html?module=bbop=postingmode=replyp=4095266
Take a look in ejb3-interceptors-aop.xml. In the Stateful Bean domain, the
cache is configured for clustered and non-clustered beans.
You can either edit this file or add the annotations to your bean.
View the original post :
1 - 100 of 305 matches
Mail list logo
