I finally got time to publish proof of concept for Maven2 build files.
Check out the code:
svn co svn://adempieretech.org/trunk
I also have maven repository (http://adempieretech.org/maven2repo) for those dependencies which can not be found from official maven repository.
Currently there is build files for following subprojects: tools, looks, base, client, serverRoot and ear subproject which builds ear package.
Dependencies work and project compiles fine. Source files are linked (svn:externals) from adempiere trunk. Of course some code changes are needed to make Adempiere actually run just by dropping ear in container.
So far just POC, but something good might come out if I find time to make needed code changes and configure Cargo (cargo.codehaus.org) for Adempiere.
-kontro-
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Most important thing for me were to get rid of 'jboss', 'install', 'utils_dev' and 'tools/lib' directories. There some stuff I want to work with, but can not do it before I get Adempiere on JEE5 server.
Last night I started the work with webstart maven plugin - to automagicly build jnlp file and war package for it.
OSGI does not interest me so much as I don't see it as much as developer tool. And since security is still so bad that no one should use Adempiere in production - I have little use for implementation tools :P
-kontro-
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
> OSGI does not interest me so much as I don't see it as much as developer tool. And since security is still so bad that no one should use Adempiere in production - I have little use for implementation tools :P
Got some feedback about that sentence, from person whose opinions I have learned to respect.
It seems that old habits die hard..
Sorry Trifon my intention were not to throw flame back to your face :(
-kontro, member of Evil Idiots Without Borders club-
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
>Got some feedback about that sentence, from person whose opinions I have learned
>to respect.
>It seems that old habits die hard..
>
>Sorry Trifon my intention were not to throw flame back to your face :(
>
>-kontro, member of Evil Idiots Without Borders club-
Timo, i do not say anything. I just say thank you for the contribution.
Please route the sorry to the appropriate people.
Kind regards,
Trifon
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Maven build (compile, pack) works, now doing deploying stuff.
I have organized my repository so that I do not commit changed sources in there, but I use maven patch plugin (which does not work on windows).
If someone likes to check out the repository - I recommend using 'svn co --ignore-externals svn://adempieretech.org/trunk' then size is only couple hundred kilobytes.
Currently making it to run in glassfish and geronimo so that DataSource is container managed and client is deployed as 'J2EE application client'. Not all working yet, but just telling if someone is interested where I am heading. Also changed jdbc code to use dynamic proxies, so that what comes to jdbc both java 5 and 6 work and can be used for compiling. Since database connection is shared using JNDI and configured using container tools lot of code is cleaned away. Most of that clean up is done quite messy way, so I have plenty of polishing ahead of me.
Not caring about JBoss compatibility yet since there is no JEE5 version of JBoss yet and jboss's support fro j2ee app clients is quite thin.
-kontro-
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
1. DataSource can be found using JNDI by name "jdbc/AdempiereDS" on both client and server side.
2. Running Adempiere instance does not know database connection parameters.
3. Connection pooling and DataSource configuration is handled by container (both on client and server side)
4. ClassName of AdempiereDatabase implementation (for stuff like 'convertStatement')can be acquired by JNDI and is configured by container admin panel.
5. Any JEE5 container works.
6. It is easy to install multiple adempiere instances on same server.
Tried this many times before (since december 2006), but this time I am closer than ever.
Stupid to talk about this before it is really 'Ready', but blame Bahman he encouraged me to share this while it is hatched.
And red1 is also to be blamed - he said couple months ago that he 'misses my contributions'.
Real leader does not need to command people - just making wishes is enough :D
-kontro-
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
You will save time if you review it later when things are not so scattered.
I have some difficulties to understand how Trx class is supposed to work.
Maybe you (or someone else) can help me and answer to these:
Now that I have container managed DataSource and connection pooling logic can not be handled manually.
1. Is plain DataSource enough or should XADataSource and XATransaction be used ?
2. Is there situations where same java thread has multiple separate transactions open ?
3. Does Trx class provide something which can not be done by using javax.transaction.UserTransaction ?
-kontro-
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Before deploying that ear onto server following objects need to be configured using container's management tools:
-datasource pool named 'AdempiereDS'
- security real named 'adempiereRealm'
In that security realm usernames must be same than those in adempiere database.
How to start application client depends on container. Glassfish provides webstart automaticly. Geronimo provides client.jar library and client.sh script for that.
Advantages:
- zero database configuration needed at client side
- client side code does not know database credentials
- deployment and configuration tools provided by server provider
- In j2ee5 server exposing adempiere functionality as webservice is really easy.
- All server resources available both client and server side (mail sessions, messaging, web-service, monitoring) etc.
- Simplifies code a lot.
This is all database configuration needed in Adempiere code:
public static CConnection get() {
if (s_cc == null) {
try {
s_cc = new CConnection();
InitialContext ic = new InitialContext();
s_cc.m_ds = (DataSource) ic.lookup("java:comp/env/jdbc/AdempiereDS");
Connection c = s_cc.m_ds.getConnection();
if (c.getMetaData().getDatabaseProductName().toLowerCase().contains("postgresql")) {
s_cc.m_db = new DB_PostgreSQL();
} else {
s_cc.m_db = new DB_Oracle();
}
c.close();
c = null;
} catch (Exception e) {
throw new RuntimeException("Failed to get database connection", e);
}
}
return s_cc;
}
-kontro-
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
This sounds interesting, I think there might be others that would like to help but the info available at the moment is rather limited.
Maybe you can put up a wiki page on the status and areas that need further work ?
If you want, may be it is good to maintain this as a new branch in the Adempiere svn ( I think jee is a good name for the branch ). I imaging we can have 2 architecture to co-exists for sometime ( "classic" and "jee" ) - there are peoples that will prefer/need to work on the current code base and there will be others that would like to move on to a more "jee" oriented environment.
Regards,
Low
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I see this improvement important for WebClient projects too. Because of backward compatibility issues webclients can not use all resources available in container.
With this architecture webclients can use messaging or any other container services and swing client can easily to be made support those too.
To point out that currently there is no other jee services used than how DataSource is deployed in JNDI. If someone wants to use same code but not jee server that is ok if standalone JNDI (simple jndi for example) service is set up and datasource bound to it before starting the application.
But seriously removing more than 10000 (not counted just guessing) lines of code and replacing it with container management panel speeds up development and makes it easier for newbies to catch up.
Also since client container handles authentication any method container support is fine for Adempiere client (ldap, properties files, jdbc, kerberos, active directory) without code changes.
About using adempiere svn - it is ok to me...
I will provide screencast about deployment on Geronimo when I get swing stuff working better (Not my expertise field, but hight time to learn).
After that I am planning to replace server side processes with ejb timer implementation instead of managing threads by hand. That allows usage of container tools for monitoring those.
And of course making Email stuff to use container provided mail services to get rid of some com.sun dependencies.
Many nice things, but there are obstacles too. Knowing your container is important those behave bit differently. And using DataSource resource-ref from application client is not one of the best documented or most recommended features. It is supported because Java EE5 platform requires so, but certainly it is not the most polished feature (But beats Adempiere's current implementation anyway).
Anyway this is important step for me towards fixing that age old 'no authorization' issue.
P.S. I replaced CStatement and CPreparedStatement with dynamic proxies so now those work both on jdk 5 and 6 without modifications.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I finally got time to publish proof of concept for Maven2 build files.
Check out the code:
svn co svn://adempieretech.org/trunk
I also have maven repository (http://adempieretech.org/maven2repo) for those dependencies which can not be found from official maven repository.
Currently there is build files for following subprojects: tools, looks, base, client, serverRoot and ear subproject which builds ear package.
Dependencies work and project compiles fine. Source files are linked (svn:externals) from adempiere trunk. Of course some code changes are needed to make Adempiere actually run just by dropping ear in container.
So far just POC, but something good might come out if I find time to make needed code changes and configure Cargo (cargo.codehaus.org) for Adempiere.
-kontro-
Hi Timo,
>I finally got time to publish proof of concept for Maven2 build files.
>
>Check out the code:
>
>svn co svn://adempieretech.org/trunk
Very nice news!
Thank you for sharing it with us and welcome back to Adempiere!
By the way do you know that Adempiere has OSGi intergation. It is just a PoC, but is very nice step in the good direction.
Kind regards,
Trifon
Hi Trifon.
Most important thing for me were to get rid of 'jboss', 'install', 'utils_dev' and 'tools/lib' directories. There some stuff I want to work with, but can not do it before I get Adempiere on JEE5 server.
Last night I started the work with webstart maven plugin - to automagicly build jnlp file and war package for it.
OSGI does not interest me so much as I don't see it as much as developer tool. And since security is still so bad that no one should use Adempiere in production - I have little use for implementation tools :P
-kontro-
> OSGI does not interest me so much as I don't see it as much as developer tool. And since security is still so bad that no one should use Adempiere in production - I have little use for implementation tools :P
Got some feedback about that sentence, from person whose opinions I have learned to respect.
It seems that old habits die hard..
Sorry Trifon my intention were not to throw flame back to your face :(
-kontro, member of Evil Idiots Without Borders club-
Hi Timo,
>Got some feedback about that sentence, from person whose opinions I have learned
>to respect.
>It seems that old habits die hard..
>
>Sorry Trifon my intention were not to throw flame back to your face :(
>
>-kontro, member of Evil Idiots Without Borders club-
Timo, i do not say anything. I just say thank you for the contribution.
Please route the sorry to the appropriate people.
Kind regards,
Trifon
Maven build (compile, pack) works, now doing deploying stuff.
I have organized my repository so that I do not commit changed sources in there, but I use maven patch plugin (which does not work on windows).
If someone likes to check out the repository - I recommend using 'svn co --ignore-externals svn://adempieretech.org/trunk' then size is only couple hundred kilobytes.
Currently making it to run in glassfish and geronimo so that DataSource is container managed and client is deployed as 'J2EE application client'. Not all working yet, but just telling if someone is interested where I am heading. Also changed jdbc code to use dynamic proxies, so that what comes to jdbc both java 5 and 6 work and can be used for compiling. Since database connection is shared using JNDI and configured using container tools lot of code is cleaned away. Most of that clean up is done quite messy way, so I have plenty of polishing ahead of me.
Not caring about JBoss compatibility yet since there is no JEE5 version of JBoss yet and jboss's support fro j2ee app clients is quite thin.
-kontro-
Or maybe to explain things simpler way.
I am quite close to system where:
1. DataSource can be found using JNDI by name "jdbc/AdempiereDS" on both client and server side.
2. Running Adempiere instance does not know database connection parameters.
3. Connection pooling and DataSource configuration is handled by container (both on client and server side)
4. ClassName of AdempiereDatabase implementation (for stuff like 'convertStatement')can be acquired by JNDI and is configured by container admin panel.
5. Any JEE5 container works.
6. It is easy to install multiple adempiere instances on same server.
Tried this many times before (since december 2006), but this time I am closer than ever.
Stupid to talk about this before it is really 'Ready', but blame Bahman he encouraged me to share this while it is hatched.
And red1 is also to be blamed - he said couple months ago that he 'misses my contributions'.
Real leader does not need to command people - just making wishes is enough :D
-kontro-
Hi Timo,
enhancements sounds really great.
Hope to find some time to review it and help with the code.
Kind regards,
Trifon
Thanks Trifon
You will save time if you review it later when things are not so scattered.
I have some difficulties to understand how Trx class is supposed to work.
Maybe you (or someone else) can help me and answer to these:
Now that I have container managed DataSource and connection pooling logic can not be handled manually.
1. Is plain DataSource enough or should XADataSource and XATransaction be used ?
2. Is there situations where same java thread has multiple separate transactions open ?
3. Does Trx class provide something which can not be done by using javax.transaction.UserTransaction ?
-kontro-
It seems that adempieretech.org domain ran out of batteries.
But tb4smb.org points to same server: svn co svn://adempieretech.org/trunk
-kontro-
Now I got it running - some Swing tweaking still needed though.
I have lan-profile only version which is deployed as j2ee application client.
I have tested it using geronimo 2.1, but any container will do just by adding container spesific deployment descriptors.
Repository is: svn://tb4smb.org/trunk
Executing 'mvn install' produces 'ear/target/adempieretech-3.5.0-SNAPSHOT.ear' file.
Before deploying that ear onto server following objects need to be configured using container's management tools:
-datasource pool named 'AdempiereDS'
- security real named 'adempiereRealm'
In that security realm usernames must be same than those in adempiere database.
How to start application client depends on container. Glassfish provides webstart automaticly. Geronimo provides client.jar library and client.sh script for that.
Advantages:
- zero database configuration needed at client side
- client side code does not know database credentials
- deployment and configuration tools provided by server provider
- In j2ee5 server exposing adempiere functionality as webservice is really easy.
- All server resources available both client and server side (mail sessions, messaging, web-service, monitoring) etc.
- Simplifies code a lot.
This is all database configuration needed in Adempiere code:
public static CConnection get() {
if (s_cc == null) {
try {
s_cc = new CConnection();
InitialContext ic = new InitialContext();
s_cc.m_ds = (DataSource) ic.lookup("java:comp/env/jdbc/AdempiereDS");
Connection c = s_cc.m_ds.getConnection();
if (c.getMetaData().getDatabaseProductName().toLowerCase().contains("postgresql")) {
s_cc.m_db = new DB_PostgreSQL();
} else {
s_cc.m_db = new DB_Oracle();
}
c.close();
c = null;
} catch (Exception e) {
throw new RuntimeException("Failed to get database connection", e);
}
}
return s_cc;
}
-kontro-
Hi kontro,
This sounds interesting, I think there might be others that would like to help but the info available at the moment is rather limited.
Maybe you can put up a wiki page on the status and areas that need further work ?
If you want, may be it is good to maintain this as a new branch in the Adempiere svn ( I think jee is a good name for the branch ). I imaging we can have 2 architecture to co-exists for sometime ( "classic" and "jee" ) - there are peoples that will prefer/need to work on the current code base and there will be others that would like to move on to a more "jee" oriented environment.
Regards,
Low
Hello Hengsin.
I see this improvement important for WebClient projects too. Because of backward compatibility issues webclients can not use all resources available in container.
With this architecture webclients can use messaging or any other container services and swing client can easily to be made support those too.
To point out that currently there is no other jee services used than how DataSource is deployed in JNDI. If someone wants to use same code but not jee server that is ok if standalone JNDI (simple jndi for example) service is set up and datasource bound to it before starting the application.
But seriously removing more than 10000 (not counted just guessing) lines of code and replacing it with container management panel speeds up development and makes it easier for newbies to catch up.
Also since client container handles authentication any method container support is fine for Adempiere client (ldap, properties files, jdbc, kerberos, active directory) without code changes.
About using adempiere svn - it is ok to me...
I will provide screencast about deployment on Geronimo when I get swing stuff working better (Not my expertise field, but hight time to learn).
After that I am planning to replace server side processes with ejb timer implementation instead of managing threads by hand. That allows usage of container tools for monitoring those.
And of course making Email stuff to use container provided mail services to get rid of some com.sun dependencies.
Many nice things, but there are obstacles too. Knowing your container is important those behave bit differently. And using DataSource resource-ref from application client is not one of the best documented or most recommended features. It is supported because Java EE5 platform requires so, but certainly it is not the most polished feature (But beats Adempiere's current implementation anyway).
Anyway this is important step for me towards fixing that age old 'no authorization' issue.
P.S. I replaced CStatement and CPreparedStatement with dynamic proxies so now those work both on jdk 5 and 6 without modifications.