Tim Cockle

Greenhorn
+ Follow
since Oct 25, 2005
Merit badge: grant badges
For More
Cows and Likes
Cows
Total received
0
In last 30 days
0
Total given
0
Likes
Total received
0
Received in last 30 days
0
Total given
0
Given in last 30 days
0
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Tim Cockle

Well I was really hoping I could say B (pink) mainly because she is fun and sexy and that is what I like (and may be if you are in the right mood, the moon is correctly positions and you have just got that new how to work so is Java). I also had some good ideas to why I thought I would have to say B (pink) as well. For starters whenever I reflect on the gender bias in software development the first thing I think of is Lady Ada Lovelace working with Charles Babbage on the Analytical Engine, she had a fantastic mind and to think that programming was first driven forward by a lady (in both senses) has always made me think about preconceptions. Also with Byron as a dad I better if you got to know her you could and gate crashed some amazing parties! In a similar way I remember talk to my dad about the computing industry when he started. He has always said that before the computing degrees he always employed a significant number of English language students as they understood the art of concise logical paragraphs that individually performed a specific task but as a group produce a complex argument or story, that they understood the importance of grammar, structure and style consistency. So from the start of computing I see a significant female involvement. Furthermore from my own experiences in a small software development group I have often found the lack of a feminine perspective. That is not to say the view of a woman, but a view that is less a list of bullet points and more empathic and role based. It is true that a male can provide this view point, in fact when discussing details with female clients I will normally adopt a more feminine view point. However back in the office this can be easily lost, err and let�s face it, a female is more likely to be feminine. So I would like to have that balance redressed

So why not F Green then, well this is my next point to why I was hopping I would choose B. I feel that Green is a little too nerdy (oh and nerdy rather then geeky). The green tank-top is not even tomboy-esk it is just nerdy, I don�t think in a particularly ironic way either. With this in mind and with the knowledge that good research most be a test of endurance and hard work I ask a group of attractive young females (mainly dancers, film students and English students) who were reading a glossy �woman�s interest� magazine why they would choose one magazine over another. They said that it was generally the cover that won them over, furthermore that given the option it would be some one like Pink that tempted them rather then Green. (On a side note I have often though as a straight male I am very lucky that both men�s and women�s magazines are covered with beautiful women� Odd then that I generally buy computer magazines, with a box on the front or a scientific magazine normally with some exciting pictures from a deep space probe on them). You see deep down I think that Green is acting all nerdy not because that is her but in the hope that nerdy guys will be a little more desperate and even though she is attractive her low self-esteem will not let her except that. So Green is not the cover for me.

All was going well then for my selection of Pink, I then took a look to refresh my memory on the other covers. For starters then there are 3 females to 2 males, so the more women argument is not looking to good. Most of all though they are all basically white, which I don�t think is a good message to portray to people new to development. I then spoke to a friend who worked first in production and then in sales of books for one of the largest publishing houses. Her job in particular is coordinating international sales, tweaking covers for the different markets. Now she told me some disturbing news about the effect of ethnicity on book sales, I don�t want to go into them as although I believe them to be true, I don�t have to hand empirical information. However I think we are on solid ground with the options we have. So here goes, time for me to make a decision.

I think we should go for A brown, I think he looks professional but relaxed and easy to talk to. His clothes are not formal but at the same time have a sense of individual style and confidence.

Finally on a slightly foolish comment but WTF is going on with C freaking head it�s massive. I hope he doesn�t ever use a pencil sharpener as that huge melon is going to keep the shavings in orbit. I mean going to a fancy dress parties does he just paint his head red and go as a balloon. Everyone is entitled to their opinion but if anyone says C they are wrong and probable suffering from some strange psychological attachments to that huge white ball from the prisoner (http://www.jetsetmodern.com/images2/prisonerrover6.gif)

Tim

PS sorry this was a bit long wasn�t it� perhaps I should of just said A at the start
18 years ago
I use xdoctlet that creates the remote and local interfaces for me. Then all i do is set the jndi context on my client i.e.

Hashtable jndiSettings = new Hashtable();
jndiSettings.put(Context.INITIAL_CONTEXT_FACTORY, "org.jnp.interfaces.NamingContextFactory");
jndiSettings.put(Context.URL_PKG_PREFIXES, "org.jboss.naming rg.jnp.interfaces");
jndiSettings.put(Context.PROVIDER_URL, url);

and then get the home interface as I would if it were local(home):
mySession = MySessionUtil.getHome(jndiSettings).create();

In side the util class made by xdoclet I have...


public static alpha.MySessionHome getHome( java.util.Hashtable environment ) throws javax.naming.NamingException
{
// Obtain initial context
javax.naming.InitialContext initialContext = new javax.naming.InitialContext(environment);
try {
java.lang.Object objRef = initialContext.lookup(alpha.MySessionHome.JNDI_NAME);
return (alpha.MySessionHome) javax.rmi.PortableRemoteObject.narrow(objRef, alpha.MySessionHome.class);
} finally {
initialContext.close();
}
}

hope this helps
Hi all, I hope you can help, I have been stuck on the same problem for a day now!!!

I am using Jboss 3.2.1, middlegen and Xdoclet.

I have a set of entity beans and a few session beans. I have created a session bean with a remote interface that is used by a remote client.

The client logs on using the logincontext then uses the remote interface of a session bean to preform a series of tasks. Basically this will be:
Look for a Person Entity Bean
Create a new Diary Entity Bean

I use Xdoclet to secure the session bean by adding the following to the different method comments:
* @ejb.permission role-name="pda_user"
* view-type="remote"

And use middlegen �cmp20-ALL-class-comments.txt� to add the following to the entity beans
*
* @ejb.permission unchecked="true"
*

The client logs in fine,
It access the session bean
The session bean uses the PersonLocalHome interface to search for a person (this will not work if I remove the middlegen comments)
The sesson bean user the PersonLocal interface to access the person's name

However, when the session tries to call create() from DiaryLocalHome I get:
java.lang.SecurityException: No method permissions assigned to method=create, interface=LOCALHOME
at org.jboss.ejb.plugins.SecurityInterceptor.checkSecurityAssociation(SecurityInterceptor.java:179)
at org.jboss.ejb.plugins.SecurityInterceptor.invokeHome(SecurityInterceptor.java:81)
at org.jboss.ejb.plugins.LogInterceptor.invokeHome(LogInterceptor.java:120)
at org.jboss.ejb.plugins.ProxyFactoryFinderInterceptor.invokeHome(ProxyFactoryFinderInterceptor.java:93)
at org.jboss.ejb.StatelessSessionContainer.internalInvokeHome(StatelessSessionContainer.java:310)
at org.jboss.ejb.Container.invoke(Container.java:694)
at org.jboss.ejb.plugins.local.BaseLocalProxyFactory.invokeHome(BaseLocalProxyFactory.java:272)
at org.jboss.ejb.plugins.local.LocalHomeProxy.invoke(LocalHomeProxy.java:110)
at $Proxy3649.create(Unknown Source)
at alpha.personEntities.DiaryBean.ejbCreate(Unknown Source)
etc...etc...etc...

The ejb-jar.xml has the following information (I am just including the interesting bits):


<security-role>
<description><![CDATA[description not supported yet by ejbdoclet]]></description>
<role-name>pda_user</role-name>
</security-role>

<method-permission >
<description><![CDATA[description not supported yet by ejbdoclet]]></description>
<unchecked/>
<method >
<description><![CDATA[description not supported yet by ejbdoclet]]></description>
<ejb-name>Person</ejb-name>
<method-name>*</method-name>
</method>
</method-permission>

<method-permission >
<description><![CDATA[description not supported yet by ejbdoclet]]></description>
<unchecked/>
<method >
<description><![CDATA[description not supported yet by ejbdoclet]]></description>
<ejb-name>Diary</ejb-name>
<method-name>*</method-name>
</method>
</method-permission>
<method-permission >
<description><![CDATA[description not supported yet by ejbdoclet]]></description>
<role-name>pda_user</role-name>
<method >
<description><![CDATA[]]></description>
<ejb-name>ReportLoader</ejb-name>
<method-intf>LocalHome</method-intf>
<method-name>create</method-name>
<method-params>
</method-params>
</method>
</method-permission>
<method-permission >
<description><![CDATA[description not supported yet by ejbdoclet]]></description>
<role-name>pda_user</role-name>
<method >
<description><![CDATA[]]></description>
<ejb-name>ReportLoader</ejb-name>
<method-intf>Home</method-intf>
<method-name>create</method-name>
<method-params>
</method-params>
</method>
</method-permission>
<method-permission >
<description><![CDATA[description not supported yet by ejbdoclet]]></description>
<role-name>pda_user</role-name>
<method >
<description><![CDATA[]]></description>
<ejb-name>ReportLoader</ejb-name>
<method-intf>Remote</method-intf>
<method-name>createReport</method-name>
<method-params>
<method-param>java.lang.String</method-param>
<method-param>java.lang.String</method-param>
<method-param>java.lang.String</method-param>
<method-param>java.lang.String</method-param>
<method-param>java.util.Date</method-param>
<method-param>java.util.Date</method-param>
<method-param>java.util.Date</method-param>
<method-param>java.util.Date</method-param>
</method-params>
</method>
</method-permission>
<method-permission >
<description><![CDATA[description not supported yet by ejbdoclet]]></description>
<role-name>pda_user</role-name>
<method >
<description><![CDATA[]]></description>
<ejb-name>ReportLoader</ejb-name>
<method-intf>Remote</method-intf>
<method-name>attachFile</method-name>
<method-params>
<method-param>byte[]</method-param>
<method-param>java.lang.String</method-param>
<method-param>int</method-param>
</method-params>
</method>
</method-permission>
<method-permission >
<description><![CDATA[description not supported yet by ejbdoclet]]></description>
<role-name>pda_user</role-name>
<method >
<description><![CDATA[]]></description>
<ejb-name>ReportLoader</ejb-name>
<method-intf>Remote</method-intf>
<method-name>commit</method-name>
<method-params>
</method-params>
</method>
</method-permission>

I have tried different configurations including giving the entity beans the same role-name. But they all come up with the same error. Interestingly I did at one point give the entity beans
a different role name. This gave a different error namely that the user did not have the correct role. When I added the role to the user the same error as now appeared.

Thanks in advance,

(My head hurts now)

Tim
I have the same problem using JBoss and middlegen and Xdoclet.
Did you solve the problem?

Thanks,

Tim
18 years ago