The database connection you're calling the stored procedure from is part of a distributed transaction. Individual participants in a distributed transaction cannot commit on their own, only the transaction coordinator can do that (otherwise the entire distributed transaction wouldn't be atomic). As Steve says, there is probably a Weblogic setting somewhere which turned distributed transactions on for you.
However, some people do say that stored procedures indeed shouldn't commit (Oracle even has a setting which causes all commits in the stored procedures to be silently ignored). I can think of these problems that can arise when calling stored procedures with commits:
1) You cannot use distributed transactions.
2) The caller (eg. a Java application) cannot build a larger transaction by calling several of your procedures in sequence, since the unwanted commit cannot be avoided by the caller.
3) You won't be able to use frameworks that control transactions (eg. through annotations) - again, because there are commits outside of the control of the framework.
And while the first case causes an error to be thrown (the ORA-02089 you got), the other two cases don't cause any errors, but result into a broken logic, which, furthermore, will surface only when there is a rollback - the committed part won't get rolled back and you'll probably end up having slightly corrupted data. I wouldn't want to be the one to look for the cause.