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

by tom.baeyens＠jboss.com

we're in the process of cleaning up jira. all the issues that were not touched for at least a year have been resolved with 'out of date'. if you know of an issue that should not have been closed. feel free to reopen and provide a remark if you think we should reconsider. from now on, we're going to resolve issues instead of close. we have a umbrella issue that links to all candidate tasks to be taken by community members. those issues are sometimes as simple as 1, 2, 3. some are a bit more difficult. that's why the issue is numbered approprietly http://jira.jboss.com/jira/browse/JBPM-1234 enjoy :-) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4158434#4158434 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4158434

16 years, 3 months

1
0
0 / 0

[TODO - DEVELOPMENT] - Re: using mySQL inside EJB

by jquintanam

Hi Pepe, have you put an e.printStackTrace inside the catch to know the exception that is being throwed? If not, try this, maybe can help you. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4158429#4158429 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4158429

16 years, 3 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: BCC in Mail Action

by tom.baeyens＠jboss.com

Awsome ! View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4158425#4158425 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4158425

16 years, 3 months

1
0
0 / 0

[Design of EJB 3.0] - Re: Unit Tests for Unbinding References from JNDI in EJB3 Pr

by ALRubinger

"jaikiran" wrote : 1) I don't see a API which returns me a JndiSessionRegistrarBase, which i can use for calling the unbindEjb. We've got mock Containers in EJB3 Proxy under src/test/java, so if you're installing your EJB into them, this logic is done for ya. :) Check out how the other session tests use these containers. "jaikiran" wrote : Just happened to see this http://www.jboss.com/index.html?module=bb&op=viewtopic&t=137339. I guess that's the reason why the annotations are not being picked up. | Yep. If you want to mock it up, the place to add this logic is in EJB3 Test, MetaDataHelper. Though probably isn't worth the effort; I see that Alexey's tests for JBoss50Creator (the guy responsible for doing this) are now passing, so I'll probably try to change over to use this soon. S, ALR View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4158424#4158424 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4158424

16 years, 3 months

1
0
0 / 0

[Design of EJB 3.0] - MergedJBossClientMetaDataDeployer is not used?

by alex.loubyansky＠jboss.com

I had to add it to the ejb3-deployers-beans.xml to get all the metadata merged <bean name="MergedJBossClientMetaDataDeployer" class="org.jboss.ejb3.deployers.MergedJBossClientMetaDataDeployer"> | <property name="type">car</property> | <depends>AppClientScanningDeployer</depends> | </bean> Is that right or I am missing something? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4158412#4158412 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4158412

16 years, 3 months

1
0
0 / 0

[Design of JBoss Portal] - Re: portal clustering problem when using optimistic locking

by prabhat.jha＠jboss.com

Thanks Galder. I will wait for your findings. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4158402#4158402 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4158402

16 years, 3 months

1
0
0 / 0

[Design of JBoss Portal] - Re: portal clustering problem when using optimistic locking

by galder.zamarreno＠jboss.com

Prabhat, I'll have a look at this in the next couple of days but it's worth noting that with SYNC communication, specially replication, there's always a chance of a deadlock because locks are only acquired at commit time. So, individual nodes could successfully acquire nodes locally, and then cross each other when trying to acquire locks cluster wide. The end result is both nodes timing out in their operation: Example: Tx1 acquires WL on N1 for node /a/b Tx2 acquires WL on N2 for node /a/b Tx1 tries to commit and attempts to acquire lock for /a/b while Tx2 is trying to commit and attempt to lock that same node cluster wide. Tx1 rollbacks because it can't acquire locks for /a/b in N2 and viceversa As I said, I'll check the attached files in the next couple of days to confirm whether this is precisely what you're seeing. However, it's worth keeping it in mind. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4158400#4158400 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4158400

16 years, 3 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Changing the way AbstractVFSDeployment serializes root

by alesj

In AbstractVFSDeployment we do | public void readExternal(ObjectInput in) throws IOException, ClassNotFoundException | { | super.readExternal(in); | root = (VirtualFile) in.readObject(); | } | | public void writeExternal(ObjectOutput out) throws IOException | { | super.writeExternal(out); | out.writeObject(root); | } | I would change it to | public void readExternal(ObjectInput in) throws IOException, ClassNotFoundException | { | super.readExternal(in); | URL url = (URL)in.readObject(); | root = VFS.getRoot(url); | } | | public void writeExternal(ObjectOutput out) throws IOException | { | super.writeExternal(out); | out.writeObject(root.toURL()); | } | that way you don't serialize all the things that were already touched. Only re-constructing lazy things on client side when needed. The only thing with 2nd approach is that you loose parent info, and you probably get different vfs context. But do we really care about that? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4158398#4158398 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4158398

16 years, 3 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: BCC in Mail Action

by koen.aers＠jboss.com

i just tagged the codebase if that gives you an idea... But i can't say today because then you will hold me onto that ;-) cheers, koen p.s. if you have a spare moment and would like to do a smoke test, please do View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4158386#4158386 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4158386

16 years, 3 months

1
0
0 / 0

[Design of JBossCache] - Re: JBoss Cache Public API

by bstansberry＠jboss.com

Just for some background on my comment on "create" being a legacy of the old JMX microkernel. Here's the content of the slide on create() from the JBoss Advanced course: anonymous wrote : Create is called when all bean I depend on are "created" | | When a service's create method is called | - This gives an MBean an opportunity to check that required MBeans or resources exist. | - The service typically cannot utilize other MBean services at this point, as most JBoss MBean services do not become fully functional until they have been started via their start method. | - Because of this, service implementations often do not implement create in favor of just the start method because that is the first point at which the service can be fully functional. The key bit is the "gives an MBean an opportunity to check that required MBeans or resources exist" comment. The create method was really an added step to get around the lack of dependency injection in early JBoss. An MBean couldn't have another MBean injected. Instead it would have an ObjectName or some other handle injected, and in create() would look up the dependency. Proper IOC removes the need for this. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4158383#4158383 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4158383

16 years, 3 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 June 2008